IOhannes m zmoelnig escribió:
And the common interface should probably be the one currently adopted by
pix_videoDS which is superior to the one currently adopted by pix_video
on Mac and Linux in that:
i'm not so aware of superiorness.
Well I meant it's a better interface (in my opinion) because of the
advantages I mentioned.
1) "open <ndevice>" and "close <ndevice>" is better than "device
<ndevice>" since it allows you to close a device without opening another
one
otoh, "close <ndevice>" is clearly faulty, as it allows you to close a
device that is not even open...
Yeah sorry, it is not "close <ndevice>" but "close" without arguments:
it closes the currently open device.
Of course you could send the message when no device is open, but that
shoud simply generate an error message: the fact that an error can be
generated doesn't mean that the interface is faulty. Even "device
<ndevice>" (which is just equivalent to a "close" [if a device is open]
followed by "open <ndevice>") may generate an error if you try to open a
device that is not available because in use by another application or
because it just doesn't exist (like "open 999")
as written in before "i have added an open/close" message now for the
new [pix_video] implementation, neither of which (currently) takes any
arguments.
I don't understand: what does a "open" message without argument mean?
Which device does it open?
Or is it equivalent to pix_videoDS's float (enable/disable) method??
2) it accepts a float (1/0) to enable/disable pix_video, i.e. turn it
on/off which is not the same as opening/closing the device
nevertheless, the exact naming of the methods is the least of my worries
now.
Nor do I worry about names; the relevant thing is that pix_videoDS has
(A) methods to open/close a device and (B) a method to turn the object
on and off, i.e. start/stop generating the output. Whatever you call
them, A and B are not the same thing and it's useful to have both.
--
Matteo Sisti Sette
[email protected]
http://www.matteosistisette.com
_______________________________________________
GEM-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/gem-dev
