Initial VST plugin

[jpcima]

This is a VST3 plugin. There remain a few TODO items.

• send notes, CC, bend, aftertouch
• select and load SFZ from UI (very basic)
• save and load state file
• reload UI display from state
• (to test) generate the bundle for macOS and test (Info.plist, PkgInfo)
• send tempo change
• send other state than SFZ file (eg. preload size, oversampling, etc)
• UI improvement

[jpcima]

Note: to build VST on MinGW, it needs to fix the SDK in ./vst/external/VST_SDK/VST3_SDK/pluginterfaces/base/funknown.cpp

	return InterlockedExchangeAdd (&var, d) + d;

Change to:

	return InterlockedExchangeAdd ((LONG*)&var, d) + d;

[jpcima]

Linux and Windows confirmed working (Reaper)
The Windows installer is good.
Merge it when you want.

[paulfd]

So this semaphore class is RT-safe in both post and try_wait? If so I actually need one of these on the background loader !

[jpcima]

This semaphore is "async signal safe".

Some info is noted here on this matter https://github.com/drobilla/jalv/blob/15f779a8603bc3f020e7000189900c52964771cd/src/zix/sem.h#L55-L58

[jpcima]

Hi, I took the liberty to revert the VST mutex lock for now. 4efdcd0

On second thought, I am uncomfortable about removing it for this reason (moreover than it's harmless):

It also synchronizes R/W access into the state structure, which might have 3 actors.

1. Read for the processing thread
2. Write for the background worker
3. Read/Write for host's state saving and loading

From docs, I think save/load can happen while VST runs, and so I'll rather keep the state fully synchronized.
In the particular patch, there might be a conflict of 2. writing SFZ path and of 3. reading it.
So, better to keep it safe for time being...

[paulfd]

Ok no problem!

[tank-trax]

hello, I built the recent develop branch and the VST3 built successfully. It loads in Reaper and Bitwig recognizes it, however as with many other VST3 plugins Bitwig only displays a black screen.

this thread may be of interest

[jpcima]

We do the runloop hack that should support Linux supposedly, it's like what Steinberg does officially in their official VSTGUI XML editor.

I was aware already of some Bitwig trouble that surrounded Surge and expected we would be hit the same, and apparently it didn't miss. I haven't tried running Bitwig myself.

As I recall, current Surge still suffers of the same problem right? I know that it uses an even bigger layer of hack to make Linux run, but it's not perfect.

[jpcima]

I observe the following problem which is logged in Bitwig.

sfizz is misbehaving: Listed an automatable parameter as a MIDI parameter: ParamID = 6 index = 6

It's on the controller parameters which are MIDI-mapped to the CC.
I thought I want them to be both attached to MIDI CC, and also manipulable by slider (like Sforzando VST2), but Bitwig seems not happy about that.

I don't really know if that's wrong to do.. at least the VST3 validator didn't complain about this.

[paulfd]

Maybe the VST Host is supposed to handle this? Meaning if you give the host a list of MIDI CCs it has to handle possible automation.

[jpcima]

It has to do with setting the flag kCanAutomate.
As you might know, in VST3 we don't get MIDI raw events for the CC.
We have to create 128 parameters of the CC and establish a MIDI-map of them.

In the VST samples, kCanAutomate flag isn't set, which designates the parameter as hidden, if my understanding is correct. (by crossing vst doc info with some forum posts I read)

It's the problem here that a parameter is both MIDI-mapped and kCanAutomate.
If I remove this flag, my guess is Bitwid stops complaining, but you can't any longer edit them by slider.

[tank-trax]

With Surge the VST3 screen can display upon opening but the menus are dead, it's possible to navigate presets via the Patch and Category +/- buttons, but once a menu is called no go, when clicking on the hide/display GUI button in Bitwig the screen reappears all black again with no way to reverse it other than double clicking the instrument in the browser in which case it loads in its INIT state

The ryukau VST3 plugins had a similar issue and after the fix they now display the GUI intermittently

Reaper is stable for VST3. Bitwig still has challenges.

[jpcima]

If the Auburn sounds VST are the ones working best, then It'll be surely a good idea to have a look how Dplug implements it.

[paulfd]

Maybe the underlying assumption of VST is that if a parameter is a MIDI CC then it is automatable but the host is responsible for choosing how to present this automation? E.g. by the same sliders as automatable parameters or by any mean it wishes to use.

I can try it ok with bigwig later this week 😄

[tank-trax]

VST3 no longer displays GUI in either Reaper or Bitwig

am at commit 474f221 using Debian Buster

my mistake, had an old version installed in ~/.vst3

appears to work in Both Reaper and Bitwig (will test further)

[jpcima]

@tank-trax here I don't experience problems in Reaper. What happens on opening UI? (black screen, or other?)

@sub26nico, did you have a chance to try VST3 in Reaper with UI on LZK3?

[tank-trax]

@jpcima I hadn't cleared VST cache and was using an older build

GUI is working now but noticed some SFZ's don't give sound, also some anomalies with the GUI
will provide some details tomorrow