[GEM-dev] setting multiple parameters at once

[IOhannes zmölnig]

On 12/02/2010 07:39 PM, Hans-Christoph Steiner wrote:
> 
> 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.


well, i understand both attitudes.
however, Gem has always tried to be as cross-platform as possible, and i
don't want to change that.

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

iem_tab

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

right now we have _set_ messages that have either 1 parameter or no
parameter at all (e.g. "do whitebalance now").
0 parameters is quite a common interface in video acquisition APIs,
though i don't remember lists of >1 parameters, but of course this
doesn't mean there won't be.

> Or all in one
> big list, like :
> 
> query result from camera object: [parameters saturation brightness(
> to camera object: [parameters 0.1 1(

but this gives us even more state.
the [parameters 0.1 1( message would do something completely different
if the query message beforehand was [parameters saturation brightness(
or [parameters packetsize whitebalanceoffset(

even worse, there are parameters that are readable but not writeable and
vice-versa.
> 
> 
> 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 thought about this, but this has several drawbacks:
- [Saturation( would query the current value (get), whereas
[ResetDevice( would change the device settings (set)
- what if the backend has a property that has a name already taken for
one of the reserved messages to [pix_video] (e.g. "open")

because of this i thought to not let the properties system interfere
with the base selector of the message.


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

definitely. i was hoping to hear more about existing use cases for
atomic settings of multiple parameters (personally i have used both, and
have not a very strong opinion, though i tend to favour the
multi-message system)


another option that comes to my mind is to provide messages for directly
setting the parameters (taking immediate effect), and for those who
really want to atomically commmit a set of settings, there would be a
more complicated way to do so.

e.g.
[set Saturation 10(
would immediately set the saturation to 10 (eventually restarting the
transfer if need be)

whereas
[advancedset Saturation 10(
would only remember the setting and not apply it, until it gets an
[apply( message.

(the selector names given above are arbitrary and can be changed to
something more intuitive, if somebody has good suggestions)

,art
IOhannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20101203/b4ff2bfe/attachment.pgp>