I would like some advice on the method that I am using for the management of my Racks.
I created some Racks grouping my VST by category: rPianos, rOrgans, rPads, etc etc
Each rack has its states. Each state corresponds to a VST / presets
Now I need to play two or more sounds in the same rack: for example 2 different pad both placed in rPads rack.
Not being able to fit into a song 2 times the same rack, I created two symbolic links to the rack in question; rPads1 and rPads2.
I’ve placed and routed with no problems in my song. Each rack has its selected and everything sounds perfectly.
I have not encountered problems even during a change.
At this point I could create symbolic links per rack and using only those.
Now I wonder: I’m doing well? You could create a problem?
I believe @brad himself suggested this some time ago - the only potential problem I could see would be competing writes, if you change something in parallel in both instances of the same rack and then try to save.
As long as you are careful with making changes to your racks, you should be OK.
Cheers,
Torsten
Thanks Torsten. I had not seen Brad’s suggestion.
For now I have not had any problems. I have to be careful not effetuare modifications in parallel.
But in case of problems, there is an alternative? Have you ever had this need?
Maybe resolved in any other way …
No, so far this is the only solution.
I’ve not had this need yet, even though my setups get pretty complex. But my racks are usually set to specific purposes (piano, strings, main synth, solo synth); some of them contain the same plugin, but with different sounds. The Korg M1 sits in three of my racks (strings, main synth, solo synth), but with totally different banks, tailored to purpose, combined with other plugins. This is why I rarely had the need to use one of my racks twice.
Cheers,
Torsten
Torsten and others set up instrument racks for specific purposes like pianos, strings, organs etc, but there’s no particular need to organise racks that way. If that way tends to lead you to the need for multiple instances of a rack, perhaps a different way to categorise by racks would work better, e.g. name your racks after the plugin itself. Or maybe you need to split categories, and have a smooth pads rack and evolving pads rack etc.
One thing I do is have rack states with generic names, like “Smooth strings”, “Lead strings” or whatever, and then once I’ve decided on a sound for a particular song, I copy it into a new rack state, with a different bank number, and importantly, name it after the song. That way I can make further tweaks to it, knowing I won’t be affecting any other songs that are using that rack state. Working that way then makes it easier to manage multiple instances of a rack; you could for example have two strings racks, Strings1 and Strings2, where you typically use Strings1, but if you need a second strings sound concurrently in a song, you store the rack state in the Strings2 rack (as a kind of “overflow”). No need to synchronise the racks, or worry about overwriting stuff. This approach works well for me - I actually have three VB3 racks, for example, as some songs I play need three instances.
Neil
I make some of my racks multi-timbral. Ch#1 may be routed to M1, Ch#2 may be routed to Kontakt, etc. My pads rack has several instances of M1 and others.
Some months back there was an item in Trello on implementing multiple versions of the same rack. But now it’s gone I see. It would be really nice to have to more solid way of handling this, instead of depending on the external feature of a symbolic link.
Maybe the collective brain power of the forum community can come together to think of a way to solve the problems that currently require Cantabile to limit you to one instance of a rack at once. One of the problems (if I remember correctly) is that suppose song A has two instances of a rack, and song B has an instance of that rack. Which one of the two instances from song A will be used in song B? It’s important because you may wish to play sounds continuously on that from song A into song B. But how does Cantabile know that’s your intent? What if both songs have two instances, where you may intend to maintain continuity across songs for both? How would Cantabile know which ones to pair up?
How do you deal with situations in a single song with two instances of a rack, where you modify one instance? Does it change the other instance automatically/immediately? Are they clones in all respects apart from currently selected rack state? How do you decide what things should change in the other instance, and what things shouldn’t? What happens when you save the song - do changes to both instances get stored in the single rack file? What if there are conflicts, where different changes have been made to the same thing in both instances?
Should it simply be an “internal” version of the use of symbolic links? In which case multiple instances of racks will overwrite the common rack file when they’re saved, and the other instances will remain as they are until they next happen to be loaded, at which point they’ll bring in the new version of the rack. Is this desirable? Dangerous in some cases?
Should Cantabile allow you to load one instance “normally”, and then additional instances in a kind of read-only mode, where you can’t change the rack once its loaded (apart from rack state), and only the “normal” rack instances can be used for continuity between songs?
In many ways, embedded racks are an answer - you can load a linked rack and convert it to an embedded rack multiple times in a song, thereby having multiple instances. But you lose the ability to make changes to the embedded racks and have those changes appear in the linked rack file - it’s a lone wolf, no longer associated with the original rack. Also you lose some of the memory-saving advantages of linked racks.
I don’t think these are all just technical details for Brad to work out - they affect how we would use multiple instances, and what some of the dangers would be. So perhaps it’s down to us to come up with some carefully thought-out ideas about how it could work in our various different scenarios.
Neil
@Neil_Durant - a great, well-thought-through post, as usual 
TBH, a lot of the aspects you mentioned are the reasons why I’m actually quite happy with my current approach of treating racks like I would treat physical synths or “rack modules”. For these, when I need two of them, I need to buy a second one and make sure that it has the data I want on it - either copy from an existing unit or develop new patches exclusively for that unit.
It actually helps me to consciously think about which “units” I use in what song; all issues around routing, notes continuing into the next song etc are much easier to resolve when staying within that paradigm and not wildly copying virtual instances back and forth 
In my other life (as an IT manager), I always found that people make less mistakes when they work within a paradigm they can relate to from “real life” - maybe I’m just so old-fashioned that I work best in a way that still reflects my physical live setup - albeit in a slightly more transport-friendly way
Cheers,
Torsten
Hi.
Bringing an old thread back to life. Just wanted to check if there is something in place which makes it possible to use two instances of the same rack in the song? That’s the thing I’m waiting for before jumping on the C3 wagon 
R
Hi Mr. Pedersen,
At this time no 2 racks in a song can have the same name afaik. But, you can still create a rack, save and name it and immediately save a copy of it with a different name (eg. “piano rack” for the first name and “piano rack 2” for the second). They are functionally the same thing but with different names. Then add the copied rack with the different name into your song and it can be in the same song that way. I don’t know if this meets your requirements but I know it works and use it all the time.
Dave
You can use the same rack in a song as often as you like as long as you load them as embedded rack and not linked.
Yes, but that means that this embedded rack is now specific to that song - and on pre-loading a setlist, multiple copies of the rack will now be loaded. Usually not what you want to happen…
Cheers,
Torsten
I’d second @dave_dore 's approach - I regularly make copies of rack files (e.g. main reverb, solo reverb, guitar reverb are all the “same” rack, but copies). The disadvantage of this approach is that changes you make to one of them will not automatically be applied to the copies. Essentially, once you “clone” the rack, each copy will take on a life of its own and evolve separately.
For me, this is not a bad thing - over time, I created different “presets” in my guitar reverb rack that I don’t need in my main keyboards reverb, so I’m happy with my divergent copies, but if you want to make sure your copies stay in sync, you’ll need to use symbolic links - with the disadvantage that after any editing, you’ll have to completely re-load all instances (essentially re-start Cantabile) to make sure the change gets loaded into every instance.
Cheers,
Torsten
I set up my shared racks in 2 different ways. For racks where only one type will be used at once (i.e. Pianos) I set up rack states. For orchestral or synth racks where I may need access to multiple VSTs, I use multiple named MIDI rack inputs. If it is a relatively resource cheap VSTI I may consider just adding a second instance of the VSTI for the rare song that needs it.