First live show using Cantabile 3

Cantabile
1

Well, on Friday I had my first gig with Cantabile 3, playing with IQ, headlining at the Reichenbach Art Rock Festival in Germany. I’ve been using Cantabile 2 live for a couple of years now, with quite a complex setup, and so migrating everything over to Cantabile 3 has taken a while. But I’m happy to report that the gig went really well, and Cantabile performed flawlessly!! Here are a few photos - one of my keyboard rig on its riser backstage (surrounded by clutter) before the show, showing Cantabile 3, and two taken during the show. Next stop Norway and Sweden in a few days!

Neil

20160401_153109.jpg1500×844 475 KB

12909569_10209475791550807_8357638744370454883_o.jpg2048×1366 224 KB

12901064_1687765191462143_428084557421159594_o.jpg1500×1000 174 KB

7 Likes
2

Looks really great Neil! Love your rig. I used C3 for the 1st time 2 weekends ago. It went very smoothly. I worked on improving my setup this past week, and gigged again this weekend. I am really impressed with C3. I had some stability problems with C2, so I was skeptical when trying this version. So glad I gave it another chance. I am further impressed with Brad’s commitment.

1 Like
3

Thanks Corky! Glad your C3 system is working as nicely as mine!!

4

Hey Neil,

That’s so cool. Really pleased to hear it worked so well. And I love seeing photo’s like this - makes it real!

Brad

2 Likes
5

Rather than start a new topic I would like to resurrect this one, although it only partially applies.

Although I have been using Cantabile for live shows for a year and a half, I’ve limited its function to MIDI routing only. I use it to control all routing, processing, filtering, Program Changes, key-ranges and layering for my Nord Stage 2, Kronos, and two rack synth modules. Workflow wise, I have a MIDI foot controller that I organize the setlists in, and it sends PC messages to Cantabile which in turn shoots out PC messages to all my units, and configures all the routing and filtering.

Using it just for MIDI, the song changes take about 300ms or so. This works well for our “no hesitation between songs - keep 'em dancing” style.

Now, having discovered that the persistent back pain I’ve experienced is osteoarthritis in my spine, and not likely to cure itself, I spent the past few days programming Halion Sonic3 (HS3) to take over the role of those rack synths so I can do away with that 35kg rack.

The major issue I will need to resolve is song-switching time. I may need to rethink the workflow paradigm that I’ve been using since 1989. MIDI FootController sends PC -> Router/processor Unit (currently Cantabile) which sends PCs -> sound sources. Router/Processor handles all MIDI traffic and mapping/filtering per song.

Last night I observed widely varying song switching times.

  1. When switching from a song that did not use HS3 c to another that didn’t use it, ~300ms.
  2. When switching from a song that used HS3 to another that did not, or vice versa, 7-12 sec!
  3. When switching from a song that used HS3 to another that used HS3, 2-4 sec (most interesting).

To describe how I added HS3 to songs: For the songs that I use Halion Sonic in, I just did an “Add Object” on the Cantabile3 routings panel and selected “Plug-in,” then Halion Sonic and it came right up. I used the default “Multi” in HS3 and picked the sound I needed and put it in slot 1 of the Multi, then saved the song. I did not create and name separate Multi’s in HS3 for each patch.

As I said, this DID work to get me through the show, but the song-switching times as described above were somewhat problematic, and caused me to miss entrance cues for some tunes.

So for the way that I use Cantabile for live shows, what might be the easiest way to improve those song switching times without making major workflow changes? I looked at Brad’s video but found it a bit confusing. I guess my head is stuck on the way I’ve always done my MIDI routing/processing. With the need to replace my other rack synth (and incorporate more VST plugins to the rig) I hope to figure out a solution.

Many thanks!

~ vonnor

6

OK, there are two main elements to have quick song switching:

  • keep your instruments in shared racks, not directly inside the song, then use setlist pre-loading, which loads all songs in a setlist into memory. Using shared racks is essential, otherwise Cantabile will have to load all the individual plugins in your songs separately, this means one instance of HS3 for each song - the more songs you have, the more memory this will consume - things will pile up and consume all your RAM

  • when using sampling instruments, try to avoid having to re-load between songs. Even if you have HS3 inside a shared rack, this will not help you if you have completely different configurations per song and try to load them via rack states. This will mean that even though HS3 is already pre-loaded, it will have to load the samples from disk at song switching time.

Using sample-based instruments with quick song switching requires that you load all the necessary samples at the beginning of your set (so you’ll need sufficient RAM to do this). So e.g. put your favorite 16 sound into one instance of HS3 in a shared rack, then simply create rack states to switch routing between these 16 sounds (rack state 1 sends input to MIDI channel 1 → sound 1, state 2 sends the same input to MIDI channel 2, …). Use MIDI filters inside the rack to achieve this. Essentially, you’re treating HS3 as a pre-populated multi-timbral sound module with your most important sounds pre-loaded. If you need more than 16 different sounds, then simply create another shared HS3 rack with 16 more sounds - as long as your RAM will allow.

The crucial bit is here to use shared racks and pre-loaded setlists - then you only need to load your samples once (when loading the setlist) and they’ll stay in memory, so you won’t need any loading between songs.

You can also create far more than just 16 sounds in one rack by adding VST effects chains after HS3 and have different configurations of these effects for each rack state, using the same basic 16 sound. E.g. the same piano sample in HS3 can be EQ’d in different ways to accomodate different songs without having to re-load a different sample set. VST effects usually switch configurations very quickly.

Of course layering of your 16 sounds is also an option - you just need multiple routes active within your rack to send your input to multiple chanels of HS3.

Hope this gives you a few pointers in the right directions - do a bit of experimenting; you’ll get there!

Cheers,

Torsten

2 Likes
7

Also, see this.

8

So to be clear, I should define a Linked Rack for each of the VST Instrument plugins I use? One for HS3, one for Synth-One, one for OBxd, and so on? And just add the appropriate Rack(s) to any song that uses them. If I do that, is turning on “setlist-preload” option all I need to do then to insure that my VST instruments stay in RAM the whole set? I think I can live with the HS3 patch-change delay (2-3 sec), but the close/open delay (10+ sec) was killer.

~ vonnor

9

Pretty much. Once the rack is loaded in the setlist, it is there. If I use the rack in another song, and I use a different preset, I allow the song to change the state for that particular preset, so I won’t have to reload that VST again.

10

Soft synths will generally change patches as quickly as any hardware synth- maybe with the exception of some ROMplers, but I’ve never had any trouble. It’s the samplers that get you. For Kontakt- and I load a good amount of Kontakt stull for our show- I don’t use linked racks, I use a separate instance for each sound and preload the whole thing before we play. With a normal hard drive it take almost 10 minutes. With an SSD it takes about 90 seconds. With the whole set preloaded I have mostly instantaneous sound changes apart from one or two that take maybe half a second or so but don’t interrupt the flow.

11

Any particular reason why?

12

By “allow the song to change the state for that particular preset” do you mean have Cantabile do the patch change in the VST instrument on song load? Or something else?

13

I’m guessing Halion Sonic 3 is a combination of soft-synth engines and sample-based rompler engines, but I’m not an expert. I do know that when I did an “Add Plugin” in a Song’s routings panel and selected HS3, the default (init?) Multi appeared. Going into the sound manager and selecting a sound (patch) for slot 1 of the Multi it took 3-4 sec to load in the slot.

~ vonnor

14

rack states

In this experimental rack for the B5 organ, I have different presets saved. For this song I have selected 1:C3 state (preset) as my choice. In another song I could select, say the 2: B3CH 3 state. The B5 organ stays loaded in the setlist, but I can change the presets (states) for the B5 by simply saving it to the song. So…on song 1 I automatically have the number 1 state, on my 4th song I have the number 2 state selected. The VST stays loaded, but the presets change with the song. I can also change presets within the song by using the song states.

15

Well, I should clarify- I do use a linked rack for a piano sound that gets reused. But generally each instance is loading a unique sound. It just seems to be easier in the long run than trying to keep up with an instance of Kontakt loading a ton of crap- having several instances just loading one thing each. It doesn’t seem to be any issue with memory doing it that way and it keeps the routing simple for me.

1 Like
16

Thanks Corky, this was very helpful. I managed to figure out an extensible way to integrate my Halion Sonic sounds into my setlist. After spending all day with trial & error and three different methods, I do have some comments and observations.

The first thing I did was just select “Pre-load Set List” with the way I had previously set-up each song - individual “Plug-In” instances of Halion Sonic in each song that used a HS3 sound. This immediately fixed the slow song switching, but as Brad’s video says is not very scalable when I start using more virtual instrument sounds.

Next I tried creating a Linked Rack and added the HS3 plugin to it. I then built a Multi in HS3 for each sound I needed. For most sounds the Multi only had slot 1 loaded, except for a bell-pad layer had 2 slots filled. I set HS3 so that incoming Program Changes would select from the 128 available Multi’s in HS3, and created song-scoped bindings to send the PC msg to the rack (or was it the plug-in?) on Song Load. So far so good, but I found that to be glitchy. Some song switching did not correctly change the sound. Sometimes loading a different song then back to the correct song fixed the rack sound.

Now in order to fix the glitchyness (which was a show-stopper for me being a live rig), I built a single HS3 Multi with the 12 sounds I needed for the setlist; one sound in each slot (chan). Then I just changed the channel routing as needed to get the correct sound in the correct Song. Again, this was functional and very fast on song changes, but hella-bad for scalability.

I struggled with trying to figure out Presets and States (shuttling thru Brad’s video as needed) but nothing I was doing seemed to work.

Until I realized that in the pop-up under “New Rack State,” “Program” is the same as a Halion Sonic “Preset!”

In the Halion Sonic VST Plug-In, it lets you define 128 “Presets” that are select-able once the plug-in is loaded into Cantabile. Is “Preset” a generic term? A Cantabile Term? Exclusive to Halion Sonic in this case? It was confusing me when I saw “Program” in the “New Rack State” pop-up. I didn’t make the connection.

Once I figured that out I just opened HS3 in the Rack, set a sound for Preset 1, changed to Preset 2 and picked the next sound (Multi’s in each case), changed to Preset 3 and picked the next sound… and so on. Then I created and named Rack States for each of the Presets I had just created. After that, the State names were selectable at the Song level.

Now everything is working super fast, only one plugin (HS3) loads on the Set List Pre-load, and the individual Rack States are being selected for the correct songs. Plus I can keep making Presets and matching Rack States up to 128.

I’m a happy camper.

~ vonnor

3 Likes
17

Very glad you got it working.!! :grin:

1 Like
18

I would think if they are always called “Presets” no matter what the plug-in, then the “New Rack State” popup should say “Preset” rather than “Program.” Just for clarity.

1 Like
19

I think the state’s “Program” assignment is for a state’s number to be assigned so one can switch to a state from a binding. See the video walkthrough at 5:45

The confusing item for me is that in the State Behavior section for a plugin, the item called “Selected Program” is actually referring to the selected PRESET. That item likely should be re-named.

@brad am I correct about that?

Terry

20

Ah! So the “Program” number assigned to each Rack State is just to identify a Binding target? I guess that makes sense.

I see I could create a “New Rack State” identified as say “Program” 12, then pick any “Preset” in the rack’s plug-in (HS3) that I wanted to. It wouldn’t necessarily have to be Preset 12 in Halion Sonic.

And when I define my HS3 presets in the Rack, the list of Presets gets saved when I save the Rack? Whether or not those Presets are selected in a particular Rack State?

~ vonnor