Unfortunately I'm not around when Support is open, so I'm hoping someone will see this here. I'm trying to open some old X1d projects in X3d. They take about 5 minutes to open, and clicking play, for example freezes up Sonar. I've tried manually removing all plug-ins, but even trying to remove a Send, for example, may result in locking up Sonar X3d. Are others having success with X1d projects in X3d?
 
Thanks!

Once open try saving as a X3D bundle.
Open the bundle then save as project
Open the new project...
 
Any good that way?
 
Cheers...

I suspected that so much had changed that it would be better to save the project as an X3d project before doing anything else with it, so I tried that. I haven't tried it as a bundle, however. Good suggestion.
 
If there's a solid recommendation that seems to work in most cases, we should coerce CW into creating a page in the manual for converting old projects to new.

Very very forward X3E

Eugene perhaps you can give us some constructive advice on how to resolve this specific issue next time? Otherwise I would suggest lobbying for X3E on another thread (this doesn't help us at all).
 
Brian please let us know how this panned out, I'm hoping converting it to a bundle and then a project may help.
 
Thanks...

Unfortunately, saving as a bundle still didn't fix the trouble. What I ended up having to do was open in Recovery, or "safe" mode (not certain those are one in the same), remove all the plug-ins and sends. Then I could save it as a new project, re-open as a normal project. So, there seems to be no way to recover my sessions as they are. I can only recover the raw mix with no FX or sends. That's from projects saved in X1d. I have not tested opening them in X2b.

I record in X1d and mix in X3d.  I've never had a session freeze (that wasn't plugin-related *StevenSlate is 90% the culprit*).
 
Maybe start troubleshooting from the start, even if it seems lame and wasted time :(
For example, create a blank project in X1d.  Save it.  Open it in X3d.  That ok?
Now go back and create a project in X1d, record a single track.  Open in X3d.  That ok?
New project in X1d, record track, add some plugs you often use.  Maybe 1-3.  Open in X3d.  That ok?
Continue till fail in that fashion.
 
If a blank project kills X3d, I'm not sure what to do.

I believe what's going on is that, since I use Waves plug-ins profusely, when they provide sub-version updates (i.e. 9r7 to 9r13 and 9r14), there's something attached to the old projects that obviously can't be updated without opening the project in the newer DAW version which would load the latest subversion of the Waves plug-ins.
 
And before people troll, let me assure that I don't believe this is solely Waves or solely Cakewalk. It takes two parties to make an incompatibility. If one party makes a change, that breaks the other party's software compatibility, the other must adapt. The original party should provide reasonable documentation and notification of the change, and both parties should test, test, and test. If there's a problem, the problem should be fixed with communication. That's how we succeed.

So if you updated your X1 project with the latest version of the Wave plugins (still using X1), and then upgraded to X3 with the latest (same versions) of the Waves plugins would there be any issues along the way? Of course Sonar does not update Waves plugins automagically in either X1 or X3.
 
>  It takes two parties to make an incompatibility
 
Nope. In the land of software generally it's one party that has the issue, and both get the blame for it as the end user can only guess and "assume" as to what is happening as they don't have access to the source code, nor are they developers. Of course sometimes it can be difficult to identify which is which. That's not to say it doesn't happen either but often (not always) it's generally down to one party.

I threw that statement out there knowing full well it might be objected to, and maybe there's an assumption I'm not a software developer or at least exposed to that type of environment. I understand the point, however. It takes only one party to make a change which induces a broken condition. My reference to an incompatibility taking two parties is in that, it is a decision of both parties not to test for backward compatibility, or to not care to address it. 
 
To state this in another way that may be more accurate: It takes two parties to make compatibility. It takes only one to break it. However, it takes two not to address it.
 
If either party seeks to address it, a fix can be found by either or both parties. If neither decide it's an issue worth fixing, then it remains an incompatibility.