Hi i am trying to understand flext and am doing the tutorial
but i get an error regarding adv1/main.cpp when issuing
make -f makefile.pd-linux in the tutorial folder
In function 'bool adv1::cb_m_any (flext_base *, cost t_symbol *, int, t_atom *)' : adv1/main.cpp:34 cannot convert 'const t_symbol * ' to t_symbol * ' for arguement '1' to 'adv1::m_any (t_symbol *, int, t_atom *)' make *** [pd-linux/adv1.o] Error 1
any help is appreciated
Pat Pagano, Director South East Just Intonation Society http://www.screwmusicforever.com/SHREESWIFT/ http://www.digitalworlds.ufl.edu
Hi Pat, there are some problems concerning the const modifiers in the examples. Try deleting the const in line 30 (void m_any) or have a few days' patience since the upcoming version will be less sensitive in this respect.
best greetings, Thomas
am 14.11.2002 2:49 Uhr schrieb shreeswifty unter ppagano@bellsouth.net:
Hi i am trying to understand flext and am doing the tutorial
but i get an error regarding adv1/main.cpp when issuing
make -f makefile.pd-linux in the tutorial folder
In function 'bool adv1::cb_m_any (flext_base *, cost t_symbol *, int, t_atom *)' : adv1/main.cpp:34 cannot convert 'const t_symbol * ' to t_symbol * ' for arguement '1' to 'adv1::m_any (t_symbol *, int, t_atom *)' make *** [pd-linux/adv1.o] Error 1
any help is appreciated
Pat Pagano, Director South East Just Intonation Society http://www.screwmusicforever.com/SHREESWIFT/ http://www.digitalworlds.ufl.edu
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
hi,
in gem-cvs Gem/src/Base/GemSetup.cpp at section Pixes///Pix-Geos the line "pix_texture2_setup();"
is missing
cheers
erich
at section Pixes///Pix-Geos the line "pix_texture2_setup();"
i thought to follow guenter's proposal to include the [pix_texture2]-functionality into the [pix_texture]-object. "pix_texture2" is now just an alias for "pix_texture" so we shoudn't need the setup-routines.
however:: erich, did this solve your crashes ?
mfg.sda.r IOhannes
is missing
cheers
erich
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
however:: erich, did this solve your crashes ?
actually i have to try it out to know this, but my patches use the pix_texture2 object, wich is then not existing anymore (iguess) so i have to rewrite them and try again
mfg.sda.r IOhannes
is missing
cheers
erich
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
at section Pixes///Pix-Geos the line "pix_texture2_setup();"
i thought to follow guenter's proposal to include the [pix_texture2]-functionality into the [pix_texture]-object. "pix_texture2" is now just an alias for "pix_texture" so we shoudn't need the setup-routines.
however:: erich, did this solve your crashes ?
mfg.sda.r IOhannes
hiya,
...well, at least for the MacOSX build, we need both texture/texture2...this is because we use an extension for non-power of 2 textures that makes for incredibly fast performance...unfortunately, I don't know if the extension (GL_TEXTURE_RECTANGLE_EXT) is available on other platforms?
...OTOH, I think that eventually it'll be nice to have one texture object that does everything, but I'm struggling to get the OS X stuff into cvs right now, as is! The holdup right now is that I want it to at least compile on my machine before I cvs checkin... ;-)
soon! jamie
I think that it's a good idea to keep separate pix_texture and pix_texture2 objects because power of 2 textures work differently from non-pow2 textures, no matter what tricks/extensions you use to allow the use of non-pow2 textures. These differences are in the support for wrap modes, borders etc.
Presently, a non-pow2 texture using texture coord scaling (as implemented by pix_texture2) will repeat but will include the black padding zones. Using GL_TEXTURE_RECTANGLE_NV repeat is not supported at all.
These behavioural differences can't be properly hidden, can they? And sooner or later it would be nice to expose the wrap mode and border settings for control via messages to the pix_textureX object...
Details for nVidia's non-pow2 extension. http://www.nvidia.com/dev_content/nvopenglspecs/GL_NV_texture_rectangle.txt
...well, at least for the MacOSX build, we need both
texture/texture2...this is because
we use an extension for non-power of 2 textures that makes for incredibly
fast
performance...unfortunately, I don't know if the extension
(GL_TEXTURE_RECTANGLE_EXT) is
available on other platforms?
Notwithstanding what I said above, the fast texture support on Mac OS X doesn't need to be used with non-pow2 textures, does it?
The texture rectangle extension is available in the nvidia drivers... not sure about other vendors or MESA.
Daniel
I think that it's a good idea to keep separate pix_texture and pix_texture2 objects because power of 2 textures work differently from non-pow2 textures, no matter what tricks/extensions you use to allow the use of non-pow2 textures. These differences are in the support for wrap modes, borders etc.
Presently, a non-pow2 texture using texture coord scaling (as implemented by pix_texture2) will repeat but will include the black padding zones. Using GL_TEXTURE_RECTANGLE_NV repeat is not supported at all.
no if you give the coords in 0..height 0..width it will cover the surface completely.
These behavioural differences can't be properly hidden, can they? And sooner or later it would be nice to expose the wrap mode and border settings for control via messages to the pix_textureX object...
yes. the option for the user to do wrap or clamp_to_edge would be nice.
Details for nVidia's non-pow2 extension. http://www.nvidia.com/dev_content/nvopenglspecs/GL_NV_texture_rectangle.txt
thanks for the info. this looks pretty close to the apple extension.
...well, at least for the MacOSX build, we need both
texture/texture2...this is because
we use an extension for non-power of 2 textures that makes for incredibly
fast
performance...unfortunately, I don't know if the extension
(GL_TEXTURE_RECTANGLE_EXT) is
available on other platforms?
Notwithstanding what I said above, the fast texture support on Mac OS X doesn't need to be used with non-pow2 textures, does it?
no, but it sure cuts down on wasted bandwidth. 640*480 is a hell of a lot fewer pixels than 1024*1024. also IMHO the power of two texture thing is just plain silly. how many images do you run across that conform to this?
The texture rectangle extension is available in the nvidia drivers... not sure about other vendors or MESA.
it would be good to check the support for this under linux and windows.
cgc
Daniel
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
If possible I am for a single texture object, from a users point of view. I have been discussing a lot with Johannes the topic of going to lower levels ( as DIPS does for example).
We have to take care to balance the usability/flexibility tradeoff. It is true that one single texture reduces flexibility to a certain amount.
I think to regain this we could have another, low level access to OpenGL functionality, for "power users".
Specifically, in order to get Gem out of the "hacker domain" we have to think a lot about usability and general concept.
Regarding Erichs problem, I think we should add and alias texture2->texture. I did this on the "old" CVS (soon to disappear).
Greetings,
Guenter
On Thu, 14 Nov 2002, chris clepper wrote:
I think that it's a good idea to keep separate pix_texture and pix_texture2 objects because power of 2 textures work differently from non-pow2 textures, no matter what tricks/extensions you use to allow the use of non-pow2 textures. These differences are in the support for wrap modes, borders etc.
Presently, a non-pow2 texture using texture coord scaling (as implemented by pix_texture2) will repeat but will include the black padding zones. Using GL_TEXTURE_RECTANGLE_NV repeat is not supported at all.
no if you give the coords in 0..height 0..width it will cover the surface completely.
These behavioural differences can't be properly hidden, can they? And sooner or later it would be nice to expose the wrap mode and border settings for control via messages to the pix_textureX object...
yes. the option for the user to do wrap or clamp_to_edge would be nice.
Details for nVidia's non-pow2 extension. http://www.nvidia.com/dev_content/nvopenglspecs/GL_NV_texture_rectangle.txt
thanks for the info. this looks pretty close to the apple extension.
...well, at least for the MacOSX build, we need both
texture/texture2...this is because
we use an extension for non-power of 2 textures that makes for incredibly
fast
performance...unfortunately, I don't know if the extension
(GL_TEXTURE_RECTANGLE_EXT) is
available on other platforms?
Notwithstanding what I said above, the fast texture support on Mac OS X doesn't need to be used with non-pow2 textures, does it?
no, but it sure cuts down on wasted bandwidth. 640*480 is a hell of a lot fewer pixels than 1024*1024. also IMHO the power of two texture thing is just plain silly. how many images do you run across that conform to this?
The texture rectangle extension is available in the nvidia drivers... not sure about other vendors or MESA.
it would be good to check the support for this under linux and windows.
cgc
Daniel
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
--
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
On the texture versus texture2 question: what's the precedent for this sort of thing in PD/GEM? Should a single object have multiple modes that support different messages, or should the different modes appear as different objects?
GL_TEXTURE_RECTANGLE_??: The issue of extensions on Windows is a bit cumbersome because support is entirely dependent on the driver you're using... so you have do to run-time checks and run-time function bindings for the desired extensions.
High level/low level I think what is really desirable is to have low-level and high level functionality together... somewhat like GL and GLU. I don't think you can do without the low-level if you want flexibility, but straightforward support for things like parameterized models would be great...
The biggest issues I've found with GEM are in data management and render flow control which both get quite awkward... these are partly problems that also occur in PD... generalized matrix formulations of things would be really good. (hello, Gridflow!)
Is a GEM redesign in the works? I'd be interested to hear more about this and contribute what I can...
daniel
If possible I am for a single texture object, from a users point of view. I have been discussing a lot with Johannes the topic of going to lower levels ( as DIPS does for example).
We have to take care to balance the usability/flexibility tradeoff. It is true that one single texture reduces flexibility to a certain amount.
I think to regain this we could have another, low level access to OpenGL functionality, for "power users".
Specifically, in order to get Gem out of the "hacker domain" we have to think a lot about usability and general concept.
Regarding Erichs problem, I think we should add and alias texture2->texture. I did this on the "old" CVS (soon to disappear).
Greetings,
Guenter
On Thu, 14 Nov 2002, chris clepper wrote:
I think that it's a good idea to keep separate pix_texture and
pix_texture2
objects because power of 2 textures work differently from
non-pow2 textures,
no matter what tricks/extensions you use to allow the use of non-pow2 textures. These differences are in the support for wrap
modes, borders
etc.
Presently, a non-pow2 texture using texture coord scaling (as
implemented by
pix_texture2) will repeat but will include the black padding
zones. Using
GL_TEXTURE_RECTANGLE_NV repeat is not supported at all.
no if you give the coords in 0..height 0..width it will cover the surface completely.
These behavioural differences can't be properly hidden, can they? And sooner or later it would be nice to expose the wrap mode and
border settings
for control via messages to the pix_textureX object...
yes. the option for the user to do wrap or clamp_to_edge would be nice.
Details for nVidia's non-pow2 extension.
http://www.nvidia.com/dev_content/nvopenglspecs/GL_NV_texture_rec
tangle.txt
thanks for the info. this looks pretty close to the apple extension.
...well, at least for the MacOSX build, we need both
texture/texture2...this is because
we use an extension for non-power of 2 textures that makes
for incredibly
fast
performance...unfortunately, I don't know if the extension
(GL_TEXTURE_RECTANGLE_EXT) is
available on other platforms?
Notwithstanding what I said above, the fast texture support on Mac OS X doesn't need to be used with non-pow2 textures, does it?
no, but it sure cuts down on wasted bandwidth. 640*480 is a hell of a lot fewer pixels than 1024*1024. also IMHO the power of two texture thing is just plain silly. how many images do you run across that conform to this?
The texture rectangle extension is available in the nvidia
drivers... not
sure about other vendors or MESA.
it would be good to check the support for this under linux and windows.
On Sat, 16 Nov 2002, Daniel Heckenberg wrote:
On the texture versus texture2 question: what's the precedent for this sort of thing in PD/GEM? Should a single object have multiple modes that support different messages, or should the different modes appear as different objects?
This is hard to answer in general. One thing that is important is to have the things on the same level, so the objects try to do what the user expects them to do.
GL_TEXTURE_RECTANGLE_??: The issue of extensions on Windows is a bit cumbersome because support is entirely dependent on the driver you're using... so you have do to run-time checks and run-time function bindings for the desired extensions.
Hum, do not know enough about that to be helpful here.
High level/low level I think what is really desirable is to have low-level and high level functionality together... somewhat like GL and GLU. I don't think you can do without the low-level if you want flexibility, but straightforward support for things like parameterized models would be great...
Yes, I think there should be support for both too, and what I heard is that Johannes is already experimenting with a low level API.
The biggest issues I've found with GEM are in data management and render flow control which both get quite awkward... these are partly problems that also occur in PD... generalized matrix formulations of things would be really good. (hello, Gridflow!)
Is a GEM redesign in the works? I'd be interested to hear more about this and contribute what I can...
Yes, I really think so. What Johannes told me is that he is trying to redesign the render flow control, using pd messages instead of the hardwire DAG list. I think that input on these issues is very important in the current stage, when things can still be changed.
Johannes, do you have something of that in CVS already ?
Guenter
daniel
If possible I am for a single texture object, from a users point of view. I have been discussing a lot with Johannes the topic of going to lower levels ( as DIPS does for example).
We have to take care to balance the usability/flexibility tradeoff. It is true that one single texture reduces flexibility to a certain amount.
I think to regain this we could have another, low level access to OpenGL functionality, for "power users".
Specifically, in order to get Gem out of the "hacker domain" we have to think a lot about usability and general concept.
Regarding Erichs problem, I think we should add and alias texture2->texture. I did this on the "old" CVS (soon to disappear).
Greetings,
Guenter
On Thu, 14 Nov 2002, chris clepper wrote:
I think that it's a good idea to keep separate pix_texture and
pix_texture2
objects because power of 2 textures work differently from
non-pow2 textures,
no matter what tricks/extensions you use to allow the use of non-pow2 textures. These differences are in the support for wrap
modes, borders
etc.
Presently, a non-pow2 texture using texture coord scaling (as
implemented by
pix_texture2) will repeat but will include the black padding
zones. Using
GL_TEXTURE_RECTANGLE_NV repeat is not supported at all.
no if you give the coords in 0..height 0..width it will cover the surface completely.
These behavioural differences can't be properly hidden, can they? And sooner or later it would be nice to expose the wrap mode and
border settings
for control via messages to the pix_textureX object...
yes. the option for the user to do wrap or clamp_to_edge would be nice.
Details for nVidia's non-pow2 extension.
http://www.nvidia.com/dev_content/nvopenglspecs/GL_NV_texture_rec
tangle.txt
thanks for the info. this looks pretty close to the apple extension.
...well, at least for the MacOSX build, we need both
texture/texture2...this is because
we use an extension for non-power of 2 textures that makes
for incredibly
fast
performance...unfortunately, I don't know if the extension
(GL_TEXTURE_RECTANGLE_EXT) is
available on other platforms?
Notwithstanding what I said above, the fast texture support on Mac OS X doesn't need to be used with non-pow2 textures, does it?
no, but it sure cuts down on wasted bandwidth. 640*480 is a hell of a lot fewer pixels than 1024*1024. also IMHO the power of two texture thing is just plain silly. how many images do you run across that conform to this?
The texture rectangle extension is available in the nvidia
drivers... not
sure about other vendors or MESA.
it would be good to check the support for this under linux and windows.
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Yes, I really think so. What Johannes told me is that he is trying to redesign the render flow control, using pd messages instead of the hardwire DAG list. I think that input on these issues is very important in the current stage, when things can still be changed.
I can see the advantages of moving the display list into the message domain. If that part of GEM is being redesigned then I wonder if we can discuss the possibility of having GEM rendering in a separate thread. If audio is ever going to run at low latency on a machine doing lots of video then we need to solve this problem, don't we?
I'll try to have a look at the state of CVS when I get a chance.
I also have a number of GEM objects for windows some of which improve the stability and flexibility of video and file input (rewritten pix_film, pix_video using VideoForWindows and new versions using DirectShow which allow use of DV footage and live DV camera input)... I've been meaning to package and document these and upload to CVS so if there's going to be another GEM release soon then that should provide motivation for me to finally do this.
daniel
Hi all !
I'm back online again (though struggling with life ;-))
guenter geiger wrote:
High level/low level I think what is really desirable is to have low-level and high level functionality together... somewhat like GL and GLU. I don't think you can do without the low-level if you want flexibility, but straightforward support for things like parameterized models would be great...
Yes, I think there should be support for both too, and what I heard is that Johannes is already experimenting with a low level API.
well yes, i started making Gem a (more or less) complete openGL-wrapper (this gives about 400 new objects,... ah it's much code to do and although i have automatized a lot of it, i still have to go through everything again (my scripts used to be not that good...))
The biggest issues I've found with GEM are in data management and render flow control which both get quite awkward... these are partly problems that also occur in PD... generalized matrix formulations of things would be really good. (hello, Gridflow!)
Is a GEM redesign in the works? I'd be interested to hear more about this and contribute what I can...
Yes, I really think so. What Johannes told me is that he is trying to redesign the render flow control, using pd messages instead of the hardwire DAG list. I think that input on these issues is very important in the current stage, when things can still be changed.
Johannes, do you have something of that in CVS already ?
yes, the CVS-version does the render-chain via the pd-message system. it seems to work fine (erich has reported a problem there, but i haven't found out, whether the problem was really related to the render-chain or something different)
i see daniel's suggestion of making Gem a second thread, but this would have been easier with the hardwired DAG
mfg.dsa.r IOhannes
yes, the CVS-version does the render-chain via the pd-message system. it seems to work fine (erich has reported a problem there, but i haven't found out, whether the problem was really related to the render-chain or something different)
sorry i havnt had time to check this - try it soon again, couse it could have been also the lost pix_texture2
lg
erich
On Mon, 18 Nov 2002, IOhannes zmoelnig wrote:
i see daniel's suggestion of making Gem a second thread, but this would have been easier with the hardwired DAG
Exactly what I thought too, when I read that proposal, but it would be great having both.
Guetner
Does anyone have a good scheme for achieving GEM rendering in a separate thread without: - too much recoding - too much synchronisation overhead - losing expected PD object behaviour ?
I've thought about it a little and haven't figured out an elegant scheme yet. Certainly keeping the rendering in a separate thread looks like it would make things easier.
Daniel
-----Original Message----- From: pd-dev-admin@iem.kug.ac.at [mailto:pd-dev-admin@iem.kug.ac.at]On Behalf Of guenter geiger Sent: Tuesday, 19 November 2002 6:45 AM To: IOhannes zmoelnig Cc: Daniel Heckenberg; chris clepper; PD-dev@iem.kug.ac.at Subject: Re: [PD-dev] Gem CVS Bug (wrong alarm ??)
On Mon, 18 Nov 2002, IOhannes zmoelnig wrote:
i see daniel's suggestion of making Gem a second thread, but this would have been easier with the hardwired DAG
Exactly what I thought too, when I read that proposal, but it would be great having both.
Guetner
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
well yes, i started making Gem a (more or less) complete openGL-wrapper (this gives about 400 new objects,... ah it's much code to do and although i have automatized a lot of it, i still have to go through everything again (my scripts used to be not that good...))
i m looking forward to 400 new objects :-), and offer my help with documentation (help patches etc.)
erich
-
chris clepper -
Daniel Heckenberg -
guenter geiger -
IOhannes zmoelnig -
Johannes M Zmoelnig
-
rat＠telecoma.net -
shreeswifty -
Thomas Grill -
tigital