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
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
chris clepper wrote:
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.
1st of all, i was asking whether it was possible to change the API. the crucial words are "asking" and "possible". i still believe that the object-api design is a bad hack as it inherits (though not in an oo way of thinking) things from a different object, that does something else. but if it breaks things i can live with it.
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.
yes that is what i am trying to do. the point is, that you just seem to tend to ignore that there are more people in this boat, and that they should somehow live together, even if one is "the odd man out". of course you are free to ignore this.
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.
well, i totally agree on that. this is why i discussed the issues of the possibility to interface several different APIs a long time ago (early may 2003) quoting you back then: "Well I've spent the past two days trying to work out pix_filmNEW and a lot of that time I was cursing the name Johannes Zmoelnig. You've done it again! It's really poor form to make changes to classes that affect..."
obviously you didn't bother since then about other platforms (since it works for you). what i do not understand is, why you think that it is so stupid to find a solution that fits all? writing [pix_record] in the way [pix_filmNEW] and [pix_videoNEW] are written would have been just the same amount of work as writing like you did. however, now it was me who has "spent the past two days trying to work out pix_record and a lot of that time I was cursing the name..."
right, your commits didn't break anything as you have put just huge #ifdefs around them, but so what?
why are you not interested in giving people who work on more than 1 (or 2) platforms the chance to re-use their patches (e.g. i know people who chose Gem because they are working on w32 _and_ linux _and_ osX)
people who just use w32 and osX are free to choose max/jitter
hope this is not too harsh.
all the best mfg.asd.r IOhannes
The problem with this situation is that you broke working code and made no accommodations to anyone else who might rely on that code. You could have implemented the new API without touching pix_record at all by making a temporary file like pix_recordNEW or whatever. This would have allowed for a gradual transition of the code without breaking anything. The timing is really bad too because I really need the current CVS pix_record to work on OSX right now. I may or may not have a problem with the object's long term stability and the changes you made are not helping right now.
I will work on the common API version when I get the chance, but I have other things that come first. Also, the current version has been tested for many months, and I would like to do the same with the new version as well.
So can we put a transitional file in place for a little while until I get things sorted here? If you don't want to do a pix_recordNEW then I will commit a pix_filmQT or similar for the time being.
Thanks Chris
hi.
chris clepper wrote:
The problem with this situation is that you broke working code and made no accommodations to anyone else who might rely on that code.
of course it was not my intention to keep anyone from working because some objects are broken. however, due to the nature of CVS there is one accomodation: ~> cvs -z3 update -D "2006-02-01 00:00:00"
You could have implemented the new API without touching pix_record at all by making a temporary file like pix_recordNEW or whatever. This
right, and have the same chaos as we still have with pix_film. i am trying to avoid exactly that. have 2 (or 3) objects which provide approximately the same functionality (but unfortunately not exactly the same)
would have allowed for a gradual transition of the code without
yes it would have allowed for that. but nobody would have cared on the long term, because "it worked (on my box)"
breaking anything. The timing is really bad too because I really need the current CVS pix_record to work on OSX right now. I may or may not
that is why i would like to make right in the first place (what is "right" is of course subject to discussion) again, i am sorry if a broke your current working environment. however, the timing would have always been bad.
have a problem with the object's long term stability and the changes you made are not helping right now.
I will work on the common API version when I get the chance, but I have other things that come first. Also, the current version has been tested for many months, and I would like to do the same with the new version as well.
which is definitely a good point in your argument.
So can we put a transitional file in place for a little while until I get things sorted here? If you don't want to do a pix_recordNEW then I will commit a pix_filmQT or similar for the time being.
i would prefer if somebody (who has a working environment on os-x) looked into the code of the common API and fixes it. if this is not feasible (because of more urgent matters) i would prefer to name it "pix_recordQT", instead of naming the common api-object "pix_recordNEW"; and put a HUGE "#warning" pragma into the source-file so people get reminded that something needs to be done.
i guess we can all work this out.
mfg.a.s IOhannes
IOhannes m zmoelnig wrote:
hi.
if this is not feasible (because of more urgent matters) i would prefer to name it "pix_recordQT", instead of naming the common api-object "pix_recordNEW"; and put a HUGE "#warning" pragma into the source-file so people get reminded that something needs to be done.
done for now.
mfg.ad.s IOhannes
Thanks. There will be a few more commits on recordQT and then I can get to work on the changes you made. Once the new file is tested enough I will fully deprecate the old code.
cgc
On 2/6/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
IOhannes m zmoelnig wrote:
hi.
if this is not feasible (because of more urgent matters) i would prefer to name it "pix_recordQT", instead of naming the common api-object "pix_recordNEW"; and put a HUGE "#warning" pragma into the source-file so people get reminded that something needs to be done.
done for now.
mfg.ad.s IOhannes
-
chris clepper -
IOhannes m zmoelnig