Hi guys, I posted it earlier. It looks like someone has deleted those posts for some reason, but the issue hasn’t been resolved, and I’ve been waiting all day for this.

All my projects are using Synplant 1 vst on Windows 10 and on Reason 12 after installing Synplant 2 the vst is not working and is showing it as a missing plug-in.

https://imgbb.com/TBV2Ls0

Can you please provide a solution

Thank you

Are you talking about this thread? https://soniccharge.com/forum/topic/2463
Your post is still there.

I'm using Synplant 2 with Reason 12 on macOS 10.15.7 and opening old projects and patches with no issues. From your image, I see you had a project saved with the VST3? I used the VST2 in most all of my projects, so I'm not sure if maybe there's an issue with the VST3 and how that is being recognized? Do you have any projects with Synplant VST2? Do those behave differently?

Are you able to load and open the VST3 version of Synplant 2 at all? Can you see it and what it is called in the plugins folder?

If you're in a pinch and are needing to focus on a previous project, you can visit the downloads page and revert to the latest version of Synplant v1 for the time being with "Sonic Charge Plugins 2022.11.25.dmg"

It would be difficult for me to find a VST 2 version of the project as most of my projects I’m working on are using VST 3 as I swapped them from VST 2. The new version as a new instance works fine; it just doesn’t work with backward compatibility to Synplant 1.

Yes, I know I can roll back to version 1; however, a fix would be suitable to use the new features.

Thanks

Hi, yall ,tbh i can second in on this with more concise VST3 stuff to the table, all my projects that use Synplant 1 have been with the VST3 counterpart never VST2. and i DLed the Demo to see the new stuff!

I love the changes and sound! But it doesnt link the new version of the VST at all with old projects and thats a big deal for me since what im working on calls on these old patches , ALOT of them. A fix would be amazing!

- N C wrote:
It would be difficult for me to find a VST 2 version of the project as most of my projects I’m working on are using VST 3 as I swapped them from VST 2. The new version as a new instance works fine; it just doesn’t work with backward compatibility to Synplant 1.
Yes, I know I can roll back to version 1; however, a fix would be suitable to use the new features.
Thanks

Yeah I was only suggesting reverting in case it was urgent for a project. I might try that later just to see if I can reproduce the issue. [EDIT] I was able to reproduce it and I know they are looking into it.

A workaround you could do would be to just replace the VST3 with v1, then have that for compatibility when opening v1 projects and have VST2 of v2 to continue to play with. Just make a backup of the v1 VST3 and v2 VST2 and replace one or the other, depending on the installer you run last.

Then when you access the VST3 in your previous projects via v1, you could save the patch, and then reopen that patch with the VST2 of v2 if you wanted.

Not ideal, but it is possible. And I don't think the VST3 offers anything special. From my understanding, it is just wrapper/bridge to the VST2 and mostly came about because of Cubase not supporting VST2 any longer.

- Joey Luck wrote:

- N C wrote:
It would be difficult for me to find a VST 2 version of the project as most of my projects I’m working on are using VST 3 as I swapped them from VST 2. The new version as a new instance works fine; it just doesn’t work with backward compatibility to Synplant 1.
Yes, I know I can roll back to version 1; however, a fix would be suitable to use the new features.
Thanks

Yeah I was only suggesting reverting in case it was urgent for a project. I might try that later just to see if I can reproduce the issue. [EDIT] I was able to reproduce it and I know they are looking into it.
A workaround you could do would be to just replace the VST3 with v1, then have that for compatibility when opening v1 projects and have VST2 of v2 to continue to play with. Just make a backup of the v1 VST3 and v2 VST2 and replace one or the other, depending on the installer you run last.
Then when you access the VST3 in your previous projects via v1, you could save the patch, and then reopen that patch with the VST2 of v2 if you wanted.
Not ideal, but it is possible. And I don't think the VST3 offers anything special. From my understanding, it is just wrapper/bridge to the VST2 and mostly came about because of Cubase not supporting VST2 any longer.

Thanks for providing the workaround, I'll keep it in mind — however, I would rather wait for the proper solution.

hello,
same problem in reason with vst3 only,
the best solution that I imagine would be to re-install synplant 1, save all my patches from the synplant interface then replace the vst3 occurrences with vst2 and put the patch back into synplant. (then install sp2)

I wonder if anyone would have a better idea before I start the process

Hi. I have investigated this problem extensively, and unfortunately, we are caught in a tricky dilemma. The problem is that we had a bug in Synplant 1.2 already. It simply didn't construct the plugin ID correctly. There is a convention for how VST3 IDs of VST2s are created, and all of our other products follow this convention, except Synplant 1.2.

Because very few hosts actually allow upgrading a VST2 to VST3, except Cubase, this problem slipped through our fingers when we released our VST3s one year ago. You see, Cubase itself doesn't care about the ID. If the plugin's name is the same, it will use it. (Thanks Steinberg. I mean that both sincerely and ironically because, like, why fool other DAWs to use mechanisms you don't use yourself?)

The same applies to Ableton Live; sometimes it can load old documents, and sometimes it cannot. I have even experienced it loading a random plugin, from other manufacturers. It's another VST3-specific problem I am afraid. This is why the internal test we carried out didn't discover this problem. But now I have confirmed that on both Mac and PC, a lot of the times, it does *not *load correctly in Ableton.

Since we cannot change the ID of Synplant 2 back to the invalid one we used for Synplant 1, we are left with very few choices, but I have two different workarounds.

1) Since the ID is different, version 1 and version 2 can coexist (at least in Ableton). You can install Synplant v1, go into your VST3 folder (/Library/Audio/Plug-Ins/VST3/Sonic Charge/ or Program Files\Common Files\VST3\Sonic Charge\ ), rename the plugin from Synplant.vst3 to SynplantV1.vst3 and then install Synplant 2 after that.

2) For Ableton users, I created a Droplet app with AppleScript that converts your song files into using Synplant 2. (Yes, I hacked the Ableton song file format; it was very easy, haha.) It will not replace any files but create new ones, so it's 100% harmless to run. If you want to try it out, please let me know how it works for you. You drag-n-drop (or select from within the program) an entire folder to process, and it will find and create new updated versions of all song files it finds that used Synplant version 1.

Here is the download: Update to Synplant 2.zip(69.3kB, 298 downloads)

New version posted further down.

Let me know if you want me to look at converting the conversion script to Windows.

- Magnus Lidström wrote:
Hi. I have investigated this problem extensively, and unfortunately, we are caught in a tricky dilemma. The problem is that we had a bug in Synplant 1.2 already. It simply didn't construct the plugin ID correctly. There is a convention for how VST3 IDs of VST2s are created, and all of our other products follow this convention, except Synplant 1.2.

Thanks Magnus, I completely understand, the solution to have the older version by renaming would do the trick and then I will save the patch and then use the v2 version.

Cheers

- Magnus Lidström wrote:
Let me know if you want me to look at converting the conversion script to Windows.

that method of renaming synplant1's vst3 did the trick so far ! Thanks on that! and i would like a windows equivalent honestly just in case to be safe if possible

Any solutions for Bitwig? The plugins are recognized as being separate by changing the Synplant 1 name to SynplantV1 and then installing Synplant 2. However, when I go to open Synplant 2, it just opens Synplant 1

What seems to work is renaming Synplant.vst3 (V1) to SynplantV1.vst3, then installing V2 and renaming Synplant.vst3 (V2) to SynplantV2.vst3

An update on the renaming of V1: the plugin is loading, although the sound engine crashes. However, I managed to open the plug-in, save the preset and then load it into the new V2. It is not the best solution, but it is what it is. :)

What? The Synplant version 1 sound engine crashes? This is in Reason right?

- Danny Clayton wrote:
Any solutions for Bitwig? The plugins are recognized as being separate by changing the Synplant 1 name to SynplantV1 and then installing Synplant 2. However, when I go to open Synplant 2, it just opens Synplant 1

I reverse-engineered their song file format yesterday. It's a binary format with a zip-file at the end, and it is possible to update all the ID fields inside it. I will update the script to support Bitwig, and there is a Windows version on its way too.

- Magnus Lidström wrote:
What? Does the Synplant version 1 sound engine crash? This is in Reason right?

Yes in Reason, sadly. This is when I followed your instructions to install Synplant v1, rename the VST3 and then install Synplant 2.

However, it does the job of retrieving the patch. The sound engine crashes with the sound of a tape stop effect after the first midi note is played.

Okay, here is an updated version of the script that can also update Bitwig projects. Mac only for now; the Windows version will follow as soon as I figure out why all anti-virus software thinks I am making a Trojan.

Update to Synplant 2.zip(70.6kB, 293 downloads)

New version below.

Ok, if you want to try the Windows version, here it is:

Update to Synplant 2 Win.zip(10.8MB, 317 downloads)

New version below.

Like the Mac version it will update Ableton Live and Bitwig projects to use version 2 of the Synplant VST3 instead of version 1.

It’s working in Reason (renaming v1) I just needed to register again.

Thanks.

Windows version worked perfect for Bitwig.
Many thanks Magnus

The Mac script gives me an error. Sh: python3: command not found (127)
Mac oS 10.14.6

- Sam Saw wrote:
The Mac script gives me an error. Sh: python3: command not found (127)
Mac oS 10.14.6

Ah, I looked this up. Apparently, python 3.x is not standard on all MacOS installations. I will test it with python 2.x (which comes with all MacOS'es) and make a new build for you.

I have updated the Mac version of the script to be compatible with both Python 2 and 3. I hope it works.

Update to Synplant 2 Mac.zip(70.6kB, 271 downloads)

New version below.

Thanks Magnus it works

- Magnus Lidström wrote:
Ok, if you want to try the Windows version, here it is:
Update to Synplant 2 Win.zip(10.8MB, 317 downloads)
Like the Mac version it will update Ableton Live and Bitwig projects to use version 2 of the Synplant VST3 instead of version 1.

Hey Magnus!

I too am in a spot of bother, but with Studio One (6.5.0.96106, but saved projects are from 6.x versions) on Windows. Any chance of a version of your script that would take care of that?

I investigated superficially, and it would seem not too daunting to reverse engineer that format at first sight: The song format is a zip (PK) archive. Amidst the various folders it contains, there is one named 'Devices'. In there, there is an 'audiosynthfolder.xml' file inside which I found:

	<Attributes name="Inst02">
		<UID x:id="uniqueID" uid="{06AD6E03-E84B-410F-8BAA-32A36F582CC5}"/>
		<UID x:id="deviceClassID" uid="{5653544E-7553-5076-7374-325F66696C65}"/>
		<Attributes x:id="deviceData" name="Synplant">
			<UID x:id="uniqueID" uid="{2E615804-F703-4766-8A99-0D37419C591E}"/>
		</Attributes>
		<Attributes x:id="ghostData" presetType="vstpreset">
			<Attributes x:id="classInfo" classID="{5653544E-7553-5076-7374-325F66696C65}" name="Synplant" category="AudioSynth"
			            subCategory="VST3"/>
			<Attributes x:id="IO">
				<List x:id="audioOutputs">
					<PortDescription flags="3" subType="3" label="Stereo Out"/>
				</List>
				<List x:id="musicInputs">
					<PortDescription flags="3" label="MIDI In 1"/>
					<PortDescription flags="3" label="MIDI In 2"/>
					<PortDescription flags="3" label="MIDI In 3"/>
					<PortDescription flags="3" label="MIDI In 4"/>
					<PortDescription flags="3" label="MIDI In 5"/>
					<PortDescription flags="3" label="MIDI In 6"/>
					<PortDescription flags="3" label="MIDI In 7"/>
					<PortDescription flags="3" label="MIDI In 8"/>
					<PortDescription flags="3" label="MIDI In 9"/>
					<PortDescription flags="3" label="MIDI In 10"/>
					<PortDescription flags="3" label="MIDI In 11"/>
					<PortDescription flags="3" label="MIDI In 12"/>
					<PortDescription flags="3" label="MIDI In 13"/>
					<PortDescription flags="3" label="MIDI In 14"/>
					<PortDescription flags="3" label="MIDI In 15"/>
					<PortDescription flags="3" label="MIDI In 16"/>
				</List>
				<List x:id="musicOutputs">
					<PortDescription flags="3" label="MIDI Out 1"/>
					<PortDescription flags="3" label="MIDI Out 2"/>
					<PortDescription flags="3" label="MIDI Out 3"/>
					<PortDescription flags="3" label="MIDI Out 4"/>
					<PortDescription flags="3" label="MIDI Out 5"/>
					<PortDescription flags="3" label="MIDI Out 6"/>
					<PortDescription flags="3" label="MIDI Out 7"/>
					<PortDescription flags="3" label="MIDI Out 8"/>
					<PortDescription flags="3" label="MIDI Out 9"/>
					<PortDescription flags="3" label="MIDI Out 10"/>
					<PortDescription flags="3" label="MIDI Out 11"/>
					<PortDescription flags="3" label="MIDI Out 12"/>
					<PortDescription flags="3" label="MIDI Out 13"/>
					<PortDescription flags="3" label="MIDI Out 14"/>
					<PortDescription flags="3" label="MIDI Out 15"/>
					<PortDescription flags="3" label="MIDI Out 16"/>
				</List>
			</Attributes>
		</Attributes>
		<Attributes x:id="Presets" pname="default" dirty="1"/>
		<String x:id="presetPath" text="Presets/Synths/2 - Synplant.vstpreset"/>
		<List x:id="synthChannels">
			<UID uid="{424A9A37-60B9-4B90-93C1-CF051917F1D2}"/>
		</List>
	</Attributes>

It looks like it would be straightforward to alter the erroneous ID in there and repack the .song file, but I didn't do any test. If it helps, I could maybe do that and try to reopen the resulting song if you tell me what to edit, just a a feasibility test?

Thanks for the info Akod. I updated the scripts to deal with Studio One projects too. Please try it.

Update to Synplant 2 Mac.zip(70.9kB, 269 downloads)

Update to Synplant 2 Win.zip(11.6MB, 283 downloads)

- Magnus Lidström wrote:
I updated the scripts to deal with Studio One projects too. Please try it.
...
Update to Synplant 2 Win.zip(11.6MB, 283 downloads)

Thanks Magnus.

It looks like the .song file extension isn't supported?

In any case, by drag & drop of a .song file or a folder containing .song files, I just get "No updated project files were generated".

The "Select a file" button opens a file dialog that doesn't allow the selection of .song files. I tricked it by entering '*.*' in "File name" and was able to fix a .song file.

I had no problem opening the repaired file in Studio One. The Synplant 1 to 2 VST3 substitution worked fine. The unsaved preset in the original Synplant was restored in compatibility mode in Synplant 2 (I saw your tool patched the binary .vstpreset in the song).

Thanks for your help.

Ah, sorry, to be honest, I didn't try the Windows version, and now I remember it has the choice to select a single file only (the Mac version doesn't). I need to add *.song to that dialog.

However, selecting a folder or dragging a file or folder onto the app should work, doesn't it?

I will look at it later today.

- Magnus Lidström wrote:
I need to add *.song to that dialog.

I'd say yes. To be safe, I'd add 'Any file','*.*' too.

However, selecting a folder or dragging a file or folder onto the app should work, doesn't it?

Nope. Neither works. Message "No updated project files were generated" in both cases.

I will look at it later today.

Thank you.

Hmmmm, I wonder why drag and drop is not working on your PC. I just tried, and both dragging a folder onto the .exe and dragging it onto the window works fine here.

It won't update projects that it has already updated, though, and I just saw it generates unnecessary errors in the log file when it tries to do that. I will fix that too.

- Magnus Lidström wrote:
dragging a folder onto the .exe

Did not try that. Wait a minute... That worked! Would not have thought of that (I think it's more of a 'Mac thing'. .exe are usually hidden away from users on PCs)

and dragging it onto the window

Nope. Double checked. That doesn't work. I'm not being contrarian.

It won't update projects that it has already updated, though,

That's not what happened. But indeed, if there already exist a [file-name]_Synplant2.song, the same message is displayed.

About this naming convention, I'd rather the reverse, though I get why you did it that way.

I would run your tool on the whole 'C:\Users\%username%\Documents\Studio One\Songs\', all the songs needing repairs would be fixed and keep their names. The next time Studio One access them, it would be completely transparent. And alongside the repaired files would be kept backups of the original files, with an extension that would make Studio One ignore them (at least on PCs), such as '.song_backup'?

Maybe it's just me.

I just saw it generates unnecessary errors in the log file when it tries to do that.

Did not see that. Now that you say that, maybe show the log anyway in folder tree mode?

I could manage with what you already made, though. Thanks for the trouble.

- Akod wrote:

- Magnus Lidström wrote:
dragging a folder onto the .exe

Did not try that. Wait a minute... That worked! Would not have thought of that (I think it's more of a 'Mac thing'. .exe are usually hidden away from users on PCs)

and dragging it onto the window

Nope. Double checked. That doesn't work. I'm not being contrarian.

Weird, but this python -> exe doesn't feel extremely solid or modern. Perhaps there is a better way. But I tried on two different installations (Windows 10 and 11) and dragging a folder onto the window worked for me. Which Windows version are you using?

Does it work if you click "Select Folder"?

I have compiled a version that shows a console window with some debug info. I would be super happy if you could give it a try, and drag and drop a folder onto it, and have a look at the console window. I just want to take one more stab at making this work. It's not essential as long as the buttons work, but it's nice.

Update to Synplant 2 Win With Console.zip(11.5MB, 274 downloads)

About this naming convention, I'd rather the reverse, though I get why you did it that way.

Yeah, I thought of doing it this way first, but I chickened out and played it safer. This entire script is pretty much a dirty hack, and I want as little trouble as possible in case the script doesn't work 100% for all users.

- Magnus Lidström wrote:

and dragging it onto the window

Nope. Double checked. That doesn't work. I'm not being contrarian.

Weird, but this python -> exe doesn't feel extremely solid or modern. Perhaps there is a better way. But I tried on two different installations (Windows 10 and 11) and dragging a folder onto the window worked for me.

I just understood something new. I always tried:

• 1st) drag and drop of the .song -> Error message (yes I then closed the message)
• 2nd) Drag and drop of the song folder -> Error message

But if I close the tool after the first error, launch a new window, and then drag and drop the song folder, then all the song files in that folder tree, history subfolder included, are repaired.

So it looks like the error state is sticky or sum'thing.

Which Windows version are you using?

Windows 10 Pro 22H2 OS build 19045.3570 Windows Feature Experience Pack 1000.19052.1000.0

Does it work if you click "Select Folder"?

Yes! Color me WTFed? Yet I thought I had tried and had the same error. Reading again my previous answers, I'm not sure I ever tried it this exact way, using the 'Select Folder' button.

I have compiled a version that shows a console window with some debug info. I would be super happy if you could give it a try, and drag and drop a folder onto it, and have a look at the console window.

Will try it directly.

About this naming convention, I'd rather the reverse, though I get why you did it that way.

Yeah, I thought of doing it this way first, but I chickened out and played it safer.

Just as I thought you did.

I have compiled a version that shows a console window with some debug info.
Update to Synplant 2 Win With Console.zip(11.5MB, 274 downloads)

Here is the output for a sequence: first, drag and drop of the song file, second drag and drop of the song project folder, without closing the tool window between the two attempts.

{C:/Users/Akod/Documents/Studio One/Songs/Test Song/Test Song.song}
Converting single file to list
processing files: ['{C:\\Users\\Akod\\Documents\\Studio One\\Songs\\Test Song\\Test Song.song}']
processing returned: {}, {}, Files generated: 0
Errors occurred: 0

{C:/Users/Akod/Documents/Studio One/Songs/Test Song}
Converting single file to list
processing files: ['{C:\\Users\\Akod\\Documents\\Studio One\\Songs\\Test Song}']
processing returned: {}, {}, Files generated: 0
Errors occurred: 0

If I close the tool and then try dropping the song project folder first:

{C:/Users/Akod/Documents/Studio One/Songs/Test Song}
Converting single file to list
processing files: ['{C:\\Users\\Akod\\Documents\\Studio One\\Songs\\Test Song}']
processing returned: {}, {}, Files generated: 0
Errors occurred: 0

WTF? Now I can't make it work again with a drag and drop of the song folder (no _synplant2 files in there). It's not one of those moments, I'm not under any influence, no nothing...

I even tried dropping on either buttons or on the empty space of the window, no difference...

Well, next test through the "Select folder" button:

processing files: ['C:/Users/Akod/Documents/Studio One/Songs/Test Song']
processing returned: {'C:/Users/Akod/Documents/Studio One/Songs/Test Song\\Test Song.song': 2, 'C:/Users/Akod/Documents/Studio One/Songs/Test Song\\History\\2023-06-08 Akod 20230608-174728 (Autosaved).song': 2, 'C:/Users/Akod/Documents/Studio One/Songs/Test Song\\History\\2023-06-08 Akod 20230608-182730 (Autosaved).song': 2, 'C:/Users/Akod/Documents/Studio One/Songs/Test Song\\History\\2023-06-08 Akod 20230608-191255 (Autosaved).song': 2, 'C:/Users/Akod/Documents/Studio One/Songs/Test Song\\History\\2023-06-08 Akod 20230608-215307 (Autosaved).song': 2, 'C:/Users/Akod/Documents/Studio One/Songs/Test Song\\History\\2023-06-08 Akod 20230608-215922 (Autosaved).song': 2, 'C:/Users/Akod/Documents/Studio One/Songs/Test Song\\History\\2023-06-08 Akod 20230608-220506 (Autosaved).song': 2, 'C:/Users/Akod/Documents/Studio One/Songs/Test Song\\History\\2023-06-08 Akod 20230608-225039 (Autosaved).song': 2, 'C:/Users/Akod/Documents/Studio One/Songs/Test Song\\History\\Test Song 20230724-225241 (Autosaved).song': 2, 'C:/Users/Akod/Documents/Studio One/Songs/Test Song\\History\\Test Song 20231024-230902 (Autosaved).song': 2}, {}, Generated new project files with Synplant version 1 replaced by version 2, for the following projects:

C:/Users/Akod/Documents/Studio One/Songs/Test Song\Test Song.song: 2 replacements
C:/Users/Akod/Documents/Studio One/Songs/Test Song\History\2023-06-08 Akod 20230608-174728 (Autosaved).song: 2 replacements
C:/Users/Akod/Documents/Studio One/Songs/Test Song\History\2023-06-08 Akod 20230608-182730 (Autosaved).song: 2 replacements
C:/Users/Akod/Documents/Studio One/Songs/Test Song\History\2023-06-08 Akod 20230608-191255 (Autosaved).song: 2 replacements
C:/Users/Akod/Documents/Studio One/Songs/Test Song\History\2023-06-08 Akod 20230608-215307 (Autosaved).song: 2 replacements
C:/Users/Akod/Documents/Studio One/Songs/Test Song\History\2023-06-08 Akod 20230608-215922 (Autosaved).song: 2 replacements
C:/Users/Akod/Documents/Studio One/Songs/Test Song\History\2023-06-08 Akod 20230608-220506 (Autosaved).song: 2 replacements
C:/Users/Akod/Documents/Studio One/Songs/Test Song\History\2023-06-08 Akod 20230608-225039 (Autosaved).song: 2 replacements
C:/Users/Akod/Documents/Studio One/Songs/Test Song\History\Test Song 20230724-225241 (Autosaved).song: 2 replacements
C:/Users/Akod/Documents/Studio One/Songs/Test Song\History\Test Song 20231024-230902 (Autosaved).song: 2 replacements
-------------------
Files generated: 10
Errors occurred: 0

That still worked. Maybe not loosing my mind after all...

I'll check again Monday if by chance you had an epiphany.

Thanks again anyway.

- Akod wrote:

I have compiled a version that shows a console window with some debug info.
Update to Synplant 2 Win With Console.zip(11.5MB, 274 downloads)

Here is the output for a sequence: first, drag and drop of the song file, second drag and drop of the song project folder, without closing the tool window between the two attempts.
```
{C:/Users/Akod/Documents/Studio One/Songs/Test Song/Test Song.song}
Converting single file to list
processing files: ['{C:\\Users\\Akod\\Documents\\Studio One\\Songs\\Test Song\\Test Song.song}']
processing returned: {}, {}, Files generated: 0

Oh wow, what are those { } doing there!? That's just weird. I don't get them when dropping files on my PC, and they shouldn't be there. I will investigate. Thanks a lot for trying this for me.

Have a nice weekend!

I got it! When there are spaces in the path, it gets surrounded by { } by this drag-and-drop API. Here's another update that should handle this case:

Update to Synplant 2 Win.zip(11.6MB, 283 downloads)

- Magnus Lidström wrote:
I got it! When there are spaces in the path, it gets surrounded by { } by this drag-and-drop API. Here's another update that should handle this case:
Update to Synplant 2 Win.zip(11.6MB, 283 downloads)

Hi Magnus!

I couldn't get this last version of yours to misbehave. It worked any way I tried it. So I decided to throw it a curveball, out of sheer mischief:

Generated new project files with Synplant version 1 replaced by version 2, for the following projects:

C:\Users\Akod\Documents\Studio One\Songs\låt fåt électron à la crème\Låt fåt électron à la crème.song: 2 replacements
-------------------
Files generated: 1
Errors occurred: 0

Generated new project files with Synplant version 1 replaced by version 2, for the following projects:

C:\Users\Akod\Documents\Studio One\Songs\Låt fåt électron à la crème\History\2023-06-08 Akod 20230608-174728 (Autosaved).song: 2 replacements
C:\Users\Akod\Documents\Studio One\Songs\Låt fåt électron à la crème\History\2023-06-08 Akod 20230608-182730 (Autosaved).song: 2 replacements
C:\Users\Akod\Documents\Studio One\Songs\Låt fåt électron à la crème\History\2023-06-08 Akod 20230608-191255 (Autosaved).song: 2 replacements
C:\Users\Akod\Documents\Studio One\Songs\Låt fåt électron à la crème\History\2023-06-08 Akod 20230608-215307 (Autosaved).song: 2 replacements
C:\Users\Akod\Documents\Studio One\Songs\Låt fåt électron à la crème\History\2023-06-08 Akod 20230608-215922 (Autosaved).song: 2 replacements
C:\Users\Akod\Documents\Studio One\Songs\Låt fåt électron à la crème\History\2023-06-08 Akod 20230608-220506 (Autosaved).song: 2 replacements
C:\Users\Akod\Documents\Studio One\Songs\Låt fåt électron à la crème\History\2023-06-08 Akod 20230608-225039 (Autosaved).song: 2 replacements
C:\Users\Akod\Documents\Studio One\Songs\Låt fåt électron à la crème\History\Låt fåt électron à la crème 20230724-225241 (Autosaved).song: 2 replacements
C:\Users\Akod\Documents\Studio One\Songs\Låt fåt électron à la crème\History\Låt fåt électron à la crème 20231024-230902 (Autosaved).song: 2 replacements
-------------------
Files generated: 9
Errors occurred: 0

The damn thing still worked with various frivolous accented characters mixed in filenames and path... ;-)

So I guess we are all done here!

Thank you!

I get a "sh: python: command not found 127" on a Mac running Monterey 12.6.3. I've tried changing the filename to a short one without any spaces or anything. The file is saved with Bitwig 5

- Niklas Winde wrote:
I get a "sh: python: command not found 127" on a Mac running Monterey 12.6.3. I've tried changing the filename to a short one without any spaces or anything. The file is saved with Bitwig 5

This is unexpected. I thought Python came preinstalled with all MacOS. 😱 Could you please open a Terminal window, enter the following line, and let me know what it returns:

python --version

"Command not found" so it appears I don't have Python at all, which I didn't even think to check since I also assumed every MacOS had it.

Now I've installed latest Python but still have the same error. I will restart and see if that helps.

Turns out I had Python 3 which means

python3 --version works and returns Python 3.12.0

So I guess the script needs updating to try that command if it fails?

- Niklas Winde wrote:
Turns out I had Python 3 which means
python3 --version works and returns Python 3.12.0
So I guess the script needs updating to try that command if it fails?

Oh, thanks for the investigation. I actually did make the script work with Python version 2 and 3, because on one installation, Python version 3 was the default "python". So this should be an easy fix.

Happy to help! Hate it when versioning gets in the way :)

I have built new versions of the script because apparently I had broken Live support in the last update. Also tried to fix the situation on Mac when python is missing but there is a python2 or python3 installed.

Mac: Update to Synplant 2 Mac.zip(71kB, 243 downloads)

Windows: Update to Synplant 2 Windows.zip(11.6MB, 252 downloads)

I can confirm this works perfectly on my system! Thank you very much for your support Magnus, great work!

I'm not sure this is the right place or if I should start a new topic but here goes.

I've updated Bitwig to the latest version, 5.1.6 and now Synplant 2 crashes. But only in projects where it was originally used as Synplant 1. Just adding Synplant 2 to a project works fine. I used the Python update script from this thread to update the projects from using Synplant 1 to Synplant 2. The projects used to be able to open after the conversion but before Bitwig version 5.1.6. Last version I know it worked on was version 5.1.3

Obviously I realize this could just as well be a Bitwig issue and have sent a support request to them as well.

I asked Bitwig support but they had no idea and now a new version of Bitwig is out but it doesn't work. So an old project that used to have Synplant 1 but has been upgraded to Synplant 2 with the script. It opens fine but upon play no sound comes out of Synplant and when I try to open the interface of Synplant it crashes.

- Magnus Lidström wrote:
I have built new versions of the script because apparently I had broken Live support in the last update. Also tried to fix the situation on Mac when python is missing but there is a python2 or python3 installed.
Mac: Update to Synplant 2 Mac.zip(71kB, 243 downloads)
Windows: Update to Synplant 2 Windows.zip(11.6MB, 252 downloads)

I've just run into this same problem, when trying to load FL Studio projects which used multiple instances of the VST3 version of Synplant v1.

The equivalent VST3 version of Synplant v2 cannot load any of these instances.

The project was last saved on 8/4/2023, so was definitely Synplant v1, as that date was before the Synplant v2 was released later that year.

I guess, the above solution didn't also include support for FL Studio's ".flp" project files? 🥺

- Magnus Lidström wrote:
Hi. I have investigated this problem extensively, and unfortunately, we are caught in a tricky dilemma. The problem is that we had a bug in Synplant 1.2 already. It simply didn't construct the plugin ID correctly. There is a convention for how VST3 IDs of VST2s are created, and all of our other products follow this convention, except Synplant 1.2.
Because very few hosts actually allow upgrading a VST2 to VST3, except Cubase, this problem slipped through our fingers when we released our VST3s one year ago. You see, Cubase itself doesn't care about the ID. If the plugin's name is the same, it will use it. (Thanks Steinberg. I mean that both sincerely and ironically because, like, why fool other DAWs to use mechanisms you don't use yourself?)
The same applies to Ableton Live; sometimes it can load old documents, and sometimes it cannot. I have even experienced it loading a random plugin, from other manufacturers. It's another VST3-specific problem I am afraid. This is why the internal test we carried out didn't discover this problem. But now I have confirmed that on both Mac and PC, a lot of the times, it does *not *load correctly in Ableton.
Since we cannot change the ID of Synplant 2 back to the invalid one we used for Synplant 1, we are left with very few choices, but I have two different workarounds.
1) Since the ID is different, version 1 and version 2 can coexist (at least in Ableton). You can install Synplant v1, go into your VST3 folder (/Library/Audio/Plug-Ins/VST3/Sonic Charge/ or Program Files\Common Files\VST3\Sonic Charge\ ), rename the plugin from Synplant.vst3 to SynplantV1.vst3 and then install Synplant 2 after that.
2) For Ableton users, I created a Droplet app with AppleScript that converts your song files into using Synplant 2. (Yes, I hacked the Ableton song file format; it was very easy, haha.) It will not replace any files but create new ones, so it's 100% harmless to run. If you want to try it out, please let me know how it works for you. You drag-n-drop (or select from within the program) an entire folder to process, and it will find and create new updated versions of all song files it finds that used Synplant version 1.
Here is the download: Update to Synplant 2.zip(69.3kB, 298 downloads)
New version posted further down.

Update: This suggested workaround allowed me to install both versions of Synplant on my device at the same time.

Which then allowed me to open the Project and manually migrate each of the Synplant v1 patches over to Synplant v2 one-by-one and then load those patches back into the newer v2 version.

It would be nice if the above script also worked on FL Studio projects. Although, perhaps that would take too much work to do?

Man, VST3 sucks with issues like this. Hopefully, CLAP will benefit everyone in future and most of us can leave these troublesome VST formats to the past.