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