[GEM-dev] setting multiple parameters at once

[Mathieu Bouchard]

On Thu, 2 Dec 2010, IOhannes m zmoelnig wrote:

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

That's normal, isn't it ? I wouldn't have it any differently.

However, 64x64 is a rather weird default size.

> so the new system does it a bit more intelligent, and tries to store all
> the parameters in a bag,

What kind of bag ?

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

Can't those restarts happen with a clock_delay(,0) ? That's the easiest 
way to get them merged into just one restart.

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

I thought about a kind of «push» «pop» interface where «push» would 
increment a counter, «pop» would decrement it, and then changes are 
applied whenever the counter goes back to zero or is already at zero. But 
in the end, I didn't choose that way, because [delay 0] ended up being a 
better idea. I think that there might be other circumstances in which 
push-pop is a better idea (though it could be better named...). I thought 
of a counter instead of a toggle because with a counter you can have 
several levels of abstractions nesting push, blah blah, pop, so that 
multiple pops wouldn't cause a refresh until the outermost update.

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

in Pd, it is customary to not write "set", but instead name the 
property-setters exactly like the names of the attributes. For example, 
you set the channel with "channel 2" and you get it using "get channel" 
(or just "get" to get all attributes at once). This example is from 
[#io.videodev], a plugin of [#in]/[#camera].

> in practice this could look like
> [set channel 2. set mode PAL, set gain 1, set(
> do you think this is feasible?

It's weird to have «set» without args do something fundamentally different 
than it does with args. There's also a difference between the two forms of 
«get» in my above example, but at least both do the same tasks, whereas 
the two sets work on different levels.

> a) it would require special escaping if the property would have symbolic
> value starting with "@"

can it happen at all ?

> b) it does not represent the idea of set of settings carried over to
> other devices.

why do you need to carry them over ?

btw you can use [attr] to do that.

> the multi-message approach has obviously drawbacks as well, e.g.
> a) requires a special message to clear the complete set of settings

What would «clear» do, and why would you need it at all ?

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

[s2l @] will remove a leading @ from a symbol, yes ?

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

In GF, this has been «size 480 640» and is likely to remain so forever.

  _______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC