When loading a project (or using a template) with disabled instrument tracks, a pop up window appears on launch asking if you want to delete the disconnected multi outs. Would be good to never have to see this window (as a one time “never show this again”).
2 (original problem resolved)
Confused multi tracks after re-opening a disabled track from a template. This is the reason I still can’t routinely use multi-out disabled tracks. This is what I got enabling Superior Drummer 3 today, after yesterday saving a brand new template:
All the outputs except output 1 are mysteriously duplicated, and audio passes through both. This kind of behaviour common to seemingly all of my multi-out plugins.
I reported this dec 2015 to Steinberg(yes, 2015) - but they wasted the ticket out in nowhere. Just does not exist - even though I have initial confirmation with title header etc. I have haunted Steinberg with this the last month - have to look up what happend - this will decide my future with Steinberg alltogether. I put many hours troubleshooting this and provided successful track archive and failed one. This is no way to treat customers.
I had that when saving to archive from a arbitrary track number in a project - I got that stuff, outputs all mixed up in order and also the dialog asking to delete tracks. So here I used maybe track 13, 18 and 25 or similar - and it becomes a mess when trying to load later. I did a folder with midi track and SD2 instrument track with 7 stereo outs and a bus.
Workaround was to redo saving to archive from a blank project, so SD2 and 7 outs and a bus for those were the only ones in that project.
That seemed to work.
If to do with tracks consequtive or not, don’t know.
So if disabled has the same problem as not starting at track 1 or something similar.
Thanks for confirming, Larioso. You don’t have a reliable step-by-step to induce a fault, do you? I’ve found it extremely erratic, but it would be nice to get it down to an A, B, C to increase the chances of Steinberg ever addressing it.
I’m sorry, I don’t have exact steps I did, I did not backup my text to bug report ticket I tried post to Steinberg.
I think, if you have an archive you import from with steps described - and if you, like me, find that doing a prepare of SD another way and make archive that works - would be good help for Steinberg.
I still have my two - one archive that works and one that does not - exat same setup - but I still have SD2. You have newer SD3.
I’ll attache those two here below - and it might be helpful if scanned by Steinberg officials.
It’s just the Avatar default kit and rerouted 7 outs with various bleeds summed to separate faders - so think anybody with SD2 can recreate it.
One will get completely altered order of outs - and also give error dialogs about deleting tracks - and the other just do what it’s supposed to.
Resemblance I see with our two outcomes are that you have disabled tracks - and I have used arbitrary tracks - when saving archive.
So might be something to do with that stuff are not in order and enabled.
I made use of my stuff as workarounds, so never looked further into this. Just being aware not saving archive from any project where tracks are spread out. I use archive strickly as track templates. It saves 10-15 minutes setup everytime I use this SD template as an example. Just a bore to redo these things and anming and routing everything. CPArchiveBug.zip (84.8 KB)
While Steinberg continue to ignore us Lariaoso, I did some tests to see if I can get reproducible steps. So far, I’ve not been able to break it starting with a blank project. As a glimmer of hope, I’ve created a completely new test template using a fair few track archives, where I’ve saved only well behaved tracks. So far, everything is behaving well having saved everything disabled as a template, opened as a new project and re-enabled.
Is it possible that our problems are related to corrupted projects / templates? Certainly in Pro Tools this kind of thing happens, and can often be fixed by loading all the tracks from the corrupted project into a new blank one. I’ll be road testing this theory further in the coming days, will report what I find of course.
Possible I guess, but not likely as I see it.
Everything works fine in original project - and I think saving to archive or reading from archive mess things up.
As I recall my error dialogs to remove tracks involved the extra outputs from multiout instrument - which is basically automation only tracks.
They never contain audio themselves.
I tried to have a peek inside xml files, but these are really hard to trace.
And even as no automation was used, in my case, there were still massive amounts of info regarding automation.
Expertise like developers need to look at those two I provided and get an idea what goes wrong.
Hopefully you can also have example of something that works and something that fails.
Will be interesting to see what you discover.
I succeded in making templates for biggest timesavers for me, so did not look any further into this.
But will make an effort again, not being alone in this search.
At some point one can only hope Steinberg officials will chime in down the line and it gets a bug report ticket number or something.
It would certainly help make up for the disappointment just throwing away reports and efforts we made before.
I’m sure this waste hours and hours for users out there getting strange anomalies using archives.
It’s a slippery thing, that’s for sure. I’ve been getting my breakages without using archives at all - only relatively recently have I used them for anything other than a bunch of audio tracks, and yet I’ve been having these problems for years. But like you my issues are entirely related to multi-out instrument tracks.
…yeah, things started breaking again. Really hard to say what triggers it, just after building a new template for a while, it all starts falling apart.
Steinberg, please look into this. Here’s two track archvies for Omnisphere - 1 instrument track, 7 midi, all outputs activated. This one opens cleanly
This one opens broken:
Here’s what I see when opening the broken version:
(with another 6 midi tracks below which are fine). The output order is messed up, and there are duplicates of G and H (also without their colour info). This archive loaded fine yesterday, and is broken for me today loading into a blank project.
Just out of curiousity, these are projects created on older versions of cubase?
Best way to resolve these issues is to rebuild from scratch in 9
Unfortunately older version templates sometimes just go bonkers
Did you log a ticket? Or followed the bug report procedure?
Raphie - yes, even with a fresh Cubase 9 project. Totally starting from scratch.
I’ve followed the bug report procedure as much as possible, but we’ve found it impossible to find the exact set of things that screw it all up. It just happens. Stuff that works one day are screwed the next. But I’m all ears for any advice on how to further escalate it with Steinberg, perhaps a support ticket pointing to this thread?
have sent this problem too steinberg many month ago with a description to reporudce it and a zip project file. No response. I guess they know about it … seems hard for them to fix though… Is CAN-13042 the official number issue that was assigned to this problem ?
Yes. It’s been pretty tortuous getting this far, but as of last week we finally have a case number, and the devs are finally on it.
I’d been getting increasingly depressed about it. Track Archives and Disabled Tracks are the two tools I want to build my new template around, but both are so buggy as to make the experience tortuous. Here’s hoping this turns the corner.
hey guys, is there still no workaround???
jesus, I’ve just upgraded to C9.5 from 8.5 mainly in hopes this was resolved since 3 years have passed
and no, its still broken
once you disable/reenable your multiout track in a big project - all the outputs get messed up, doubled or renamed to SYNTH tracks, plus theres a bunch of inactive original tracks you need to remove.
the original naming structure disappears as well as the order of the tracks which makes it super confusing. plus there are these doubles that clutter the hell of the project
same when you’re importing a multiout track from another project - it all goes to crap, which makes it really annoying!
we really need to get their attention to this otherwise they will never fix this SO OBVIOUSLY BROKEN thing
Seriously, Steinberg, what the hell?! 3 years! I’m speechless
PLEASE RESPOND ASAP!!!
Depressing, isn’t it? My daily reality, and I do share your incredulity. I’ve heard whispers that Steinberg are listening, but we’d all love to hear something direct from them.
As it is, I’ve not updated to 9.5 because I knew nothing had been done - I’ll be jumping all over 10 if they’ve spent some time on this whole area of track management.
I’d be keen to assist in hunting down the issue. Sometimes it works, I can even transfer the tracks successfully in some cases, but with other projects its impossible.
I wonder if its windows only? It could be related to ram/cpu load
But I can actually see that this would happen beforehand. If you open another project and leave it inactive, you can see the outputs greyed out - that means they are already messed up when you drop the track into project
the fact that a simple multiout track without any processing can be moved around/disabled without any problems means that it can be fixed.
possibly quite easily
edit
OK I’have just reproduced it
a blank project with 1 kontakt instance and a simple multiout instrument - works fine, can be dropped into another project in integrity
but then I duplicated it so its 10 kontakt instances and there you go - same old mess when trying to transfer it
so the only workaround I can imagine would be to make a single project file for a few instruments
and then you’ll have to never disable them in the main project. just deleting and adding them from those templates again if needed
its not any less painful though
or just go through the poop disabling/enabling them, deleting those dummy tracks and renaming everything back manually. even thinking about it makes my blood boil
