In case anyone is interested AID is a project I am currently working on and will probably end up writing the PD interface objects for it:
www.interaccess.org/aid
Ben
----- Original Message ----- From: Frank Barknecht fbar@footils.org Date: Sunday, January 12, 2003 8:28 am Subject: Re: [PD-dev] object for motion control
Hi, Julien Jassaud hat gesagt: // Julien Jassaud wrote:
Well, if someone is interested in this little device, I can put
up a
web page decribing it.
It sounds interesting, my question is: Could this be made two-way? So that you could build a kind of motor-fader that can control and be controlled by Pd?
ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Hi Gem people,
After the various discussions on image formats I've delved into the possibilities of using C++ generic programming (templates) for efficient, data format independent image processing code.
I started working on some proof of concept classes with a mind to testing just how good/bad the performance would actually be in practice. Then I decided to do the google sanity check to see if anyone had done this before... and the answer is yes.
Ullrich Koethe has developed a library called VIGRA which provides generic programming classes for computer vision... and has published some papers giving performance comparisons: http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/
So... it certainly is possible to use templates to good effect for the image format problem. Whether VIGRA is a good fit for GEM I haven't yet established...
I'll continue to look into this unless anyone can point out why this might be a waste of time...
In other business: nvidia has included a NV_pixel_data_range extension in its latest list of published extensions: http://www.nvidia.com/dev_content/nvopenglspecs/GL_NV_pixel_data_range.txt
this should allow much faster texture uploads under windows and linux when using nvidia drivers.
This introduces the more general problem of how to handle openGL extensions under GEM. At the moment extensions are handled at compile time and in a fairly ad-hoc way... perhaps something like GLEW would be useful (altho it doesnt support OS X) http://glew.sourceforge.net/
Daniel
Daniel
thanks for doing all that research. i'm going to post my proposal for the color-space stuff in the next 24hrs. basically i'm going to suggest that the start of the chain sets the format and conversion is done only in special cases (i.e. no auto-conversion). i'm also going to propose a system for proposals!
This introduces the more general problem of how to handle openGL extensions under GEM. At the moment extensions are handled at compile time and in a fairly ad-hoc way... perhaps something like GLEW would be useful (altho it doesnt support OS X)
we already do this on OSX. we have some sgi code that checks for the string in the driver. it's very simple and should be cross-platform.
cgc
chris clepper writes:
This introduces the more general problem of how to handle openGL extensions under GEM. At the moment extensions are handled at compile time and in a fairly ad-hoc way... perhaps something like GLEW would be useful (altho it doesnt support OS X)
we already do this on OSX. we have some sgi code that checks for the string in the driver. it's very simple and should be cross-platform.
ok... great.
does that code handle the annoying explicit binding requirement for extension functions under windows? (a call to wglGetProcAddress is required for each extension function)
i had a play around with the nvidia pixel_data_range extension last night... strangely enough it seems that the GL_BGR texture format can't be used with this extension... annoying because that format and YUV are usually the only pixel formats that Windows video codecs can produce without explicit conversions... Also, GL_RGBA can't be used, only GL_BGRA... so here's another case where pixel formats can be problematic, hardware dependent and complicated...
daniel
-
bbogart＠ryerson.ca -
chris clepper -
daniel heckenberg