[GEM-dev] setting multiple parameters at once

[Hans-Christoph Steiner]

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 at 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.