score
score copied to clipboard
Automation does not respect custom min and max values
Steps to reproduce are the same as in #12 with a few additions:
Add the following to dbap=-model-maxhelp:
----------begin_max5_patcher----------
342.3ociREsbBCBD7YxWACOmpIQMN1ekNcbHgSEmDHCPrwww+8BGIVssSqOD
H2xd2srGWRHrJ8.XYzWouQIjKIDBBE.HiwDVKentgaQZrcMZUeKKMdj+Wcuq
Ab3gEinV24F.YOwSJvPc0wWx2LAFyzctChBvylxp3p8L56iT53t5CR09sFn1
EYsYY9rrTZ9pkgsUYg0hhYY2xwqIoZRR42Jjg2BNvrET7pn5xFOam1zxwpWF
.tljDVReRCQAe3uVS2IGLfUhcblWxf7DPm2dVTw6ly6ER878bo52cuEOk6U7
mtG98LtW9Bbqbw+Xe2YHHCViT88GLXaB3O5RVcuodRbSZm9UiDf0IUbmTqtm
zlGHcPJDf59okPZCCPzRx9g73ccm.icrlnT7iqiZSHbcJFJUwPrhLCbRNwuD
Q3Fuq47VVuINGFJWxhopEfQ0KGsFemul7IvAsNr0
-----------end_max5_patcher-----------
Modify the start and end values of /mydbap/audiogain in the i-score automation inspector as shown here:
Expected result: When playing, gain value during the automation should start from -16 dB and end at +7 dB.
Observed result: The automation starts at -96 dB and ends at +12 dB.
this is certainly not applied into the core. I assign to me.
@theod Mhhh I'm not sure. The curve is created in OSSIAAutomationElement::on_curveChanged_impl, and I scale the points by this min / max before putting them in the curve so this should just work ? I'll try tomorrow.
I had a bug in there that may have been the cause for this. Please test (I'll make a release tonight).
I realized this issue is maybe not an issue. it depends what we expect to change using Min and Max for an Automation. IHMO this should only change the view range for edition purpose.
as it is now this is changing the start value and the end value (changing the value into the start state and the end state). this makes 2 ways to access to the same datas which sounds wrong to me.
one things that makes me realized this misunderstanding was when I've created a sequence from -96 to 0. At this point the Automation Min and Max are -96 and 12 which is fine as the curve is also displayed with a little offset on the top as the curve doesn't reach the max bound.
but if I change 12 into 6 for example this is changing the end value and so my automation goes to 6 instead of 12 which is not what I expect to do here (if I want to change the end value I should do that into the end state).
or if those Min and Max fields should allow such access to start and end state I propose to rename them to "start value" and "end value" (but how can I change the range to display then ?)
what do you think @bltzr, @reno-, @jln- and @avilleret ?
I'm not sure to understand well the problem. In my point of view, min/max are attributes of Jamoma parameters. If I create an automation in i-score, it could be convenient that when it is created, the displayed range bounds to parameters min and max. But if I change parameters attributes, I don't want to see any change in my automation. If I put +12dB in my automation while my max values is now +6dB, then the value will be clipped on Jamoma side, not on i-score side. In the other hand, if I change the min/max display range, I don't want to change the automation value but only the display range. Automation could be out of the display range for me.
IMHO min/max in i-score are for the display range - it's good that they default to the attributes values, but :
- they should keep the values if changed manually by the user
- they have no relationship whatsoever with start and end values of the automation
@jcelerier : maybe a quick fix would be to rename "Min" and "Max" into "Start value" and "End value" as it is what they are related to for now ? or simply remove those fields while it is not possible to setup the range of what is displayed into Automation view and it can confuse users to be able to change start and end values from here ?

then we can create a more precise feature request to allow to manage the range of what is displayed into Automation view.
a quick fix would be to rename "Min" and "Max" into "Start value" and "End value" as it is what they are related to for now ?
No, they are really a min and a max.
In i-score the automation is stored between 0 and 1, 0 being the bottom of the box and 1 being the top.
Before sending it to the API it is scaled like this : api_y = iscore_y * (max - min) + min; with these factors.
ok I understand how it works for now. however min and max of a parameter should be centralized into the device manager window. and if the user changes them afterward i-score should propose to the user if he wants to apply the change to each existing automation (by clipping or scaling).
then in the inspector the min and max should be related to the display range for edition convenience.
mhh... what should happen if the address of the curve is missing in the device explorer ?
by default min and max are 0. and 1. so the default range to display if the effective range is missing should be also 0. and 1.
is this still a problem ? Maybe, we should add a field for the start and end values ?
Maybe, we should add a field for the start and end values ?
they can be changed in the state, though