MXXX: Getting parameters to match when they're being fed the same Multiparameter value

[Annabanna]

Are you referring to routing the control data through the MP in order to somehow force a numeric rather than range based interpretation, or are you referring to setting up over a hundred banks, and sweeping through those banks so the interpolation errors are limited to the space between each bank? (each bank defining an individual point on a dotted translation curve)

Hmmmm... while that sounds like it could minimize any one particular error, it also sounds like it's taking a sweep that was smooth (even if the arc wasn't calibrated), and putting points on it so it no longer sweeps smoothly (100 sided polygon vs circle). I could be wrong about how that plays out, though.

EDIT: Just saw your second message.

OK. I get it.

ummm... sure there isn't an "easy button?"

I suppose the relationship between those two things is important enough to me on an ongoing basis to justify all that. I guess I can use that as a template for future limiter hacks.

[Annabanna]

I sometimes want them locked as a single value, but other times, need them locked to where they are offset by a ratio or constant (like one is half the other, or 2dB lower than the other). This doesn't appear to jive well at first glance with the banks method (Well, the ratio one might be doable via a shift in range), but I'm not very familiar with banks, so I'll need to take a closer look.

[MeldaProduction]

When you want multiple parameters to be somehow related, it is usually possible, but it's sometimes a bit like rocket science

[Annabanna]

When you want multiple parameters to be somehow related, it is usually possible, but it's sometimes a bit like rocket science

Ironically, though, that's not the problem I'm having at all. I've already worked out how to to link, unlink, offset, multiply, glide between set values with best fitted curves, and all the rest.

The one and only reason the whole ridiculously complex web of nested modulators and meta-controls isn't working properly at the moment comes down to something as basic as it gets:

The inability to get a parameter to just accept the value I'm feeding it.

Code: Select all

$eNqdVE1z2jAQvedXaJRriI3BxsxgMoSQTGZwSqEN9KjaC9YgLCrLSeiv78pfMbSncrF4u3r79u3ao7uPgyBvoDIu04B2b21KII1kzNNdQHO97fj0bnw1CjebTQZaI5yRa0ykZCqFYMcM4iXfJXrBUhABtQ2eaoUx5Jyl7KeAuICfvj+v+G9w8K7nuzcD32mwGctOBu863s3A8yiZL1dHwbUGZcJdDNm+fQnjDWfYoyRkH-PHL-dCRnsDB7SHzGEuNF8wxQ6A6VmjtZCyAgGRhngh8h3Hru0bpHmtPRj4g77r0fGoDGf1gTzmQrwgYUDn-MCRlqALZwAlm6LADxTREKzObbuOgIvC3U4XhV7rREGWSBFjm-at57jusN9zuu7ApWSiNYv2oYyxxCPLdMv0zwax+cr8DtLPebqfJixFICu0zKXcTxJg8QMIdiqgfzq2RFNYBu1iKx4DcvF0Ud9skBVEMo2ZOlW1ymiulMzTuK5fjt8MtvyhJXXKqxT5AazxyDo3qQGaQ2a273ya4wvAJg+wZQi9MpGDsdHteQPX94c9x0dPnrDkMaCzXzkT2C-OjXTI7Cvxig2cxVxLVfb9ItWBiXIxkXsp30vDzoLlyKflGIlFvtUTRAeOUO3Yp5TqXHLcn8iWq0yTYy3e7El9LlZsydIdZvYpafCLrUP1VfXPOtT6L56W9kax0+95Tt8fOvbAMbTWhdt-IWZEk0jzN1ggG2jS-lO+bFK1XkEciTHdHMajKdOwk+r0rOHwnG4lmeQ6kSqgmBQyLszB4Oa5Xq-xgZKmuEaQ6moUhch2TaNHHckSqfEjgWFcoWpz1jzWSYiLKHMVAcH8LRcYKt7IwkWrTrHCujmr-fkbX-0BRW6viA==

Here's the issue in it's simplest form: One MP. Two parameters. I've set the ranges to match, the units are the same, and yet you can see that when the MP slider is anywhere in the middle, the threshold is off in many cases by nearly 4dB. I've measured much worse mismatches when the behavior compounds, but even in this simple case, the margin of error makes it unusable as wired.

As I mentioned in OP, I understand the cause of the issue, but that doesn't make it any easier to fix. Is setting up hundreds of banks really my best option here?

If I gave the impression I'm trying to complicate things, let me clarify: I'm seeking to UN-rocket science things, and use an MP in the most basic possible way. The simple ability to get the parameter to accept the value I'm feeding it would automatically solve all the other related issues mentioned in this thread along with several others I haven't shared.

Is there a simpler fix?

[DarkStar]

Confirmed.

I did try setting up 24 Banks (1 per dB) but editing the Threshold values was a real pain as the banks scrolling kicks in too late (at 30? banks) and the banks get too narrow for comfort. Here, anything over about 16 banks gets too small:

>>> https://i.imgur.com/mEaYibn.png

@ Vojtech, can you have a look at having a larger minimum width and earlier scrolling?

The second thought I had was to adjust the Transformation Shape for the Threshold - but I could not work out a systematic way of creating the 'right' shape. Here is an approximation (paste it into a spare A-H slot in MXXX):

Code: Select all

$eNqtVt1zmzgQf89foaF9TAIIMDATu+M49l1m4tZn9+L0UQXZ6CwjnxCxnb++K-FR7DTTaae8sKz2W7-d5ebDYcvRM5UFE3nfcq8dC9E8ESnL132rVKuryPowuLiZPj09FVQpYBfoHQhaaCRyJQXnoDvOyVdO074F2iMpikKAxalIad-Cfnpri0R1Dj4fd3AwzAkXawv99e-9gr1QDDZ97FyGfq-ljUlx1HwX9y7DHvAfWL4xTh7mix1nSlGp5VyQcaJXbFDFkYWm5PAw+XTLRbLR3L7lYWCWXLEZkWRLQboYQR5kV9QpPDblCKMwdLE1uGlj11EfX6hEi60QKstpUYDKtRNYaMnyVOyr5P4meQ5qM0lXjIMDKBt8CZYrNOFkXdzqbKGGB11yz3EdHMdxACnab4n552L2mXEpEghGSAe1twGaE8a5IRaZ2EOWQj4SXtLC8D5nLDH1tDv6LjJiUDxnGGEcTSYW+gSZS5ZSc-K2Km5VIxy5zvAXVL3fV-U7AeNxhH+uar+6TkD4V5KnTgvtGg5zts7UjOSU-xrsYu8N3C0op4mi6YyXawYIcy5BclFKKco8HWUAG8rrdtLArx6NJCNfNASalJx-BPD2rQe2ZeAZQdgnDAs9mZi-gOPWwOK0hd8llHHT6VfYh0+VSVpkgqeuBjUOXBzEjhf4XmyhoVIk2VRNPSGF6lTpezNBwnW13Kpbm5Sq8gmxGWaUpHeUk6Nh-bBIcygSKWjX10JfZkZYPms0W86CJiJPiTzWvqrTn5e0EXkUvNxS01EnNWoZLVH8QGlq5sfgZslSlU1BQJQyoajbnA3qGhG70bEN5vR0PZ1GgzOGg24JlBL8KsCWhe7oioCA6WR9UYHXC4Moij1oHRieEOCub43-LwlnelS56AqN-0HVXB2nTIl6Nn8Uckt4NW7B01zsqzsxh9pl0WBqVOEE2dBHNUSgxjvaDMw6kpqqDRzRislCoV2Th4ZhQ6PxQc3rOaTBPCf5GpQAha1I5RriSE0KLdCBruPpeB68H7567vazfb8Pt9dY-GP+u1XIyI52R257Ldj3etiPYuyEsEPeP-3n+eqweX55iU7jMxaauZ9ALzrXsHRON0C1VnRhERwdzc4JfTfAgY+9EMffF0diXEdB14BzbuCghfwowLHvumHPD2ubXhjHoRP4fuzGb+8i10i7BtR18N0a22fofcUpAPLDRLFnCm0CfxWo+1FNSCE7Kxn8adhqAlYxUXQt5PFe0e19vhJoWKpMD3kQmhLGNaH5+r1cLuEFYY6gbSlkUl2pCbzrU8cjd2gOpnWD2bolf7+vL4Dq-C4NLr4BMfn1mA==

I used two interpolated banks, but it should be possible with a "Normal" MP

[Annabanna]

Confirmed...

Thx. I've been doing something similar. Unfortunately, the time and guesswork to create a manual correction curve turn out to be the least of the issues as the method only addresses the absolute simplest case where no other MP's or Modulators interact in any way.

All in all, I think I've spent more time trying to fix this one simple issue than I have on everything else combined as I started measuring in the first place because I was very clearly hearing the effects of parameters not accepting the values I fed them on several plugs, and needed to troubleshoot the errors. As I dug in, I began to realize that it was not only happening on all modules and plugs that contain control elements, but that whenever those control elements interact, it compounds.

The only way I've found to address this dynamically at all is to have not only separate controls, but entirely separate chains to address any parameters with different innate ranges. Have just 3 parameters you're trying to control? That could be 3 sets of controls and 3 entirely separate chains just to address this.

Even the simplest static case can often be off by nearly 4dB, but the much deeper problem is that any interaction between MP"s or modulators causes dynamic ranges which nullifies both the banks and correction curve methods entirely as they only address a single static range mismatch. (Unless the correction curve is automated which is why I was asking about a reverse-engineered formula for deriving the curve).

If that's not clear, take @DarkStar's corrected case as I did, and change just one thing (which is what would happen if another MP or Modulator were involved in even the most basic way). I changed the lower bound of the ranges so they are now -12dB to 0db. If you then tell the threshold parameter via the MP that you want it to have a value of -9dB, you can see the calibration doesn't translate when the ranges shift. I've noticed this same issue many times now among many Melda plugs... really any that have controllers like MP's and Modulators. It's not just an MXXX phenomenon.

Unfortunately, this shifting of ranges is what automatically and necessarily happens any time more than 1 modulator or MP interact. These compound cases are often MUCH worse than the basic ones... and the basic ones themselves often cause clearly audible issues.

Allowing the parameter to simply receive the exact value being fed would fix all static and dynamic cases automatically for this and every other module, and would greatly increase the output accuracy in many common examples of the plug's use (as well as for all other plugs that have mod/MP's)

[jmg8]

OK, I took a look at the code you posted here.
The thing is this. MPs work in percent NOT values.
So the ceiling at 50% will not be the same value in db as the threshold at 50%

I can see you have the MP set up to display value from 1st parameter, don't be fooled by this. It is not sending that value to the parameter, is is receiving that value from the first listed parameter and simply displaying it.

[Annabanna]

OK, I took a look at the code you posted here.
The thing is this. MPs work in percent NOT values.
So the ceiling at 50% will not be the same value in db as the threshold at 50%

I can see you have the MP set up to display value from 1st parameter, don't be fooled by this. It is not sending that value to the parameter, is is receiving that value from the first listed parameter and simply displaying it.

I more or less guessed as much in the OP.

When I started the thread, I was under the impression it could be addressed on the user end. I am now relatively convinced that it cannot, and that it rather consistently makes the simplest case excruciatingly complex if not impossible. I have resigned myself at this point to creating entirely separate nested control structures per parameter as there appears to be no other dynamic fix on the user end.

I'd say it's a safe bet that no new Melda user ever has set a value for a parameter under the assumption that it would instead set itself to some other value. Whether any of them actually measured the effects, broke down why the plugs weren't performing as instructed, or noticed how quickly the discrepancies compound (in some cases creating margins of error over 100%) whenever multiple MP"s or modulators are involved is another matter.

I just don't see any real solution here at all other than making everything and every control 2-3x more complex to separate the control structures. At this point I can just hope for the addition of the ability to simply allow MP's to pass their actual values... just like every single user would naturally assume it works in the first place.

While I can appreciate the possible need for more complex behavior under the hood, I have a hard time believing that the behavior most people want and expect isn't the exact behavior I'm trying to force. Frankly, I haven't encountered a single case where I'd have any reason to want it to do anything OTHER than what I'm describing... yet that seems to be the one thing it absolutely cannot do.

I understand the development concerns of backwards compatibility, not breaking existing presets, etc, but surely there must be a way to just add a checkbox or something that boils down to "Stop overcomplicating things and just do the exact thing I'm telling you to do." I've put a lot of thought into this, and I'm having a very difficult time figuring out any reason that shouldn't be the default setting.

I'm eternally optimistic, though, son in the meantime, I'll restate the original question: Is there a way to force the passing of a simple numeric value?

After all, if it is just a percentage, and being interpreted according to another percentage, then shouldn't it be possible to run it through something that undoes that exact ratio? The elements that CREATE the ratio (original ranges of the plugs) are visible, so there shouldn't be any guessing involved. OTHER ratios can easily be forced (divide a value by 2, etc).

For instance, shouldn't it be possible to do something like create the inverse relationship on another MP so the banks are set up to essentially neutralize the operations created by the first?

[jmg8]

I actually know of no other software that can do what you are wanting.
The MPs in most other software are called macros.
All the macros I've ever seen only display % values. This is because they could be controlling more than 1 parameter at the same time.
So if the macro was controlling say, frequency hz and level db at the same time, which value should it display? It cant do both, so it is normal to just show a percentage value.
Melda has a nice option to display the value of the first parameter, which is helpful.
But you cannot expect the MP to send the first parameters value to the second parameter also.

Let's say you have MP1 controlling "Threshold" (first parameter) and then "Frequency" (second parameter)
MP1 is displaying the first parameters value.
Now type in -6db into MP1 it will successfully set the threshold value to -6db, but do you expect it to set the frequency parameter to -6db? Obviously not because its value is in hz, not db.

Basically, THE DISPLAYED VALUE IS RELEVANT ONLY FOR THE FIRST PARAMETER.


You can switch, threshold and ceiling around and you will now see that it can set the other one correctly.
Only one at a time, not both.

[Annabanna]

I get it, but to be clear, I'm not expecting to be able to interchange units.

I'm trying to do something much, much, much more straight forward.

I have two parameters with the same units, and just want to set them with a single control.

Isn't that, after all, the fundamental purpose of having a MultiParameter?

Also to clarify, the use of percentages isn't an issue in isolation either. Units can be easily interchanged. The range values are already known to the plugin, and there are already much more complex transformations happening behind the scenes. Resolving this under the hood should be trivial. On the user end... not so much.

[Annabanna]

I've got another potential approach that might at least be able to consistently address any case where they are linked directly.

The one case where all mismatched ranges appear to resolve themselves is when the MP's slider is set to one of the ends of the selected range.

In other words, though the innate range of the ceiling is 24dB vs 80dB for the Threshold, if I assign a MP to both, and set both of them within the MP to a value of -12dB, and a max value of 0dB, then set the MP's slider value itself to one of those ends (0dB, or 12dB), then the parameters match. It's only ever for the values BETWEEN the selected range ends that they don't match.

If I then change that -12dB on both assignments to -7dB and again match that on the MP's slider, I again get matching values at the parameter.

So... if they always match when being fed from an MP who's slider is set to one of the range ends, I would think it would be possible to force this by routing not directly to the parameters, but through a MP where the ranges AND the MP's slider itself are simultaneously forced to the same value. If the MP is always only sending it's end case, then it should in theory be forced into the state where it always works out a match behind the scenes.

That's the idea, anyway. Trying it now, but wondering if it's just kicking the can down the road since sending the same value to the value field of both assignments within the MP might just then force a reinterpretation for one of them making it impossible to just set their ranges to match.

[DarkStar]

OK, I took a look at the code you posted here.
The thing is this. MPs work in percent NOT values.
So the ceiling at 50% will not be the same value in db as the threshold at 50%

I can see you have the MP set up to display value from 1st parameter, don't be fooled by this. It is not sending that value to the parameter, is is receiving that value from the first listed parameter and simply displaying it.

Yep, I understand that. If you look at the Ceiling and Threshold parameters in the Edit screen while changing the MP, you'll see that they change to about the same value (thanks to the Threshold target's Transformation Shape).

As for changing the bounds of the targets, that's an additional requirement.

[jmg8]

OK, I took a look at the code you posted here.
The thing is this. MPs work in percent NOT values.
So the ceiling at 50% will not be the same value in db as the threshold at 50%

I can see you have the MP set up to display value from 1st parameter, don't be fooled by this. It is not sending that value to the parameter, is is receiving that value from the first listed parameter and simply displaying it.

Yep, I understand that. If you look at the Ceiling and Threshold parameters in the Edit screen while changing the MP, you'll see that they change to about the same value (thanks to the Threshold target's Transformation Shape).

As for changing the bounds of the targets, that's an additional requirement.

Sorry, I didn't mean your code. I was looking at the first lot of code that was posted.

[Annabanna]

Yeah, forcing a match via matching the MP value to the user selected target endpoints appears to fail because it kicks the can down the road in the sense that the mismatched parameter's value can't be set automatically no matter where it appears.

Apparently, the MP value/endpoint method works manually specifically because it is manual... a human has to intervene and set the target points. I don't see any way of automating this.

That being said, the very fact that the plugin can snap to those matching bounds despite their differing percentage values tells me that the type of behind the scenes correction I'm suggesting is not only doable, but being done... albeit only for the static end case.

[DarkStar]

@ jmg8 - no problem

@ Annabanna - yep, but even for the static case, it's a lot of trial and error to get anywhere close.

Can we go back to the first steps? If I understand correctly, what you are looking for is

a means for two or more target parameters with the same units
to be changed by the same absolute value
(dB in the case, but it could be frequencies, time etc),
regardless of the range of each target,
but respecting the limits of the ranges.

Have I got that right?