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