Opening (Converting) 32bit EDL to 64bit SawStudio

[Carl G.]

Have reason to open lots of old SAWStudio 32bit EDLs in SAWStudio 64bit.

What are the "Best Practices" for opening an EDL from SAWStudio(32) into SAWStudio 64?
Preparing EDL in SAWStudio32?
Export EDL/Files with and without FX?
Simply Open 32bit EDL directly in SAWStudio 64?
(I've done this one - can present problems when plugins are different between old/new computers).

Any/all ideas appreciated.

Thanks.

[cgrafx]

Have reason to open lots of old SAWStudio 32bit EDLs in SAWStudio 64bit.

What are the "Best Practices" for opening an EDL from SAWStudio(32) into SAWStudio 64?
Preparing EDL in SAWStudio32?
Export EDL/Files with and without FX?
Simply Open 32bit EDL directly in SAWStudio 64?
(I've done this one - can present problems when plugins are different between old/new computers).

Any/all ideas appreciated.

Thanks.

You can simple open the 32bit EDL in Saw64. I don't remember exactly what it says about missing plugins (but I believe it just gives a warning). Then you can go about swapping/replacing effects or you could try something like JBridge to load the 32-bit plugins.

[mr_es335]

Carl,

What Philip stated is precisely the situation?

If you happen to know the plug-in(s) deployed, then ensure 1) that that|those plug-in(s) are installed - as 64-bit, 2) that the presets are available as well [presets are generally NOT bit specific], and, 3) when you launch the .Session .edl, you will not be too overly surprised when you observe any potential error messages.

In my present situation, as I could no longer employ Valhalla plug-ins or Overloud's TH-U plug-ins due to their JUCE deployment, I had to research which plug-ins were going to replace those plug-ins. Though this situation is NOT exactly the same as transitioning from 32-bit to 64-bit, the end result is the same.

As an example, if I were employing a 32-bit reverb plug-in that had not previously upgraded to 64-bit , I would obtain a 64-bit replacement, configure the 64-bit plug-in replicate the output of the 32-bit plug-in [inasmuch as this IS possible], and then proceed accordingly.

I do hope that this makes sense?

[Carl G.]

Carl,

What Philip stated is precisely the situation?

If you happen to know the plug-in(s) deployed, then ensure 1) that that|those plug-in(s) are installed - as 64-bit, 2) that the presets are available as well [presets are generally NOT bit specific], and, 3) when you launch the .Session .edl, you will not be too overly surprised when you observe any potential error messages.

I do hope that this makes sense?

Yes - thanks! Great help.
1). I made a big check list - moving over only the cream of the crop 64bit versions (eliminating lots mediocre plugins). I sure wish that Sonoris 64 bit bundle would have materialized! I also use a lot of Waves Plugins. And I really enjoy SS 64 Native. 2). This is GREAT news to me. It should be a time saver - Thanks! 3). Found key is once you got the errors taken care of then quickly save the EDL!

Glad to hear 'best practices' are simple - easy - quick!

Would like to add a finding on #3). On some SS32bit .edl's, while opening in SS64, I've had consistent crashes the minute I start play in multi-track, or when trying to remove the offending (crashing) plugin. However, I found the CURE was to Delete the plugin from the VST folder BEFORE opening SawStudio, so the plugin doesn't show up in the SawStudio FX list. Then, I would open the session and Only then could I safely 'remove' the crash-causing plugin from the channel in which it is patched. Of course then, when all clean... save the EDL.

[UpTilDawn]

...
Would like to add a finding on #3). On some SS32bit .edl's, while opening in SS64, I've had consistent crashes the minute I start play in multi-track, or when trying to remove the offending (crashing) plugin. However, I found the CURE was to Delete the plugin from the VST folder BEFORE opening SawStudio, so the plugin doesn't show up in the SawStudio FX list. Then, I would open the session and Only then could I safely 'remove' the crash-causing plugin from the channel in which it is patched. Of course then, when all clean... save the EDL.

That's good to note.
I've had similar experiences, as I slowly move older 32 bit sessions to SAW64.

I'm also retaining a 32 bit copy of the sessions (at least for the near future) for those times when I need or want the original, intact mix, with the original plugin choices. Sometimes SAW64 doesn't seem to like bridged 32 bit plugins, so trying to retain the older plugins in migrated sessions hasn't always worked well.

There's also the issue of previously SAW-stored 32 bit plugin presets. They are not available to the 64 bit plugin versions and so it's necessary to recreate favorite presets from scratch. Edit - I may be wrong about this, so will probably test my assumption soon, by copying a preset or two from the 32 bit folder to the 64 bit folder to see what happens....

One way would be to open both a 32 bit session and 64 bit copy of the session and recreate those desired presets one at a time, comparing the sessions side-by-side... another reason why I'm making and migrating copies of the original sessions into SAW64, rather than simply converting original sessions.

[MMP]

Be sure not to overwrite the 32bit EDL files, as the 64bit converted versions are not backward compatible. I started a brand new folder area for all my 64bit sessions to keep them separate from the 32bit ones. For a while, I added 64bit to all the new 64bit file names just to keep from screwing anything up. Good luck!

[mr_es335]

Carl,

Following is a procedure that I have adopted many, many times in "other" migration scenarios. This procedure has never failed me and ensured data integrity across various platforms.

• Note: This procedure was written from a very "generic" perspective - as indeed, such a procedure must be!
  
• Hopefully, the procedure is simple enough to be deployed in "other" scenarios?
  
• This procedure leaves the original data intact!

Part A
1. I obtain a 32-bit plug-in and install that plug-in in the 32-bit app VST_PlugIns folder
2. I launch the 32-bit app, insert the 32-bit plug-in and save the session as "Session32"
3. I exit the 32-bit app

Part B
1. I copy-and-rename the 32-bit plug-in to "Transfer"
2. Launch the 32-bit app with the "Session32" session file
3. Insert the 32-bit Transfer plug-in "after" the 32-bit plug-in
4. Remove the original 32-bit plug-in
5. Save the 32-bit session file as "Transfer"
6. I exit the 32-bit app

Part C
1. Obtain any 64-bit free standalone plug-in and copy that plug-in in the 64-bit app VST_PlugIns folder
2. I rename the 64-bit plug-in to "Transfer"

Part D
1. Move the 32-bit "Transfer" session file to the 64-bit app Session folder
2. Launch the 64-bit app
3. Launch the moved-and-renamed 32-bit "Transfer" session file
4. Observation: The 32-bit session file launches as expected
5. Save-and-rename the 32-bit "Transfer" session file as "Session64"

Conclusion
As this point, when a replacement 64-bit plug-in has been obtained, simply copy that plug-in to the appropriate 64-bit VST_PlugIns folder, launch the Session64 session file and insert that plug-in - again "after" the "Transfer" plug-in, as usual. I can then remove the "Transfer" plug-in.

I hope that some will find this information to be of some practicable use?

[Carl G.]

Be sure not to overwrite the 32bit EDL files, as the 64bit converted versions are not backward compatible. I started a brand new folder area for all my 64bit sessions to keep them separate from the 32bit ones. For a while, I added 64bit to all the new 64bit file names just to keep from screwing anything up. Good luck!

Renaming files for 64bit version & copy/rename EDL - Great suggestion! Thanks Bob and MMP.

[mr_es335]

Carl,

You stated "Renaming files for 64bit version & copy/rename EDL - Great suggestion! Thanks Bob and MMP."

Though the suggestions provided are worthy of note, I personally believe that such "reaming schemes" to be a lot of unnecessary work and effort.

Bob's software can run concurrent 32-bit and 64-bit versions - as long as the hardware will handle such scenarios.

With current backups, I personally enure that I have recent backup[s] of ALL that important data. With proper naming conventions on the backup side, I can then restore - either way, whatever data is required.
* With backups as well, of both the 32-bit and 64-bit versions of SAC|SAW, I can then restore these versions if-and-when required as well.

As can be observed, the above is really-and-truly contingent on ensuring that I do indeed, have a backup scenario in place - something of which, very sadly, is NOT a scenario that is performed as routinely as such scenarios should.

Anyhow, my "9-bits" worth....inflation you know.