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