hi all,
i would like to hear your opinions on this little problem:
new generation [pix_video] will support more video-backends then ever, and it will support setting loads of parameters of the video-device. what's more, since each device can have different parameters, there will be a way to query the available parameters. (e.g. my analog capture card has about 19 read/writeable parameters, including saturation, contrast,... whereas my fake pylon camera (kind of a "GigE emulation") claims to support about 24 different parameters like "ExposureTimeAbs")
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.
so the new system does it a bit more intelligent, and tries to store all the parameters in a bag, which is then sent to the current device at once. if the current device cannot handle a parameter in the current set, it will simply ignore it (e.g. my bttv card does not know how to deal with "ExposureTimeAbs", but it won't complain)
this also allows for "atomic" commits of a set of parameters, which makes a lot of sense, given that some parameters might need a restart of the entire device. example: my grabber card defaults to channel#0(TV), NTSC and the dimension is 64x64. i would like to change that to channel#2 (S-VHS), PAL and 640x480, and set the gain to 1.
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), and finally no more message to set the gain :-) the "hangs a second" is a exaggerated, but the hangs are usually noticeable.
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.
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) "set mode PAL" (again, triggering nothing) "set width 640" (...) "set height 480" (...) "set gain 1" (...) and finally: "set" which will apply all the settings at once.
in practice this could look like [set channel 2. set mode PAL, set gain 1, set(
do you think this is feasible?
an alternative would be to use a max-style property syntax, e.g. [set @channel 2 @mode PAL @gain 1( i like this less, because a) it would require special escaping if the property would have symbolic value starting with "@" b) it does not represent the idea of set of settings carried over to other devices.
the multi-message approach has obviously drawbacks as well, e.g. a) requires a special message to clear the complete set of settings 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.
the new interface will definitely have a way to commit several settings at once, but which one should it be? probably something completely different?
mfgasdr IOhannes
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"
hello,
this is nice.
i like the [set foo bar, set< approach, but i think "set" is not the best name for this massage.
maybe "set foo bar" and "apply"
Cyrille
Le 02/12/2010 15:09, IOhannes m zmoelnig a écrit :
hi all,
i would like to hear your opinions on this little problem:
new generation [pix_video] will support more video-backends then ever, and it will support setting loads of parameters of the video-device. what's more, since each device can have different parameters, there will be a way to query the available parameters. (e.g. my analog capture card has about 19 read/writeable parameters, including saturation, contrast,... whereas my fake pylon camera (kind of a "GigE emulation") claims to support about 24 different parameters like "ExposureTimeAbs")
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.
so the new system does it a bit more intelligent, and tries to store all the parameters in a bag, which is then sent to the current device at once. if the current device cannot handle a parameter in the current set, it will simply ignore it (e.g. my bttv card does not know how to deal with "ExposureTimeAbs", but it won't complain)
this also allows for "atomic" commits of a set of parameters, which makes a lot of sense, given that some parameters might need a restart of the entire device. example: my grabber card defaults to channel#0(TV), NTSC and the dimension is 64x64. i would like to change that to channel#2 (S-VHS), PAL and 640x480, and set the gain to 1.
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), and finally no more message to set the gain :-) the "hangs a second" is a exaggerated, but the hangs are usually noticeable.
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.
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) "set mode PAL" (again, triggering nothing) "set width 640" (...) "set height 480" (...) "set gain 1" (...) and finally: "set" which will apply all the settings at once.
in practice this could look like [set channel 2. set mode PAL, set gain 1, set(
do you think this is feasible?
an alternative would be to use a max-style property syntax, e.g. [set @channel 2 @mode PAL @gain 1( i like this less, because a) it would require special escaping if the property would have symbolic value starting with "@" b) it does not represent the idea of set of settings carried over to other devices.
the multi-message approach has obviously drawbacks as well, e.g. a) requires a special message to clear the complete set of settings 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.
the new interface will definitely have a way to commit several settings at once, but which one should it be? probably something completely different?
mfgasdr IOhannes
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"
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
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 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.
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.
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. You could query what parameters are available and get a list from the object to use to build the list to send it.
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.
Introducing custom new techniques for this stuff is a bad idea, 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?
.hc
On Dec 2, 2010, at 9:09 AM, IOhannes m zmoelnig wrote:
hi all,
i would like to hear your opinions on this little problem:
new generation [pix_video] will support more video-backends then ever, and it will support setting loads of parameters of the video-device. what's more, since each device can have different parameters, there will be a way to query the available parameters. (e.g. my analog capture card has about 19 read/writeable parameters, including saturation, contrast,... whereas my fake pylon camera (kind of a "GigE emulation") claims to support about 24 different parameters like "ExposureTimeAbs")
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.
so the new system does it a bit more intelligent, and tries to store all the parameters in a bag, which is then sent to the current device at once. if the current device cannot handle a parameter in the current set, it will simply ignore it (e.g. my bttv card does not know how to deal with "ExposureTimeAbs", but it won't complain)
this also allows for "atomic" commits of a set of parameters, which makes a lot of sense, given that some parameters might need a restart of the entire device. example: my grabber card defaults to channel#0(TV), NTSC and the dimension is 64x64. i would like to change that to channel#2 (S-VHS), PAL and 640x480, and set the gain to 1.
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), and finally no more message to set the gain :-) the "hangs a second" is a exaggerated, but the hangs are usually noticeable.
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.
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) "set mode PAL" (again, triggering nothing) "set width 640" (...) "set height 480" (...) "set gain 1" (...) and finally: "set" which will apply all the settings at once.
in practice this could look like [set channel 2. set mode PAL, set gain 1, set(
do you think this is feasible?
an alternative would be to use a max-style property syntax, e.g. [set @channel 2 @mode PAL @gain 1( i like this less, because a) it would require special escaping if the property would have symbolic value starting with "@" b) it does not represent the idea of set of settings carried over to other devices.
the multi-message approach has obviously drawbacks as well, e.g. a) requires a special message to clear the complete set of settings 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.
the new interface will definitely have a way to commit several settings at once, but which one should it be? probably something completely different?
mfgasdr IOhannes
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"
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
----------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
-----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.
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
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
----------------------------------------------------------------------------
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
On Thu, 2 Dec 2010, 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.
How many would be too many ?
Do these parameters often accept multiple values?
GEM just separated «dimen» into «height» and «width» to avoid that. OTOH, I have decided that GF would keep its multiple-value attributes, and that there would be more of them in the future.
_______________________________________________________________________ | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Thu, 2 Dec 2010, IOhannes m zmölnig wrote:
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.
You can achieve that with abstractions. Make [pix_video] an abstraction that picks [pix_v4l1], [pix_v4l2], [pix_ds], etc.
these people will now be relieved to learn that they can now finally control (most) parametesr.
congrats ! (that was one of the big reasons why I avoid using [pix_video] when I can)
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.
that's not a problem.
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 @-syntax is also used in Flext.
_______________________________________________________________________ | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Thu, 2 Dec 2010, 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 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.
I think it can be fine to destroy some simplicities, as long as it doesn't make it harder for the user. In the end, making things easier for the user is a good reason to increase complexity. However, there are ways to achieve it that are better than some others.
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.
The way I made it in [#in], there's a single class that handles "open" and "close", with dynamic patching to instantiate a handler of image, movie, camera, live screenshots, or generic data files. Some of them have things in common. For example, «bang» is known to all of them as meaning «fetch me a frame», whereas «size» is known to all camera handlers, «seek» is known to all movie handlers (though it's missing from one help file), ...
(similar things happen with [#out]).
a class can be a rather complex arrangement of methods and it's normal that it's like that. It's good to break things into smaller components but it doesn't seem like the parameters are the right place to do this. Instead I made one component per API and arranged them so that they have as many methods (and conventions) in common as it makes sense to have ; and then I made a general frontend for inputs ([#in]) and a visual frontend for cameras ([#camera]) which detects which parameters exist in a certain object and colours gui objects accordingly :
http://gridflow.ca/gallery/%23camera-2010.png
(here you can see that channel/tuner/norm/frequency are greyed-out because they don't exist at all, and then you can see minsize and maxsize are black-on-grey because they are readonly).
(maybe I didn't understand what you mean)
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.
I always thought that this gemwin way of doing things is terrible. I don't think that any other classes should have similar behaviour. When I set a property of a window, I expect it to be applied right away (or within a reasonable amount of milliseconds). Having to do «destroy, create, 1» all of the time is wrong.
_______________________________________________________________________ | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
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
-
cyrille henry -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
IOhannes zmölnig
-
Mathieu Bouchard