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

[jmg8]

@Annabanna

1. Your posts are way too long. Vojtech will never read this, he is way too busy. So I suggest that if you come to some sort of conclusion here that turns into a feature request. That you should start a new thread for the feature request and keep the text just a few lines. Try to be as concise as possible. Also title the new thread with "FR:" at the beginning. example "FR: Option to disable hidden transfer curves for parameters"

2. You now have a pretty good understanding. I agree with your top paragraph.

3. I still feel your missing something though. You describe the second parameter not being set the same as the MPs displayed value as an error. Please try to understand that the MPs displayed value is relevant for the first parameter only

And please please try to be more concise, I don't mean to be rude to you (I actually like to read your posts, you have a good use of language) but I do not have time to read this much. I do really want to help you and enjoy the discussion but please keep it short and to the point.

[Annabanna]

Big ideas in life rarely make punchy headlines or concise bumper stickers.

I'm quite clear that MP's display only the first value. It is, however, not the case that it is RELEVANT for the first parameter only. If that were true, the second parameter would not change as a result. If it's irrelevant, then it's just as correct for it to produce the second value by rolling dice. This is not a semantic issue, so let's jut blow past all the semantics with some basic common sense criteria we can all appreciate:

1) Is it intuitive and easy to use?

2) Is the user able to get the behavior they intend?

3) Are the results accurate and reliable?

I used basic math operations in the comparison of current vs proposed behavior specifically because we can all agree that 2+2 is not 5. It's objective. The bigger picture here is that intuitive behavior REQUIRES objectivity. This is about something much bigger than just precision.

A minor modification would make the plugin intuitive in ways it currently is not, and reduce current spaghetti flow charts down to a couple of clicks. Anyone who doesn't care about precision is welcome to consider it's 100% accuracy a mere side effect. Sure, it allows a user to enter 2+2, and get 4, but perhaps more importantly, behavior becomes so intuitive that even new users could now create much more complex interactions with less effort and brain twisting than it currently takes to do a single basic operation inaccurately.

It may actually not be possible to comprehend this suggestion fully without first digesting the terms as discussed in the last post because they decouple a range concept that is otherwise undifferentiated, so, as always, be careful what you wish for... but ask and ye shall receive:

Checking a box on the controller does two things: It allows linear behavior for the target, and it changes the range upon which all calculations are made to match the one set by the user in the controller. If that's not clear (and I suspect it's not), just read the definitions I gave (bold red) for MAX RANGE, OPERATION RANGE, AND CONTROLLER RANGE. Currently, operation range matches max range. Button instead resets operation range to match controller range.

This addresses the core issue causing all the anti-intuitive behavior, and allowing linear interpretation addresses the core issue causing all the... um... let's go with discrepancies. Once you wrap your head around how these two changes interact with the existing controller range, it's mind-boggling just how many aspects of the user experience are improved... whether you care about accuracy or not. That it can be done relatively simply without breaking anything is just gravy.

It's rather difficult to imagine a situation where you WOULDN'T want this proposed mode engaged. I haven't encountered a single one yet.

[jmg8]

I'm quite clear that MP's display only the first value. It is, however, not the case that it is RELEVANT for the first parameter only. If that were true, the second parameter would not change as a result. If it's irrelevant, then it's just as correct for it to produce the second value by rolling dice.

Again I disagree, still. The second parameter can have its value changed and still be not relevant to the displayed value at the same time. Trust me, it is only relevant for the first parameter because the second parameter is not displayed on the MP and therefore in almost every case will not have a value the same as the first parameter.

We should agree to disagree here, but don't worry, we can still be friends. After all, you are entitled to your wrong opinion

[Annabanna]

I'm quite clear that MP's display only the first value. It is, however, not the case that it is RELEVANT for the first parameter only. If that were true, the second parameter would not change as a result. If it's irrelevant, then it's just as correct for it to produce the second value by rolling dice.

Again I disagree, still. The second parameter can have its value changed and still be not relevant to the displayed value at the same time. Trust me, it is only relevant for the first parameter because the second parameter is not displayed on the MP and therefore in almost every case will not have a value the same as the first parameter.

We should agree to disagree here, but don't worry, we can still be friends. After all, you are entitled to your wrong opinion

They are linked not only by correlation, but causation. Call that whatever you like. "Irrelevant" strikes me as an odd choice, but so be it. Let's go with that.

What the mod does is match user input to output directly without all the nested kludges. In other words, it makes the user input relevant. 100% relevant to be precise. Saying that user input is currently irrelevant to output implies control is futile without the mod... so perhaps you do understand after all.

What is certainly irrelevant is the semantic distinction. It's a lovely tree, but if you were to chop it down and hear it fall, you might realize you're standing in a forest.

I think maybe I'll buy you a pint someday... though only if we promise NOT to talk about plugins.

[jmg8]

Actually all my friends have no clue about what I do. So if it is OK with you, I would prefer to talk about nothing other than plugins
I'm in Devon UK, how far are you? Pint sound good

[Annabanna]

Oops. Hit edit rather than quote, and erased this post with no way to recover.

[Annabanna]

Actually all my friends have no clue about what I do. So if it is OK with you, I would prefer to talk about nothing other than plugins
I'm in Devon UK, how far are you? Pint sound good

I know the feeling... though no one seems to know what I'm talking about here either.

I'm in Devon too.

... unless you're one of those pedantic nitpickers who's hung up on accuracy for no reason. If so, the margin of error is roughly 33% of the planet.

... but that's irrelevant.

Cheers

[Annabanna]

1. Open the transfer curve window (making sure to arrange the windows in such a way that you can see the target parameters)...

I'm nearing completion on the other development behind this project, but it all hinges upon accurate and predictable interaction between these two parameters which remains elusive.

It appears that the hidden transformation curve is imposed on the entire range. Unfortunately, it appears that when a user changes the range via a controller, the user imposed translation curve applies to the restricted range, but the developer imposed translation does not. As a result, any user imposed curve is will only ever be accurate for the range in which it was created. Expanding or restricting the range will necessarily throw any static curve out of calibration.

I see only two possible fixes. One is to somehow force an intermediary step right before the parameter that has a fixed tranformation curve and always remains full-range, then to feed it the controller message rather than the parameter directly, so it functions only to force full-range translation. Not sure if that makes sense or not. Just thought of it. Certainly would be simpler if there was a way.

The other option is to create a dynamic version of your curve... meaning a separate curve for each possible range value (in 1dB increments)... and animate between them. I would understand how to do that if it involved automating the points, but the points on individual parameter translation curves don't appear to be automateable, so...

Is there some way to do this via banks? Not as familiar there. Again, want a correction curve for 12dB range, another for 11dB range, etc... and automate between them so whenever the range changes, the correction curve does as well.

Is this doable?

[jmg8]

To help me better help you find a solution. Could you explain why you need the range to change? Why not just keep it at -12db?

[Annabanna]

To help me better help you find a solution. Could you explain why you need the range to change? Why not just keep it at -12db?

"It's complicated."

Those two parameters are being fed by a chain of modulators flowing from 4-5 separate MIDI triggers. It's not that the range might change. It's that it's constantly in flux.

If the translation to non-linearity doesn't happen until the last step when it hits the parameter, then perhaps there is a way to create a static full-range translation interface by parking a controller in front of the parameter that does nothing but translate the curve, and is always set to full range... then route to that dedicated interface controller as if it were the parameter itself so no matter what sort of range weirdness happened before that point, it's full range at the point of translation. Can't quite wrap my head around whether that makes sense or not. The Cabernet isn't helping.

Edit: I rearranged the modulator chain so the last one before the threshold has a fixed range... basically the concept above. I still have a manual control that changes the range, but I can find a way around that.

Chaining modulators is a hell of a crash course in signal flow. The ranges of the parameters perpetuate all the way up the chain. Chain a dozen modulators together, and the ranges on the last one in the chain reflect those in the first. Thanks to the range mismatch issue, it's painfully difficult to keep tabs on as the numbers mismatch at every stage. HOPEFULLY that's just due to the range mismatch, and it's linear turtles all the way down until the parameter where there's a single non-linear translation. If so, I should have it worked out soon so that I can use a single static curve.

If not, I may just renounce all technology, shave my head, and become a monk. It's worth mentioning this would all be reduced to a few clicks with the mod I mentioned... and without the rounding errors at each step in the chain.

[jmg8]

Wow, that is complicated. I don't know if it is because I have just woken up, but I didn't follow that much. I enjoyed the Discworld reference though.

Can you just paste me your settings so far and I will take a look. It will probably make much more sense for me to actually see it and interact.

The short answer is no. There is no way to change the correction transfer curve. As you pointed out, we can not modulate the points in the graph. Unfortunately, there is no way to do it in banks either, as the number of banks cannot be modulated.

There may be some workaround though, I am usually good at finding these hacks, I know the software inside out. However I really need to play around with your preset to do this, I am at my limit with trying to visualise this now.

[Annabanna]

Wow, that is complicated. I don't know if it is because I have just woken up, but I didn't follow that much. I enjoyed the Discworld reference though.

Can you just paste me your settings so far and I will take a look. It will probably make much more sense for me to actually see it and interact.

The short answer is no. There is no way to change the correction transfer curve. As you pointed out, we can not modulate the points in the graph. Unfortunately, there is no way to do it in banks either, as the number of banks cannot be modulated.

There may be some workaround though, I am usually good at finding these hacks, I know the software inside out. However I really need to play around with your preset to do this, I am at my limit with trying to visualise this now.

It's not just you waking up. It's genuinely complicated. I have trouble following it... let alone describing it... and it's still stage 1 of a 3 stage plugin... though it looks like stage 3 will have to be split into a separate instance due to limitations in the DAW's sidechain architecture.

I can't get into details, but I'm actually not at liberty to share the setup... as a whole, at least. As I work through some of the issues, I'm sure I will split out parts and share them as I recently did with the rebound easing type and damping control... which was one of many elements I needed to work out to make this work. It's not lost on me that any success is due in large part to the help on this board, and I come across individual bits that may be of use to others, I will continue to share.

As for the correction curve, for the moment at least, it looks like I may be able to complete the reconfiguration to force everything down to feed a single full-range controller... which unless I've missed something should hopefully mean I can resolve the non-linearity with a single full-range (actually 24dB range) static translation curve. Fingers crossed.

[Annabanna]

Now that I've thought it through, I think forcing a static translation layer should be quite simple. Instead of pointing directly to a parameter, direct the end of the chain instead to an MP's value with a full range, assign the MP to the parameter, and enable the translation curve. So long as everything behaves linearly before that point, it's, that should solve all static AND dynamic range cases since it converts to a static range before the translation. If you want your own non-linear behavior (dialing in a sweet spot, favoring one end of the range, etc), just do it twice.

Do it once, and impose your desired curve. Do it again by feeding the output to another MP, and impose the linear correction curve. The linear correction translation layer should always be the last step. If correct, I'll post a working example of the babel fish once I've got a working curve. Working on some other elements at the moment.

[Annabanna]

It works!

Using Jmg8's static curve by itself works if the range is static. With dynamic ranges, it can still be used, but it must be applied to a separate static translation layer.

MOD 1 steps through random values, and MOD 2 synchronously changes the range of MOD 1. Outputting from MOD1 directly and applying the curve does not work because the the range keeps changing, and any curve is only ever good for a single specified range. Outputting instead to a dedicated static translation layer forces static translation of the curve, allowing it to be used accuately

Watch the ceiling and threshold values. Note that every time the value shifts, so does the range of the modulator generating it. By introducing the static translation layer (MP1 a.k.a. Babel Fish), errors at this point are down to the tolerances of the curve itself, and the (assumedly minor, though unnecessarily convoluted) rounding errors resulting from the mismatched ranges.

Working on creating an accurate 24dB curve, but the process is rather cumbersome having to close the transformation window each time to access the MP, etc.

The whole concept of forcing a low poly interpretation just rubs me the wrong way, too, so I just had an idea, though I'm not sure if it's possible. What about building a little tool that makes it easy to dial in any two parameters? Something along the lines of a stereo meter where each parameter feeds one side of it, and a modulator quickly sweeps the range while the user opens the transformation shape, and without adding any points, puts it in freeform curvature mode, and just moves the single curvature dot until the meters match.

Want greater precision? So long as the meters could be calibrated to clearly show small differences, if the user wants more precision at that point, they could just zoom way in on the transformation curve, and move the dot again. Total time to dial in ANY two parameters with a perfectly smooth curve... dunno. Less than 30 seconds, I'd say.

Not sure if that's possible to set it up in such a way that the values would match on the meters though the controller percentages do not.

In the meantime, having a problem with the point method. Threshold value display seems to be limited to three places, so there are two decimal places if a single digit preceeds them, but for any thing under -10dB, there is suddenly only one decimal place. Any way to see higher precision?

Code: Select all

$eNrtWNtu2zgQfd+vENTXJuadFJCkSHMpAsStYbdN9pG1WFuoLHklKlvv1++Quli2U62LzT4sUAeIpOGc4cxwdIbU2ZvvqzR4MkWZ5Nl5iE9RGJhsnsdJtjgPK-v1RIVvLn47Gz8+PpbGWhCXwStQDIOrPE31ujTxNFks7URnJj0PkZNntoAxsHmT6S+pib343ae7WfKXIYBVWL2WJOpkN7rcgFwpVIvvp7N1mlhrCjeKAUEw3RcDgEQgHVepTSa60CsDI2XnlZ90ZlIztyaepNUigfjQa3D8cxutVJJxEV6c1cNlexPcVmn6Hgyeh-fJKgGzAcB2BGHw6Cf43aWixc12E-RqbpLU5-GEnColkOSKM3D5lV0WplzmaQyxoVPFRIQJFxGXJAwurdXzb+M8hsludWl7id6Gen-7oUk4zHOfZN+uljqD59I7dZ-n3y6XRsfXJtUbL5pCInRp+mZnSWwAlmSTVqmTzMw8z2JdbBqz9WhVFHmVxe1U9eKCB80P0tCqfM7TamVGF2ej3cR0gu6mhNqCYGAE-qOgKxgI67Ywf1RQixv-VHv+Pi9WOnUJbxfcr9VUZwsYZaCmv3-WaWVcXiWPWESFhLpSYdAh6nX0j25ZW-Xm7i0kv1o7OA8hgPHd9d3UQOXvuAazvM8toATAxkm2fZhBmKmZLXPrUc4uWLnJnkyar11GZski0+luOMFT7QMPt6rBLNPrj-m7Iokf-Zzb57bm8iSzwbzOVaoX5Vu4pU5zled2+Uj8yMfNGizXIgh39AMcUa3qdV5BnC4z30FuTjBE5Zegg+6Amslw7ePAzM4cOoU69+ZOhl35SauNUTCPiIoIkgyTl-GXgqnaYSgITAVTL2O3dRgxRQRw0IsYFW1yISMEmFRSxl7Gsuz8xRIz4LEXsqtk5zHi4jmj9HmoL59R+7LAa2XNOrizZoX8qiEqI+B2WC9gVCfGfg4puILMCEWArryc+MVAgpIIY6gcXoupV8c0IgxxRGmrzr2cCUU5Y5RK2egLHwyYVkwq7JqKF0tf6IFz7tqs7bLx+8PaFNpCCyqDyRJY2ScWgbsIYUwJTOijq6kCYttk8x36uTfZwhk78QkbOeb0-In-PX-usSSgqlTbvCiDE2ciwHDdYnHHtz-kUfyLRX+x6C8W-T+yqOQUC8ZJpPocymuaixASssehpFbmkQD26nEoIZhjFUVAlo0Z5lcOZEpSLgUWW2rFW9rcJ+v-nkNxfXE70r0zxcWeALmDy02cAC-uMpA7z4DKNP-TE+HuYM2ob-UXkwa3SbmEmNamOaf8YM-qxbWViSnmJrPl8dzdHV2Asq-qk4ivjJ9Hf2yPK+DyUq9NP4+d5ywSmClJkKLuSOUVgw9wsgSuNZ+yxJaOgWm4T8n7tep68OhQyJpaRwyL9ifb14minmwIrOj214I5NHM4lkkB9TYExh0-IhX1zAxBxIGvsMuggtKIEzIYJ+n52kI5f5Y5e6COwVXEGXgp8GA+YNOz7x8hbAhBDxNIuDwqGbSjP8epxyCeWWoKGy8pj4Dyg-S5JiSRGkxg6yHD7KiC4uwggey5PtRDqIMEskgdNZnolpczchzisP74cALkYdkJyhDspykX0TC09U4oLAdzIA-LTlJoEwwryaLB+nvmBYYNN7y+BP4wHoR2Dip63OpGh-WnhtMXHZZd9A9rxZtO3G0PR5463ReSlpHhfq8BHUhc17qc2+TJTAq-0e4-1F-B8qL3bQzmcw2sJuArbc0iLzau995lX-PgsrLLvDgPQWmsk9TdOLm7Pjw8wAXcvKqKAhpS09a84-05nT-FOphqt6d320joqk0zfUhiuxxDi8gr6GkB6H9NUhjyn8r8Tn-UqozGbXCj-hfIi9-+Brd41-c=

[Annabanna]

I've got the static translation layer working quite well except for the fact that the Threshold olnly shows 3 places total (decimal or otherwise), so any values above 10.0 show only one decimal place. The correction curve is very accurate for the upper part of the range, but less so for the bottom part as a result.

Is there some way to force greater accuracy so I can both see and enter values with 2 decimal places? Maybe some sort of inversion trick where the curve gets flipped so I am measuring and adjusting using the opposite end of the scale where there are 2 visible decimal places? Something else?