On 23-Oct-09, at 11:28 AM, vade wrote:
I looked at inputs and but the first major stumbling block was I
could never figure out how to limit the values into a rational
range so that the user gets what they want. In most cases hardware
wants discrete value ranges so that the is actually changing
something with their supplied value. So if a controls supports a
range of 0 to 23, there is zero sense having it as a float of -1.0
to 1.0 I seem to recall someone complaining about this from lurking
on the list for almost a year to see what problems developers
people had with it before I dipped in my toes.
Why not make an integer input? Not all controls need to be double,
you can control what type of input datatype you want in the input
port property declaration?
Yes but -32767 to 32768 is not 0 to 23 or 0 to 4, is it?
Also inputs don't handle things like dynamic change. For example I
am using Device A and want to switch to using Device B or C or E
from within the same plugin. There is no way to handle that with an
input, because the end user would never know if and input value of
0.23 is device "B" or if it's Device "E".
Make a menu with the device listing in it, make an integer input
port and provide keys for the device names? You can create a dynamic
list of connected devices during patch creation.
I do not expect a static List. A user may plug in or unplug a device
at any time, but you can't update the input dynamically to what it's
range is. So when the user opens the GUI, we show what's available at
that instant, not at start up which is minutes, hours or days later
and may be completely misleading.
For example, if the user switches from NTSC to PAL Video, the
Video width, height and frame rate changes too, so that would need
to fed back to the input so they know it changed. But there's no
way to do it because input is one way. If they switch from single
field to interlaced to double field, that changes the height
parameters. And there is also the time it takes to tear down and re-
initialize the isoch channels when the user does something that
will cause it to need to be re-built, like changing format, video
size etc. either.
As a user, I would just expect the output video size to change
according to the specification I have selected. If I switch from PAL
to NTSC, just output an NTSC sized frame.
Yes, but the user can also set the of the video coming out from the
device too, and changing NTSC to PAL changes that too.
For NTSC the device can deliver 320x120, 320x240, 640x240, 640x480 and
for "E" series 720x240 and 720 x480.
For PAL its 384x144, 384x288, 768x288 or 768x576 and for "E"series
720x144 and 720x288.
So how will you rationally represent the above the above to the user
via an input? A dynamically adjusted GUI menu is 100% intuitive and
doesn't require tons of skanky overriding code.
And the DFG is a "simple" device compared to some of the Cameras I
work with daily that have hundreds of video sizes, frame rates, bit
depths etc.
Also to avoid re-sizing or scaling, it's important the user keep the
video sizes matched, which adds to the CPU / GPU load. For example,
you will get much better performance if all your patches operate at
delivered size and then optionally scale at the end rather than
upscaling / downscaling at different points.
I dont see the need for input sizes necessarily, or I am
misunderstanding what you mean by 'so that would need to fed back to
the input so they know it changed. But there's no way to do it
because input is one way"
Which is what I said. It's one way and you can't tell / show the user
than this Input changes other Input ranges or that it has been changed
itself.
That would be a very stupid thing to expose as an input and would
have a huge impact on Mac performance.
Do you expect users to be switching these settings that cause info
to be rebuilt often? As an end user who has used DFGs and other
capture devices for performance that exhibit similar behaviour, most
of those are a "set once" settings and not "continuously fiddle"
with settings. And btw, that does not break down the argument that
things messed with less often should be moved to settings custom
views. Just because I only change it once or twice does during setup
not mean I do not want to publish it soI can control it from outside
of the editor.
No I don't expect them to do it. But if it's an input, they can hook
up some generator patch to send the device to do this. If it's in the
GUI, then they can't do this except with a mouse click and they see
the consequences of their actions.
A good design prevents users from doing something truly stupid. That
would be like making electrical outlet plugs that use a fork shaped
plug, and then being surprised when someone electrocutes themselves
using a fork.
The last thing your missing is how does a user know what each input
does and what are expected parameters. They have to read a document
and lets face it, people don't read anything anymore. That's why a
GUI interface makes so much sense, it's all laid out in front of
them, they can adjust it at will and it has Tool Tip / Balloon Help
to give them more information. How many users are going to figure
out how to increase/decrease brightness when all you have is an
input on the side of the plugin?
Because you label your input port as "brightness"?
And how would they know that the expected range is 0 to 23 or 0 to 35
instead of - 32767 to 32678 for an integer? And please don't tell me I
should be scaling it down, that's just as idiotic as the arbitrary way
that it was done in QuickTime SequenceGrabber with having the controls
set to a fixed 0 to 65,535 range back in the 1990's.
Frankly inputs are not the way to solve this, unless I want to release
a "frankenplugin" that leaks like sieve on the Mac community.
If Apple had actually tested their apps and code samples for leaks
like proper developers (how hard is it to launch the Terminal.app,
type in top- w and watch the app for leaks when being used) , we would
not be even having this conversation and coming up with "hack"
solutions to try and fix it.
Later..
Milton J. Aupperle
President
ASC - Aupperle Services and Contracting
Mac Software (Drivers, Components and Application) Specialist
#1106 - 428 Chaparral Ravine View SE.
Calgary Alberta T2X 0N2
1-(403)-453-1624
[email protected]
www.outcastsoft.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to [email protected]
