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?
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.
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. 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"
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.
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"?
On Oct 23, 2009, at 12:21 PM, Milton Aupperle wrote:
On 22-Oct-09, at 6:13 PM, vade wrote:
Just as a developer and an end user, I really frown upon using view
controllers for custom QC patches. The reason is simple as this:
you cannot publish controls exposed in the view controller to the
host app since they have no outlets or inlets, nor can you publish
the view itself to the host app*
In short, if your patch has controls, please make them standard
input ports, so they can be used with 3rd party Quartz friendly
apps by other devs.
Just saying :). Why not make your controls parameters?
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.
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".
The current GUI way uses menu options that need to be verbally
designated or check boxes or radio buttons that make no sense to try
and implement with an input. Also some parameters are interactive
and changing one parameter changes others simply because that's how
the devices operates.
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.
That would be a very stupid thing to expose as an input and would
have a huge impact on Mac performance.
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?
So inputs could be implemented for some things, but overall they
make very little sense for the bulk off it and a GUI is necessary.
And the current architectures makes doing a GUI impossible if -
dealloc isn't ever called for the QCPlugin because of the catch 22.
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]
