Anacreon Synthesizer | Anacreon 2.5 Released

[crickey13]

I understand not liking a GUI and I understand hyperbole - but why is it AIDS? It truly hasn't harmed more than a few retinas.

It's internet parlance and is just meant to be a joke. That being said, the contrast and the combination of colors makes me want to bang my head against the computer screen, so it is kind of AIDS.

[Erich.Pfister]

I see - I apologize for any headdesking or headmonitoring this may have caused you.

[Erich.Pfister]

IMessage is going to break me I swear to god what am I doing wrong Steingberg????? Deliver me from this.

[Kott]

what have you chose for the GUI lib?

[Erich.Pfister]

Nothing yet. I'm still reworking the parameter system for the patch cables. I'm going to be looking for the best supported cross platform library capable of doing basic 2D stuff like text, vectors, bitmaps and the ability to rotate at least vectors and text in 90° increments. I'd like to make a UI that is primarily vector based if possible since I want the window to be resizable. The license also has to be good for use in commercial products.

[Erich.Pfister]

I have successfully made IMessage work between my custom editcontroller and processor. Steinberg does a great job of forcing you to implement every interface from the ground up if you want to change one tiny thing about their helper classes, and those helper classes make a lot of weird assumptions about your use case. Quite frustrating.

At any rate, I'm going to be using this messaging paradigm to keep track of the patch cables independent of the parameter system... meaning I am no longer limited by the N^2 problem of having a parameter for every possible connection. Next step is to rewrite the patch cable system around the new messaging paradigm. After that, I'll use my newfound knowledge of the vstpreset file format to create a special area in the file specifically for patch cable info.

Edit: it's still randomly crashing for some reason, not sure why. I'm thinking it's a data race.

[Erich.Pfister]

UDPATE - I FINALLY got IMessage to work without crashing. It wasn't a data race - I didn't use the special magic IPtr type that Steinberg wanted me to use. I fixed it.

Next up - patch cable management via IMessage followed by saving patch cables to file.

[Erich.Pfister]

Turns out I need to completely overhaul the graphics library as my next step. Can't change the patch cables without complete overhaul. Onscreen controls are inexorably tied to ParamIDs, so if I don't want the cables to be VST Parameters, I need to be able to represent them onscreen without using VSTGUI4. Time to find a new graphics library!

[Erich.Pfister]

- 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.

[Kott]

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

[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!

[Kott]

I can suppose it's not implemnted at this moment. VST3 support is in development stage. I've asked FalkTX (the author) if he can reveal this.

[Erich.Pfister]

I can suppose it's not implemnted at this moment. VST3 support is in development stage. I've asked FalkTX (the author) if he can reveal this.

If you could ask him how the heck he figured out how to render onto an existing HWND... I would REALLY like to know that! Been trying for hours to get SDL_CreateWindowFromParent(parent) in the body of my implementation of IPlugView::attached(void* parent, FIDString type). All I can think is that I need some sort of child window.. I'm digging into the VST3 SDK further to see what the hell they are doing in there. It's a terrifying mess.

[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.