I currently have several works on three continents which rely on pix_record working exactly as is. Given the low to mid six figure worth of the work and the fact that I cannot recall it to change it over, I am going to have to say the interface is fixed. Sorry but I made pix_record in order to make a living! It is central and critical to the work I am doing so any change would possibly fork my contributions to GEM. Hopefully I can make things work like I designed them, but if that is not possible then I will have to consider alternatives.
If you want to do you own thing on Linux then please make a separate object. I was actually going to suggest doing that in the other thread because, honestly, Linux is the odd man out on this one and should probably just adapt to the other two platforms as well as possible.
Sorry if this comes off as a bit harsh, but these changes are costing people time and money. This should have been discussed and agreed upon before it was done.
cgc
On 2/5/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
i am currently not really happy with the interfacing of [pix_record]. basically it has been taken from [pix_write], which was meant for single-frames and not for movies.
what i like least is that there are "bang" (for single frames) "auto 1/0" (for a series of frames) and "record 1/0" for turning recording on/off.
the bad thing is, that while splitting this object into several i have eventually lost the "record" message and now i am missing it :-(
however, i am wondering whether we really need the "auto" and "bang" ways of recording. if somebody really wants to do a "stop-motion" video they can well do so via turning the rendering on/off for the whole (sub)tree where [pix_record] lives.
i am thinking of making [pix_record] close to [writesf~], e.g it only takes an "open"-message to specify the filename, and a "start"/"stop" (or 1/0) pair to start and finish(!) recording.
does this sound bad? will it break patches?
mfg.a.arsdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev