Oh, this interests me a lot!
Let's see... I guess I'll simply start writing here what I have to say about it, even though, some of what I say may need further and proper thinking, because some of the suggestions may clash with each other or may turn out to be very impractical to others (hey, it's my humble opinion, so) or even to implement:
Please help us improve our synths: Hardware control,
We are currently updating our V-series synths.
One direction for improvement is to make hardware control easier.
Features being discussed are:
- Loading and saving MIDI mapping configurations
- Preset configuration dedicated to Arturia controllers
- Controlling one or multiple parameters from a single hardware controller.
- Controlling one parameter from several hardware controllers (how would you use it ? how to combine the control actions towards different parameters)
- Setup range values (min and max)
- Filtering by MIDI channel
In the mean time, do you expect support for third party controllers such as automap, hypercontrol... ?
Please send us your feedback,
Sincerely yours,
Thomas
1) Load/Save MIDI map configs is a good solution if implemented in a way that's very easy to set what's the default map to load on first instance run but also quick to change to an existing map on other instances.
Example: Usually, I have a 5 controller keyb setup. I would set all V-Synths default to my main keyboard, so at first run of, let say Jupiter-8V, I would know that it would respond to my main keyb controls right away. Starting another instance of Jupiter-8V would behaved in the same manner, but if I wanted, I would quickly map that instance to my 2nd keyboard (and by quickly, I would say 2 to 3 clicks away from main GUI).
BTW, dunno how or if this makes any sense, but... the config map preset being used should be part of the available parameters saved by the DAWs that supports capturing the VST state snapshot.Edit: This quick change aspect would also cater for those frequent situations where I'm not at my usual setup and I only have with my 1 or 2 of the smaller keyboard controllers. Quickly changing the map to those on the opened instances would be a time saver.
2) Preset configuration dedicated to Arturia controllers is a must, of course, no discussion here
3) Controlling one or multiple parameters from a single hardware controller, if possible to implement, is a must, really, when looking at how limited "knob/fader/button" count-wise most of the controllers are. I'm not sure if this point is refering to:
3a) "Should it be able to allow various synth parameters mapped to the same controller control/fader/knob/button ?" ...and to this, I say a big fat "Yes!" ...with an unintrusive (preferably not needing an "OK" click) warning msg like "That control is already mapped to another parameter" in the mapping stage.
3b) "Should it be able to allow and support sets/layers of controller controls allowing mapping to more parameters than the available controller controls ?" ...to this I also say "Yes please!", where the mapping implementation should support increment/decrement or direct selection of sets/layers of maps for that controller.
Example of direct access to these layers: Mapping controller "Button B1" to Layer A, where the available controls concentrate on OSC paramenters, "Button B2" would change to Layer B, where those same controls now are dedicated to Filter+Envelope related parameters... etc.
Example of inc/dec access to layers: Same as above but one would only need a pair of buttons to access next/previous layer of control maps
4) Controlling one parameter from several hardware controllers is to me a nice-to-have feature, especially useful when having non-keyboard controllers that may complement/extend the existing controls of a keyboard controller. Example: Someone with an Arturia Analog Experience THE LABORATORY midi controller + Arturia Spark Controller ...those Spark controller rotaries are begging to control some synth parameters, extending what's possible to control with the built-in controls of the Lab controller.
How to achieve this? Well... from a user point-of-view, the way I would expect to see the mapping of a synth parameter is with an array of possible controller controls mapped to that parameter. So, in the mapping stage, clicking on the required synth GUI control (i.e. parameter) I would expect to see a list (editable array?) of controllers+controls and if possible min/max ranges mapped to that parameter.
As I describe this, I'm almost assuming that, to have such level of mapping complexity, maybe a dedicated "V-Synth Map Editor" would be the way to go... freeing the existing GUI from this degree of extra complexity... although on-the-fly MIDI learn implemented on each instrument GUI is very useful too, for quick, temporary or track/song/project based mapping.5) Setup range values (min and max), if possible, yes, but again, to me, it's a nice-to-have.
6) Filtering by MIDI channel is a must, to me, especially useful when dealing with controllers that have keyboards and pads, that usually are on different MIDI channels (pads on Ch10, usually).
MIDI channel filtering would allow a proper use of those Note sending Pads, not interfering (i.e. mirroring, turning them useless in most cases) with the notes sent by the Keyboard.
Sorry for the long post, but as I said in the beginning, I thought it would be best to simply start typing out the ideas for discussion or (most likely) for later editing (by me) as I think more about this while in front of my controller setup and all of the V-synths.
One issue I still have no idea how to deal with is the case of the Mg Modular V, how to deal with the dynamic setup it represents... maybe the mapping would simply work per possible module, then no matter which modules are present, there would always be a control mapped to each parameter... and this would definitely need those "layers/sets" I've mentioned in 3b)
...and speaking of the MMV (and ARP2600V), please improve the wiring physics/animation, please!!! -.-'Edit: I would think that
automap/hypercontrol/directlink controller owners would expect some sort of support for their controllers, but can't say much about it because I've been avoiding those for a while, so I don't own any of these types of controller.
