MXXX: Getting parameters to match when they're being fed the same Multiparameter value
-
- KVRist
- 452 posts since 21 Jul, 2018
I've been having 2 separate issues with this, so I'll list them separately:
1) Sometimes (but not always, and I've yet to figure out why) when I set up a multiparameter to control 2 fields that are both measured in dB, the parameters panel gives me dB for the range and value options on the first parameter, but forces % for the second one.
I can't just check "use the first parameter's range" since one might be half the other, etc. Changing the value mode in the behavior mode to use the units from the first parameter doesn't do it since that just changes the units on the MB's slider, and not for the parameter being set.
I feel like I must be missing something obvious here. If the parameter should be in dB, but is instead showing %, how do I get the range and value type settings to reflect this?
2) Sending the same multiparameter value to two different parameters often results in them not having the same value for any but the edge (top or bottom) values. At first, I thought this might be a linear vs log interpolation issue, but I'm noticing that even in cases where the units match.
For instance, have a multiparameter send to both the threshold and ceiling parameter of a limiter module. Both are set up the same, so I'll use the example of a value of -12, and a Max value of 0 in "interval" mode (though I've tried the same thing using the other modes). Now, crank the multiparameter dial to one extreme, and both say 0dB. Crank it to the other, and both say -12dB.
Looks great... until you crank it to anything other than either extreme. In that case, whichever parameter is first matches what's on the multiparameter, and whichever is second does not.... and is in some cases nowhere near the intended value.
Since they're using the same units, and there's no custom transformation shapes enabled to throw off the interpretation, my guess is that the issue comes down to the fact that they have different ranges to begin with, so the interpolated (between the top and bottom) values are being interpreted according to some sort of percentage of their relative ranges, or something like that. Dunno. Could be something else. That's the only explanation I could think of.
How do I just pass the same exact value to both fields via a single multiparameter?
1) Sometimes (but not always, and I've yet to figure out why) when I set up a multiparameter to control 2 fields that are both measured in dB, the parameters panel gives me dB for the range and value options on the first parameter, but forces % for the second one.
I can't just check "use the first parameter's range" since one might be half the other, etc. Changing the value mode in the behavior mode to use the units from the first parameter doesn't do it since that just changes the units on the MB's slider, and not for the parameter being set.
I feel like I must be missing something obvious here. If the parameter should be in dB, but is instead showing %, how do I get the range and value type settings to reflect this?
2) Sending the same multiparameter value to two different parameters often results in them not having the same value for any but the edge (top or bottom) values. At first, I thought this might be a linear vs log interpolation issue, but I'm noticing that even in cases where the units match.
For instance, have a multiparameter send to both the threshold and ceiling parameter of a limiter module. Both are set up the same, so I'll use the example of a value of -12, and a Max value of 0 in "interval" mode (though I've tried the same thing using the other modes). Now, crank the multiparameter dial to one extreme, and both say 0dB. Crank it to the other, and both say -12dB.
Looks great... until you crank it to anything other than either extreme. In that case, whichever parameter is first matches what's on the multiparameter, and whichever is second does not.... and is in some cases nowhere near the intended value.
Since they're using the same units, and there's no custom transformation shapes enabled to throw off the interpretation, my guess is that the issue comes down to the fact that they have different ranges to begin with, so the interpolated (between the top and bottom) values are being interpreted according to some sort of percentage of their relative ranges, or something like that. Dunno. Could be something else. That's the only explanation I could think of.
How do I just pass the same exact value to both fields via a single multiparameter?
- KVRAF
- 2703 posts since 9 Jul, 2015 from UK
2. You were correct that the two parameters have two different curves. Ceiling goes down to -24db where threshold goes down to -80db.
Even though you have said that the range min values will be -12 for both, they do not line up as each parameter has different min and max values and therefore a different curve.
There are two ways to tackle this, although neither will be exact, I don't think, but will get you a lot closer.
You could use the transfer curve in the MP to compensate for the different curves.
Or use banks mode to lock the two values together at intervals.
Again use the code bellow in MXXX and I will demonstrate both techniques.
MP1 will use the transfer method and MP2 will use the banks method.
Even though you have said that the range min values will be -12 for both, they do not line up as each parameter has different min and max values and therefore a different curve.
There are two ways to tackle this, although neither will be exact, I don't think, but will get you a lot closer.
You could use the transfer curve in the MP to compensate for the different curves.
Or use banks mode to lock the two values together at intervals.
Again use the code bellow in MXXX and I will demonstrate both techniques.
MP1 will use the transfer method and MP2 will use the banks method.
Code: Select all
$eNrtVlt32jgQfu+v0HH3bUMwYMCcE9IDhCR0IbiQBPIobIEVhEQlucH8+h3Z2FyStOnpPq4fbHkumss3M9LFl82KoR9EKip40yqd2xYi3BcB5YumFel5wbW+XH66GEynU0W0BrJCn0HQQh3BGF4rErQxD7oB1ULu6FxL4MGeXY5njARNC3btSKGUAEsDEZCmVXaCdlH4+oBxH6+B0eKYiYWFrmQ8Ibo1nxNfqx5fR-oGU55YuHnojemWlOGnUnPPqg03p3WxioHuuvZZvdywUJ-yZWK+PxqvGdWaSCNWAlW7XDslg2YFZAd4078etpnwl4YKxDIQ20ceDSN96NIgYpp6WOIVgb1UnpvE9mOW3rpbd6o16-Iij9lEG2+JROOVEDrkRClQOberFppQHoiXNCm3mHNQ8ySZUwYGAAb4E5RrdM3wQrXBCQfc2BgIKzbE1mg0qrWaVXxPzDkVK55sLoUPzghpoxxF0LymjCWLcSheIEohHzGLiEpo9yH1k2wXD-RLaAhxShqQRPx9wfJHBSsfFXR+IVh8BQNU+gyq2d6V+JuFMCYMCoAEHosWBn37rALESEoR8aATAlKE7SofNtk9BrxEXmULdB0xdgf10rT6dEUh7wgsHhEsNE3q58k4k+mNj7uwpTX2l2lPXWOlD-pyX5MQhIfBraZVKKU9kfmZ9oYQy1ZIcHBFGI4T0puRjyByrMihsbFJbghd4GWaOWVMfMEDLOOdrZT76zxlIo+CRSuSVOZR4DnhJ5ksv5-Jyv+ZfCOTxbw6XyslHWHOgOMZd3lCsM0MTs+BNK47IVeYpaMZREbiJU3IEXO8JtmUNIMkQSJZpWLtGM2pVBqtMzMGvmydID-CfAGSjoVyeoq9OZdQCRVQ3l+wvg8lUaFgQW7QPncatZLj1su2W0kn5h-s3yGUQW7NgMRrcjA6IbOGks1jHyrIPi+5FZj0R7M5Hfgmeqjid8c3vGPzNvjs9i3m7sH6BJpTrEoInF92AGdtDlHrt6AzqupPketu9Gh3bPxekssfAfHyr+W25C6Hs1ZlW6j2SD3qN2YLz74dtePQLUfdglIVYT-fR86z28Fsxr5t+ktvI4et7T-h6O+HwkPvdjZkQ6-67PK47nj+UHKvwFWwFWQSLQvezXcefZ3Oa8+FR-+p1e1Nt8p7UYO7sU0GxCm0do975TaPoPmPUpDXWZYAiDmz6Vw1HtNnGnq16HvyRL3cp+qez-b8p5xf2-PXe77I+fU9X+-5P4n5pBxLrygKxkvL1-QHgVsI3DORKca0azpYk4WQcU+TVY-PBWpFOjSHuYW6A0yZWRi6+U4mE-hAT3RgiBFomzSBSZccbm+syTUawdZwEwU2DLfdTJvQQIcDaFYRSZ+gw0tRdmvIRIqDzPXi4fX48tO-vcur0Q==Jason @ Melda Production
-
- KVRist
- Topic Starter
- 452 posts since 21 Jul, 2018
OK, thx. Those are the two possible fixes I came up with too. The correction curve proved inexact and problematic, and I hadn't gotten around to trying the banks yet, but figured I could set up a separate bank for each 1dB increment or something like that.
Having the same issue here where I can cut and paste, but not from the snippet you posted. Is it possible this is a version issue? A friend of mine left his system behind, and I've been taking the opportunity to dig in and use his setup to test some Melda plugs I haven't used before, though I suspect everything on it is old as he's got end of life hardware that can't even run modern browsers, etc. He's actually still got 32 bit plugs running.
If so, I suppose I could audition a newer version. Don't know that he'd be ok with me messing with his system.
Having the same issue here where I can cut and paste, but not from the snippet you posted. Is it possible this is a version issue? A friend of mine left his system behind, and I've been taking the opportunity to dig in and use his setup to test some Melda plugs I haven't used before, though I suspect everything on it is old as he's got end of life hardware that can't even run modern browsers, etc. He's actually still got 32 bit plugs running.
If so, I suppose I could audition a newer version. Don't know that he'd be ok with me messing with his system.
- KVRAF
- 2703 posts since 9 Jul, 2015 from UK
Yeah, you got it. I just used 1db increments also. But if it is really important for them to match you could take the time and use more banks to get a better resolution.
Jason @ Melda Production
-
- KVRist
- Topic Starter
- 452 posts since 21 Jul, 2018
Is it always necessarily the case that parameters can't be dictated numerically via any other control, but rather via some sort of range-specific interpolation between end cases? Is there some way to force it to just be a number?
For instance, off the top of my head, If I were to do something like use the math module to multiply the value by 1, would that then process as a number instead? Something else along those lines? Bounce it through some other MP with some other range mismatch that undoes the first one?
I know. I'm a noob. Seems like the kind of thing that might have a solution, though.
For instance, off the top of my head, If I were to do something like use the math module to multiply the value by 1, would that then process as a number instead? Something else along those lines? Bounce it through some other MP with some other range mismatch that undoes the first one?
I know. I'm a noob. Seems like the kind of thing that might have a solution, though.
- KVRAF
- 2703 posts since 9 Jul, 2015 from UK
You will need to reword that question, I am afraid I am a little lost here.
"Is there some way to force it to just be a number?"
What is "IT" in this sentence?
Try to explain again in different wording.
"Is there some way to force it to just be a number?"
What is "IT" in this sentence?
Try to explain again in different wording.
Jason @ Melda Production
-
MeldaProduction MeldaProduction https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=176122
- KVRAF
- 14339 posts since 15 Mar, 2008 from Czech republic
1) Seems like there either is some problem, or the other parameter actually isn't dB. Please post some settings.
2) Some parameters are transformed somehow, so that it is easier to use (you'd be surprised how many design things are there most people won't even notice, but help the workflow brutally
). If that's the case you may be in trouble, because you'd need to perform some sort of inverted transformation using the multiparameter. That will never by 100% accurate probably. Anyways again feel free to post some settings.
2) Some parameters are transformed somehow, so that it is easier to use (you'd be surprised how many design things are there most people won't even notice, but help the workflow brutally
-
- KVRist
- Topic Starter
- 452 posts since 21 Jul, 2018
I must be missing something about the posting of code. Every time I use the code insert, it not only fails to format, but it erases everything in my post after the snippet. Should I be using quote instead or something like that?
Anyway, still experimenting to determine exactly under what circumstances MP forces the second parameter into % mode even though it is a dB parameter. Will report back when I can isolate which cases trigger this.
As for the mismatch, simplest case is sending an MP to both the threshold and ceiling of a limiter. Both within the MP are set to a value of -12dB, and a max value of 0db.
The entire point of doing this is to make them both match, yet they match only at the end cases (in this case, 0dB and -12dB.) In every other case, the first parameter matches the MP, and the second does not.
I have come to the conclusion this is the result of each interpreting the input according to it's own range rather than just accepting the user input, yet however sophisticated or necessary such interpretations may be, this appears to be stopping me from just doing something very simple and necessary. I just want the parameters to both match the value I set.
Open to any fix, but after much experimentation, the banks method seems overly complex and limited, and the custom curve method like a bunch of imprecise guesswork. Hopefully there is a much more straight forward approach, but if not, Is there at least some way to derive an inverse correction curve mathematically based on the ranges so I can calculate and apply it vs endlessly moving the dot and remeasuring?
Anyway, still experimenting to determine exactly under what circumstances MP forces the second parameter into % mode even though it is a dB parameter. Will report back when I can isolate which cases trigger this.
As for the mismatch, simplest case is sending an MP to both the threshold and ceiling of a limiter. Both within the MP are set to a value of -12dB, and a max value of 0db.
The entire point of doing this is to make them both match, yet they match only at the end cases (in this case, 0dB and -12dB.) In every other case, the first parameter matches the MP, and the second does not.
I have come to the conclusion this is the result of each interpreting the input according to it's own range rather than just accepting the user input, yet however sophisticated or necessary such interpretations may be, this appears to be stopping me from just doing something very simple and necessary. I just want the parameters to both match the value I set.
Open to any fix, but after much experimentation, the banks method seems overly complex and limited, and the custom curve method like a bunch of imprecise guesswork. Hopefully there is a much more straight forward approach, but if not, Is there at least some way to derive an inverse correction curve mathematically based on the ranges so I can calculate and apply it vs endlessly moving the dot and remeasuring?
-
- KVRist
- Topic Starter
- 452 posts since 21 Jul, 2018
Is there, perhaps, just some general formula to derive an inverse curve to get two parameters with different ranges to match for all interpolated values?
Example: Limiter ceiling has -24 - 0dB range
Limiter threshold has -80 - 0dB range
Is there some formula, rule of thumb, or at least starting point to bring them into alignment? Does it depend on the endpoints for each if the full range isn't being used?
If you were trying to get them to match up (and needed more intermediate options than are reasonable via banks method), how exactly would you go about tuning the response? I've pretty much just been guessing and measuring, guessing again and measuring, guessing again and measuring...
Example: Limiter ceiling has -24 - 0dB range
Limiter threshold has -80 - 0dB range
Is there some formula, rule of thumb, or at least starting point to bring them into alignment? Does it depend on the endpoints for each if the full range isn't being used?
If you were trying to get them to match up (and needed more intermediate options than are reasonable via banks method), how exactly would you go about tuning the response? I've pretty much just been guessing and measuring, guessing again and measuring, guessing again and measuring...
- KVRAF
- 2703 posts since 9 Jul, 2015 from UK
I can't imagine a scenario where they need to be EXACTLY the same. Just use the banks method to get them closer together.
After all if you are making MPs then you must be accessing them from the easy screen in which case you can not see the parameter values anyway and you will just be using/trusting your ears. Using your ears you will not be able to tell the difference between 0.05db.
So why does it matter?
After all if you are making MPs then you must be accessing them from the easy screen in which case you can not see the parameter values anyway and you will just be using/trusting your ears. Using your ears you will not be able to tell the difference between 0.05db.
So why does it matter?
Jason @ Melda Production
-
- KVRist
- Topic Starter
- 452 posts since 21 Jul, 2018
Because they're not off by 0.5dB. Even within a greatly restricted range, they can be off by a significant margin, and it's not only noticeable, but stops the rest of the chain from functioning properly.
The mismatch in particular between intended and resulting values for limiter threshold vs ceiling can actually compound to the point where the real world result is even more pronounced than even the (multiple dB) numeric mismatch would indicate. It starts actually getting much worse as they begin moving, and the mismatches cause wide swings in resulting behavior as the movements don't match.
I've measured the effects of all of this. I'm not guessing. I started measuring BECAUSE of what I was hearing, not despite it.
In this case, at least, everything that follows is entirely predicated upon the accuracy of those first two parameters. If they're off, the rest of the chain is nonsense. Imagine, for instance drawing a hard line saying everything on this side of the line gets processed this way, and everything on the other side gets processed that way. Now move the line at random. If the line itself was critical and not arbitrary, the plug no longer works.
I thought for the longest time my idea just didn't work. Turns out it does... it's just the parameter mismatch causing the problem. I know that because I can MAKE it work by forcing a match by setting each individual parameter by hand. I'm just trying to improve on that workflow if possible.
To be clear, I'm not complaining, I'm entirely solutions oriented. It occurs to me that the mismatch is not random, but the specific result of a mathematical calculation behind the scenes based upon variables that are visible to the user. It stands to reason, then, that there might be a way for the user to make that same calculation, and apply it's inverse transformation. I'm just not sure what that calculation is, so I"m asking.
EDIT: Just wanted to add that if it is the case that some sort of inverse curve can be calcultaed, but that having restricted ranges complicates this, I could use the full range. It's not ideal from the control knob perspective, but it's minor, and much more important to get them to match as they sweep.
The mismatch in particular between intended and resulting values for limiter threshold vs ceiling can actually compound to the point where the real world result is even more pronounced than even the (multiple dB) numeric mismatch would indicate. It starts actually getting much worse as they begin moving, and the mismatches cause wide swings in resulting behavior as the movements don't match.
I've measured the effects of all of this. I'm not guessing. I started measuring BECAUSE of what I was hearing, not despite it.
In this case, at least, everything that follows is entirely predicated upon the accuracy of those first two parameters. If they're off, the rest of the chain is nonsense. Imagine, for instance drawing a hard line saying everything on this side of the line gets processed this way, and everything on the other side gets processed that way. Now move the line at random. If the line itself was critical and not arbitrary, the plug no longer works.
I thought for the longest time my idea just didn't work. Turns out it does... it's just the parameter mismatch causing the problem. I know that because I can MAKE it work by forcing a match by setting each individual parameter by hand. I'm just trying to improve on that workflow if possible.
To be clear, I'm not complaining, I'm entirely solutions oriented. It occurs to me that the mismatch is not random, but the specific result of a mathematical calculation behind the scenes based upon variables that are visible to the user. It stands to reason, then, that there might be a way for the user to make that same calculation, and apply it's inverse transformation. I'm just not sure what that calculation is, so I"m asking.
EDIT: Just wanted to add that if it is the case that some sort of inverse curve can be calcultaed, but that having restricted ranges complicates this, I could use the full range. It's not ideal from the control knob perspective, but it's minor, and much more important to get them to match as they sweep.
-
- KVRist
- Topic Starter
- 452 posts since 21 Jul, 2018
I actually can't though. It could still be off by several dB because while that works for the values set by the MP's themselves, the actual values are the dynamic result of various sweeps between those bounds as determined by various LFO's and envelopes whose bounds are set by the MP's, but who's interpolated values are not.
For instance, if a parameter sweeps between 0 and some user bound, I can use banks to force the numeric accuracy of the bound, but the sweep itself is still subject to the interpolation. I've seen mid-sweep values off by more than 3dB.
I can get closer by endlessly guessing at custom correction curves, but since the values that determine the range interpolation in the first place are user-viewable (I can see the range of each parameter, and unit type if that's a factor), I should, in theory, be able to use that information to counteract the forced curve rather than simply guessing.
For instance, if a parameter sweeps between 0 and some user bound, I can use banks to force the numeric accuracy of the bound, but the sweep itself is still subject to the interpolation. I've seen mid-sweep values off by more than 3dB.
I can get closer by endlessly guessing at custom correction curves, but since the values that determine the range interpolation in the first place are user-viewable (I can see the range of each parameter, and unit type if that's a factor), I should, in theory, be able to use that information to counteract the forced curve rather than simply guessing.
- KVRAF
- 2703 posts since 9 Jul, 2015 from UK
Have an MP set up to control the ceiling and threshold parameters. Set it to banks mode and use 120 banks to lock the two together with no more than 0.1db difference. Set it so that it will not be visible on the easy screen, this will just be a dummy to keep them locked together.
Now instead of modulating the parameters directly just modulate the dummy MP instead.
I would then use a second MP that will be shown on the easy screen to set the value. This MP will actually control the modulators "value"
I would recommend that the modulator is set to "Up and down" not "interval" then you can set up a 3rd MP controlling the modulators "Range". This 3rd MP will then essentially be a "Modulation amount" control.
Now instead of modulating the parameters directly just modulate the dummy MP instead.
I would then use a second MP that will be shown on the easy screen to set the value. This MP will actually control the modulators "value"
I would recommend that the modulator is set to "Up and down" not "interval" then you can set up a 3rd MP controlling the modulators "Range". This 3rd MP will then essentially be a "Modulation amount" control.
Jason @ Melda Production
