In build 3107, if I go into a rack and do Save Rack As, I seem to get “Object reference not set to an instance of an object”, although it does appear to save a rack file (though whether it’s complete/correct I don’t know).
Once that has happened, if I then go back to the rack’s parent (song or rack), I can’t double-click the embedded rack to open it any more (although I can open other racks if I haven’t done Save Rack As with them).
Neil
I have the same problem here as Neil. I checked and the racks that are created do work when loaded up.
Thanks - I’ll check it out.
Build 3108 available now fixes this.
Thanks alot (and I thought this was by design) 
Well, just trying out build 3108 and finding unexpected results. If I go into an embedded rack within a rack, and choose “Save Rack As”, it saves it, but leaves me with a completely empty rack view, as if it has disappeared. There’s then no way to go back “up” to the parent rack.
If I then change song in the setlist, it asks me to save, and having done that, I find the rack I saved now appears as another rack alongside its original parent rack. I find this surprising because I would have expected “Save Rack As” to only save the rack to disk, and not insert it anywhere. It’s as if it’s really “Save and insert into song”. Is this intentional?
So to summarise, this is the situation before:
Rack A
±–Embedded Rack B
“Save Rack As” on Rack B, and we get:
Rack A
±-- Embedded Rack B
Rack B
Furthermore, this Rack B is inserted into all songs in the set list. And if I delete Rack B from a song, save the song, select a different song, then go back to the first song, Rack B has reappeared!
Definitely some fishy stuff going on…
Yikes that doesn’t sound right at all. I’ll check it out.
Hi Neil,
I’ve had a look at this, and the problem relates to the rules about where linked racks are allowed. In your example you’re trying to convert and embedded rack to a linked rack in a location where linked racks aren’t supported (ie: in a double nested rack situation).
(For the record, linked racks are only supported in songs and a song’s immediately referenced racks can reference other racks already loaded by the song).
The Save Rack As command gets kinda complicated in these situations - and depending on the hierarchy may be able to work around it by adding the newly saved rack to the song, or may not support converting embedded rack to a linked rack.
So, I’ve worked around this by disabling the Save Rack As command for situations where it doesn’t make sense, but added another command “Save Rack Copy As” which is available on all racks and lets you save a rack as a file and then insert it into a song somewhere else.
This will be in the next build (later today probably)
Brad
The thing is, from a user’s perspective, it doesn’t seem like there should be any reason why an embedded rack (regardless of where it’s located) shouldn’t be able to be saved out to a file. Because I wasn’t explicitly trying to create a linked rack within a rack, I was trying to save an embedded rack within a rack, so that I could use it elsewhere, in an allowed location (at the top level of a song). For “Save Rack As”, does Cantabile internally create a rack in the current location that it then saves out?
The reason I tried this was that after converting my v2 session into a v3 setlist, all my plugins were stored as embedded racks in a “session” rack. My intent was then to save these racks so they can be re-used across songs. But if “Save Rack As” is disabled for embedded racks within a rack, I can’t do this, which means the v2->v3 conversion will produce settings that leave me stuck unable to make good use of v3 functionality - essentially running a v2 setup within v3.
Would converting the imported monster “session” rack into an embedded rack allow me to the do “Save Rack As” on the nested embedded racks, and thus liberate them?
Hi Neil,
Yep, this is exactly what the new “Save Rack Copy As” command does - it saves a copy of the rack to a file, but doesn’t replace or otherwise affect what’s already in the parent rack or song - ie: it liberates a copy of it - regardless of where it is and then you can delete the embedded one and link the saved copy back into a parent song as required.
Brad
Aha, excellent!!
It seems slightly confusing wording though - “Save As” in most software doesn’t generally change the state of the thing you’re saving (or insert it anywhere), other than to mark it as no longer having unsaved state. I wouldn’t expect a “Save As” command to do anything other than store to disk, so it seems “Save Rack Copy As” is a “Save As” type function, but “Save Rack As” has some (to me) unexpected side effects - it’s converting the thing you’re saving.
Hi Neil,
The one thing that does change with Save As is the name (and possibly location) of the thing you’re saving - so I think to invoke save as and the name of the rack not to change would be confusing. Some windows app these days do have “Save Copy As…” which saves the file, without changing the name of the loaded document - which is where “Save Rack Copy As” comes from.
Brad
Fair enough! Just one suggestion for consideration then - how about “Export Rack As” instead of “Save Rack Copy As” ? To me that makes it feel like a much more “external save” kind of operation, distinct from “Save Rack As” which seems to be more of an “internal” save within song kind of operation.
Nice - I like it, done!
I’ve just been playing with this functionality in build 3110 and it works great! It’s very usable, and I think I should be able to convert my monster v2 session into a really decent v3 setup fairly fast. Nice work Brad!!! 