I am testing a LV2 plugin that I am developing and which uses Qt5. I know that there was released libsuil 1.0 that added Qt5 support. What GNU/Linux distros now have in the repository Ardour built against this version of libsuil, so there is a support for Qt5?
Ideally there would be none.
Plugins are supposed to be self-contained and not depend on external libraries. Some longer explanation is http://lists.ardour.org/pipermail/ardour-users-ardour.org/2018-November/028948.html and
If this is new plugin, please do not use GTK2/3/4 or QT4/5 or any toolkit that cannot produce self-contained binaries.
Thanks Robin for your quick response. I agree. Than I’ll release only the standalone version for now, and than I’ll see that to do with the plugin version and what toolkit to use for it.
If I may ask: What plugin are you working on? What does QT offer you for a pro-audio GUI?
Apart from perhaps a checkbox/switch I don’t see any suitable widgets. QDial and QSlider do jump immediately (no gradual change) and are not suitable for audio controls. …and layout is likewise more suitable for a spreadsheet application.
Here is the application (https://gitlab.com/iurie/geonkick/) . Is a percussion synthesizer. The synthesizer is actually an API written in C. The GUI part is done in Qt that takes the pointer of the API and acts as a view–controller upon API. I can change the GUI without changing anything into the synthesizer, since GUI is doing only the presentation/control of what is in API. The LV2 related code is small since the split is done already. LV2 (Qt5) works in Ardour, but now I see the problem of GUI toolkits regarding plugins. The application also can run as standalone.
Not too much. Anyway you have to redesign all widgets if you want to have a look you need. There maybe only some widgets like file browser that need to call native widgets, but even this is not essential.
Maybe have a look at dpf
If I am not wrong DPF is a framework to develop plugins. But there a is need for a GUI toolkit that comply with the requirements regarding plugins(shared libraries as GUI plugins). I saw Claf started to develop one, but I don’t know what is the status.
There’s a basic toolkit in dpf.
Classes for sliders, knobs, drawing shapes etc etc.
I think it will do just fine for this.
I can help you out if you like. I helped with the dragonfly reverb gui and done a basic sample slicer in dpf.
Currently working on a better version of that slicer with help of Patrick DeSaulniers, who did Wolf Shaper. That’s all done in nanovg btw.
Thank you. But for the version 1.0, I’ll release only the standalone variant. The plugin will be postponed for the next version that will add more functionality, new UI design, and I don’t know what “GUI toolkit” will be used in order not to create problems for the host.
That make sense, the code will need some updates for LV2 as well. Controlling it via instance-access behind the back of host isn’t really an option, but it should be relatively straight forward to decouple that. Also the inner loop would benefit from block-processing until the next midi-event (if any) every cycle, rather than branch out sample-by-sample deep into the codebase. It’s quite CPU and DSP load heavy currently.
It’s fun playing around with chirps! I’m looking forward to a 2.0 already 
Ah, thank you . I am not quite sure I understood you. Which loop? From LV2 or Jack client?
Regarding instance access. I saw some plugins are using this work-around. To do it properly I need to learn LV2 documentation about how messages are sent, and how fast are between GUI and DSP, but for my case I needed “to send” a buffer that represents the kick graph, actually the sampled kick to GUI every time the parameters of synthesizer is changed. If I have a kick of 4 seconds length, this is quite a lot of data. I developed an algorithm to move less data to GUI and avoid aliasing in the kick graph, but the graph is not very smooth, so now I just copy (memory) the entire kick buffer data GUI to be shown. I.e. when moving a point of the envelope the graph should change in a way that the user not to feel that there is a delay in kick graph changes.