Thanks to popular demand, i just commited few shaders exemple in gem exemple directory.
hope it will help Cyrille
Chris McCormick a écrit :
On Sat, Dec 22, 2007 at 11:26:18AM -0600, chris clepper wrote:
This is what the vertex_array objects basically do. The vertex_model object opens up a .obj and then passes the vertex, normal, texcoord and color data to other vertex_ objects for processing. The speed is pretty good - better than standard geos - but the better route is to use shaders. Shaders allow for more end user manipulation than the vertex_objects could ever offer.
Alright, I'll have to take a closer look at shaders in Gem then. Thanks for the advice. Can anyone point me to a simple vertex manipulation shader I can run in Gem to get started?
Best,
Chris.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Excellent, it's good to see all this good stuff in Gem starting to get some recognition! Example patches help so much with this, Jitter is a good example of the power of examples.
.hc
On Dec 23, 2007, at 4:55 AM, cyrille henry wrote:
Thanks to popular demand, i just commited few shaders exemple in gem exemple directory.
hope it will help Cyrille
Chris McCormick a écrit :
On Sat, Dec 22, 2007 at 11:26:18AM -0600, chris clepper wrote:
This is what the vertex_array objects basically do. The vertex_model object opens up a .obj and then passes the vertex, normal, texcoord and color data to other vertex_ objects for processing. The speed is pretty good - better than standard geos - but the better route is to use shaders. Shaders allow for more end user manipulation than the vertex_objects could ever offer.
Alright, I'll have to take a closer look at shaders in Gem then. Thanks for the advice. Can anyone point me to a simple vertex manipulation shader I can run in Gem to get started?
Best,
Chris.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
------------------------------------------------------------------------ ----
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
yep, I agree about the power of exemple. BTW, i'd like to add the exemples i made for the graz conferences (repeat, LS, etc) any objection?
franck : can i also add your double-gemhead exemple?
Cyrille
Hans-Christoph Steiner a écrit :
Excellent, it's good to see all this good stuff in Gem starting to get some recognition! Example patches help so much with this, Jitter is a good example of the power of examples.
.hc
On Dec 23, 2007, at 4:55 AM, cyrille henry wrote:
Thanks to popular demand, i just commited few shaders exemple in gem exemple directory.
hope it will help Cyrille
Chris McCormick a écrit :
On Sat, Dec 22, 2007 at 11:26:18AM -0600, chris clepper wrote:
This is what the vertex_array objects basically do. The vertex_model object opens up a .obj and then passes the vertex, normal, texcoord and color data to other vertex_ objects for processing. The speed is pretty good - better than standard geos - but the better route is to use shaders. Shaders allow for more end user manipulation than the vertex_objects could ever offer.
Alright, I'll have to take a closer look at shaders in Gem then. Thanks for the advice. Can anyone point me to a simple vertex manipulation shader I can run in Gem to get started?
Best,
Chris.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
I agree about the power of exemple. BTW, i'd like to add the exemples i made for the graz conferences (repeat, LS, etc) any objection?
franck : can i also add your double-gemhead exemple?
Yes, of course.
Ciai
On Dec 26, 2007, at 8:20 AM, Frank Barknecht wrote:
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
I agree about the power of exemple. BTW, i'd like to add the exemples i made for the graz conferences (repeat, LS, etc) any objection?
franck : can i also add your double-gemhead exemple?
Yes, of course.
Claude's gem recursion would be great to have in Gem example, like examples/30.recursion. What do you guys think?
.hc
------------------------------------------------------------------------ ----
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
Quoting Hans-Christoph Steiner hans@eds.org:
On Dec 26, 2007, at 8:20 AM, Frank Barknecht wrote:
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
I agree about the power of exemple. BTW, i'd like to add the exemples i made for the graz conferences (repeat, LS, etc) any objection?
franck : can i also add your double-gemhead exemple?
Yes, of course.
Claude's gem recursion would be great to have in Gem example, like examples/30.recursion. What do you guys think?
the more the merrier. however, i would prefer if no examples within the Gem-tree would depend on any external other than Gem.
e.g. you can replace [repeat 5] by [t a a a a a].
for stuff that has additional dependencies i would suggest to create a separate meta-directory parallel to the Gem-tree. (e.g. for gem+lua; gem+chaos,...)
fmgasd.r IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Dec 30, 2007, at 1:53 AM, zmoelnig@iem.at wrote:
Quoting Hans-Christoph Steiner hans@eds.org:
On Dec 26, 2007, at 8:20 AM, Frank Barknecht wrote:
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
I agree about the power of exemple. BTW, i'd like to add the exemples i made for the graz conferences (repeat, LS, etc) any objection?
franck : can i also add your double-gemhead exemple?
Yes, of course.
Claude's gem recursion would be great to have in Gem example, like examples/30.recursion. What do you guys think?
the more the merrier. however, i would prefer if no examples within the Gem-tree would depend on any external other than Gem.
e.g. you can replace [repeat 5] by [t a a a a a].
for stuff that has additional dependencies i would suggest to create a separate meta-directory parallel to the Gem-tree. (e.g. for gem+lua; gem+chaos,...)
I find it quite depressing that we can't get agreement on a standard way to distribute and use libraries (aka externals). This really cripples the Pd community. Then we have to do things like organize examples around why libraries might be used rather than the concepts involved.
.hc
------------------------------------------------------------------------ ----
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne
Quoting Hans-Christoph Steiner hans@eds.org:
for stuff that has additional dependencies i would suggest to create a separate meta-directory parallel to the Gem-tree. (e.g. for gem+lua; gem+chaos,...)
I find it quite depressing that we can't get agreement on a standard way to distribute and use libraries (aka externals). This really cripples the Pd community. Then we have to do things like organize examples around why libraries might be used rather than the concepts involved.
that is why i was proposing to add a separate section for just this kind of things.
i really don't want to tell people that they should use linux, or pd-extended or whatelse, if all they want to do is use pd/Gem.
otoh there also should be a repository of more elaborate example patches _too_.
mfgas.dr IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
zmoelnig@iem.at a écrit :
Quoting Hans-Christoph Steiner hans@eds.org:
for stuff that has additional dependencies i would suggest to create a separate meta-directory parallel to the Gem-tree. (e.g. for gem+lua; gem+chaos,...)
I find it quite depressing that we can't get agreement on a standard way to distribute and use libraries (aka externals). This really cripples the Pd community. Then we have to do things like organize examples around why libraries might be used rather than the concepts involved.
that is why i was proposing to add a separate section for just this kind of things.
i really don't want to tell people that they should use linux, or pd-extended or whatelse, if all they want to do is use pd/Gem.
otoh there also should be a repository of more elaborate example patches _too_.
i'm not a big fan of externals. So i think that elaborate exemple should not use externals.
for now, [any] is the only mandatory one. [list] should replace it, but for now it does not work. so, i think i'll commit every patch that can be made without externals, and i'll wait for [list] to work for next exemple.
Cyrille
mfgas.dr IOhannes
This message was sent using IMP, the Internet Messaging Program.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
for now, [any] is the only mandatory one. [list] should replace it, but for now it does not work.
Idea: What if Gem would include an objectclass to store a gem-pointer? (pdp has something like that called pdp_reg IIRC.)
Ciao
On Dec 30, 2007, at 3:08 PM, Frank Barknecht wrote:
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
for now, [any] is the only mandatory one. [list] should replace it, but for now it does not work.
Idea: What if Gem would include an objectclass to store a gem-pointer? (pdp has something like that called pdp_reg IIRC.)
Can't you just store it in a [list]? IIRC, the gem messages are just regular Pd messages.
.hc
------------------------------------------------------------------------ ----
kill your television
Quoting Hans-Christoph Steiner hans@eds.org:
for now, [any] is the only mandatory one. [list] should replace it, but for now it does not work.
Can't you just store it in a [list]? IIRC, the gem messages are just regular Pd messages.
Gem messages (ab)uses pointer-messages; unfortunately Pd does not handle pointers very well: neither [pack] nor [list] can handle pointers that are not data-structures.
i think the thing to do is to move away from pointers and use numbers/symbols instead (as ids to Gem-packages)
mfga.dsr IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
zmoelnig@iem.at a écrit :
Quoting Hans-Christoph Steiner hans@eds.org:
for now, [any] is the only mandatory one. [list] should replace it, but for now it does not work.
Can't you just store it in a [list]? IIRC, the gem messages are just regular Pd messages.
Gem messages (ab)uses pointer-messages; unfortunately Pd does not handle pointers very well: neither [pack] nor [list] can handle pointers that are not data-structures.
i think the thing to do is to move away from pointers and use numbers/symbols instead (as ids to Gem-packages)
this is a lot's of work. is it?
maybe copying the [any] from iem to [gempointer] and included it in Gem source would be the fastest way to have everything to work (?)
(gempointer could be made as an abstraction later, when it will be possible to do it with [list]).
what do you think?
cyrille
mfga.dsr IOhannes
This message was sent using IMP, the Internet Messaging Program.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hi
cyrille henry wrote:
this is a lot's of work. is it?
don't know, i haven't started yet :-)
maybe copying the [any] from iem to [gempointer] and included it in Gem source would be the fastest way to have everything to work (?)
(gempointer could be made as an abstraction later, when it will be possible to do it with [list]).
what do you think?
this might be a good idea anyhow, as such an object could check whether the context is setup correctly and whether the state is valid. [any] should be prone to crashes if used incorrectly.
i don't like the name "gempointer" though, as it is inspired by the underlying implementation rather than the concept.
probably [gemcache] or [gemstate] are better names...
fam,rsd. IOhannes
IOhannes m zmoelnig a écrit :
hi
cyrille henry wrote:
this is a lot's of work. is it?
don't know, i haven't started yet :-)
is it really on your todo-list?
what would be the benefit (other than using "float" better than "any")?
maybe copying the [any] from iem to [gempointer] and included it in Gem source would be the fastest way to have everything to work (?)
(gempointer could be made as an abstraction later, when it will be possible to do it with [list]).
what do you think?
this might be a good idea anyhow, as such an object could check whether the context is setup correctly and whether the state is valid. [any] should be prone to crashes if used incorrectly.
i never get a crash using any, but yes, that would be a good thing to do this check.
i don't like the name "gempointer" though, as it is inspired by the underlying implementation rather than the concept.
ok
probably [gemcache] or [gemstate] are better names...
gemstate is ok for me
cyrille
fam,rsd. IOhannes
cyrille henry wrote:
this is a lot's of work. is it?
don't know, i haven't started yet :-)
is it really on your todo-list?
what would be the benefit (other than using "float" better than "any")?
miller expressed his concerns once, that people should not abuse the gpointer for whatever. Pd assumes things about the gpointer, which are not necesserarily true when they are really pointers to "something else".
it is kind of on my todo-list, but what i really want to do is get custom types into Pd (which would make the integer-id "hack" unnecessary)
fgmasdr. IOhannes
On Thu, 3 Jan 2008, IOhannes m zmoelnig wrote:
miller expressed his concerns once, that people should not abuse the gpointer for whatever. Pd assumes things about the gpointer, which are not necesserarily true when they are really pointers to "something else".
I'm curious: apart from GEM, GridFlow and PDP, are there any other externals using pointers abnormally?
it is kind of on my todo-list, but what i really want to do is get custom types into Pd (which would make the integer-id "hack" unnecessary)
Oh wow! If you can get Miller to add it, you're very good. I've spent hours in IRC meetings talking about that kind of thing in 2005. Nothing came out of it, and it was not a "maybe", it was pretty much a "no". Krzysztof was also against it... at least in 2002...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Jan 3, 2008 4:27 PM, Mathieu Bouchard matju@artengine.ca wrote:
On Thu, 3 Jan 2008, IOhannes m zmoelnig wrote:
miller expressed his concerns once, that people should not abuse the gpointer for whatever. Pd assumes things about the gpointer, which are not necesserarily true when they are really pointers to "something else".
I'm curious: apart from GEM, GridFlow and PDP, are there any other externals using pointers abnormally?
In the SQL stuff that I am working on, I cast a (char *) to a gpointer. BUT, I believe I have it set up in such a way that PD never actually does anything to that object, other than pass it around in a message. I send it in a message to another object, and immediately cast it back to a (char *). So far nothing has crashed on me. I am sure there are probably better ways of handling character strings, I just have not found the proper way (if there is one) to do it... My reasons for doing this is because I don't want to have to deal with all the various characters that PD will escape, things like comma's and semicolons.
Mike
ok, i finally named this object "gemlist", to be consistent with gemlist_info, and helpfile.
i just commited it.
it is not fully tested yet, please tell me if you've got problem. moreover, i' did not managed to have a clean context test. please look at the code if you wish to help me.
if it's ok for everybody, i'll commit exemples in a few days.
cyrille
IOhannes m zmoelnig a écrit :
hi
cyrille henry wrote:
this is a lot's of work. is it?
don't know, i haven't started yet :-)
maybe copying the [any] from iem to [gempointer] and included it in Gem source would be the fastest way to have everything to work (?)
(gempointer could be made as an abstraction later, when it will be possible to do it with [list]).
what do you think?
this might be a good idea anyhow, as such an object could check whether the context is setup correctly and whether the state is valid. [any] should be prone to crashes if used incorrectly.
i don't like the name "gempointer" though, as it is inspired by the underlying implementation rather than the concept.
probably [gemcache] or [gemstate] are better names...
fam,rsd. IOhannes
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Dec 30, 2007, at 3:08 PM, Frank Barknecht wrote:
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
for now, [any] is the only mandatory one. [list] should replace it, but for now it does not work.
Idea: What if Gem would include an objectclass to store a gem-pointer? (pdp has something like that called pdp_reg IIRC.)
Can't you just store it in a [list]? IIRC, the gem messages are just regular Pd messages.
As Cyrille wrote, it doesn't work (yet) for the purpose of storing a full gem state. [iem_anthing] works.
Ciao
Hans-Christoph Steiner wrote:
I find it quite depressing that we can't get agreement on a standard way to distribute and use libraries (aka externals). This really cripples the Pd community. Then we have to do things like organize examples around why libraries might be used rather than the concepts involved.
hi,
there is a standard way to distribute externals: to go to the developers web site, and get the external there, then fiddle around with its installation. I agree with hans that this procedure could be managed in a better way.
there once was the idea to create (additional?) standard libraries, like string, math, time, net... I think core pd should come with a few more objects, but additional standard libraries should be provided from a central repository by a oneliner on the commandline or by one click in the pd-prefs (apt-get pd-library-install pd-math...). and then as an additional addition the existing external libraries. iemgui, fiddle, bonk are examples that became kind of internal externals. otherwise you will get the known flamewars (help-files, distributions, future maintenance of libs, patch compatibility, namespaces...). would this make sense to rewrite a set of standard libraries (even if based on code from existing external libraries that are around already)?
marius.