hi gem-devs!
it has been a long time since the last "stable" (ok, 0.87 wasn't that stable) release of Gem has been done. i think we should make this step sooner (or later)
what has to be done ?
just a few thoughts:
1. feature freeze: features that have to be done (yet): a) yuv_* -> pix_* (what is still missing ? eventually the objects would just have methods for yuv - only there shouldn't be any more yuv_objects) b) [pix_video] for firewire-devices on all missing platforms (linux) c) i'd like to have the new video/film classes rather than the old OS-dependent d) make [pix_write] work under osX e) make the output of [gemkeyname] platform independent. but how ?
2. documentation a) since chris is working on his tutorial (me, being lazy again) this might get into 0.88. (if not, it would be a pity which i could live with) b) clean up the code (as jamie has pointed out, the short description in the source-files should match the functionality)
3. make it run when compiled with gcc-3.2. (is the only problem that gltt is not compiled with gcc-3.2 ?) (a linux only problem, but i am not very experienced with compiler/linker internals; help would be appreciated)
X. make it stable ! a.) the openGL-wrapper doesn't necessarily have to be stabilized/tested. it is far too much work, and i was rather thinking of fixing things when they are used.
of course, i have forgotten the most important things. which ?
mfg.as.rd IOhannes
hi gem-devs!
it has been a long time since the last "stable" (ok, 0.87 wasn't that stable) release of Gem has been done. i think we should make this step sooner (or later)
yes, it would be nice to have a release if only for reference. maybe GEM 0.90 since there have been so many changes since 0.87 ;)
what has to be done ?
just a few thoughts:
- feature freeze:
features that have to be done (yet): a) yuv_* -> pix_* (what is still missing ? eventually the objects would just have methods for yuv - only there shouldn't be any more yuv_objects)
i've gotten just about everything moved over and most of the pix_objects converted to yuv. anything that hasn't been moved will be a new object with new implementation anyway. so yuv_ is dead...
b) [pix_video] for firewire-devices on all missing platforms (linux) c) i'd like to have the new video/film classes rather than the old OS-dependent
we are still working on the old objects to get playback even better and still have to work out the switching color-space on the fly issues.
d) make [pix_write] work under osX
i'm actually going to work on a pix_record object that records to a quicktime .mov. the initial version will only record the pix_ part of the chain, but adding a glReadPixels() to it to capture the whole render output is possible as well. this may remove the need for pix_write on OSX since the problem was with the lib used to actually write the buffer to disk.
e) make the output of [gemkeyname] platform independent. but how ?
- documentation
a) since chris is working on his tutorial (me, being lazy again) this might get into 0.88. (if not, it would be a pity which i could live with)
i will have a lot more time to work on the tutorials this week, and plan to add ones for texturing, movie playing, video input and video mixing.
b) clean up the code (as jamie has pointed out, the short description in the source-files should match the functionality)
yes this is needed. i have a lot of messy code that needs commenting and formatting.
- make it run when compiled with gcc-3.2. (is the only problem that
gltt is not compiled with gcc-3.2 ?) (a linux only problem, but i am not very experienced with compiler/linker internals; help would be appreciated)
X. make it stable ! a.) the openGL-wrapper doesn't necessarily have to be stabilized/tested. it is far too much work, and i was rather thinking of fixing things when they are used.
apart from some crashes when rendering begins and ends caused by objects not having a context to work with, GEM is pretty stable on OSX. i have had a few pd related crashes and one or two odd quicktime ones. a frozen release will help track down any bugs...
of course, i have forgotten the most important things. which ?
i can't think of too much, apart from maybe changing the names of a few objects to better describe what they do. i'll put this in another mail...
cgc
mfg.as.rd IOhannes
of course, i have forgotten the most important things. which ?
hi iohannes,
it would be nice if there would be a possibility to switch between single and double buffer on the fly
about the markex discussion: personally i hate the idea of again having some additioanl lib to compile and install but i understand the idea of putting it out of gem. a practicle solution would be to include it into another basic lib which "everybody" installs(if this is copyright wise possible) like your zexy - otherwise i think its not a very good idea to seperate thx
erich
On Mon, 28 Apr 2003 rat@telecoma.net wrote:
about the markex discussion: personally i hate the idea of again having some additioanl lib to compile and install but i understand the idea of putting it out of gem. a practicle solution would be to include it into another basic lib which "everybody" installs(if this is copyright wise possible) like your zexy - otherwise i think its not a very good idea to seperate
I propose making it part of the pd-externals package from the SourceForge CVS. This is rapidly becoming the base lib for Pd since so many externals have been merged into this package. And having all of the externals in one package makes it much easier to deal with name conflicts, which MarkEx has many (abs~, average, change, counter).
.hc
zen \ \ \[D[D[D[D
-
chris clepper -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
rat＠telecoma.net