On Oct 23, 2009, at 2:15 PM, Milton Aupperle wrote:
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?
you can set min and max values for the plugin inputs :) so yes, 0 to
23, or 0 to 4 is 100% possible. Ive done this on "shipping" plugins.
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.
This is 100% true. Its a shortcoming, I will grant you that 100%. I
would love to have true dynamic input port specifications.
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.
Just have a menu for those settings? I dunno, Im sorry if I am coming
across as 'pushy', I don't meant to be, its just that the value of
such a plugin is seriously diminished in my eyes if many options are
not accesible from outside of the editor.
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.
I hardly think the two are equivalent. I also think you are
potentially confusing two user bases. I would like to think that users
who use Quartz Composer Editor to create patches have the option of
doing things how they want. It is, in fact, a Development environment,
even if its pretty, and has 'noodles'.
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.
Because you set min and max values on your input ports like so:
Here is an input menu , NSInteger, with labels, defaults and min max
values:
if([key isEqualToString:@"inputLoopMode"])
{
return [NSDictionary dictionaryWithObjectsAndKeys:@"Loop Mode",
QCPortAttributeNameKey,
[NSArray arrayWithObjects:@"Loop", @"Palindrome", @"No Loop",
nil], QCPortAttributeMenuItemsKey,
[NSNumber numberWithUnsignedInteger:0],
QCPortAttributeDefaultValueKey,
[NSNumber numberWithUnsignedInteger:2],
QCPortAttributeMaximumValueKey,
[NSNumber numberWithUnsignedInteger:0],
QCPortAttributeDefaultValueKey,
nil];
}
Here is a floating point value, with min and max values:
if([key isEqualToString:@"inputVolume"])
{
return [NSDictionary dictionaryWithObjectsAndKeys:@"Volume",
QCPortAttributeNameKey,
[NSNumber numberWithFloat:0.0],
QCPortAttributeMinimumValueKey,
[NSNumber numberWithFloat:0.0],
QCPortAttributeDefaultValueKey,
[NSNumber numberWithFloat:1.0],
QCPortAttributeMaximumValueKey,
nil];
}
A checkbox boolean:
if([key isEqualToString:@"inputColorCorrection"])
{
return [NSDictionary dictionaryWithObjectsAndKeys:@"Color
Correction", QCPortAttributeNameKey,
[NSNumber numberWithBool:YES],
QCPortAttributeDefaultValueKey, nil];
}
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]
