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