[GEM-dev] setting multiple parameters at once

[Hans-Christoph Steiner]

On Dec 2, 2010, at 1:20 PM, IOhannes m zmölnig wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/02/2010 06:38 PM, Hans-Christoph Steiner wrote:
>>
>> 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
>
> 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.

I agree, I am mostly afraid of pix_video becoming a mega-object with  
too many messages so for most people it becomes a headache to use.  On  
the otherhand, I think also having objects that directly reflect the  
underlying API is also useful for people who don't need cross- 
platform.  I always intended on making a compliment library to [hid]/ 
hidio that was just a direct representation of the underlying OS's  
API, but never got to it.

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

No argument here against adding the possibility of controlling  
parameters.

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

Sure, but the 'apply' message is bizarre to me, I've never seen  
anything like that.

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

Do these parameters often accept multiple values?  If not, then you  
can just make lists of alternating pairs of value/parameter.  Or all  
in one big list, like :

query result from camera object: [parameters saturation brightness(
to camera object: [parameters 0.1 1(

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

The @ syntax is not common in Pd unless you are Thomas Grill. ;)   
CamelCase is also very common in programming, yet Max/MSP demonstrated  
its not a good idea in Pd/Max (think MouseState, etc).

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

I agree, but I think its better than the [set blah blah, set( syntax.

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


Your proposed syntax looks like the gemwin syntax if you remove all  
instances of the word "set", which it looks like you could easily do.   
Then you can reuse the existing method of "configure before things  
take effect" that exists in gemwin.

I think patching uses cases here would be the best way to figure this  
out.

.hc


----------------------------------------------------------------------------

                                               http://at.or.at/hans/