[GEM-dev] setting multiple parameters at once

[IOhannes m zmoelnig]

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"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20101202/54140190/attachment.bin>