I think your interface questions will be much easier if you don't try to do everything in [pix_video]. I think [pix_video] is great as it is, its simple and straightforward, and most of the time people will just need to get video in without thinking about parameters. Adding all this stuff to [pix_video] will destroy that simplicity.
Instead make a new über-pix_video object which has all of this option handling. Or even multiple objects if there are logical groupings, like if one interface or camera API always exposes the same parameters, make a custom object for that camera API and the object arguments can also be a way to set the parameters.
And instead of creating a new custom way to make lists that only works for this object, why not just use lists of parameters and use the standard, well-defined, well documented ways of building lists in Pd. You could query what parameters are available and get a list from the object to use to build the list to send it.
Or you could follow gemwin-style, and have all of the parameters settable when the render is off, then they'll only take effect once render/create is set.
Introducing custom new techniques for this stuff is a bad idea, especially when there are plenty of well-established techniques for doing this stuff in Pd. You like to reuse code, why not also reuse interface ideas?
.hc
On Dec 2, 2010, at 9:09 AM, IOhannes m zmoelnig wrote:
hi all,
i would like to hear your opinions on this little problem:
new generation [pix_video] will support more video-backends then ever, and it will support setting loads of parameters of the video-device. what's more, since each device can have different parameters, there will be a way to query the available parameters. (e.g. my analog capture card has about 19 read/writeable parameters, including saturation, contrast,... whereas my fake pylon camera (kind of a "GigE emulation") claims to support about 24 different parameters like "ExposureTimeAbs")
another thing that i found annoying in the past years, is that whenever you change a parameter on the camera (e.g. set the capture size to "640 480") and then open another camera, this will have a completely different size (e.g. falling back 64x64 if possible). also all other (of the few) settable parameters will not survive a device-change.
so the new system does it a bit more intelligent, and tries to store all the parameters in a bag, which is then sent to the current device at once. if the current device cannot handle a parameter in the current set, it will simply ignore it (e.g. my bttv card does not know how to deal with "ExposureTimeAbs", but it won't complain)
this also allows for "atomic" commits of a set of parameters, which makes a lot of sense, given that some parameters might need a restart of the entire device. example: my grabber card defaults to channel#0(TV), NTSC and the dimension is 64x64. i would like to change that to channel#2 (S-VHS), PAL and 640x480, and set the gain to 1.
with the current (well, 0.92) implementation this would result in a message "channel 2", restarting the video-transfer (Pd hangs for a second), a message "mode PAL", restarting the video-transfer (Pd hangs for another second), a "dimen 640 480" message, restarting the video-transfer (Pd hangs for yet another second), and finally no more message to set the gain :-) the "hangs a second" is a exaggerated, but the hangs are usually noticeable.
in the new implementation i want to have a way to accumulate the settings and when the user decides that he has set everything they want to, they say "doit" and all (applicable) settings are applied.
now i'm not sure about the nicest way how to do that. the current (svn) implementation has something like: "set channel 2" (doing nothing but adding the property "channel" with a value "2" to the settings-bag) "set mode PAL" (again, triggering nothing) "set width 640" (...) "set height 480" (...) "set gain 1" (...) and finally: "set" which will apply all the settings at once.
in practice this could look like [set channel 2. set mode PAL, set gain 1, set(
do you think this is feasible?
an alternative would be to use a max-style property syntax, e.g. [set @channel 2 @mode PAL @gain 1( i like this less, because a) it would require special escaping if the property would have symbolic value starting with "@" b) it does not represent the idea of set of settings carried over to other devices.
the multi-message approach has obviously drawbacks as well, e.g. a) requires a special message to clear the complete set of settings b) one can write a simple parser in Pd that turns the multi-messages into an "@" like single-message, whereas it's hard to do it the other way round.
the new interface will definitely have a way to commit several settings at once, but which one should it be? probably something completely different?
mfgasdr IOhannes
PS: of course the old messages will be kept for compatibility. "dimen 640 480" will simply be internally translated to e.g. "set width 640, set height 480, set"
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
----------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.