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