VI Host vs DAW

[mauriziodececco]

I am experimenting with a rig based on a Novation SL mkIII and my laptop, at least for one of the group i am playing in.

 

I am very happy with the SL, paired with the laptop sum up to a nice multitimbral workstation, even if it need a good preparation before; still learning.

 

I am wondering what to use as plugin host; i used MainStage before, but the paradigm "one physical controller -> one on screen controller" do not work when you have something around 24 continuous controller and 48 buttons for each of the eight track the SL can control.

 

I am starting out with Logic (that have in theory a reasonable integration with the SL), but i wondering if there are more interesting solution out there.

 

So, would you use a DAW or a VI host, and why ?

 

Maurizio

[ElmerJFudd]

Seeing as MainStage is basically Logic with DAW features swapped for gigging features, I"d stick with MainStage. Any definition Logic/Apple has for the SL would be recognized in both as your starting point. And MainStage"s GUI is more conducive to the task at hand.

 

Your other option on OSX is to try Gig Performer which takes a different but highly flexible approach to building your rig. And they say it"s a bit more resource friendly since it isn"t as graphically elaborate.

[GuitarMage]

Although a DAW can be used for live performance, I recommend all gigging musicians to use an audio plugin host that is specialized for live performance.

 

Why? The focus is live performance and addressing unique needs of live performers.

Plus, there are many things to have in mind, e.g. integration with your FoH engineer, advanced MIDI manipulation, possible lights control, application stability and other.

[Reezekeys]

I'm not sure what exactly you want to do, but Bidule has been a great host for me for 15 years, and I've used it only for live performance. You can download a free "demo" â which I put in quotes because it's the regular program with all features enabled â the only difference between it and the paid version is that it stops working at the beginning of September.

 

The downside (for some!) is that it's more of a geek type interface (like Max/MSP) with modules you wire together. It also has no real manual, just a help file that's a little out of date. But it has all the basics (and much more, which you can ignore until you need them): midi & audio mixers & switchers, routers, etc. And it can easily "midi learn" a controller too, so relatively quick to get going once the plugins are "wired" correctly. And there is great support from the developer in the forums there. I don't get a commission for this sales pitch - just a happy user!

[Groove On]

I prefer VI Hosts because the interface is streamlined for live performance. Show-stopping "accidents" are kept to a minimum and that's music to my ears. In contrast, there are a lot of settings unnecessarily exposed in DAWs that can be "accidentally" activated. Yes you can be careful, but accidents happen. Great for the studio, not so great on a live stage.

 

But - it may also depend on the type of music you are performing. VI Hosts are built for the traditional live performing musician with set lists, patches and who actually play an instrument. But if you're doing modern electronic style music, Live Loops in Logic or the Session view in Ableton can be very effective; plus, your Novation SL mkiii is built with those DAW features in mind - so something to consider. I've done performances where I'm the traditional musician using MainStage with an instrument, accompanied by a DJ/performer using the Session view in Ableton - so (despite my preference) they can both work well on-stage.

 

Personally I use MainStage because I like to stay native on MacOS and it integrates with Logic and all it's instruments; but I found MainStage the most difficult of the VI Hosts to setup. It's good-looking on top, but figuring out where everything is, can be frustrating, even at the beginning - there's lots of googling and trying to read the many times useless manual. In contrast, Gig Performer is much easier, I was able to get up and running almost immediately with almost no need for the manual.

 

The one live performing VI host I'm curious about is OnSong. I notice it's used by many traditional / non-techie musicians, and I like the simplicity of the interface - worth looking at.

[mauriziodececco]

As i said earlier, MainStage is not really an option, at least from the point of view of managing the MIDI controllers: the SL MkIII have an interesting approach: it is built around eight tracks (ok, there is a sequencer there, but even if you don't use the sequencer, you have to think in terms of these 8 tracks).

 

Each track have a whole "virtual panel"; if you switch the selected track, you switch the virtual panel.

So, in practice, you get 16 encoders (2 banks of 8), 8 sliders, 32 buttons (2 banks of buttons), and 16 pads for *each* track, so, if you use 8 VIs, and want to map all the controllers, you need to map a total of 576 controllers; unless i missed something on MainStage, in order to use a controller you have to map it to a Perform screen representation; just not possible.

 

There is another important point: the SL MkIII use tracks preset, called templates, that you can program with the Novation Component editor/librarian. So, you can prepare a preset for your favorite VI or hardware instrument, and combine them in a complete setup (called Session), by assigning a template to a track.

 

This means that you want a VI Host that can bundle together a VI with a his controller mapping, and that allow you to compose these bundles to create different setup. You can do that with Logic (and probably with any DAW) by just having the mapping in the VI track, but you cannot do it easily with MainStage (again, if i haven't missed something) because mappings are handled in a centralised way, not instrument by instrument.

 

Other than the above, Logic have for me two obvious advantages: it is the DAW i use today, so i know it well, and i can use its vi and plugins; the other is the SL have some integration, like showing the track smartcontroller, and mapping sliders to track volumes. The SL have no such integration with MainStage .

 

On the other side, to change setup you have to close the project and load a new one; take time and it is a pain in the ass :<, changing song on MainStage is a lot faster ....

 

Maurizio

[johnchop]

So, in practice, you get 16 encoders (2 banks of 8), 8 sliders, 32 buttons (2 banks of buttons), and 16 pads for *each* track, so, if you use 8 VIs, and want to map all the controllers, you need to map a total of 576 controllers; unless i missed something on MainStage, in order to use a controller you have to map it to a Perform screen representation; just not possible.

 

But in practice, would you try to manage 576 controllers? I'd probably want to dumb that down so I don't have to worry about switching "pages" in the heat of battle.

 

 

On the other side, to change setup you have to close the project and load a new one; take time and it is a pain in the ass :<, changing song on MainStage is a lot faster ....

 

Right, because MainStage and GigPerformer and the like are built around this concept.

[mauriziodececco]

So, in practice, you get 16 encoders (2 banks of 8), 8 sliders, 32 buttons (2 banks of buttons), and 16 pads for *each* track, so, if you use 8 VIs, and want to map all the controllers, you need to map a total of 576 controllers; unless i missed something on MainStage, in order to use a controller you have to map it to a Perform screen representation; just not possible.

 

But in practice, would you try to manage 576 controllers? I'd probably want to dumb that down so I don't have to worry about switching "pages" in the heat of battle.

 

 

Probably not :->; but just consider a reasonable set up (more or less what i plan do do): for each track, use the main encoders page for important parameters (for example filter cutoff, resonance, etc.), and the second page for "in case of needs" stuff, like envelops or other stuff; since the encoders have a nice display telling you the name and the current value of the parameter it would be a pretty usable solution. I would map the sliders to a fixed scheme, like level, a couple of sends and equalisation. I would probably use a few buttons for switching on/off insert effects. This would make something between 20 and 25 controller per track; that make 160 on screen controllers for an 8 VI setup.

And this do not count the keyboard; if you want to use the SL MkIII native features, like lights guides for the splits, and switching between instruments by switching the SL track, you need 8 on screen keyboards.

Note that i speak about an 8 instruments setup, that doesn't necessarily correspond to a single song.

 

 

The point is not that i don't like MainStage, or that MainStage do not have the right features; it is just that the SL MkIII have a logic organisation that is *very* different from those of other keyboards (for example the Arturia stuff), and this organisation does not map very well to the MainStage organisation.

 

Of course, nobody oblige you to use the all the different features of the SL; you can stay in a single track with a single panel, and MainStage will work just fine; but then you would probably buy another keyboard .

 

Maurizio

[johnchop]

Yeah I'm trying to think of how that would work in Gig Performer, given that each widget binds to a specific MIDI control on a specific channel.

 

The concept doesn't quite map onto how Gig Performer wants to work.

 

If each "track" can be tied to a particular MIDI channel, you would still have 500+ "widgets" to place and assign on different panels in a rackspace. Yikes.

 

And at this time, there's only so much you can do to modify GP widgets programmatically, so it's not like you can have a master set of widgets that you dynamically repoint to different plugin parameters based on the selected "track".

 

Related: I'm working on a "fire up and jam" Gig Performer rackspace that will allow me to dynamically choose from a small palette of sounds (AP, EP, Clav, Organ, Synth pad, Synth lead), each with some variation controls + global FX. It's like a less capable Nord

 

Still, it's a bit of a fun puzzle, but Gig Performer does what I tell it to do, and I love being able to choose my preferred VIs.

[EricBarker]

MainStage doesn't NEED on-screen controllers for CC flow, btw. You can set them up in the secondary tab up at the top (I forget what it's called): it's just a text-based table with all your controllers. If you're just passing controllers through to VIs, then you can setup a few hundred without them taking up any more screen real-estate. The on-screen controls are just for visual feedback and easy access.

 

SIMILARLY (but less known), MainStage doesn't NEED those big honking graphical keyboard widgets to input from different controllers... I haven't for years. There's a little button-shaped widget (looks like a HAL eye), unfortunately called "MIDI Input Monitor", that has all the functionality of those big keyboard things, but in a tiny circle you can size down. I have an array of 8 of them in my current setup, tucked away on the side for 8 independent midi channels coming from my board (sounds like you're doing something similar). You can even do splits and layers, but you just use the edit pane, which is really better for that anyway.

 

Just some food for thought.

[Deskew Tech]

I'm one of the developers of GP and I would encourage you to discuss some of these issues on the GP forums where other existing users will be able to offer some insights. When I read some of the comments above, I'm not quite sure I understand what people are trying to do. I'm seeing references to "tracks", and to a need for a large number of widgets, neither of which make sense in the context of Gig Performer. For example, the reasons for using widgets (knobs, sliders, etc) in Gig Performer are different than on other systems. Typically you would only have widgets for parameters you either want to change in real time during your show or for remembering variations, a mechanism that doesn't really exist in MainStage, for example. If you want to tweak other parameters during design, then you just open the plugin window and adjust stuff directly. As for MIDI channels, I use anywhere from one to four controllers depending on the band, and they're all on MIDI channel 1. In the GP model, one switches variations or rackspaces or songparts (on the fly) to change sounds and so it is rarely necessary to depend on using different MIDI channels. If one actually wants to select an "instrument" from a multi-timbral synth where each instrument is on a different channel, then the SOP would be to map the MIDI channel on the fly inside Gig Performer rather than changing the incoming MIDI channel. That way, you can create an arbitrary number of splits, routed to arbitrary instruments and never actually worry about MIDI channels at all.

 

It's a bit of a paradigm shift as many people are used to thinking in terms of MIDI and channels and in the GP world, we're trying to just get away from that.

 

Just my 2 cents.

[EricBarker]

For example, the reasons for using widgets (knobs, sliders, etc) in Gig Performer are different than on other systems. Typically you would only have widgets for parameters you either want to change in real time during your show or for remembering variations, a mechanism that doesn't really exist in MainStage, for example.

 

As I mentioned, MainStage actually works the same exact way, too, it just doesn't like you to think that! My observation, if I may be blunt, is that the average MainStage user is actually pretty... dumb. I'm on some MainStage groups, and it's breathtaking how little they understand about the basics of signal flow, MIDI, or how VIs operate. For that reason, MS promotes itself for the lowest common denominator, and has a lot of terminology and instruction that suggest a very rigid workflow. Many view third-party VIs as scary or unusual, and don't much deviate from prefab templates. Thankfully, when you dig in, MS is actually far more flexible than it appears, with many different ways to skin a cat. It's surprisingly deep for Apple (lol). Most of the graphical displays are completely optional for real-time operation, they just squirrel away the non-graphical midi objects in a "scary" list. That said, I'm sure MS is not the best any more. Gig Performer has really caught my attention... if I were to start from scratch, I would probably go with it or Audio Modeling Camelot (I LOVE their patch organization philosophy). But I have put thousands of hours into my MainStage projects and have generally made them work well for me, so I have no desire to switch.

 

What I would NEVER NEVER use is a DAW. Some do, and I don't know how or why. To me that's like bringing a Semi Truck to a car race. Both have incredible uses, but they excel in very different areas. Momentary patch switching on a DAW (even Ableton "Live") is a horrific ordeal, the very thing that a VI Host is designed around. DAWs are designed to do a single very complicated project at a time, VI Hosts are designed to manage many relatively simple projects (songs or patches) and switch on a dime. You can make a DAW work, but personally I can't understand Why? I guess if you're only playing one patch per song and have time to switch in-between (like in musical theatre), otherwise, a VI host is almost always going to be the more flexible option.

[mauriziodececco]

Whow, the discussion become very dense, and contains a lot of information; thanks .

 

Some more comments.

 

For Deskew Tech, thanks for participating; i'll try to explain why i talk about "tracks"; the real question behind the discussion is: I got a Novation SL MkIII master keyboard; this keyboard have a richer set of features than many of the competitors (this does not means it is better or worse, it is just different); it propose a philosophy and organisation of the workflow; of course, you can ignore it, dumb it down to a basic keyboard and do what everybody else does, with MS or GP or something else. The point i am trying to understand is different; i like the workflow the keyboard propose, and i want to adopt it 100%. So, my quest is for a VI Host or DAW that fit this workflow, provide what this workflow needs and stay out of the way for the other stuff; for example, the workflow will be completely keyboard centred, i will not look or touch the laptop while performing; from this perspective, MS on screen controls are a nuisance, not a feature (i do not know GP, i cannot comment on its features). So, when i talk about tracks and midi channels, it derive from the SL MkIII workflow; yes, i know i am thinking the other way around wrt most of the other people .

 

For EricBarker: thanks for your comments, this is something i was hoping to hear; OK, some homework for holidays, deep dive in MainStage. And yes, i *am* an average pretty dumb MainStage user; i invested a lot of time in Logic, but a lot less on MainStage, because up to now my needs where pretty basic.

 

About DAW vs VI Host, there a number or more or less legitimate reasons to use a DAW:

 

1) Most obvious: because you want to have some part of the show driven by the DAW; for example, using Live Loops in case of Logic; most of the people using Ableton Live do just that.

 

2) Because you are less dumb on the DAW than on the VI Host, and may be you don't have the time to change this; for me, setting up what i needed for the first post-covid rehersal on Logic took 15 minutes; on MainStage, it will take a month. OK, the first time only.

 

3) Because your keyboard talk to the DAW, and not the VI Host (in the sense that provide built in integration with); this is also a matter of time, because you can make the keyboard talk as well to the VI Host.

 

4) Because your set is not based on many different patches for different songs, so the patch switching is somehow less important; personally, i still do not know if this will be the case.

 

5) Because you want to share setups between your studio/composition activity and your live activity; AFAIK, this is not really a point between Logic and MainStage, that can share data.

 

Then, of course, there are a good number of reasons for not using a DAW; For me it is not a matter of being a Truck or not, or too many features; it is more in the little things, like plugin loading, record enabling tracks when you want to play them, a number of littles things that get on the way, other than patch switching, of course.

 

Anyway, i'll go back to the MainStage documentation, and i'll report bak after holidays

 

Maurizio

[Groove On]

You can also count me as one of the dumb MainStage users - so it will be interesting to see how you get the Novation to play nicely with MainStage or Gig Performer.

 

Here's some videos of an older Novation SL working with MainStage. It looks like the older Novation also used "Pages". He was also able to incorporate the Novation automap software (though it may turn out the MainStage MIDI learn may be usable now). 1st video is an overview, the 2nd video has more of the technical details.

 

Ultimate Apple MainStage Keyboard Rig

http://jaminajar.com/my-ultimate-apple-mainstage-keyboard-rig/

[Deskew Tech]

i will not look or touch the laptop while performing

Maurizio

 

Indeed - that was a design goal for us too - my laptop sits off to the side. Having said that, our OSC implementation allows one to have just a couple of items displayed on an iPad right in front of you which can be very useful if you want to (say) select songs quickly or have access to a small number of widgets that you can tweak on the fly.

 

Some more comments.

I got a Novation SL MkIII master keyboard; this keyboard have a richer set of features than many of the competitors (this does not means it is better or worse, it is just different); it propose a philosophy and organisation of the workflow

Maurizio

Understood completely and that approach can certainly be used with GP. However, although this does not apply to absolutely everyone, there are a couple of major benefits to using a "dumb" controller and letting GP do all the manipulation

 

1) If your "fancy" keyboard dies on stage, you're totally screwed!

2) If you're touring (or you're part of a festival) and you need to leverage a backline, there's a damn good chance you won't get the specific keyboard you requested -- that has happened to me quite a few times. Then you have the situation where, not only do you not have the overall control you are used to, but the knobs/sliders may be sending different messages than you were used to and now you have to find the manual and figure out how to change everything -- not a good thing during sound check or when you only have 10 minutes to get ready. Again, all of these issues go away if one uses a "dumb" controller with GP.

[mauriziodececco]

MainStage doesn't NEED on-screen controllers for CC flow, btw. You can set them up in the secondary tab up at the top (I forget what it's called): it's just a text-based table with all your controllers. If you're just passing controllers through to VIs, then you can setup a few hundred without them taking up any more screen real-estate. The on-screen controls are just for visual feedback and easy access.

 

SIMILARLY (but less known), MainStage doesn't NEED those big honking graphical keyboard widgets to input from different controllers... I haven't for years. There's a little button-shaped widget (looks like a HAL eye), unfortunately called "MIDI Input Monitor", that has all the functionality of those big keyboard things, but in a tiny circle you can size down. I have an array of 8 of them in my current setup, tucked away on the side for 8 independent midi channels coming from my board (sounds like you're doing something similar). You can even do splits and layers, but you just use the edit pane, which is really better for that anyway.

 

Just some food for thought.

 

OK, i started to play around with MainStage, and about the first point, the tab is Assignements And Mappings in the Edit screen. On the action menu (little gear icon up on the right), there is a "New Assignement" item, that create an assignement where you do not need to put a on screen controller. So, that solve the problem.

 

About the second point, there is also another trick, but have some limits: if you check the "Send unassigned MIDI to all channel Strips" and you do not have any keyboard on screen controller, note on/off messages are sent to all the VIs. This is useful only if you have less than 16 instruments, because all the MIDI inputs are merged together, *and* only if your VIs allow you to set the input MIDI channel (well, nothing that a small Scipter script cannot fix).

What is strange is that while the Notes mapping is shown in the assignement list, you cannot create one manually. You need a widget to create the mapping. Anyway, this is not a big deal.

 

The only problem i'll still have to resolve is the need to "package" the mapping in libraries (so to mirrow the SL MkIII template organisation); like having a mapping set for a VI (let's say for the NI Noire), one for another one (let's say the Arturia MiniMoog), and then compose them in a MainStage concert; i am aware of the hierarchical organisation of MainStage, but i this case it is more a matrix thing needed. Working on the subject

 

Maurizio

[mauriziodececco]

i will not look or touch the laptop while performing

Maurizio

1) If your "fancy" keyboard dies on stage, you're totally screwed!

 

As i said before, i never used GP, so take the following as a general comment on VI Hosts.

 

The point is that there is nothing fancy about a keyboard that offer split points and different MIDI channels; my first MIDI master keyboard, an Elka 88, bought in 1986 (or 7) offered 4 splits.

 

My impression, as an amateur musicians, and as a software guy, is that there is something deeply wrong in the market: you have two great tools, VI Hosts and powerful MIDI controllers and keyboards, that instead of enriching each others require to make a choice, and either dumb down one or the other. Probably the keyboard people and the VI host people should talk a bit more .

 

Maurizio

[Deskew Tech]

VI Hosts and powerful MIDI controllers and keyboards, that instead of enriching each others require to make a choice, and either dumb down one or the other. Probably the keyboard people and the VI host people should talk a bit more .

 

Maurizio

 

(My personal opinion now - not wearing my GP developer hat - but rather my experience with performing and touring)

I disagree strongly with this. I don't think anybody is suggesting that one has to make a choice. There is certainly nothing stopping people from using very sophisticated controllers with plugin hosts. I've drooled over owning a PHYSIS PIANO quite a few times and the only thing stopping me was its weight!

 

Any decent VI host should be able to manage external hardware synths and deal with sophisticated MIDI controllers. If one wants to leverage a controller's ability to create separate zones (splits) and route them directly to different devices (whether plugins or other external hardware) that's absolutely fine. Nobody is suggesting that any "compromise" is necessary.

If you're performing at home, or even playing local venues, and you are comfortable that the risk of a keyboard failure (say) is very low - no issue - and if it fails - so be it!

 

However, if you're touring and/or otherwise performing in front of audiences who have paid to see you perform, you have a certain responsibility to make sure that "the show must go on". Now, if you're with an arena level band (or even just large theatre) it's quite feasible that everything that can fail will be duplicated and so if you are using a really sophisticated controller, your road crew will be carrying an extra one just for that eventuality. (If you're computer-based, you're probably running two machines in sync so if one fails, instant switchover to the other)

 

On the other hand, if you are part of a "normal" touring band, perhaps with the occasional festival, then you have a logistics issue where the keyboard you want to use or typically use is just not available. In that situation, you may have to depend on the availability of other controllers at the venue. In that situation, the less dependent you are on a "smart" keyboard controller, the easier it will be to handle issues that may arise.

 

One of my bands was the headliner at a festival in Norway a few years ago. For that band, I use four keyboards. When I arrived, I was given four keyboards, different than what I had requested. Worse, while everything worked in rehearsal, when we got up on stage for the show, one of the controllers failed. Everyone had to wait for almost 1/2 hour until someone could find another keyboard and what they found wasn't even close to what I was using. That experience (and a few "almosts") convinced me never to be clever with the keyboard itself.

[johnchop]

My experiments with integrated hardware+host software has failed twice now.

 

First NI Kore2. Hardware was dodgy (went through two problem units), host was pretty cool. NI abandoned it.

 

Next, VIP + M-Audio CTRL49. I actually liked VIP as a relatively simplistic but still effective host, and the keyboard integration was good enough. Now VIP looks like abandonware (no upgrades in forever, no VST3 support), and you don't see version 2 of any of the VIP-enabled hardware. The market spoke again. Too bad.

 

And I didn't even touch the other proprietary stuff like Nektar's stuff, NI's NKS, and Novation's InControl and Automap.

 

I haven't delved into the MIDI 2.0 spec enough to know, but perhaps it will allow transmission of parameter names and values back to a controller for display? That would be cool.

 

Meanwhile, in the real world of live playing, I agree that it helps to have a VI host that's effectively device independent.

[Reezekeys]

On the other hand, if you are part of a "normal" touring band, perhaps with the occasional festival, then you have a logistics issue where the keyboard you want to use or typically use is just not available. In that situation, you may have to depend on the availability of other controllers at the venue. In that situation, the less dependent you are on a "smart" keyboard controller, the easier it will be to handle issues that may arise.

Exactly. I tour with my Roland A800 but in the last seven years (it"s been eight but I didn"t count last year - 2 gigs in total!) I"ve had a keyboard failure twice. Once was at a sound check, and the other time was after we took the stage to start our show (that was a rental, not my Roland). I carry a Korg NanoKontrol in my backpack that duplicates most of the functionality of what I programmed in the A800. I also carry some artist"s putty, and a few globs of that sticks it onto any midi-capable keyboard made. All I need for it to do is transmit on channel 1 and have a sustain and expression pedal. A working pitch bend and mod wheel help too! (I already had my NanoK going for the incident with the rental so that was a quick if awkward changeover while our front man told a few jokes)!

 

The pretty screens and integration of controller features might be nice for a studio setup but imo you"re adding another layer of 'shit that can go wrong' to the mix, and of course you"re committing to a single manufacturer"s proprietary software; something you"ll depend on to be updated and keep pace with your host, computer OS, etc. Not to mention what happens if down the road your controller breaks and you realize you really want that new super-whiz-bang model from another company â except you"ll be either be spending hours re-assigning things to fit it into your current workflow, or learning a new workflow. As John mentioned above, that doesn"t always work out. For me, a dumb controller and smart host sw will always be the way to go.

[PianoMan51]

+1000 to decoupling the keyboard from the host software. I"ve made two major strategic mistakes in using a software stage setupâ¦

 

1. I spent an enormous amount of time getting the visuals of Mainstage 'just right". And then I never ever looked at the screen once the set started. DOH! (Yes, I am attracted to shiny things).

 

2. I spent an enormous amount of time interlinking my VMK Organ and VAX77 keyboards with Plogue Bidule and a dozen VSTs. And the result was always great because basically if I wanted a capability I could make it happen. Then the VAX broke. DOH!

 

I realized that as long as I backed up my software I could always quickly find a replacement MAC. Not so much with keyboards that have proprietary features.

[mauriziodececco]

I see your point guys, but i think there is basic misunderstanding: i am *not* doing anything fancy with the SL; i haven't touched the sequencer, scales, sysex to switch on or off the lights and so on.

 

I am just stuck with two thing;

 

1) Willing to change sound by change MIDI channel on the keyboard

2) Having a reasonable set of controllers

 

And the fact that i want to be able to reuse the configuration work i do on the computer side with an instrument/sound granularity. This is just not possible with MainStage, and only partially possible with Logic.

 

Considering that the whole concept of MIDI channel is there just to be able to do what i want, it seems a pretty basic set of functionalities, that is available on every MIDI keyboard you can think of.

 

Maurizio

[Reezekeys]

I'm not exactly sure I understand what you need, but I know that in Bidule for instance, you can first split your SL's midi by channel, then send each channel to their own destinations that can be any VIs or controller assignments you want. Anything you wire together can be saved as a Bidule "group" and is available to use in any future Bidule setup you make. So you could have sixteen groups, each corresponding to one of the midi channels, and bring any/all of them into a setup, and easily switch between them by changing midi channels on the SL. Is this what you mean?

[Deskew Tech]

 

And the fact that i want to be able to reuse the configuration work i do on the computer side with an instrument/sound granularity. This is just not possible with MainStage, and only partially possible with Logic.

Maurizio

Can you explain this please? What exactly are you doing that is not possible with a plugin host?

[mauriziodececco]

 

And the fact that i want to be able to reuse the configuration work i do on the computer side with an instrument/sound granularity. This is just not possible with MainStage, and only partially possible with Logic.

Maurizio

Can you explain this please? What exactly are you doing that is not possible with a plugin host?

 

OK, i'll try to answer in the following; i'll also try to answer another point you raised earlier, and to clarify some i said; then i'll shut up for a while .

 

1) Mapping management

 

I am exclusively referring to Logic Pro and MainStage, not to every possible plugin host; i am just starting to look around for alternatives, being a Logic users i would prefer by far

to find a solution or a strategy using Logic or MainStage.

 

A few words about the context: i am not preparing a set with a fixed list of songs and their specific sounds; i play improvised music, and i think in terms of instruments: i prepare a coherent set of instruments for each song or group of songs, and i want to expose on the keyboard some controller to tweak the sound while i am playing.

 

For example, for the last rehearsal i prepared a set with Noire (NI piano), a Falcon pad and a trumpet NI Session Horns Pro. For the next rehearsal, i want to add a set up in which instead of the piano i'll have an acoustic guitar.

Then a third where i keep the piano, but i'll have a sax instead of the trumpet.

 

So, i want to think in terms of a set of mappings for the piano, a set of mappings for the pad, and one for the guitar, one for the trumpet and one for the sax. I want to be able to mix and match these mappings as i wish.

 

In Logic (*) and MainStage, mappings are in a global table; you cannot separate them, you cannot even copy/paste them. (*) Actually, in Logic you have some channel strip level mapping, the smart controls, that offer 8 pots for each channel; if you stay within this limit, this is a solution. In MainStage smart controls work differently, you can have a single set of smart controls for each patch.

 

MainStage offer a hierarchical organisations of patches, where you can inherit settings from your 'parent' patch; this work in some case, but for example not in the case above, where the three different setups cannot be organised in a hierarchy.

 

There are workaround: in some case you can handle MIDI controller mapping within the plugin itself, for example.

 

Note also that the above have nothing to do with the fact i a have a SL MkIII; the only difference is that on the SL i have virtually more controllers; but the problem above exists (and i found discussions in various logic/mainstage related forums) even if you have 8 or 16 controllers. If i want to dedicate the first 4 to NI Noire everytime i have it in a patch i'll need to redo the mapping manually (at least in Mainstage).

 

As a side note, i am aware that certain technologies allows me to design complete solutions to this problem; Max for example (sorry for the shameless plug, i couldn't resist), for the moment i am trying to keep it simple .

 

 

2) Keyboards and failures

 

I see your point, but i think that the general principle is more "Have a plan B", and if you are a professional, "Have a plan B, a plan C, and the skills to build a plan D on the fly".

 

Do having a plan B require not to rely on special keyboard features ? Well, it probably depends on what you do and how you do it. I understand that in your case it does.

 

Personally, having a backup laptop is not justified, so i see an high risk in the whole setup, laptop, software, cables, external disk, audio interface and keyboard.

My plan B, compatible with kind of stuff i do, is to switch off the laptop and use my Nord Electro.

 

I think other people in the forum have this kind of strategy (using standalone keyboards as a backup to laptop based setup), but of course it depends on what you do.

 

3) Final rant

 

When i say that VI Host/DAW developers and keyboard hardware developers should talk more, i mean that at the industrial level, not at the single developer level.

 

As a software guy, with a past in the computer music area, I think that the whole discussion derive from the fact that there is an unsolved problem that the industry don't handle.

 

You can go back home and say "Siri (or Alexia or Google or ..), switch on the light in the dining room and put on Kind of Blue".

 

But i cannot say to a VI Host or DAW "map the first knob on the left of my controller to the Mini filter cutoff". And i cannot ask it to do it whatever controller i use.

 

The technology interconnecting a MIDI controller to a laptop is primitive, it was already simple and primitive when the MIDI was defined in the early 80s.

Things like MCU and HUI are still very primitives and the various ad hoc solutions (like automap, smart controls, and even NKS) are proprietary and of limited use.

 

In the time of internet, solving these problems is technologically trivial, especially if the solution is restricted to the controller/computer use case.

I am not up to date wrt MIDI 2, so i have no idea if the solution can be implemented in this framework.

 

But the industry need a solution that rise the level of abstraction of the interoperability between these kind of equipement.

 

Maurizio

[mauriziodececco]

Oups, quick update: apparently, Ableton Live allows to do what i want, by saving an instrument settings and its mapping in a object called "Instrument rack", that be saved/loaded from/to a file independently of the others.

 

Maurizio

[Irena]

As does Bitwig, arguably even moreso than Ableton. Bitwig's hierarchy of instrument level and instrument-preset level mappings is very flexible, and its VST sandboxing makes it a particularly stable VST host for live performance.

[Deskew Tech]

OK --- a lot to digest - I'm going to try and answer just some of these without getting into "sales" mode because I really want to avoid that in a forum where one is just looking for answers but to be honest, I will have to mention GP in places because it was designed to address many of the deficits of other apps -- frankly such deficits are WHY we gave up and developed our own product! I hope I'm not misunderstanding what you're asking.

 

So, i want to think in terms of a set of mappings for the piano, a set of mappings for the pad, and one for the guitar, one for the trumpet and one for the sax. I want to be able to mix and match these mappings as i wish.

Maurizio

This sounds like you're just talking about a channel strip "preset" -- one for a piano with some sounds and effects, one for pads, etc, one for trumpet so you can just create a patch by inserting a few "preset" channel strips. If so, pretty much any system has mechanism to do this kind of thing. Ableton can certainly do it. In the GP world, we call these "favorites" and Matt Vanacoro has a great tutorial on how we do this (do a search for "gig performer favorites" on youtube)

 

Max for example (sorry for the shameless plug, i couldn't resist)

Maurizio

I'm not quite sure why that's a shameless plug --- Max is awesome, I've been using it since Opcode Systems released it! I've taught it at university and in fact the prototype for what later became Gig Performer was based on a custom MaxMSP system I developed for touring 5 years before we started developing GP. In fact, the OSC system built into GP was originally designed so that I could leverage all the work I did with Max (hundreds of abstractions) and drive plugins inside GP directly from Max.

 

 

 

But i cannot say to a VI Host or DAW "map the first knob on the left of my controller to the Mini filter cutoff". And i cannot ask it to do it whatever controller i use.

Maurizio

I regret that we do not yet have support for voice recognition. On the other hand, the widget system we use (some of which quite frankly was inspired by what MainStage did and even what MOTU did long before MainStage with their original Performer sequencer) makes it very easy to do this kind of thing with just a few clicks. I would add however, that one should not actually ever map a knob on a controller directly to a plugin parameter. Indeed, the beauty of MainStage (the reason I went to MS before ultimately giving up and developing GP) was the use of indirection, i.e. put a slider on a panel, have the slider control the plugin parameter and have the hardware control the slider. That turns out to have huge benefits over controlling a plugin parameter directly from a hardware controller. Ironically, I wrote a blog article on this particular topic a few months ago (https://gigperformer.com/avoid-controlling-plugin-parameters-directly-from-your-midi-controller/)

 

And i cannot ask it to do it whatever controller i use.

Maurizio

Asusming I'm not misunderstand you here, one of the reasons we created our "Rig Manager" was to address this very problem. You can use the Rig Manager to define "names" for your controllers and for the knobs/sliders/buttons on your controllers. You then use those named items in your patches. If you want to use a different controller, you update the Rig Manager with the new controller (if you haven't done so already) and then your new controller will happily control all the same things your old one did. By the way, the other main reason for the Rig Manager is to make it easy to disambiguate between multiple identical (from a USB view) controllers.

 

 

 

Personally, having a backup laptop is not justified, so i see an high risk in the whole setup, laptop, software, cables, external disk, audio interface and keyboard.

Maurizio

Here I have to strongly disagree. I think people forget how reliable are laptops these days. Think about it - most people work on them all day, every day, carry them around to work, throw them around, even drop them occasionally and they just keep on working. If this was a real concern, there wouldn't be hundreds of thousands of musicians popping up on stage with laptops beside them. In my own touring rig, I have a 19" rack that contains my audio interface, in-ear monitor transmitter, a bunch of USB hubs and power --- everything is connected (where appropriate) to a patch panel on the back of the rack. On stage, I just plug my keyboards into the back of the rack (USB sockets on the back), plug my computer in as well, and then just connect audio via XLRs (also on the back). That rack has been all over the world (US, Canada, many countries in Europe and Japan), thrown around by roadies, thrown into the luggage compartment on airplanes, etc --- never had a problem, since 2012 when I started doing this. Many of our own users also throw in a headless computer, such as a MacMIni into their racks so they don't even have to connect up their laptop.

[EricBarker]

Oups, quick update: apparently, Ableton Live allows to do what i want, by saving an instrument settings and its mapping in a object called "Instrument rack", that be saved/loaded from/to a file independently of the others.

 

Sorry I didn't respond earlier, because I think I can offer some help in this regard. MainStage, too, can have a robust "Instrument Rack" system. Are you familiar with Alias Channel Strips? If you're not, drop everything you're doing, and go look them up. I may not be understanding everything you want to do, but the fact that an Instrument Rack solves your problems makes me think that MainStage has all the tools you need. Aliases are basically like an Instrument Rack, but you can create them anywhere. If you create a piano CS, you can copy and paste it as an Alias to any other Patch. It takes up no more RAM or CPU, and maintains the settings of the original, except for split point, volume, and midi routing. That way you can have a piano in your LH for one patch, but in the RH on another. If I'm understanding correctly, you want to create a number of patches that place different instruments in different regions of your boards. Aliases are PERFECT for this scenario.

 

If you want to treat them like more conventional "Instrument Racks", as I do, Just create a special Patch called "RACK", and throw a bunch of instrument channel strips in there. Then, copy and past them as Aliases (Cmd-Shift-V) into your other patches. This is how I set my concerts up. That way, I know where all my "Parent" patches live, and don't have to worry about accidentally deleting a parent. You'll know an CS is an alias because it will have a green arrow in the mixer. A Parent will have a green arrow inside a circle.

 

Does this make sense? Does it help? It's SUPER powerful, and every MainStage user should know how to use them, it saves a ton of resources and allows you to do exponentially more complex setups.

[mauriziodececco]

 

Here I have to strongly disagree. I think people forget how reliable are laptops these days. Think about it - most people work on them all day, every day, carry them around to work, throw them around, even drop them occasionally and they just keep on working.

 

The first of July 2019, at 10am, i was typing a mail on my beloved 2015 MacBook 12". When i typed an 'l' the screen went dark, the compute froze, shutdown and never restarted; this event, other than showing that computers *do* fails, was actually the origin of this thread; i bought a new laptop, powerful enough to use it in my home studio, and to stop using and finally selling my Mac Pro. At that point, it was logical to use it in rehearsals and concert, so i ended up posting the message at the origin of this thread.

 

Last year, an USB cable failed on me, burning the USB hub i had; during a rehearsal.

 

Without counting the endless days spent in managing the system, correcting human mistakes, finding solutions to bugs, solving problems created by an update or another.

Or a RAID 1 having both disks falling at the same time.

 

If laptop are so reliable, why people buy expensive insurances like Apple Care ? Why people keep two or better three different backup copies of their data ?

 

The more complex a system is, higher is the risk of problems; hardware, software, or configuration.

 

If you are a professional, and you have a dedicated system, you may afford the luxury to freeze it from the software point of view, and do not touch it other that for using it.

But this do not protect you from hardware failures.

 

Clearly, you have been lucky up to know. YMMV: personally, unlike you, i never had an keyboard failure, but plenty of computer related problems (expecially if i include my 37 years career in the sofware sector) .

 

Maurizio