I think you are right - the disabled track issue is worse than track archive in general.
Even more sad it wasn’t taken care of then - it would fix both parts like track archive too.
In the root - it’s the same issue - keeping track of what belongs together and how.
And you get the same symtom slike scrambled order of output and extra automation lanes Cubase does not know what it is.
You don’t want to continue working on a project showing those symptoms - you never know what turns up later when everything is added and saved and stuff.
But I think it’s a good hint - that saving what arbitrary tracks or track neighbours makes a difference in track archive thingy.
Hope you get it sorted - even in 9.5.50 - but I’m leaving Steinberg now, I’m done.
Managed to reproduce the issue from the ground up in 9.5.41 in a few easy steps
1 created a kontakt instrument track with 7 outs, used some instruments from the factory library.
2 put a plugin on each output (soundtoys)
3 duplicated this kontakt instance a few times
4 saved “good” version of the project
5 disabled one istance of kontakt
6 closed/reopened Cubase
7 loaded the project (got the usual cubase error asking me if I want to remove the tracks it cannot connect - deserves discussion too)
8 enabled that instrument track
9 boom - its broken on the first try
10 saved the failed “broken” project
here’s both projects, hopefully this brings us closer to the solution since it was so easy to break it
I hope the devs can compare both versions and find the breaking point
I think we’ve established that one person’s precise experience is not necessarily replicated by someone else. My conviction is that if someone is looking for the bug (or even if they are not), it shouldn’t be very hard to find, however. Closing Cubase and re-opening is an important factor, and if the devs / beta testers haven’t been doing that it would explain a lot.
Well at the very least now they can see how the issue actually looks
But it was so easy to reproduce this time around, I think its definitely connected to closing/reopening cubase and/or some ram/cpu load.
I’d love to try somebody else’s project though, don’t have v10 so cant try yours
It should be triggered in 100% cases across all our machines if we tick all the needed boxes
Hmm, I think that’s looking for something that won’t ever exist. Things don’t behave the same way on my own system two times in a row.
The best we can do is provide all the elements and instructions which should trigger it for everyone given a small amount of tenacity. At this point my feeling is we’ve done enough between us, it’s down to Steinberg.
Ok
We can agree that its pretty easy to reproduce from scratch though
PS I’m sure on my machine any other project in question will inevitably fail. just so happens that I get this issue in 100% of my projects pretty much straight out the door
TEST PROJECT3 - the fresh working “good” project(from my previous post p798193), I exported the track archive xml from this one
TEST PROJECT4 - a new blank project I used to import the xml into. I selected a few tracks from the track archive xml and they loaded broken straightaway. Saved it after the failure obviously
2411 TEST PROJECT3 track archive2.xml - the xml itself.
so a different mehtod but exactly the same outcome
Hello Everybody,
Thank you all so much for your posts and help so far.
Thanks kavinsky for your repro.
Question:
A) Does this repro nail down the problem or are there more related repros to be found?
Request:
Please try to find and posts problem related repros in a style that is examplified by kavinsky. Thus more like a cooking recipe.
Repro:
Create Empty Project
Add Instrument Track “Kontakt 5 8out” (vst2)
Activate all Output for Track (Kontakt 5 8out 01, kt, aux 1[Stereo], aux 2[Stereo], aux 3[Stereo])
Right click track and “Disable Track”
Save Project as “ReproMultiOut”
Close Cubase
Open Cubase
Load Porject “ReproMultiOut”
When asked “Remove tracks that could not be connected” please choose “Cancel”
Right click Instrument Track and “Enable Track”
Problem: The single outputs of the instruments are ghosts. This is also recognizable as they are missing the little keyboard symbol on the left. (Please also view Screenshots “MultiTrackGhosts” and “MultiTrackReal” for comparison)
Hi JHP - i’ve been discussing this with Matthias. I’m pretty convinced that a watertight repro does not exist - the nature of the problem is slippery. I doubt this repro would fail in all cases.
My belief is the best we can do alongside possible repros is to provide materials and instructions as I did earlier up the page, and I’m told this is being looked at by you folks too. I added a READ ME to illustrate the kinds of activities that increase the probability of failure, these include:
Restarting Cubase (I’ve never had a failure on a new archive or disabled track without at least one restart)
Restarting the OS
Increasing the complexity of the project (though it can fail on just one instrument in a blank instance)
Any activity that has already failed once is much more likely to fail again
The above applies to disabled multitrack tracks and track archives on I believe any version of Cubase from v8 - v10 (probably earlier where the feature was present ie since inception). My layman’s theory is that there are factors unique to each setup at work, possibly including preferences, though a clean slate install will rapidly become buggy again once these features are used.
Hugely grateful for all your ongoing efforts in tracking this down once and for all, and thanks for taking the time to post here to keep us in the loop.
Just what Guy said, its not as easy as an a+b=c, but its really not that hard to get it following our instructions
Mainly these are the problems:
-greyed out “ghost” outputs (renamed as “synth” outputs in their place)
-duplicated outputs (a visual bug)
-mixed order of the outputs
-the outputs randomly picking up names of neighboring instrument tracks.
The ways of getting the issue:
-track import/export
-disable/reenable
-import tracks from project
-drag’n’drop from inactive project into active one
All of them lead to the same exact problem.
I have loads of projects manifesting all of the described issues - if that can help
I have projects that are working fine on its own, but its literally impossible to correctly import a particular track out of them.
Anyway if I can assist in any way - let me know.
I’m down for doing more repros though. Will report back here
Thanks for your posts and all of your efforts. This is very helpful.
Often only repros are usefull for the engineers. *.cpr and *.xml and so are much less enlightening.
I found another repro.
Repro:
Add “Kontakt 5 16 out” and activate all Outputs
Add “HALionSonic” and activate all Outputs
Disable both tracks
Select both tracks → File-> Export → Selected Tracks → Save as “KonHalDis1”
Close Project (Before that make sure to remeber the way the track listg looks, maybe make some Screenshots)
Open Empty Project
File–> Import Track Archive → “KonHalDis1”
Sometimes Problem–> Crash
Enable both tracks
Problem: The multi outs are dublicated, in the wrong order and there are some ghost tracks
Even if you hide the tracks and show again most of the problems remain
And the search for more repros goes on. Thanks for all your help
This is more of a logistical and structural remark.
We will gather all of the repros in this thread and in CAN-13042 which are both linked.
Most likely after that each repro will get its own Issue and Jira number so we and the engineers can beat down the bugs bit by bit. This is to get a better structur and overview of the occurences. If some repros point to the same cause in the code we can still link the Jira Issues and treat them as one.
I’ll definitely spend some time on it this weekend
In the meantime, here’s what I got a few minutes ago when imported a Kontakt instance from a different project
So its Kontakt
But the outputs 9/10 to 17/18 are duplicates from another instrument that was already in the project(Superior Drummer)
so if you solo these, the original outputs get soloed aswell.
Its obvious that they are mixed in in place of the “ghost” outs, but in a project with multiple multiout tracks, they instantly get mixed up.
Sometimes the outputs are renamed to other instrument outputs’ names, so as you can guess it would be really hard to replicate each iteration of this problem exactly as it has many faces.
But we hope that fixing one issue would be the cure for the others.
UPD
Here’s what I got importing this same exact track from another project it was used in.
The main stereo output is doubled, its quite usual aswell.
and the outputs are not in order of course
Hello Jan, I just followed these precise steps on my rig, Win 10 64bit, and I had no issues - it re-enabled completely clean. I then retried the test having restarted the OS, and it also re-enabled clean. I get this issue all the time as you know, but it illustrates how this particular problem is so tough.
I’d urge you good folks as much as possible to work around the fact that the cooking recipe option does not always trigger the fault. It sounds like you’re seeing it, but it really is slippery which I realise makes it harder to track down.
In the light of this, please advise on how we can best help. My conviction remains that brute force and repetition using the techniques I already outlined is the best way of triggering the fault. More cooking recipes would seem to me to be of limited use.
I think I’m with Guy here. We can break it easily on our machines but its not predictable in 100% cases
And if you’re in a busy project trying to import something - the possibility of failure raises drastically.
It happens in each and every one of my “serious” projects
Just something goes wrong at some point. We were not able to narrow it down for the last 3 years
All we can do is to assist in helping to replicate it on your end - a few different approaches and the issue will inevitably manifest itself.
Hi Everybody,
I do not want to dispute what you are saying that the issues mentioned in this thread occur intermittent and system specific. I understand that. But I am pretty sure that without dedicated repros debugging is not possible. This is what debugger tools do. They show the code that is being executed during the time of failure which give the engineer hints on how to fix it. So again, if you can find repros that work on your system please post them here. At least on my system the repros I postet work 100%. So that will be a good clue for the engineer. In these system specific cases engineers install special software on the problematic systems to latch into the Cubase code during the process of failure. This is called “Remote Debugging”. But also for this a repro is needed.
Thank you for all your help. I will continue to investigate. With the working repros on my system engineers will soon be involved as well to (remote) debug the problems that are pointed out by the repros.
Thanks for the update, Jan. Perhaps the best tip I can offer is that if it is breaking on your system using those steps, for the debugger to be installed on that machine as you suggest. I’ve found that when something breaks on a machine, it should fairly reliably break every time afterwards - in fact I have a theory that over time the problems escalate. What starts out as phantom tracks might in a few weeks time end up as duplicated and re-ordered outputs.
The problems all start when trying to get a replication on a different machine, and this was a good example - kavinsky and I both get these problems routinely, but not on the specific steps you’ve found it on yours. So marrying up the debugger with a machine where there is a known recipe has to be the dream ticket I’d have thought.
Just an update from my end - I’m now on the Cubase beta team, and this is now being actively investigated there. Anyone with any more info do keep posting here too and I’ll make sure it gets seen.
Had a thought today (always dangerous I know). Great to know Steinberg are finally on CAN 13042, but a solution could still take a while I guess. I’ve been therefore wondering about returning to using Rack Instruments, at least temporarily. While its not possible to disable rack instruments which would be a shame, I wonder if freezing them might be a workaround, adding just a simple dummy note in bar 1 to make the process work. Does anyone have any experience with freezing rack instruments? I’m hoping its solid, and unaffected by these bugs. If I get round to properly trialling this, I’ll let you know how it goes.
