Thanks @Torsten for your opinion on my suggestion.
The first quote above makes my point that the variable $(SongProgram) is saved with the setlist. What I am suggesting is a variable $(SongID) which is hard-wired to a song and is saved with the song, i.e. it is used instead of a song’s title.
The picture shows a typical way I use Cantabile. Because my full library takes up a lot of RAM (nearly all my 32GB), I tend to load just a few songs that require some editing as shown.
When loaded, there is an automatic assignment of $(SongProgram) values of 0, 1 and 2. To identify the songs in any bindings I would have to change the “slot” numbers to 4, 24 and 14. Using my suggested variable $(SongID) would render this unnecessary and my binding logic would still work.
I know I could save the setlist with a different name. But I might need a different set of songs to edit the next day and I don’t want to build up a big list of setlists that I might never look at again.
If $(SongID) is just an additional variable, I don’t think this will break any existing setlists so a Cantabile user can continue to use existing setlists as you describe. (Perhaps @brad could confirm this?)
I’m just hoping that others can see how useful $(SongID) could be.
My comments were mainly aimed to clear up any potential misunderstandings about the uniqueness or non-uniqueness of the Song Program variable.
I am still trying to understand why you would want to have a song with a unique song ID by itself. Is it because you want to do something in your background rack based on the specific song that is loaded?
I typically try to avoid these kinds of mechanisms and interdependencies - too much that can go wrong. But to each their own…
One suggestion would be to turn the mechanism around and make the SONG trigger the changes in the Background rack instead of the Background rack reacting to some knowledge of the song loaded. My principle is: everything song-specific should be driven by the song file itself.
So if you want to change some setting in your background rack based on the current song, why not make the current song send a program change to the background rack via a loopback port. Then create a mechanism in the background rack to react to these program changes and load a specific configuration - all done!
Essentially that “OnLoad” program change becomes the unique “Song ID” - just a different mechanism.
It would mean on loading a set list every song file would need to be at least parsed once to extract those numbers - since they wouldn’t be stored in the set list.
I agree with Torsten that this then creates a duplicate set of numbers to maintain.
It’s a second number that wouldn’t be displayed in the set list, or you might need another option to show it instead.
It would probably also require a new set of bindings to Load Song By Id, Load Song With Id etc…
What if instead of a SongID, each song file had a “Default Program Number” property? When set and when adding the song to a set list that number would be used in preference to automatically picking the next available number? I quite like this because it’s easy to implement, straightforward, doesn’t require any additional bindings or display rendering changes and its use would be optional.
Also, I still think the master set list approach without any changes can handle this easily enough:
Create a master set list and assign your song program numbers
Turn off pre-load on your master set list - that way it will load quickly when you want to edit it
When you want to work on a subset of songs, create a new set list and then use Add Song From Another Set List to build your working set list. You can bring in as few or as many songs as you want and they’ll keep their program numbers from the master list.
This approach is essentially the same as having a default song number for each song - it’s just that the default is stored in another set list rather than in the song itself.
Using Add Song from Set List with a master set list approach, you don’t need to save new the set lists if you don’t want to.
Thanks for your detailed replies. @brad’s suggestion solved it. I used “Import songs” to create a mini and temporary set list and it worked a treat.
@Torsten asked me what I’m trying to do.
When a song loads I use a binding in the background rack to load a preset for a Vocals Rack to set up the plugins in the rack suitable for talking between songs (labelled P.A.)
Then I press a button on my Stream Deck which switches the Vocals preset to that used in the song for singing, i.e. adds reverb, etc.
To avoid adding a binding to every one of 90 songs, I wanted a binding in the background rack to switch the presets. I wanted to reference every song so I used $(SongProgram) but this was breaking down when I added just a few songs in a “new” set list.
@brad’s suggestion has solved this. I didn’t know about “Import Songs” as I had never tried it.
Sorry for the wild goose chase. Will I ever understand how Cantabile works?
Personally, I put my vocal rack (controls my VoiceLive 3) inside my songs. With linked racks, this creates no additional overhead compared to putting it in the background rack, but of course I need to have this rack in all my song files (it is part of my standard template when creating songs). I find that this is a more cohesive and predictable approach - have everything song-related (like the song-specific vocal settings) within the scope of a song file, while the background rack doesn’t care about songs and simply has all functions that work across all my songs.
With your approach, you’ll potentially need to modify your background rack for every new song you create - or when you want to modify your vocal sound for an existing song. This wouldn’t be my preferred approach - but to each their own.
Good that you found a way to make your approach work with Cantabile’s existing mechanisms!
Thanks for your reply but I think you’ve misunderstood what I’m doing.
The presets are all part of the linked rack “Vocals Rack” which is in every song and not in the background rack so I’ve got no bindings for vocals in any song. The bindings are in the background rack.
I’m definitely a convert of linked racks and have been since I first used Cantabile - I’ve read all your posts.
