On Aug 20, 2013, at 12:30 PM, Dieter Dave Becker <
email@hidden> wrote:
Hi There ;-)
I am having a problem (sort of) pertaining to the Subject above…
1) If setting parameterMin to anything other than sliderMin : The Slider won't appear after compiling.
Same goes for parameterMax & sliderMax…
Question: What use are they ?
They should appear have an effect unless you've mixed them up. Are you seeing any output in the console log? If you get them backwards (make slider min less than parameter min, make slider max greater than parameter max, or swap min and max) the results are undefined. But if that happens, you should see something logged to the console.
When set up and working properly, the parameter min and max define the range of the parameter. The slider min and max define the slider's range. So you might have a parameter that can go from -10,000 to +10,000, but that's a really wide slider range, and probably not useful for users. If you set the slider range to, say, -100 to 100, then the slider is easier to use and users can scrub the printed value to go above or below that up to the parameter limits. (By scrubbing, I mean, simply click and drag on the number next to the slider.)
We use this is several of our built-in plug-ins, and have not received any bugs about it not working, so I believe it's working in the current shipping release. Let me know if you find that not to be the case.
2) Regardless of the decimals after the point motion provides nothing more than 2 decimals…
Question: How do I go about obtaining greater precision -- using math after creation of fader ?
The UI will never display more than 2 decimals, except when you double-click on the value to edit it by typing in a new value. It's very rare for more than 2 decimal points to be useful to users. In those cases, you may want to make the slider cover a larger range and in code divide the value by some amount. For example instead of going from 0 to 1 and using 3 decimal places, make the slider go from 0 to 1000 and divide the value by 1000 in code.
Also note that regardless of the range or decimal places printed, the user can type in a value by hand and we'll honor that (up to, 4 places after the decimal).
3) The Delta has zero effect on anything
Question - What use is it ?
It's used for giving the user more precise control over the values. If you click once on a value to select it, you can step up and down with the up and down arrow keys and it should increment by your delta value. Alternately, you can click on the value (not the slider, but the printed number) and drag, and it should also go up and down by the delta increment.
Furthermore, if you hold down the option key while scrubbing the value, you should see that it offers more precision. Holding down shift does the opposite - it moves by larger amounts than the delta. Shift also works with the arrow keys.
You can test all of this with the built-in Brightness plug-in.
In case I did not make myself clear… Below are the parameters in doubt ;-)
defaultValue: 0.0
parameterMin: -1.0
parameterMax: 1.0
sliderMin: -1.0
sliderMax: 1.0
delta:0.001
Those look valid to me. Are you seeing any console output indicating an issue? Also, I forgot to mention that the default value must be between slider min and slider max (as it is above). Otherwise, you'll see some console output and your parameter may not get created or may not get created properly.
4) Are all those parameters "old" parameters pertaining to a prior version of Motion and FCP ?
If so --- perhaps it would be a good idea to mention that in the SDK Manuals ;-)
Nope, they're all used today. If you find something isn't working, feel free to file a bug report and we'll look into it.