[GEM-dev] setting multiple parameters at once

Thu Dec 2 19:20:46 CET 2010

so what do you suggest?
[pix_video] does only capture and it allows to control the capture
parameters.
this is basically like it has always been and like all other video
capture objects for Pd work.

the only thing i think you could possibly mean, is that it would be
better to have [pix_v4l2] and the like, but i think it is one of the
strengths of Gem that it allows a patch regardless of the OS.

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

nobody needs to think about parameters.
until now, you couldn't set (most) parameters, so people could think
about it and bang their heads against walls because there was simply no
way to set (most) parameters.
these people will now be relieved to learn that they can now finally
control (most) parametesr.

people who never cared about setting any parameters will continue to
live happily in ignorance. they don't need to think about it any more
than they used to.

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

again, i think this is one of the great strengths of Gem (as opposed to
say pdp) that it provides a unified interface for all platforms.

another problem is, several devices using the same v4l2 backend expose
different parameters. there are some standard ones (e.g. "saturation")
but there are also custom parameters.

i guess you are not proposing to create a custom API for each camera out
there?

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

hmm, i thought what i'm talking about _are_ ordinary Pd-lists.

> You could query what parameters are available and get a list from the
> object to use to build the list to send it.

this is exactly how it is currently (svn) working.
the problem remains how to address multiple parameters.

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

this basically _also_ works with the way it is now (this is a sideeffect
of making the settings persistent when changing devices; in this case
you basically changing from "no" device to an existing one)

> Introducing custom new techniques for this stuff is a bad idea,the "
> 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?

because they don't work in some cases.
if Pd had lists of lists, then everything would be very simple.

as it is, Pd does not have lists of lists.

my interface ideas are not very new either:

the "@" syntax is borrowed from max/msp where they have been around for
ages (for object arguments, don't know about messages though)
it is basically the same as miller's cmdline-arg-like interface as seen
in e.g. [soundfiler]. i have to admit, that i don't like this interface
at all - everytime i use it i shudder.

the multi-message idea is not new either.
it is basically what you suggested with the "gemwin like" syntax.
another library that does this iirc, is iem_tab (and my only relation to
this libb is, that i'm working here; but i never touched a code in it)

mfgasdr
IOhannes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkz3430ACgkQkX2Xpv6ydvThegCfaR6SgLXQ6z0CAzawrl7jLXlf
3CMAoNNXSgg8PvKD0I/7yNfogpRHg5Hs
=P0jL
-----END PGP SIGNATURE-----