search

helgoboss / helgobox

Helgobox: ReaLearn & Playtime
https://www.helgoboss.org/projects/helgobox
GNU General Public License v3.0
204 stars 20 forks source link

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

Closed vonglan closed 3 years ago

vonglan commented 3 years ago

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:

VST Mappings:

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 commented 3 years ago

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 commented 3 years ago

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

vonglan commented 3 years ago

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 commented 3 years ago

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

vonglan commented 3 years ago

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

stereokai commented 3 years ago

Yeah for collaboration

vonglan commented 3 years ago

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 commented 3 years ago

ob6 and repro5 mappings.zip

vonglan commented 3 years ago

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 commented 3 years ago

Okay, this is also how I understood it initially.

vonglan commented 3 years ago

Status:

helgoboss commented 3 years ago

@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:

vonglan commented 3 years ago

I used the following system:

I hope that can coexist with your ideas/domains.

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

and for controllers

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 commented 3 years ago

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"):

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

vonglan commented 3 years ago

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 commented 3 years ago

Current Status:

Next (starting end of this week):

Later:

vonglan commented 3 years ago

Published:

helgoboss commented 3 years ago

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