Anacreon Synthesizer | Anacreon 2.5 Released

[Erich.Pfister]

I wrote some details about VST3 support in DPF here https://kx.studio/News/?action=view&url ... ember-2021
And follow the ongoing discussion around VST3 in https://github.com/DISTRHO/DPF/issues/207

My point is precisely to separate DSP and UI, I am already setting the "distributable" flag but might be missing something.
I am doing the VST3 implementation from scratch, not using the official SDK, so there are very likely some quirks here and there.
That said it is already in a state where it works on most hosts, state is saved and restored, almost everything works.

Now a few notes for things worth clarifying:
- You can use makefiles or cmake
- SDL is NOT suitable for plugins since it cannot be embed into other windows afaik (GLFW has some "hints" for this though)
- grepping DPF source code for things like "kDistributable" and "IMessage" will show no results, expected as I am not using the VST3 SDK
- it is possible to use DPF plugin API while still use "external"/third-party window management, ie, DPF with SDL, GLFW or others. An already working example of this is https://github.com/lucianoiam/hiphop (UI is a browser window)

And as a final point.. contrary to JUCE and Steinberg, DPF development is completely done in the open and the project accepts pull requests on a regular basis. It is a effort mostly lead by me, but still with input and features from the community.

Falk, thank you for making me look at this again. What do you know, I was wrong! Real shocker there - I've eaten my own word salad often enough that I should probably just apply dressing. A few points:
- You DID figure out IConnectionPoint and IMessage and even implemented a workaround if unsupported (is it just basic shared memory?)
- You have VST3 barebones support and I've been pretty much only using the interfaces.
- You use Pugl which I was thinking of using.

I'm downloading your repo now and I'll be doing my best to see if I can ditch Steinberg. I've had it up to my eyeballs with their shenanigans. If I've done anything that could potentially be helpful to your project, I'll contribute.

Thanks for your help AudioJunkie!

[Erich.Pfister]

perhaps worth a look at https://github.com/DISTRHO/DPF

Thank you for taking the time to inform me about this library!

Just took a look - I can't use this library due to the structure of my plugin. I'm writing it to be a true "kDistributable" plugin meaning that you could run the GUI on a separate machine from the Processing part with an appropriate host, at least with VST3. The IMessage class is the only legal way to communicate between controller and processor if you want to be in compliance with VST3 standards, and despite this library claiming to fully implement the different plugin architectures, a search for IMessage yields no results, meaning the IConnectionPoint interface must not have been implemented, or is relying on a default implementation from the VST3 SDK, or I'm just totally wrong, which happens a lot! https://github.com/DISTRHO/DPF/search?q=IMessage

I'm already underway reading more into SDL2 as we speak and I've nuked the old GUI (and there was much rejoicing) and have Anacreon running headless for the time being. Feels like a big step back but I'm really looking forward to not writing literal thousands of lines of C++ to manually render the GUI. That was a stopgap that went on for WAY too long. I believe someone on this forum said there's no such thing as temporary solution, but in this case, it has been deleted, so it was temporary!

If you are choosing to run headless, and have the GUI run separately, please don’t do what LinuxSampler did. It is really really difficult—in fact nearly impossible—to run multiple instances of Linuxsampler using the GUI for their headless server. Please make some way to easily run and control multiple instances from the GUI.

Headless in this case means "I deleted my GUI and hardcoded a patch cable from the oscillator to the main output so I can prove to myself it's still alive even though I won't be seeing it again for the next few months"

Thanks for putting me in touch with Falk!

[OBSOLETE160530]

[Erich.Pfister]

A few points:
- You DID figure out IConnectionPoint and IMessage and even implemented a workaround if unsupported (is it just basic shared memory?)

Yes, but it is not shared memory.
I just create the connection point myself if there is none at the time that the UI is about to be created.
See https://github.com/DISTRHO/DPF/blob/cd9 ... .cpp#L2792
I set a special `shortcircuit` flag that will make it so that messages from the UI are fed directly into the DSP instance, instead of the usual view -> controller -> component path.

- You have VST3 barebones support and I've been pretty much only using the interfaces.

Correct, though calling it "barebones" might be misleading.
See https://github.com/DISTRHO/DPF/blob/develop/FEATURES.md for the current table of supported features.
By the end of this month I imagine everything that fits into DPF will be implemented on its VST3 wrapper.
So it is "barebones" in the sense that no bloated SDK code/classes are used, but not in terms of features.

- You use Pugl which I was thinking of using.

Haha yes, pugl is great for these kind of things. I have been involved quite closely with David Robilla (the pugl and LV2 author) on a few things. There are some PR fixes for pugl from my side
Do note DPF has a few things on top of pugl, small corrections here and there and for extra features not present upstream (yet). They are all in the https://github.com/DISTRHO/DPF/blob/dev ... c/pugl.cpp file, so they are easy to see.

I'm downloading your repo now and I'll be doing my best to see if I can ditch Steinberg. I've had it up to my eyeballs with their shenanigans. If I've done anything that could potentially be helpful to your project, I'll contribute.

Thanks for your help AudioJunkie!

I hope that it is useful! Feedback and testing on the VST3 implementation would be much appreciated at this point.

Unfortunately, I have become an "expert" in VST3 SDK Implementation, so I'm sure I'll be able to present some feedback. Regarding calling it "barebones" - I just meant "interface only" and didn't want to say "interface" twice in one sentence for some reason. Was NOT meant to be disparaging in any way. Digging into it now, stay tuned!

[Erich.Pfister]

UI host-filebrowser - what does that mean? Are you talking about the Plugin being able to request a filebrowser from the Host?

[OBSOLETE160530]

[Erich.Pfister]

Yes exactly.
This is supported on LV2 already. Could be made to work in VST2, but tbh I am not sure if I ever saw a single host that implements this opcode.
Should be possible in VST3, not sure which through which interface yet. But should not be too hard to do.

I've been using https://github.com/native-toolkit/tinyfiledialogs for fear of delegating yet another thing to the host LMAO.. been spawning it in a separate thread so I don't block the main UI. Based on your experience, do you think this would cause any problems in the long run / should I be trying to use the host's file dialog?

[OBSOLETE160530]

[audiojunkie]

perhaps worth a look at https://github.com/DISTRHO/DPF

Thank you for taking the time to inform me about this library!

Just took a look - I can't use this library due to the structure of my plugin. I'm writing it to be a true "kDistributable" plugin meaning that you could run the GUI on a separate machine from the Processing part with an appropriate host, at least with VST3. The IMessage class is the only legal way to communicate between controller and processor if you want to be in compliance with VST3 standards, and despite this library claiming to fully implement the different plugin architectures, a search for IMessage yields no results, meaning the IConnectionPoint interface must not have been implemented, or is relying on a default implementation from the VST3 SDK, or I'm just totally wrong, which happens a lot! https://github.com/DISTRHO/DPF/search?q=IMessage

I'm already underway reading more into SDL2 as we speak and I've nuked the old GUI (and there was much rejoicing) and have Anacreon running headless for the time being. Feels like a big step back but I'm really looking forward to not writing literal thousands of lines of C++ to manually render the GUI. That was a stopgap that went on for WAY too long. I believe someone on this forum said there's no such thing as temporary solution, but in this case, it has been deleted, so it was temporary!

If you are choosing to run headless, and have the GUI run separately, please don’t do what LinuxSampler did. It is really really difficult—in fact nearly impossible—to run multiple instances of Linuxsampler using the GUI for their headless server. Please make some way to easily run and control multiple instances from the GUI.

Headless in this case means "I deleted my GUI and hardcoded a patch cable from the oscillator to the main output so I can prove to myself it's still alive even though I won't be seeing it again for the next few months"

Thanks for putting me in touch with Falk!

I'm definitely happy you were able to be in contact with FalkTX. However, I believe the credit goes to @Kott.

[EvilDragon]

- Ditch VSTGUI

Best move you could have made.

I think I'm going with SDL2 - thoughts? I want 3D in case I ever want graphics card accelerated audio processing.

No experience with that one over here! At Surge Synth Team, we're pretty big fans of JUCE...

[Erich.Pfister]

Whoops - thanks Kott! Sorry, I'm all over the place these days.

[Erich.Pfister]

Yes and yes.
For one...

falkTX, you have a great product. I'm currently pouring over plugin examples to try to understand the structure a bit better. I like that, for everything I've questioned, you have an "actually, we implemented that!"

I'll hope to have a test plugin built by the end of the week.

Edit: your filebrowser implementation looks better, by the way.

[Erich.Pfister]

I think JUCE is a great framework, just a bit heavy for my liking. I've learned from FalkTX and my own experience these last couple days that SDL2 can't render to a window it didn't create (despite having a function called SDL_createWindowFrom(void* parent)... ugh.) Thanks for weighing in!

[Erich.Pfister]

falkTX - asking this publicly in case it helps someone else trying to use DISTRHO. I can't figure out how I'm supposed to include pugl. It seems like the source is expecting it to be inherited from multiple locations? I also have a fundamentally crappy understanding of GIT, so I don't really understand what pugl-upstream is... my instinct was just to rename pugl-master and see what happens *confused mumbling*

[ahanysz]

By the way, I don't think I've seen someone live-blog a VST development like this before. It gives us a better insight into how hard the developers work to get all these amazing plugins to us!