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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
