From zmoelnig at iem.at  Thu Nov  4 05:50:06 2004
From: zmoelnig at iem.at (zmoelnig at iem.at)
Date: Thu, 04 Nov 2004 05:50:06 +0100 (CET)
Subject: [GEM-dev] problem to start gem
In-Reply-To: <31065272.1099051739659.JavaMail.www@wwinf0303>
References: <31065272.1099051739659.JavaMail.www@wwinf0303>
Message-ID: <1099543806.4189b4fe4b47a@iem.at>

Quoting bastien beliah <bastien.beliah at wanadoo.fr>:

> Hello
hi

> have an error message: "I belive I'm in the wrong directory I thought
> that the pd-executable would be C:/programme/pd/bin/pd.exe please edit
> this file and set the PDPATH-variable appropriatly" I don't know exactly
> what to do.

well, i would propose to 
1) exactly read, what the message says
2) exactly do, what the message tells you to do.


open the GEM_INSTALL.bat file with your favourite text-editor end edit it: 
there ought to be a PDPATH-declaration somewhere at the top of that file which 
you have to adapt to your system.

> If someone could help me that would be really nice; thanks
> ps: I'm on pc (win XP) w/pd 0.37-3

and make sure, that you download the gem-bin-0.90.1.zip too: this has an 
important bug-fix for windos.


mfg.bht.rtj
IOhannes





From doelie at zzz.kotnet.org  Fri Nov  5 14:49:52 2004
From: doelie at zzz.kotnet.org (Tom Schouten)
Date: Fri, 5 Nov 2004 14:49:52 +0100
Subject: [GEM-dev] pf/pdp/3dp in Gem
Message-ID: <20041105134952.GC2636@zzz.i>

hi gemmers,

just talking with jamie here in bergen and it's pretty
clear to me how to write the bridge between libpdp and Gem.

practicly, for me it is the build system. i'd like to
add 5 objects. 3 of them are already in the pf/pd bridge.

* [gem.get <thing>] : forks off one gemstate object as pdp packet
* [gem.set <thing>] : inserts one pdp object in gem state
* [pdp <thing>] : generic pdp processors (functional maps)
* [3dp <thing] : 3d drawing objects (draw to current gl context)
* [pf <script>] : any pf script

the last 3 i have C code for and they don't depend on gem, but if
pf/pdp/3dp is running inside Gem they need to be included. 

the first 2 need to be written from scratch as gem objects,
possibly just derived from GemBase.

i suggest someone helps me with setting this up, by adding
templates for the gem.get and gem.set objects in the source
tree and add them to the build process. the names are of
course open to discussion. anything sane and short.

the rest i need is just an init callback.
this callback will:
* initialize the forth and pdp memory manager
* create the pf/pdp/3dp pd objects

maybe it is best to keep this optional, since it introduces
a library dependency.

so, who is motivated to help me out here by adding the
templates? i don't have time to learn the build and init process.

cheers
tom



From zmoelnig at iem.at  Sun Nov  7 19:42:33 2004
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Sun, 07 Nov 2004 19:42:33 +0100
Subject: [GEM-dev] problem to start gem
In-Reply-To: <13189920.1099665451535.JavaMail.www@wwinf0102>
References: <13189920.1099665451535.JavaMail.www@wwinf0102>
Message-ID: <418E6C99.7090306@iem.at>

hi

bastien beliah wrote:
>      > Thank you very much, but 
> 
>     1) exactly read, what the message says: I'm french but I've learn
>     english at school
this shouldn't be a problem; i am austrian and my english is far from 
being perfect too


> 
>      2) exactly do, what the message tells you to do: same answer
> 
>     anyway: I dont have any GEM_INSTALL.bat, I only have a GEM_INSTALL
>     Ms-Dos command...I don't think that it can be read whith a text
>     editor (I've tried but it doesn't worked). So: I don't know exactly
>     what to do....

allright (trying not to be rude about XP)
tell explorer to display filename-extensions: you will see that the 
"GEM_INSTALL Ms-Dos command" is in fact a "GEM_INSTALL.bat"-file
why are you not able to edit it ?
try right-clicking the file and use "Edit"
or try opening the notepad-application (should be somewhere in 
"utilities" or "extras") and open the file with it (you might have to 
tell notepad to open "any file" and not just "*.txt files")


please understand that i cannot give a full manual to such an 
error-prone OS as windos (to be fair: i cannot give a full manual to any 
OS); your problems are really with windos


mfg.a.rd
IOhannes






From zmoelnig at iem.at  Mon Nov  8 11:21:59 2004
From: zmoelnig at iem.at (Johannes M Zmoelnig)
Date: Mon, 08 Nov 2004 11:21:59 +0100
Subject: [GEM-dev] problem to start gem
In-Reply-To: <17945245.1099906395559.JavaMail.www@wwinf0802>
References: <17945245.1099906395559.JavaMail.www@wwinf0802>
Message-ID: <418F48C7.1010405@iem.at>

bastien beliah wrote:
> Hi, 
>
> Well, I finally open this GEM_INSTALL.bat but I still don't know what to do with it. 
> I do have a line on top of the message which says: set PDPATH=C:\programme\pd. What should I do? Edit it into the Pd search path?

ok, here we go:
i suppose you have pd installed on your computer; if not install it, as 
gem will not work without pd.
now remember where you have installed pd. if you don't know search for 
pd.exe.
on my system pd.exe is in "C:\Programme\pd\bin\pd.exe" : therefore my 
PDPATH is "C:\Programme\pd\" (just strip the last "bin\pd.exe")
if your pd.exe was "D:\puredata\bin\pd.exe", the PDPATH would be 
"D:\puredata"

now edit the line "set PDPATH=C:\programme\pd"
to "set PDPATH=D:\puredata"
(or whatever matches your installation)


mfg.a.sdr
IOhannes



From zmoelnig at iem.at  Mon Nov  8 13:26:11 2004
From: zmoelnig at iem.at (Johannes M Zmoelnig)
Date: Mon, 08 Nov 2004 13:26:11 +0100
Subject: [GEM-dev] problem to start gem
In-Reply-To: <22573790.1099915975541.JavaMail.www@wwinf0803>
References: <22573790.1099915975541.JavaMail.www@wwinf0803>
Message-ID: <418F65E3.4020807@iem.at>

hi.

this seems to me like a loop

bastien beliah wrote:
>  
> 
>>ok, here we go:
>>i suppose you have pd installed on your computer; if not install it, as 
>>gem will not work without pd.
>>now remember where you have installed pd. if you don't know search for 
>>pd.exe.
>>on my system pd.exe is in "C:\Programme\pd\bin\pd.exe" : therefore my 
>>PDPATH is "C:\Programme\pd\" (just strip the last "bin\pd.exe")
>>if your pd.exe was "D:\puredata\bin\pd.exe", the PDPATH would be 
>>"D:\puredata"
>>
>>now edit the line "set PDPATH=C:\programme\pd"
>>to "set PDPATH=D:\puredata"
>>(or whatever matches your installation)
>>
>>
>>mfg.a.sdr
>>IOhannes
> 
> OK! I had pd on my computer until the begingin (no problem with that) and  it's install in C:\Program Files\pd\bin\pd.exe (more or less like you I guess). So what should I do? Is that correct? should I change something? 

no, it is not like me
i have "C:\Programme\pd" instead of "C:\Program Files\pd"
i think this is a severe difference.
windows cannot (yet) translate filenames for you.

so set the line to read
	set PDPATH="C:\Program Files\pd"

you might need the quotes.
it might not work at all (because of the space between "Program" and 
"Files")
it would be better anyhow to install pd into a place without spaces: 
e.g. "C:\pd"


mfg.a.sdr
IOhannes




From zmoelnig at iem.at  Wed Nov 10 15:35:34 2004
From: zmoelnig at iem.at (Johannes M Zmoelnig)
Date: Wed, 10 Nov 2004 15:35:34 +0100
Subject: [GEM-dev] pf/pdp/3dp in Gem
In-Reply-To: <20041105134952.GC2636@zzz.i>
References: <20041105134952.GC2636@zzz.i>
Message-ID: <41922736.7030207@iem.at>

Tom Schouten wrote:
> hi gemmers,
> 


 >
 > so, who is motivated to help me out here by adding the
 > templates? i don't have time to learn the build and init process.

shouldn't be too much of a hazzle, so (i guess) i volunteer..

> 
> * [gem.get <thing>] : forks off one gemstate object as pdp packet
> * [gem.set <thing>] : inserts one pdp object in gem state


 > the names are of
 > course open to discussion. anything sane and short.

i'd rather have "pdp" somewhere in the name, as [gem.set] and [gem.get] 
could be anything (not necessarily related to pure data packets)

for me the most simple names i can think of right now are
[gem_pdp] : gem->pdp (or probably [gem_3dp] ?)
[pdp_gem] : pdp->gem


> 
> the first 2 need to be written from scratch as gem objects,
> possibly just derived from GemBase.
> 
> i suggest someone helps me with setting this up, by adding
> templates for the gem.get and gem.set objects in the source
> tree and add them to the build process. 

so what exactly should these do (aka: what do you want me to make them do) ?

how would a patch look like ?

<snip>
[gemhead]
|
[gem.get]
|
[pdp_noise]
|
[gem.set]
|
[pix_texture]
|
[square]
</snip>

and the pdp packet would just hold (additionally) the data of the 
gem_list (?)

and i guess, that [gem.get] should *not* output the gem_list anymore ?


sorry for being not into pdp-code ;-)

mfg.asd.r
IOhannes



From zmoelnig at iem.at  Fri Nov 12 10:57:59 2004
From: zmoelnig at iem.at (Johannes M Zmoelnig)
Date: Fri, 12 Nov 2004 10:57:59 +0100
Subject: [GEM-dev] pf/pdp/3dp in Gem
In-Reply-To: <41922736.7030207@iem.at>
References: <20041105134952.GC2636@zzz.i> <41922736.7030207@iem.at>
Message-ID: <41948927.3020200@iem.at>

Johannes M Zmoelnig wrote:
> Tom Schouten wrote:
>>
>> * [gem.get <thing>] : forks off one gemstate object as pdp packet
>> * [gem.set <thing>] : inserts one pdp object in gem state

on re-reading this appears to me rather like:

<snip>
[gemhead]
|
[gem.set noise]
|
[pix_texture]
|
[square]
</snip>

than

> <snip>
> [gemhead]
> |
> [gem.get]
> |
> [pdp_noise]
> |
> [gem.set]
> |
> [pix_texture]
> |
> [square]
> </snip>

is this correct ?

how would you use [gem.get] then ?


questions, questions,....


mfg.as.dr
IOhannes



From TimBlechmann at gmx.net  Mon Nov 22 13:10:55 2004
From: TimBlechmann at gmx.net (Tim Blechmann)
Date: Mon, 22 Nov 2004 13:10:55 +0100
Subject: [GEM-dev] pix_analyse_colors
Message-ID: <20041122131055.26380d75@laptop>

hi all ...

i wrote a small object that analyses the color channels of an image ...
nothing you can't build as abstraction with pix_histo, but faster
(both in terms of cpu speed and coding time) ... 
i know pix_analyse_colors is a stupid name, but no better one came to my
mind ...

feel free to add it to the cvs, if you are interested ... if not, is
there any way to build externals for gem that are distributed
seperately?

cheers ... tim

-- 
mailto:TimBlechmann at gmx.de    ICQ: 96771783
http://www.mokabar.tk

After one look at this planet any visitor from outer space 
would say "I want to see the manager."
				      William S. Burroughs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pix_analyse_colors.cpp
Type: text/x-c++src
Size: 2745 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20041122/e092c87a/attachment.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pix_analyse_colors.h
Type: text/x-chdr
Size: 1580 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20041122/e092c87a/attachment.h>

From zmoelnig at iem.at  Tue Nov 23 09:02:33 2004
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Tue, 23 Nov 2004 09:02:33 +0100
Subject: [GEM-dev] pix_analyse_colors
In-Reply-To: <20041122131055.26380d75@laptop>
References: <20041122131055.26380d75@laptop>
Message-ID: <41A2EE99.2000605@iem.at>

Tim Blechmann wrote:
> hi all ...
> 
> i wrote a small object that analyses the color channels of an image ...
> nothing you can't build as abstraction with pix_histo, but faster
> (both in terms of cpu speed and coding time) ... 
> i know pix_analyse_colors is a stupid name, but no better one came to my
> mind ...

hi tim.

thanks for the code.
i am still wondering whether it wouldn't be better to make this 
behaviour with a new (and working) version of [pix_resize] and 
[pix_dump] (i mean: if [pix_resize] would take arguments for the new 
size and this size could be 1x1 *and* the resizing would do 
interpolation than this would do almost the same as [pix_analyse_colors] 
(i think it is rather [pix_mean_color], but who cares) and it would be 
more flexible (finally the object we need to mix/merge/... images of 
different sizes)

we could then have a look at performance and eventually include it as an 
abstraction.

but thanks anyhow.
btw, have you tested the greyscale code ?


> 
> feel free to add it to the cvs, if you are interested ... if not, is
> there any way to build externals for gem that are distributed
> seperately?

this is possible (but in this case you haveis quite an elementary object 
that should rather go into Gem itself)
under linux it is simple, on windows you probably now better than me 
(when i started to compile my own Gem objects i didn't bother to make 
them separate externals but rather built my whole Gem++, just because i 
was to lazy/stupid; later i became maintainer and the problem was gone)


mfg.a.sdr
IOhannes



From TimBlechmann at gmx.net  Tue Nov 23 13:26:36 2004
From: TimBlechmann at gmx.net (Tim Blechmann)
Date: Tue, 23 Nov 2004 13:26:36 +0100
Subject: [GEM-dev] pix_analyse_colors
In-Reply-To: <41A2EE99.2000605@iem.at>
References: <20041122131055.26380d75@laptop>
	<41A2EE99.2000605@iem.at>
Message-ID: <20041123132636.2a6dcec9@laptop>

> i am still wondering whether it wouldn't be better to make this 
> behaviour with a new (and working) version of [pix_resize] and 
> [pix_dump] (i mean: if [pix_resize] would take arguments for the new 
> size and this size could be 1x1 *and* the resizing would do 
> interpolation than this would do almost the same as
> [pix_analyse_colors] (i think it is rather [pix_mean_color], but who
> cares) and it would be more flexible (finally the object we need to
> mix/merge/... images of different sizes)
you are right with the name ... 

> we could then have a look at performance and eventually include it as
> an abstraction.
right ... at the moment pix_histo / pix_dump would imply quite some pd
message handling overhead ...

> but thanks anyhow.
> btw, have you tested the greyscale code ?
works on my machine ...

> this is possible (but in this case you haveis quite an elementary
> object that should rather go into Gem itself)
> under linux it is simple, on windows you probably now better than me 
hm ... i might have a look into it ... but not today ...

btw, i don't think, you judge me right ... i'm not really a windoze ...
hacker ... in fact the whole asio code was written on linux with a smb
connection to win ...

cheers ... tim

-- 
mailto:TimBlechmann at gmx.de    ICQ: 96771783
http://www.mokabar.tk

After one look at this planet any visitor from outer space 
would say "I want to see the manager."
				      William S. Burroughs



From simi at quirxi.net  Tue Nov 23 12:16:02 2004
From: simi at quirxi.net (simi at quirxi.net)
Date: Tue, 23 Nov 2004 12:16:02 +0100 (CET)
Subject: [GEM-dev] movie und transparenz
Message-ID: <20041123111602.F1FB065E30@basicbox7.server-home.net>

Hi;
kann mir jemand erkl?ren, ob man den alphakanal von einem bild  und ein
movie texturen kann?
dake





From doelie at zzz.kotnet.org  Tue Nov 23 13:02:56 2004
From: doelie at zzz.kotnet.org (Tom Schouten)
Date: Tue, 23 Nov 2004 13:02:56 +0100
Subject: [GEM-dev] pf/pdp/3dp in Gem
In-Reply-To: <41922736.7030207@iem.at>
References: <20041105134952.GC2636@zzz.i> <41922736.7030207@iem.at>
Message-ID: <20041123120256.GA12325@zzz.i>

> >
> > so, who is motivated to help me out here by adding the
> > templates? i don't have time to learn the build and init process.
> 
> shouldn't be too much of a hazzle, so (i guess) i volunteer..
>

thanks johannes!

 
> >
> >* [gem.get <thing>] : forks off one gemstate object as pdp packet
> >* [gem.set <thing>] : inserts one pdp object in gem state
> 
> 
> > the names are of
> > course open to discussion. anything sane and short.
> 
> i'd rather have "pdp" somewhere in the name, as [gem.set] and [gem.get] 
> could be anything (not necessarily related to pure data packets)
> 
> for me the most simple names i can think of right now are
> [gem_pdp] : gem->pdp (or probably [gem_3dp] ?)
> [pdp_gem] : pdp->gem
> 

since it's really only 'get' and 'set' (just about exchainging data
with a gem render chain) i think this should be clear in the name.

the object qualify as 'gem chain objects' not pdp objects. so [pdp_xxx]
seems confusing.


> >
> >the first 2 need to be written from scratch as gem objects,
> >possibly just derived from GemBase.
> >
> >i suggest someone helps me with setting this up, by adding
> >templates for the gem.get and gem.set objects in the source
> >tree and add them to the build process. 
> 
> so what exactly should these do (aka: what do you want me to make them do) ?
> 
> how would a patch look like ?
> 
> <snip>
> [gemhead]
> |
> [gem.get]
> |
> [pdp_noise]
> |
> [gem.set]
> |
> [pix_texture]
> |
> [square]
> </snip>
> 

a getter would look like:

[gemhead]
|
[gem.get pixbuf]
|	       |
|              [pdp_gain 2.0]
|              |
|              [pdp_blur]
|              |
[gem.set pixbuf]
|
[pix_texture]
|
[square]


this would fork off the pixbuf as a pdp packet,
then process it using pdp_gain and pdp_blur, and
insert it back into gemstate.



> and the pdp packet would just hold (additionally) the data of the 
> gem_list (?)
> 
> and i guess, that [gem.get] should *not* output the gem_list anymore ?
> 

i think it should, because the get/set objects are really renderchain
objects.



From zmoelnig at iem.at  Tue Nov 23 13:06:19 2004
From: zmoelnig at iem.at (Johannes M Zmoelnig)
Date: Tue, 23 Nov 2004 13:06:19 +0100
Subject: [GEM-dev] movie und transparenz
In-Reply-To: <20041123111602.F1FB065E30@basicbox7.server-home.net>
References: <20041123111602.F1FB065E30@basicbox7.server-home.net>
Message-ID: <41A327BB.9080500@iem.at>

simi at quirxi.net wrote:
> Hi;
> kann mir jemand erkl?ren, ob man den alphakanal von einem bild  und ein
> movie texturen kann?
> dake

hi.
please note that the language of this list is english.

anyhow, i do not really understand your question.
using the alpha-channel should not be a problem. however, you have to 
turn on alpha-blending with the [alpha] object.
i don't know whether there are any movie-formats that support the 
alpha-channel (mpeg surely does not; AVI might, but i don't think that 
Gem/win32 is able to handle it; QuickTime might, and if so, Gem will 
most probably support it)

mfg.a.sdr
IOhannes



From zmoelnig at iem.at  Tue Nov 23 13:33:53 2004
From: zmoelnig at iem.at (Johannes M Zmoelnig)
Date: Tue, 23 Nov 2004 13:33:53 +0100
Subject: [GEM-dev] pf/pdp/3dp in Gem
In-Reply-To: <20041123120256.GA12325@zzz.i>
References: <20041105134952.GC2636@zzz.i> <41922736.7030207@iem.at> <20041123120256.GA12325@zzz.i>
Message-ID: <41A32E31.3020701@iem.at>

Tom Schouten wrote:

>>
>>i'd rather have "pdp" somewhere in the name, as [gem.set] and [gem.get] 
>>could be anything (not necessarily related to pure data packets)
>>
>>for me the most simple names i can think of right now are
>>[gem_pdp] : gem->pdp (or probably [gem_3dp] ?)
>>[pdp_gem] : pdp->gem
>>
> 
> 
> since it's really only 'get' and 'set' (just about exchainging data
> with a gem render chain) i think this should be clear in the name.
> 
> the object qualify as 'gem chain objects' not pdp objects. so [pdp_xxx]
> seems confusing.

true.
still i think that "pdp" should be in the name too, as [gem_set] 
wouldn't necessarily have something to do with pdp packages.
so probably [gem_pdpout} and [gem_pdpin] would be more apropriate ?
(or [gem_pdp.out] and [gem_pdp.in])


> a getter would look like:
> 
> [gemhead]
> |
> [gem.get pixbuf]
> |	       |
> |              [pdp_gain 2.0]
> |              |
> |              [pdp_blur]
> |              |
> [gem.set pixbuf]
> |
> [pix_texture]
> |
> [square]
> 
> 
> this would fork off the pixbuf as a pdp packet,
> then process it using pdp_gain and pdp_blur, and
> insert it back into gemstate.

thanks for the clarification

> 
> 
> 
> 
>>and the pdp packet would just hold (additionally) the data of the 
>>gem_list (?)
>>
>>and i guess, that [gem.get] should *not* output the gem_list anymore ?
>>
> 
> 
> i think it should, because the get/set objects are really renderchain
> objects.

which is clear from your sketch.


so the templates are almost done; just want to settle the name before i 
check them in



mfg.a.sdr
IOhannes



From TimBlechmann at gmx.net  Tue Nov 23 16:17:52 2004
From: TimBlechmann at gmx.net (Tim Blechmann)
Date: Tue, 23 Nov 2004 16:17:52 +0100
Subject: [GEM-dev] pix_analyse_colors
In-Reply-To: <41A2EE99.2000605@iem.at>
References: <20041122131055.26380d75@laptop>
	<41A2EE99.2000605@iem.at>
Message-ID: <20041123161752.00ce7491@laptop>

> [pix_analyse_colors] (i think it is rather [pix_mean_color], but who
> cares) and it would be more flexible (finally the object we need to
> mix/merge/... images of different sizes)
renamed and added (empty callback again)

tim

-- 
mailto:TimBlechmann at gmx.de    ICQ: 96771783
http://www.mokabar.tk

After one look at this planet any visitor from outer space 
would say "I want to see the manager."
				      William S. Burroughs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pix_mean_color.cpp
Type: text/x-c++src
Size: 2774 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20041123/e4fbc988/attachment.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pix_mean_color.h
Type: text/x-chdr
Size: 1551 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20041123/e4fbc988/attachment.h>

From doelie at zzz.kotnet.org  Wed Nov 24 11:29:40 2004
From: doelie at zzz.kotnet.org (Tom Schouten)
Date: Wed, 24 Nov 2004 11:29:40 +0100
Subject: [GEM-dev] pf/pdp/3dp in Gem
In-Reply-To: <41A32E31.3020701@iem.at>
References: <20041105134952.GC2636@zzz.i> <41922736.7030207@iem.at> <20041123120256.GA12325@zzz.i> <41A32E31.3020701@iem.at>
Message-ID: <20041124102940.GH29960@zzz.i>

> >since it's really only 'get' and 'set' (just about exchainging data
> >with a gem render chain) i think this should be clear in the name.
> >
> >the object qualify as 'gem chain objects' not pdp objects. so [pdp_xxx]
> >seems confusing.
> 
> true.
> still i think that "pdp" should be in the name too, as [gem_set] 
> wouldn't necessarily have something to do with pdp packages.
> so probably [gem_pdpout} and [gem_pdpin] would be more apropriate ?
> (or [gem_pdp.out] and [gem_pdp.in])
> 
> 
...
> 
> 
> so the templates are almost done; just want to settle the name before i 
> check them in
>


[gem_pdp.out] and [gem_pdp.in] seem ok to me

or even

[out_pdp] and [in_pdp] to keep them shorter, since most gem
objects don't have a gem_ prefix.

yeah, politics!





From ben at ekran.org  Wed Nov 24 17:09:46 2004
From: ben at ekran.org (B. Bogart)
Date: Wed, 24 Nov 2004 11:09:46 -0500 (EST)
Subject: [GEM-dev] pf/pdp/3dp in Gem
In-Reply-To: <20041124102940.GH29960@zzz.i>
References: <20041105134952.GC2636@zzz.i> <41922736.7030207@iem.at>
    <20041123120256.GA12325@zzz.i> <41A32E31.3020701@iem.at>
    <20041124102940.GH29960@zzz.i>
Message-ID: <32927.141.117.13.207.1101312586.squirrel@141.117.13.207>

to match the convension of gem

pdp_in and pdp_out would be best

(since we have sub-chains with prefixes in gem, pix_ vertex_ etc.. )

B.

(I'm looking forward to play with this...)


>
>> >since it's really only 'get' and 'set' (just about exchainging data
>> >with a gem render chain) i think this should be clear in the name.
>> >
>> >the object qualify as 'gem chain objects' not pdp objects. so [pdp_xxx]
>> >seems confusing.
>>
>> true.
>> still i think that "pdp" should be in the name too, as [gem_set]
>> wouldn't necessarily have something to do with pdp packages.
>> so probably [gem_pdpout} and [gem_pdpin] would be more apropriate ?
>> (or [gem_pdp.out] and [gem_pdp.in])
>>
>>
> ...
>>
>>
>> so the templates are almost done; just want to settle the name before i
>> check them in
>>
>
>
> [gem_pdp.out] and [gem_pdp.in] seem ok to me
>
> or even
>
> [out_pdp] and [in_pdp] to keep them shorter, since most gem
> objects don't have a gem_ prefix.
>
> yeah, politics!
>
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/gem-dev
>





From ben at ekran.org  Wed Nov 24 17:12:51 2004
From: ben at ekran.org (B. Bogart)
Date: Wed, 24 Nov 2004 11:12:51 -0500 (EST)
Subject: [GEM-dev] pf/pdp/3dp in Gem
In-Reply-To: <20041124102940.GH29960@zzz.i>
References: <20041105134952.GC2636@zzz.i> <41922736.7030207@iem.at>
    <20041123120256.GA12325@zzz.i> <41A32E31.3020701@iem.at>
    <20041124102940.GH29960@zzz.i>
Message-ID: <32932.141.117.13.207.1101312771.squirrel@141.117.13.207>

Oops,

Of course the pdp_ objects start with pdp_ so my suggestion is illogical.

Do the objects only deal with pixel data?
If so then pix_pdpin pix_pdpout may work...

Ok thats enough of me.

B.

>
>> >since it's really only 'get' and 'set' (just about exchainging data
>> >with a gem render chain) i think this should be clear in the name.
>> >
>> >the object qualify as 'gem chain objects' not pdp objects. so [pdp_xxx]
>> >seems confusing.
>>
>> true.
>> still i think that "pdp" should be in the name too, as [gem_set]
>> wouldn't necessarily have something to do with pdp packages.
>> so probably [gem_pdpout} and [gem_pdpin] would be more apropriate ?
>> (or [gem_pdp.out] and [gem_pdp.in])
>>
>>
> ...
>>
>>
>> so the templates are almost done; just want to settle the name before i
>> check them in
>>
>
>
> [gem_pdp.out] and [gem_pdp.in] seem ok to me
>
> or even
>
> [out_pdp] and [in_pdp] to keep them shorter, since most gem
> objects don't have a gem_ prefix.
>
> yeah, politics!
>
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/gem-dev
>





From zmoelnig at iem.at  Wed Nov 24 17:17:25 2004
From: zmoelnig at iem.at (Johannes M Zmoelnig)
Date: Wed, 24 Nov 2004 17:17:25 +0100
Subject: [GEM-dev] pf/pdp/3dp in Gem
In-Reply-To: <32927.141.117.13.207.1101312586.squirrel@141.117.13.207>
References: <20041105134952.GC2636@zzz.i> <41922736.7030207@iem.at>    <20041123120256.GA12325@zzz.i> <41A32E31.3020701@iem.at>    <20041124102940.GH29960@zzz.i> <32927.141.117.13.207.1101312586.squirrel@141.117.13.207>
Message-ID: <41A4B415.2030700@iem.at>

B. Bogart wrote:
> to match the convension of gem
> 
> pdp_in and pdp_out would be best
> 
> (since we have sub-chains with prefixes in gem, pix_ vertex_ etc.. )
> 

well, but the pdp_ prefix is for pdp-objects (not for gem objects)
ther will only be 2 such objects, so i don't think it is worth to start 
a new "class",
otoh the "gem_" prefix would indicate that something "serious" is going 
on ;-)


anyhow, i have added the files now to the HEAD into src/Control/

the files are called gem_pdpout.{cpp|h}, resp. gem_pdpin.{cpp|h}
[gem_pdp.out] and [gem_pdp.in] are aliases (easier for me)

to add the files to your build-system, just re-run the 
"makesource"-script in Gnu and recompile.
allons-nous!!


mfg.mi.dxy
IOhannes




From tigital at mac.com  Wed Nov 24 17:20:04 2004
From: tigital at mac.com (james tittle)
Date: Wed, 24 Nov 2004 11:20:04 -0500
Subject: [GEM-dev] pf/pdp/3dp in Gem
In-Reply-To: <32927.141.117.13.207.1101312586.squirrel@141.117.13.207>
References: <20041105134952.GC2636@zzz.i> <41922736.7030207@iem.at> <20041123120256.GA12325@zzz.i> <41A32E31.3020701@iem.at> <20041124102940.GH29960@zzz.i> <32927.141.117.13.207.1101312586.squirrel@141.117.13.207>
Message-ID: <B309A058-3E34-11D9-B06E-000D93AE3A7A@mac.com>

...now that IOhannes has committed something, I may as well start to 
discuss naming, too :-)

On Nov 24, 2004, at 11:09 AM, B. Bogart wrote:

> to match the convension of gem
>
> pdp_in and pdp_out would be best
>
> (since we have sub-chains with prefixes in gem, pix_ vertex_ etc.. )

...I think this holds to the general design of gem, too; but...

>> [gem_pdp.out] and [gem_pdp.in] seem ok to me
>>
>> or even
>>
>> [out_pdp] and [in_pdp] to keep them shorter, since most gem
>> objects don't have a gem_ prefix.

...I'm not sure that in and out are the best terms here? (although they 
aren't the worst, and make pretty good sense once ya see a patch)...

How about something more like [gem_to_pdp] & [gem_from_pdp]?

2 cents 2 late,
jamie




From ben at ekran.org  Wed Nov 24 17:24:10 2004
From: ben at ekran.org (B. Bogart)
Date: Wed, 24 Nov 2004 11:24:10 -0500 (EST)
Subject: [GEM-dev] pf/pdp/3dp in Gem
In-Reply-To: <B309A058-3E34-11D9-B06E-000D93AE3A7A@mac.com>
References: <20041105134952.GC2636@zzz.i> <41922736.7030207@iem.at>
    <20041123120256.GA12325@zzz.i> <41A32E31.3020701@iem.at>
    <20041124102940.GH29960@zzz.i>
    <32927.141.117.13.207.1101312586.squirrel@141.117.13.207>
    <B309A058-3E34-11D9-B06E-000D93AE3A7A@mac.com>
Message-ID: <32947.141.117.13.207.1101313450.squirrel@141.117.13.207>

James inspired me,

gem2pdp and pdp2gem or pix2pdp and pdp2pix

:)

Ok this time I'm really going to shut up and go back to work.

B.


> ...now that IOhannes has committed something, I may as well start to
> discuss naming, too :-)
>
> On Nov 24, 2004, at 11:09 AM, B. Bogart wrote:
>
>> to match the convension of gem
>>
>> pdp_in and pdp_out would be best
>>
>> (since we have sub-chains with prefixes in gem, pix_ vertex_ etc.. )
>
> ...I think this holds to the general design of gem, too; but...
>
>>> [gem_pdp.out] and [gem_pdp.in] seem ok to me
>>>
>>> or even
>>>
>>> [out_pdp] and [in_pdp] to keep them shorter, since most gem
>>> objects don't have a gem_ prefix.
>
> ...I'm not sure that in and out are the best terms here? (although they
> aren't the worst, and make pretty good sense once ya see a patch)...
>
> How about something more like [gem_to_pdp] & [gem_from_pdp]?
>
> 2 cents 2 late,
> jamie
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/gem-dev
>





From zmoelnig at iem.at  Wed Nov 24 18:20:08 2004
From: zmoelnig at iem.at (Johannes M Zmoelnig)
Date: Wed, 24 Nov 2004 18:20:08 +0100
Subject: [GEM-dev] pf/pdp/3dp in Gem
In-Reply-To: <32947.141.117.13.207.1101313450.squirrel@141.117.13.207>
References: <20041105134952.GC2636@zzz.i> <41922736.7030207@iem.at>    <20041123120256.GA12325@zzz.i> <41A32E31.3020701@iem.at>    <20041124102940.GH29960@zzz.i>    <32927.141.117.13.207.1101312586.squirrel@141.117.13.207>    <B309A058-3E34-11D9-B06E-000D93AE3A7A@mac.com> <32947.141.117.13.207.1101313450.squirrel@141.117.13.207>
Message-ID: <41A4C2C8.5060206@iem.at>

B. Bogart wrote:
> James inspired me,
> 
> gem2pdp and pdp2gem or pix2pdp and pdp2pix
> 

well, the problem is, that there already are [gem2pdp] and [pdp2gem] 
objects (thanks to yves)

and the new objects will work differently from the old ones (although 
both provide a bridge between gem and pdp)

but of course they are nice names (probably that is why they are already 
chosen)


mfg.a.dr
IOhannes



From ben at ekran.org  Wed Nov 24 19:48:47 2004
From: ben at ekran.org (B. Bogart)
Date: Wed, 24 Nov 2004 13:48:47 -0500 (EST)
Subject: [GEM-dev] pd .38 test 10 on OSX (.app)
Message-ID: <51051.141.117.13.207.1101322127.squirrel@141.117.13.207>

Hey Miller and all,

I decided to try test 10 on OSX and see if the "path" stuff has been
fixed. Unfortunatly it seems much less functional than before.

Here are a few notes:

* When pasting (Apple-V) into "pd search path entry boxes":
  error: .gfxstub41d8c0.f?: no such object
  Where "?" is 0-9 corrseponding to the entry field

* When Copying in console widget: (Apple-C)
  error: .printout.text: no such object

The fun stuff:

When I add a few things to the path requester and press save and then ok I
get a plist that has anything but correct values for the paths. When
opening the path requestor again (without closing pd) indeed the paths we
added are gone, and in their place only the first feild contains "0" and
nothing more (nothing in the other fields either).

The plist itself contains only this path:

	<key>path1</key>
	<string>2???</string>

Looks like something is really quite wrong with the plist creation. (more
wrong than in test7)

so after a hunch I decided to try creating my own plist for test 10
without using the "path" requester at all. The result? Perfectly loading
libs.

So it looks like the problems with test 10 are specific to how the
variables in the path (and startup) requesters.

I also tired loading my working plist from test 10 into test 7 and indeed
it does not load the libs, so thanks for fixing the plist parsing in test
10!

Ok so now I'm going to make my own working plist for test 10 and things
will be looking up!

also even test 10 still complains: "error pasing RC arguments" even when
it is loading paths and libs properly.

Hope this helps with test11,

B.




From zmoelnig at iem.at  Sat Nov 27 11:05:03 2004
From: zmoelnig at iem.at (IOhannes m zmoelnig)
Date: Sat, 27 Nov 2004 11:05:03 +0100
Subject: [GEM-dev] Re: Feature Requests
In-Reply-To: <50080.141.117.13.236.1101228366.squirrel@141.117.13.236>
References: <20041122131055.26380d75@laptop> <41A2EE99.2000605@iem.at> <50080.141.117.13.236.1101228366.squirrel@141.117.13.236>
Message-ID: <41A8514F.1050902@iem.at>

B. Bogart wrote:
> Hey all,

have i answered this already ?

> 
> Should we post feature requests for Gem to the PD feature request tracker
> on source-forge or continue posting to this list?

i don't think that using PD's feature request tracker is the way to go, 
since Gem isn't even hosted on the same site...
as for now (relatively few developers) i think it is ok to post to GEM-dev

oh, and i have just noticed, that i have set up a feature-tracker on 
http://sourceforge.net/projects/pd-gem a long time ago...

> 
> In terms of the idea of pix_mean_colors (I think I'm using the wrong name)
> I think it would be very nice in the long term to be able to work with
> pixel-data a little more effectively. (rather than having the pass the
> whole image as PD messages and go from there.) Maybe something related to
certainly true, although i have no idea where to go : forth ? ruby ? ;-)


> Anyhow I have a list of features I've posted over the years and thought It
> would be good to have it all together somewhere.
> 
> otherwise I'll dig em all up and post in one long message...


yes, would be great to have them available on one place.
the tracker is probably best, because there we can close the request, 
once it is done.
however, i would like to see it on the mailinglist too...


mfg.a.dsr
IOhannes



From TimBlechmann at gmx.net  Sun Nov 28 14:25:18 2004
From: TimBlechmann at gmx.net (Tim Blechmann)
Date: Sun, 28 Nov 2004 14:25:18 +0100
Subject: [GEM-dev] Re: [PD] motion detection with gem?
In-Reply-To: <926799F5-4100-11D9-8C34-000A95AC7646@deviation.de>
References: <926799F5-4100-11D9-8C34-000A95AC7646@deviation.de>
Message-ID: <20041128142518.128b1bfa@laptop>

> I read on the TODO of Gem that the motion detection has to be 
> implemented first but I want to know if somebody tried some 
> 'workarounds' to get something like motion detection. I think about 
> using an infrared camera which will input a black/withe signal.
> Any suggestions?
for a project i'm doing, i use a different approach with optical trigger
fields that send out a bang, if movement has been detected in a certain
area of the incoming image ...
it's not tested very well (works for my purpose) and i didn't send it to
the gem-list, since it's probably possibly to rewrite it as an
abstraction... 
i attached the source files, maybe it can be of use ... in general i
think that image analyse functions in gem should be improved ... either
in c++ or in abstractions (whatever is faster)

cheers ... tim

-- 
mailto:TimBlechmann at gmx.de    ICQ: 96771783
http://www.mokabar.tk

After one look at this planet any visitor from outer space 
would say "I want to see the manager."
				      William S. Burroughs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pix_trigger.h
Type: text/x-chdr
Size: 2079 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20041128/a08e9e93/attachment.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pix_trigger.cpp
Type: text/x-c++src
Size: 3629 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20041128/a08e9e93/attachment.cpp>