Standardized set of Analog Synth virtual parameters, for easier exchange of Mappings

[vonglan]

This is not a feature request, rather a suggestion for the users of ReaLearn:
If we could agree on a small standard set of parameters of (analog-style) synth VSTs, ReaLearn users all over the world could create a library of a) Hardware Synth Controller Mappings and b) VST mappings, and other users could simply combine these.
For example:

Controller Mappings:

• Sequential OB6 —> Standard set of virtual parameters
• Clavia Nord Wave —> Standard set of virtual parameters
• Access Virus —> Standard set of virtual parameters
• ...

VST Mappings:

• Standard set of virtual parameters —> u-he Diva
• Standard set of virtual parameters —> TAL J-8
• Standard set of virtual parameters —> sonicprojects OP-X
• …

The standard set of virtual parameters could have something like 50 parameters (Osc, Mix, Filter, Envelopes, Modulation) or 90 (additionally some ModMatrix slots, XY-Sets, Arp/Seq control, generic FX parameters, Delay FX, LFO FX).
Users could then simply combine a downloaded (or created) Controller Mapping for their Hardware Synth with the VST Mappings for the software synths they own.
(You could also use the parameter sets/mapping for a generic controller like APC25 or Twister, but the main advantage would be if you use a Hardware Synth with lots of knobs and buttons as MIDI Controller.)

[helgoboss]

I second this because I consider exactly this composability of controller presets and main presets as one of ReaLearn's main strengths. It would be great if some conventions could be established around what virtual control element (e.g. Multi 1, Button 3 etc.) usually controls what kind of analog synth parameter. When designing ReaLearn, I intentionally distinguished only between "Multi" and "Button" (leaving everything else up to the user) because I think this is the lowest common denominator and every distinction beyond this would be highly domain-specific.

The domain here as brought up by @vonglan would be "Analog Synth" and I'm sure that within this domain a reasonable standard could be established. This could be in a separate ReaPack repository.

[vonglan]

here is a suggestion for a controller set
Analog Synth suggested Standard Controller Set.xlsx

[vonglan]

Improved the controller set. 72 Knobs and 12 Buttons.
Assigned to 9 banks of 8 knobs (and some buttons), or 6 banks of 4 knobs (essential only).
Concept only, so far.
Analog Synth suggested Standard Controller Set.xlsx

[stereokai]

Hey, these look great! Hopefully this will be adopted. Could you please upload these to Google Spreadsheets?

[vonglan]

Hi @stereokai, do you mean for reviewing? It would certainly be good get some feedback and improvement suggestions.

[stereokai]

Yeah for collaboration

[vonglan]

Here it is https://docs.google.com/spreadsheets/d/1Sq1ZfV5X20jha0A94UWfiEH1Wl-AhHtC7iurwTLAUXE/edit?usp=sharing.
I am using this for the first time (but I have some experience with Google Docs collaboration).

At the moment I am working at a subset (the one for "Banks of 4" controllers) for the OB6 and RePro-5.

[vonglan]

ob6 and repro5 mappings.zip

[vonglan]

Some clarification (because I just realized that I was confused when I wrote the initial description of this issue):
This is NOT about ReaLearn's FX parameters, but about the virtual sources/targets. (I called them "virtual parameters" in the description above, but that is misleading and might be used for something new in the future, see #241 .)

The "library" would consists of presets for Controller Mappings and presets for Main Mappings (corresponding to the VSTs that are the target).

[helgoboss]

Okay, this is also how I understood it initially.

[vonglan]

Status:

• full OB6 Controller Mapping created
• J-8 Mapping 90% finished
  Archiv.zip

[helgoboss]

@vonglan Could you come up with a kind of "System name" for your virtual-analog set of controller/main preset? It should be terse but expressive because I would like it to display it as prefix or suffix together with the preset name.

The idea: I already mentioned that your set of controller/main mappings follows a different system/philosophy then mine. You use different virtual control element names than my presets etc. So they won't be compatible with each other. I want to make it easy for the users (including myself haha) to recognize which controller preset is combinable with which main preset. I think we could call these different philosophies and name usages "Systems". Displaying the name of the compatible system(s) next to the preset name would be an easy and effective way to let users know what works together and what not.

What systems I have come up with so far:

• "Grid": For numbered control elements, e.g. an 4x4 matrix of encoders or a row of encoders with another row of buttons.
• "Mackie": For presets that use the naming which is typical for DAW controllers. Not satisfied with the name yet. Maybe "DAW" is better.

[vonglan]

I used the following system:

• "SY" as prefix for the "Analog Synth" domain
• Virtual targets/sources all start with SY/
• Controller Mappings are called for example "OB6 SY" and "X-Touch Mini SY"
• Main Mappings are called for example "SY J-8" and "SY Repro-5"

I hope that can coexist with your ideas/domains.

Do you have any "analog" softsynth installed? I plan to make mappings for

• TAL J-8, U-NO and Baseline101
• u-he Repro1+5, Diva and Hive
• OP-X Pro

and for controllers

• OB6 and Prophet 6
• X-Touch Mini
• midiplus X3 mini (6 buttons and 4 absolute knobs)
• maybe APC20 (8 faders and many knobs)

What systems I have come up with so far:

I think it would be great to have some similar "standard" for the domain "DAW control" (you had an issue for that). But I cannot contribute so much to that, because I did not spend much time using DAWs so far. (And because I want to finish the SY thing first.)

[helgoboss]

I used the following system:

• "SY" as prefix for the "Analog Synth" domain
• Virtual targets/sources all start with SY/
• Controller Mappings are called for example "OB6 SY" and "X-Touch Mini SY"
• Main Mappings are called for example "SY J-8" and "SY Repro-5"

I see you use uppercase letters. My first instinct was to introduce case-insensitivity and suggest to agree on using lowercase letters. But then I though further and saw that this comes with disadvantages. It's not super important but I think we should very shortly agree on basic naming conventions, better now before having a forest of different conventions from the start already.

So far I used identifiers such as ch1/fader/touch (the slash indicating hierarchy). And with combined words on one level I used "kebab-case" (e.g. ch-right or fast-fwd). However, there's one counter argument, which is maybe premature optimization, but in the audio domain I'm very careful: I intentionally reduced those names to a maximum of 16-character ASCII-only strings - in order to make comparisons still fast (because they need to be done in audio thread, too). So the amount of characters is limited. Enforcing lowercase and using kebab-case takes characters away. On the other hand, it looks cleaner than camelCase and I had no issue at all with the limited number of characters. I guess I still tend to kebab-case. The performance aspect could be even neglected by removing the hyphens.

What's your take on this? Would you be okay with kebab-case? Would be good to come up with something consistent at least.

Also, I don't think we even need a domain-specific prefix. This just takes away space. If one controller uses elements of one domain only, it doesn't matter. If it's a mix of domains, the name clash is maybe even desired? Like if something is called "record" in the synth domain, then maybe it would make sense in the DAW domain, too?

I hope that can coexist with your ideas/domains.

I don't see any problem with that. I was thinking actually more about the name of the system/domain. E.g. "Edo" or "Analog" ... something like that. It should be immediately visible in the preset list.

I revised my list of "domains" (which is a better name than "system"):

• "Grid": Just for grid controllers such as Launchpad - control element names such as 1/1/pad, 5/2/pad, 7/6/pressure
• "Linear" or "Numbered": For a simple linear numbering of elements
• "DAW": For typical Mackie-style DAW controllers

Control presets can cover many domains. E.g. the Akai APC Key 25 has control elements of all of the above domains. Plus a rule, for my repository at least: A controller should never double-expose one single control element under different virtual control element name.

Main presets can support multiple domains. E.g. they could bind a track volume change both to the numbered multi control element 5 ("Linear" domain) and to the named multi control element ch5/fader ("DAW" domain) by using 2 mappings with the same target. Then they support both kinds of controllers.

Any ideas?

Do you have any "analog" softsynth installed? I plan to make mappings for

• TAL J-8, U-NO and Baseline101
• u-he Repro1+5, Diva and Hive
• OP-X Pro

and for controllers

• OB6 and Prophet 6
• X-Touch Mini
• midiplus X3 mini (6 buttons and 4 absolute knobs)
• maybe APC20 (8 faders and many knobs)

I have some NI stuff and Zebra.

What systems I have come up with so far:

I think it would be great to have some similar "standard" for the domain "DAW control" (you had an issue for that). But I cannot contribute so much to that, because I did not spend much time using DAWs so far. (And because I want to finish the SY thing first.)

Yes, this issue: #256. I solved it.

[vonglan]

Quick answer (maybe more detailed tomorrow):
I think a short domain prefix is useful, to be able to quickly distinguish from what ("standard") domain a virtual source/target is.
I much prefer camel case (maybe because it is not supported in ABAP, my everyday language ;-).
Examples:

Description	Technical Name
Cutoff LFO Modulation Amount Bipolar	SY/CutoffLFOModB
Cutoff Velocity Modulation Amount Unipolar	SY/CutoffVelModU
Bandpass or Filter Slope	SY/BP|FiltrSlope
Filter Attack	SY/FilterAttack
Filter Decay	SY/FilterDecay

Regarding performance: it that is an issue (not sure), you could use a 4-byte hash value for the 16 characters.

[helgoboss]

Quick answer (maybe more detailed tomorrow):
I think a short domain prefix is useful, to be able to quickly distinguish from what ("standard") domain a virtual source/target is.

I'm a bit divided myself on this. It looks clean and nice with prefix, was my first thought for sure. But after putting more thought into it, I see the same problem here that I see with every form of categorization/hierarchies: Very often something belongs into multiple categories - and then what? E.g. grid controllers usually have a button "Stop clip" ... is this "DAW" or is this "Grid" domain? They also have left/right/up/down keys ... which would conform to Mackie's cursor-left, cursor-right etc. (DAW domain). But do we really want to be that strict and make this form of intuitive and therefore maybe wrong categorization part of an ID? Because the virtual control element name is nothing else than an ID that conveys a bit of meaning.

Addition: If a controller has one button which is labeled "Play", I feel the ID should be play, not daw/play. It's more intuitive. And who knows if the intention of that button is to start playing in the DAW (could also be a tape or a single sample). I have the feeling that in this sense, name clashes are actually welcome and intuitive to some degree.

I much prefer camel case (maybe because it is not supported in ABAP, my everyday language ;-).

Okay, I have the feeling we will not be able to agree on one case style haha. Whatever ... let's embrace diversity then. I will just leave it as it is for now (case-sensitive and different case styles).

Regarding performance: it that is an issue (not sure), you could use a 4-byte hash value for the 16 characters.

It doesn't seem to be a problem so far. The 16-byte restriction is already an optimization. I could add some more characters if needed. It's just important that it doesn't get too long and that it's reasonably limited. I'm quite happy with the decision to restrict it to ASCII, I don't want to see variety of unicode in control element names ;)

[vonglan]

But do we really want to be that strict and make this form of intuitive and therefore maybe wrong categorization part of an ID?

I agree that for "play" there should be no prefix. And that there are lots of cases where it is ambiguous. But I think for "Analog Synth" it is not ambiguous and makes sense.

Okay, I have the feeling we will not be able to agree on one case style haha. Whatever ... let's embrace diversity then. I will just leave it as it is for now (case-sensitive and different case styles).

Thanks, fine with me.

The 16-byte restriction is already an optimization.

At first I was a little bit annoyed, but now I like it and think it has more advantages:

• Forces you to think about a meaningful short version
• You still have the mapping description to write a longer "text"
• I assume it has advantages when displayed on the companion app (don't use that as I don't have such a device) or maybe in the future on a controller device

I could add some more characters if needed. It's just important that it doesn't get too long and that it's reasonably limited. I'm quite happy with the decision to restrict it to ASCII, I don't want to see variety of unicode in control element names ;)

Similar to 16-bytes, I also like the restriction to ASCII.

[helgoboss]

But do we really want to be that strict and make this form of intuitive and therefore maybe wrong categorization part of an ID?

I agree that for "play" there should be no prefix. And that there are lots of cases where it is ambiguous. But I think for "Analog Synth" it is not ambiguous and makes sense.

For the "Grid" and "DAW" domain I will skip the prefix. Maybe I will put it into categories in the name picker for easier navigation (see last ReaLearn prerelease), but I will not use a prefix. I will leave the decision for your "Analog synth" domain up to you.

[vonglan]

I have some NI stuff and Zebra.

Monark? Didn't want to install this on my new computer (even though I have the license), but will if you use that.

[helgoboss]

Yes, I sometimes use Monark. But less often because I try to use only Linux-compatible VSTs.

[vonglan]

I tried Monark and ReaLearn on my old computer. It seemed that Kontakt does not send feedback. So I won't make a Monark preset after all.

[vonglan]

Current Status:

• Finished OB6 and X-Touch Mini Controller Mappings to "SY"
• Finished TAL J-8, Repro-1 and Repro-5 Main Mappings from "SY"

Next (starting end of this week):

• Add Controller Mappings for Prophet-6 (small adaption of OB6 - can't test it) and Midiplus X3 Mini (6 banks of 4)
• Refine documentation
• Publish

Later:

• Main Mappings for Hive, Diva, U-NO, Baseline101, maybe OP-X
• Maybe Controller Mapping for APC20

[vonglan]

Published:

• Github
• Reaper forum discussion

[helgoboss]

Great! Congratulations. Hope to contribute a Bass Station II controller preset at some point.