Possible VST project for live performance - opinions wanted

[Kanthos]

I do a fair bit of live performance, and I'm not happy with my setup. I've got two MIDI keyboards and a MIDI foot controller that all interface with my laptop, and I find it fairly hard to get what I want, plus there are a few other weird quirks. At the moment, changing sounds means changing MIDI channels on both keyboards, probably changing the program on both keyboards, and possibly hitting a few stompboxes on my foot controller to change effects. I also can't reuse hardware controls across multiple plugins easily, without having them affect both (i.e. I can't selectively use a foot pedal to control wah for one instance of guitar rig at some times and volume in another instance of guitar rig at other times). I also use my laptop for playing, and find that it's hard to see the things I want; while Guitar Rig has a nice live view, the B4-II shows me much more of the organ than I'd want to see, and I can't ever tell what the drawbar positions are from the display (the numbers are too small).

I'm thinking of the following solution. I'll write a light-weight VST plugin that will act as a MIDI transformer: it'll inspect every MIDI event and either pass it through, filter it out, or change the channel. Setting up a project in your DAW would basically involve creating MIDI channels, Instrument channels, Effects channels, and adding an instance of my MIDI plugin as the first insert on each MIDI channel. The plugin would have a minimal interface; all you'd have to do with it is set the output channel.

There would also be a standalone program which would have two views: one where you set up your configuration, and a live view. I'd make it standalone so that it's not limited by the interface of your DAW.

The basic idea of setup would be this:

1) Set each of your MIDI devices to output on a different channel (or, some/all devices to the same channel, if that's what you want).

2) Set up a virtual device for each hardware device in the program (give it a name and say which MIDI channel it will send on). Of course, multiple devices can map to the same channel. If you use different hardware in different places (I have two keyboards at home but only bring one to church and use it with the church's upright digital piano), you can use this ability to have the same setup in different locations *independent of hardware* (as long as you set the MIDI channels correctly on your hardware; see #1)

3) Define a number of Instruments in the software. Most likely, these will correspond to the VSTIs you plan to load, but you can define multiple Instruments for a VSTI to handle transposition and/or limited ranges. For example, if I'm playing organ by itself, I'll use both keyboards for the organ, like a real organ. I'd define two Instruments for the organ here (one per channel; B4-II uses channel 1 for the upper manual and channel 2 for the lower channel by default). But if I'm playing mainly piano and want some organ chords and some Rhodes in a song, I'll use one keyboard for the piano and split the other, using half for the rhodes and half for the organ. I'll likely want to transpose the organ and Rhodes so that both sound in the best range for the instrument, regardless of where I'm playing. I can do this with my Axiom, but it takes a few button presses on the keyboard to get this working, plus more to change the output channel and patch for each of the two instruments in the split. I'd like this to happen *automatically* when I change patches.

4) Define Control Groups and Controls. A group is just a logical grouping, such as grouping the 9 drawbar controls on an Axiom together. Each control should describe the hardware control; the software should know what channel and CC number the hardware control will be sending on. Besides the input, you can define the default output values for a control.

5) Set up banks and patches. Banks should be obvious; a patch in this sense has a few parts. One is a mapping of the virtual devices to instruments. You'd accomplish a split by mapping a device to two instruments that don't overlap. You could also have the same part played on two different instruments this way. Patches also contain control states (whether toggle controls are on or off, and what the starting values for pedals and other continuous controls are; this would let you default your distortion effect on for some patches but not others) and can optionally override any control values (for example, I'd use a lot of organ patches, and the organ uses the mod wheel to toggle the rotation speed of the leslie speaker, but if I use a synth that has the mod wheel hard-coded to control some synth parameter, I can override the control settings that change only for the patches that use that synth). Patches will also have actions they can perform when they're toggled on, so you could use this to send program changes to your VSTIs or to do other hardware things that aren't otherwise captured by controls.

6) Switch into live view and drag the control groups around so that they make visual sense based on how they're used. My complaint in this regard with Guitar Rig is that I want to see the controls arranged the way they are on my hardware, not Guitar Rig's virtual Rig Kontrol, since I don't have a rig kontrol. You'll be able to drag and drop your groups, and also change the sizing so that you can see exactly what you want when you're in live mode.

7) Start playing. The VST plugins will be really light-weight (all they need to know is how to transform the channels and notes), and will talk with the standalone program so that the live view on the standalone program will be updated when a program change happens.

This sounds a bit complicated, but the basic idea is that I should be able to do a program change on one piece of hardware, or by clicking the right area in the live view, and that should generate program changes for all the instruments I want, should set my effects the way I want, and should set controller values the way I want. And it should be easy to see and should match my control scheme.

A goal in this is to make the setup as easy as possible. It'll be possible to copy patches and controls around and to apply changes to all selected objects much like iTunes (so I can override some values without changing all of them). Adding a new patch should be easy, as long as I know what VSTIs and Effects VSTs are being used and how I want to map the hardware controls to the controls in the VSTs.

[Kanthos]

If you made it through the description of the program, I have a few questions.

1) Is this something you'd want to use?

2) Is this something you'd pay to use, whether as a fixed payment or a donation? How much would you think is reasonable (assuming, of course, that it looks good, behaves well, is bug-free, doesn't use much memory, etc. I wouldn't ask people to even donate anything for something that's buggy or poor quality).

3) In the description, is there anything that sounds like a bad idea?

4) Are there any other features I should consider with this project?

5) If you use a DAW other than Cubase, does your DAW support VSTs that transform MIDI data? What DAW do you use? (Obviously, this idea won't work for you if your DAW can't handle plugins that transform MIDI data before it gets processed by a VSTI).

[analoq]

This could be a case of tl;dr but it seems to me there are already solutions to what you're trying to accomplish.

In Ableton Live you can throw multiple instruments in an instrument rack and add the keyboard splits in any combination necessary along with your knobs. Switching between configurations would just be switching between tracks, which can be triggered however you'd want.

You can get the same thing in Logic with its multi/mapped instruments and do MIDI transformations in any way imaginable.

And if that's not enough there are probably more sophisticated ways of doing it in Reaktor or Max.

MIDI transformation is the easiest VSTi programming you can possibly do, so don't let me try and stop you -- you could very well come up with a good solution for yourself. But for others I think there are better solutions.

cheers.

[Kanthos]

Thanks for the input. I asked around on #ocremix and #ocrwip and got some of the same suggestions. The one thing that seems obvious is that implementing a system with multiple instances of a VST talking to a single instance of a standalone program is much too complicated from a programming perspective, and will probably waste resources (very important when you're taking away from resources you can use to load more samples). If nothing else, someone suggested using MIDI Yoke to connect my program to Cubase.

It doesn't surprise me that something like logic or live do that kind of thing. I know that Cubase can at least do filters (I use them in my current performance setup), and can probably do more as well. I just don't want to go out and buy Live when I'm happy with Cubase and have other things I could better afford to throw money at.

Obviously, I'd imagine switching tracks in live is easy, and it's probably not that hard to make a track switch also send a bunch of PC and CC events. My concern with it would be whether or not it lets me have a really large number of tracks (I'm talking 30-50 two-manual organ presets, the same number of one-manual organ and piano combinations, the same number of one-manual organ/rhodes combinations, the same number of one-manual organ/rhodes splits with piano, plus a few other tracks for synths). If so, would the data be easy to manage in Live? Would I get a good user interface that showed me all the controls I wanted to see using large enough images so that I could clearly see it on a 1680x1050 laptop a few feet away? Would the interface reflect my hardware in terms of how controls are grouped, visualized, and displayed?

My suspicion is that anything I could get, whether free or otherwise, would either not be able to do the transformations the way I'd want them or wouldn't have the kind of interface I'd like. At any rate, it's not like writing something would be a waste of time, as I'm looking at doing it in C#, a language I don't yet know, so learning it through a project like this makes me a lot more marketable.

[analoq]

What you're trying to do is not unusual, it's how you want to go about it that is unusual.

If you're doing this as a learning experience or because you're committed to Cubase, then more power to you.

But it's a bit naive to suggest this as a worthy solution for others when you only have "suspicions" that current solutions are inferior.