hello,
this is nice.
i like the [set foo bar, set< approach, but i think "set" is not the best name for this massage.
maybe "set foo bar" and "apply"
Cyrille
Le 02/12/2010 15:09, IOhannes m zmoelnig a écrit :
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