Changing order of parameters within MP/Modulator window

[Annabanna]

I'm assuming it's probably something simple I'm missing, but I don't recall coming across this:

How do you switch the order of the target parameters listed within either the MP's or Modulators.

For example: Mod 1 is assigned to 4 different parameters, and I want to switch their order.

Code: Select all

$eNqlU8FuozAQvfcrLO81GyBpIUhA1Y3SVaTSItA2uXphINY6dmRMt+3X7xiSNElPq14Av5l5vJl5jm5ft4K8gG65kjH1xi4lIEtVcdnEtDP19xm9Ta6idL1et2AMwi35homUzJUQbNdClfNmYzImQcTUtbg0GmPIuZDst4Cqh3-+Whb8HSZYG4T+KPSnR2zB2jfEw8AdhcENJQ95sRPcGNA26mGFF6Iy153MLoNYNgkn4zAMA88+KEnZ68P90w+hyj82IaazT9hTXQsuoe8i7YThGdNsC0jZHpvqNRcgoDRQZaJrOI7HHWHF82FYwSy4vvFpEg3h1rFzOqdLLgDXtryouFE6VRUqeFR6y8QwCUzJ1d-+x+fBR4zE9JocaQ4zRoU72Gt9ZqLDLHc8nfr708CSgS5BmtYKPRLcd0LkTDaWl34QD3-qj8T-4KTOf9aGX6j13K8UT8+LnYv5f0JaXNpdafgLZBrQ4eT0MOxf6RNXoAGsXYtSA8j00jM2itu1H0k0ZwYapd+WBrZLWSty15mN0jHFpJRxYT8sbt+r1QpfKHjeaY3b2u+8b+FUkVWrdyRHanQ+7S23d9qKV2aTJlGhOlw4wfyaCwz1N3kYxiHFSQ+tO6cXO7n6B2E7Ubo=

[jmg8]

ATM, not possible, sorry.

[dmbaer]

You are not alone is wishing for this capability. Right now to change the order you must delete and redefine assignments. Keeping a tidy house is most helpful for complex presets, but it's overly much work to do so as things stand. I would *so* love a simple drag and drop just to maintain an orderly organization as preset designs evolve.

[Annabanna]

..Right now to change the order you must delete and redefine assignments....

I've done that hundreds of times in the past week.

It would be quite helpful if the naming system was more intuitive as well.

For instance, I'm looking at an assignment that says:

Multiparameters - Param 34 Parameter 1 value

Ignoring that I have to nearly fullscreen the plug just to read the unabridged name in it's restricted window, it's just not intuitive at all. I now have to look through a list of MP's to figure out what that is. The MP's already have names. If I didn't mean to refer to it by that name, I wouldn't have assigned the name in the first place.

Much more user friendly nomenclature would be:

"MyName" (MP-34) - P1 value

[DarkStar]

^^^^
With the target parameter visible, click the MP Menu button on the main GUI, select "Learn" (the label will change to "REC" then adjust the target. Reaper for each target for that MP then click "Rec" to stop the recording of targets.

But +1 to being able to reorder the targets (or, at least, to set one of them to be at the top).

[Annabanna]

^^^^
With the target parameter visible, click the MP Menu button on the main GUI, select "Learn" (the label will change to "REC" then adjust the target. Reaper for each target for that MP then click "Rec" to stop the recording of targets...

I'm not sure I follow. It sounds like you're referring to a general process for adding parameters.

If the image refers to something that actually exists rather than a feature request, I'm, missing it.

[dmbaer]

^^^^
But +1 to being able to reorder the targets (or, at least, to set one of them to be at the top).

Well, that would make a lot of situations a *whole* lot of work. Example: you've got seven targets and you want to move the 5th one up two slots. I'm sure you could eventually use move-to-top to make that happen, but it's getting a bit close to Rubic's Cube territory.

If not drag-and-drop, a context menu offering "move one position up" and "move one position down" (and - why-not? - "move to top" and "move to bottom") would be perfectly adequate, and possibly a bit easier to implement than drag-and-drop.

[DarkStar]

^^^^
Other than tidiness I cannot think of any reason for such a move, e.g. from 5th to 3rd. Only the first parameter slot has a special significance.

moving

^^^^
With the target parameter visible, click the MP Menu button on the main GUI, select "Learn" (the label will change to "REC" then adjust the target. Reaper for each target for that MP then click "Rec" to stop the recording of targets...

I'm not sure I follow. It sounds like you're referring to a general process for adding parameters.

If the image refers to something that actually exists rather than a feature request, I'm, missing it.

(a) I was referring to a general process - but it avoids having to find the target in the parameter browser list especially as some of the names are generic. Having said that it might be handy to be able to jump from the target parameter in the MP Editor to wherever that target parameter is.

(b) The image is a feature suggestion; for making a target parameter the first one.

[Annabanna]

Every position CAN (potentially) have special significance because every one can be the target from another controller which is similarly locked.

If MOD1 has 5 parameters assigned, then I may well also have 5 controllers that refer to MOD1 P1, MOD1 P2, etc. I'm currently working on something that has 4 outputs, and each is merely the endpoint for a thread that runs back through the entire chain (and needs to because there are different settings at each point in the chain per thread). It's not the easiest thing to explain, but generally speaking, being able to move them would be useful, and a more organized and user friendly naming system would eliminate the need to open all those windows in order to visually track everything down.

If I've named MP 1 "Threshold", then I did so for a reason. It means something to me. It's what it does.

When I'm selecting a target parameter from the dropdown, the name makes some sense in the global section as it says "Parameter 1 (Threshold)."

For some reason, though, when I go down the list under the MultiParameter heading, it just says "Param 1". Selecting it, and then pointing to it's value from another controller, I see "Multiparameters - Param 1 Parameter 1 Value."

It just becomes unnecessarily difficult to track. Again, there's a fundamental concept in naming systems that says if you give something a name... use that name.

I know what "Threshold (MP 1)" Means specifically because I gave it that name to begin with... and yet the bit in parentheses still (much more compactly) conveys all the same information as before. That I can actually read it because the window doesn't cut off the characters just as it's beginning to differentiate itself from all the other similarly verbose names in the list is just a bonus.

Anyway, as to the reordering, if drag and drop is problematic or difficult to implement for some reason, I would think a simple up and down arrow would be nearly self-explanatory, and able to address any user's use case with minimal real estate, and probably the most intuitive, least confusing implementation that still allows every possible reconfiguration.

[DarkStar]

Ah - I had thought that the mapping followed the target if preceding targets were removed. But it doesn't. My mistake, sorry. If moving targets up/down were implemented this would need to be implemented too.

Some time ago I did ask Vojtech about making those generic names into specific ones and it looked like quite a lot of work, given the % of users who would use it.

Will the [Map] button be any help in tracking down the internal control routing? At the top-right of the MP Editor, the Modulator Editor and the MIDI Settings windows.

[Annabanna]

If anything, clicking on the map button is more confusing. Clicking from one of my modulators produces a list of over 50 parameters. Oddly, the ones it's directly assigned to are buried in the middle of the list.

Perhaps your earlier discussion about names was for some more complex implementation. While I agree that the re-ordering is necessarily complicated by the relationships of up and downstream connections, the naming seems straight forward. There are apparently multiple naming systems that refer to the same thing in place throughout the plug. One would assume it's simpler and more efficient from a coding perspective to have them reference the same thing. Nothing new needs to be created. They just need to point to the same source.

For instance, In order to generate a compound name like:

Multiparamaters - Param 1 - Parameter 1 Value

There has to already exist a bank of names for the individual components.

"Multiparameters - Param 1" is just a verbose way of saying "MP1" that sometimes causes the full name to be unreadable because the characters overflow the box containing them. Unfortunately, it is often the most important item... WHICH parameter it is... that gets cut off and is unreadable.

Parameter 1" already has a name generated by the user. The fact that the same item appears elsewhere by the name "Param 1 (MyName) indicates that the coding already exists to cross reference these existing name banks, and combine them with preset prefixes to generate compound names.

It stands to reason, then, that replacing that entire string with:

"MyName" (MP1) - P1 Value

is a straight forward matter of abbreviating in order to always allow the full name to appear, and pointing the existing compound naming system toward a bank that already exists, and is already being accessed to do the exact same thing elsewhere.

[DarkStar]

I concur and have suggested something similar to Vojtech some time ago. I think I recall that tracking down the names was going to be a lot of work.

Anyway, let's try a put together a simple example of this suggestion. Currently the appearance is this:

>>> https://i.imgur.com/DU22KLb.png
with the third target in MP2 being the Max Value of the second Parameter in MP1.

And we are proposing that the "real" names are used. As in this mockup:
>>> https://i.imgur.com/DJfQS1z.png
with the initial part abbreviated to MP1 and a / separating the target field. It could even have MP1's name "Tilt" at the front too.

If that does represent your idea accurately we should post a short new thread for Vojtech's consideration.

[dmbaer]

^^^^
Other than tidiness I cannot think of any reason for such a move, e.g. from 5th to 3rd. Only the first parameter slot has a special significance.

For complex presets, it's far more than tidiness, IMO. I was playing around with a preset idea that used pairs of modulators - four of them, only one pair being active at any one time. The assignments got out of order and it was maddening to try to make changes to all four with them having differing assignment ordering.

Or even a simpler situation. You have multiple assignments to multiple modules in the grid. Simply keeping the top-to-bottom ordering of the assignments consistent with the top-to-bottom ordering of the modules on the grid could be a big advantage.

Granted, for simple presets, we don't have a compelling reason for this feature. But when things get complex, chaotic assignment list order is not your friend.

[Annabanna]

I concur and have suggested something similar to Vojtech some time ago. I think I recall that tracking down the names was going to be a lot of work.

Anyway, let's try a put together a simple example of this suggestion...

We're roughly on the same page, though some minor variations have occurred to me as I've been working over the past week or so. I'll keep an eye out for times this would be helpful over the next couple of days, and see if there are any additional nuances that pop up in the process.