Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VST3 Presets Streaming: Make the fix less weird #2110

Closed
tank-trax opened this issue Jun 12, 2020 · 14 comments
Closed

VST3 Presets Streaming: Make the fix less weird #2110

tank-trax opened this issue Jun 12, 2020 · 14 comments
Labels
Bug Report Item submitted using the Bug Report template JUCE Ex Machina Issue that will likely be fixed by porting Surge to JUCE UI/plugin back-end VST3 VST3 plugin related issues
Milestone

Comments

@tank-trax
Copy link
Collaborator

With Bitwig for Presets to show in Bitwig's built-in Preset browser, Surge's presets would need to be converted to the .vstpreset format

bitwig-presets-vst3-surge

I tried to create a few via Reaper and Bitwig and the resultant presets did not match the original FXP

Here are a a few examples

Surge-vst3.tar.gz

Bass 1 and 2 are OK but Bass 3 and 4 are not saved as they should be

It also appears that the VSTPRESET is saving the Zoom level which in my opinion should not be included in a preset

@baconpaul baconpaul added this to the 1.7.n milestone Jun 12, 2020
@mkruselj mkruselj added the VST3 VST3 plugin related issues label Jun 12, 2020
@baconpaul
Copy link
Collaborator

So if you create a preset by saving a DAW track rather than saving a preset it will contain the ‘dawExtraState’ and ‘dawEditorState’ which include zoom, tuning, mpe state, midi controllers, and a few other things. This exists in the daw state so you can save and restore sessions in reaper, logic etc... reliably and is not in the patches for exactly the reason you say.

If you want to convert all the fxp to a different format, I think we would need to know what that format is, figure out how to advertise it, and write code. I knocked the ‘vst3 exposes preset’ issue out of the 1.7 milestone because it was just too annoyingly hard (see #1256) and I presume the exact same thing would be part of this solution.

@mkruselj
Copy link
Collaborator

mkruselj commented Jun 14, 2020

image

Exporting to vstpreset then later reimporting it doesn't work - what you get is the init patch instead of what you were trying to export. I opened the saved .vstpreset file and it seems all the XML is there, so saving works fine - there's something happening when loading it.

@mkruselj mkruselj modified the milestones: 1.7.n, 1.7 beta 1 Jun 14, 2020
@baconpaul
Copy link
Collaborator

so when i just now did this on my mac with the vst3 at head and reaper, it all loaded fine.
Can you give me a step by step of exactly what breaks for you?
I don't see anything in the code that is windows only but I wonder if there's a byte order thing perhaps?

@baconpaul
Copy link
Collaborator

similar no problem loading and storing vstpreset reaper linux

so what's exactly the problem? Right now I can 't find something to fix! :)

@mkruselj
Copy link
Collaborator

  1. load whatever patch in Surge
  2. export .vstpreset from Reaper
  3. load a different patch in Surge
  4. import that exported .vstpreset -> sound goes to init sawtooth instead of whatever the preset was

Alternatively if after step 2 you remove Surge instance and reload it, the imported preset will show in Reaper's preset list - this won't work either.

image

@baconpaul
Copy link
Collaborator

Yup so seems this only happens on win10 - for me with reaper on mac and linux it doesn't. will look when I next have windows open.

@tank-trax
Copy link
Collaborator Author

I find that some save properly and others don't. Haven't determined what the nuance(s) is(are) that differs between those that stream properly and those that don't.

@baconpaul
Copy link
Collaborator

So

I haven't been able to make this break in mac reaper, mac bitwig, win reaper.

I even opened your .vstpresets on my mac, @tank-trax and they were fine.

What's exactly the bug please?

baconpaul added a commit to baconpaul/surge that referenced this issue Jul 1, 2020
In some situations which we don't understand, in some daws,
on some operating systems, we get a non-surge set of bytes
in front of VST3 ::setState on a second call we don't understand
when loading a preset.

So for now, leave our debugging code in, and ignore blocks which
don't begin with "sub3", since they corrupt surge

Addresses surge-synthesizer#2110 and lets us move it out of the 170 milestone
baconpaul added a commit that referenced this issue Jul 1, 2020
In some situations which we don't understand, in some daws,
on some operating systems, we get a non-surge set of bytes
in front of VST3 ::setState on a second call we don't understand
when loading a preset.

So for now, leave our debugging code in, and ignore blocks which
don't begin with "sub3", since they corrupt surge

Addresses #2110 and lets us move it out of the 170 milestone
@baconpaul baconpaul changed the title VST3 Presets not streaming properly VST3 Presets Streaming: Make the fix less wierd Jul 1, 2020
@baconpaul baconpaul modified the milestones: 1.7 0, 1.7.n Jul 1, 2020
@baconpaul
Copy link
Collaborator

OK the above PR makes it so the corrupted load problem is solved (at least for @mkruselj - @tank-trax if you can confirm on your end that woudl be good)

Along the way i discovered that the stream object is supposed to have attributes that let us detect project vs preset, which could also solve the zoom in preset problem (and the scale and mpe state in present problem) making the .vstpreset the same as the .fxp store.

but reaper doesn't seem to implement the IStreamAttributes interface on the stream it hands us. So I'm going to leave this issue open for further exploration in 1.7.n; keep my debugging code #ifdef 0 in SurgeVst3Processor::setStream, and return to this after we ship 1.7.0

@tank-trax
Copy link
Collaborator Author

Since the recent changes, I've been able to create vst3 presets in Bitwig and Reaper from the Factory Patches and they load well whether creating from Bitwig opening in Reaper or vice versa.

@baconpaul
Copy link
Collaborator

Yeah what we have works; but there's more we could do in future versions

@baconpaul baconpaul modified the milestones: 1.7.n, 1.7.1 Jul 17, 2020
@mkruselj mkruselj modified the milestones: 1.7.1, 1.7.2 Jul 30, 2020
@baconpaul baconpaul modified the milestones: 1.7.2, 1.7.n Sep 9, 2020
@mkruselj mkruselj modified the milestones: 1.8.n, 1.9.0 Oct 8, 2020
@mkruselj mkruselj added the Bug Report Item submitted using the Bug Report template label Nov 9, 2020
@mkruselj mkruselj changed the title VST3 Presets Streaming: Make the fix less wierd VST3 Presets Streaming: Make the fix less weird Jan 16, 2021
@mkruselj mkruselj modified the milestones: 1.9.0, Surge XT Jan 24, 2021
@mkruselj
Copy link
Collaborator

mkruselj commented Feb 4, 2021

@baconpaul I wonder if JUCE would also help us with this one, too?

@baconpaul
Copy link
Collaborator

Oh yeah it already has :)

@mkruselj mkruselj added the JUCE Ex Machina Issue that will likely be fixed by porting Surge to JUCE UI/plugin back-end label Feb 4, 2021
@baconpaul
Copy link
Collaborator

I'm closing this.
The weird fix will ship in 1.9 in our hand-coded VST3 and be obviated in XT with the Juce handling of preset-wrangling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Report Item submitted using the Bug Report template JUCE Ex Machina Issue that will likely be fixed by porting Surge to JUCE UI/plugin back-end VST3 VST3 plugin related issues
Projects
None yet
Development

No branches or pull requests

3 participants