Removed valueHint from effect parameter and turn all values form QVarian...

[daschuer]

...t into double

While testing the Goaslicer #337
it turns out, that all other value hints, other than VALUE_FLOAT did not work.

This is due to the fact, that a knob gets out of sync if it is turned to other values than full integer in case of an integer value.

If an effect needs integer or boolean parameter, the can expressed as a double as well. The quantization and rounding should be done at the effect, if required.

The feature of the QVariant to be invalid was not working, since it defaults to a double value range of 0.0 ... 1.0 anyway. These are the new defaults if no value is explicit set in the manifest.

This pull request cleans up the code and the effect interface a bit. The performance improvement should be only marginal.

[rryan]

If an effect needs integer or boolean parameter, the can expressed as a double as well. The quantization and rounding should be done at the effect, if required.

I think having actual types to parameters is important and helps avoid bugs since the programmer is encouraged to handle each case separately.

If an effect needs integer or boolean parameter, the can expressed as a double as well. The quantization and rounding should be done at the effect, if required.

This will result in duplicated code in the best case, and inconsistency bugs in the worst case.

The feature of the QVariant to be invalid was not working, since it defaults to a double value range of 0.0 ... 1.0 anyway. These are the new defaults if no value is explicit set in the manifest.

I don't think I follow.. could you clarify?

[rryan]

If an effect needs integer or boolean parameter, the can expressed as a double as well. The quantization and rounding should be done at the effect, if required.

In the event of an integer parameter, you want the widget to reflect the quantization so the user understands the knob has individual gradations. This isn't possible if the quantization happens inside the black box of the effect.

[rryan]

If something isn't currently working with the value hints let's fix that. No reason to throw the baby out with the bathwater. Also there is future work to be done on connecting effect parameters to the GUI. Right now everything is geared towards float values. Button and integer support are not there yet.

[ywwg]

This looks like something that should have just been a bug report first, rather than jumping ahead and trying to rewrite a lot of stuff. Can we start over with a bug report and then discuss what the best solution might be?

[daschuer]

Here it is: https://bugs.launchpad.net/mixxx/+bug/1378195

[daschuer]

Please have a look here:
http://www.mixxx.org/wiki/doku.php/effectparameter_scaling

[daschuer]

The feature of the QVariant to be invalid was not working, since it defaults to a double value range of 0.0 ... 1.0 anyway. These are the new defaults if no value is explicit set in the manifest.

I don't think I follow.. could you clarify?

It is about the remove of "hasMinimum()" the code always has a minimum and it is required to work correct.
Thats why I have removed this and similar part of the code.

[daschuer]

If an effect needs integer or boolean parameter, the can expressed as a double as well. The quantization and rounding should be done at the effect, if required.

In the event of an integer parameter, you want the widget to reflect the quantization so the user understands the knob has individual gradations. This isn't possible if the quantization happens inside the black box of the effect.

This is a valid request. But I cannot see how we can achieve this in an optimum way on a Rotary widget with our limited Skin Space. Because of that, Nicu has introduced the Enum Button including the fly-out menu.

[daschuer]

If something isn't currently working with the value hints let's fix that. No reason to throw the baby out with the bathwater. Also there is future work to be done on connecting effect parameters to the GUI. Right now everything is geared towards float values. Button and integer support are not there yet.

I have some ideas how the support should work. The current solution does not fit the requirements well.
I am very please with Nico solution in his LV2 Branch. But we need some more options to set up the desired scale. Currently the picked scale (Behavior) feels somehow random.

But I cant come up with complete solution for this on my own. So I need your support.
Do you have time to start such a discussion now?