Any cross platforn GUI/Graphics library for plugins in C code?

[xos]

Is there any cross platform library for making editors for audio plugins?

[xos]

Pugl (PlUgin Graphics Library) is this right?
https://github.com/lv2/pugl

Anyone that has any experience using it?

[BertKoor]

Any particular reason not to go for Juce (&c++) ??

[xos]

Any particular reason not to go for Juce (&c++) ??

Yes, good question

The main reasons for using JUCE is probably that it's looks like a fast lane to get cross-platform plugs in many different plugin formats. Giving a focus on learning this one thing. And that it's becoming like a first choice for many because of this.

But to me personally it's looks like a bloated, very feature rich implementation with a giant dependency tree. Documentation that lacks code examples and lacks comments coupled with the documentation for asking about different functions and stuff. That may be okay if you are a experienced C++ programmer, with a couple of thousands hours of practice in C++. Not anything close to give a pleasant learning curve.

It also looks like very abstracted coding style, that takes focus away from the actual algorithms. Giving a look like it's trying to hide practical knowledge about what you are actually doing.

And I understand that C++ is mostly the only reasonable choice to do any serious work when it comes to some types if programs, and audio plugs certainly lies in that category. But coming from a embedded systems background making synthesizers, precognition of memory-footprint and speed of the code you are going to write is key. You don't want to spend excessive amount of time with speed and size measurements, just because that you don't know things like that beforehand.

And JUCE will certainly make most of the work futile when it comes to converting your effort to a similar hardware product, if your product shall have any chance of surviving or selling many copies with a high enough margin. The elaborative code base dependency in JUCE makes it highly dependent on modern OS for normal computer use, not anything like you would like to convert for usage in a embedded audio product that needs to be lean and mean.

I have been coding on a plugin toolkit that uses 100% C code only for some time. That gives some kind of cross platform compatibility. I finally got it to work a few days ago thanks to helpful people here from this forum. And it compiles plugs to Windows and Linux with the 100% exact samecode for the plug, optimized for skeuomorphic animated graphics, with a minimal set of functions, that has more similarities with a game engine than a computer application when it comes to graphics. This approach has limits that is optimized for it's intended use. One benefit of this, is that it limit possible bugs drastically as there is almost no code. And the learning curve would be much smaller as C is a very small language and that there is almost no code.

And I'm 100% confident that I can port any plug that make for it to a built in system to make affordable audio hardware from it fast. It's just about possible buffer sizes and computing performance of that hardware it's ported to.

JUCE is probably excellent alternative for it's intended use and market. But it comes with limits that makes it unsuitable, for what I intend to use my current and future codebase for. Making hardware products is not the market that JUCE was intended to have compatibility with. But from what I have now, I cant even see that I personally would have that much need of using it, compared to the time needed to be spent making useful applications with it, it's now better to build upon what I have, and is certainly much faster to make plugs. I just change a few lines of code and I get a new plug from it instantly, sparing time and effort to focus on custom graphics design.

[xos]

Pugl (PlUgin Graphics Library) is this right?
https://github.com/lv2/pugl

Anyone that has any experience using it?

Looked and it said...
Stability: Pugl is currently being developed towards a long-term stable API. For the time being, however, the API may break occasionally.
...and if I understand it right, the exact same code can't be compiled to get plugs for different platforms, some code need to be hand written.

[BertKoor]

[mystran]

One possible option is to write your plugin code as C and then wrap around it with JUCE or some other C++ toolkit. This way the parts that are kept in C are still portable to embedded if written in a portable way... but with modern C++ moving further away from C there is certainly some learning curve.

[bitwise]

https://github.com/lvgl/lvgl

[wrl]

i wrote https://github.com/wrl/rutabaga

documentation is close to none and the API is weird (because i'm weird) but i'm shipping it in my plugins and it's stable. openGL based and quite performant.

[Urs]

Another option is CLAP with Dear IMGUI. We have developed a plug-in-friendly glue layer for IMGUI to Mac (Metal) and Windows (Direct X) which is free of any dependencies to GPU-rendering layers:

https://github.com/free-audio/clap-imgui-support

and an example project (sorry for typos... I only just saw that now) here:

https://github.com/free-audio/clap-saw-demo-imgui

This is nearly free of any dependencies, and there's absolutely no bloat.

Furthermore, there's a CLAP-to-VST3 wrapper, and I'm hearing chatter about working CLAP-as-AU as well.

[mystran]

i wrote https://github.com/wrl/rutabaga

documentation is close to none and the API is weird (because i'm weird) but i'm shipping it in my plugins and it's stable. openGL based and quite performant.

What's the issue with event loop in standalone on Windows? Looking at your code, your windows platform event loop calls your message dispatcher directly, but if you simply change this to go through DispatchMessage (which then calls window proc, which then calls your dispatcher), why would this not exactly the same as a host event loop in a plugin?

[soundmodel]

C does not usually require a GUI library, because what "object-oriented" C would be, is practically implemented by C++. And C++ compilers are more often available just where C compilers are.

[xos]

C does not usually require a GUI library, because what "object-oriented" C would be, is practically implemented by C++. And C++ compilers are more often available just where C compilers are.

It's not hard to write object oriented C code. And most C libraries use object oriented concepts. Usually the object is passed as the first parameter in function calls in C.

There is a reason why people write C wrappers around GUI libraries written in C++ code. It's to make it possible to use these libraries with other languages. So there is definitely a use for GUI libraries written in C code. And there is nothing that prevents making a C++ wrapper for it.

What you say is also true, but the reason to use C code, is to ensure that the code can be moved. C++ gives to many options to make code that can't be ported to low cost systems. So C++ is a great tool to prevent the software to be converted to hardware gear. If you are not interested in making hardware, then you probably don't need to care about C that much.

[wrl]

i wrote https://github.com/wrl/rutabaga

documentation is close to none and the API is weird (because i'm weird) but i'm shipping it in my plugins and it's stable. openGL based and quite performant.

What's the issue with event loop in standalone on Windows? Looking at your code, your windows platform event loop calls your message dispatcher directly, but if you simply change this to go through DispatchMessage (which then calls window proc, which then calls your dispatcher), why would this not exactly the same as a host event loop in a plugin?

it's a matter of which code is blocking in the "while GetMessage/TranslateMessage/DispatchMessage" top-level event loop. obviously, a plugin shouldn't do that!

it looks like that's an old comment in rutabaga, before i added "owns_application_event_loop". now, if that's nonzero, rutabaga runs its own dispatch. otherwise, it just returns to the host application.

[animed]

Another option is CLAP with Dear IMGUI. We have developed a plug-in-friendly glue layer for IMGUI to Mac (Metal) and Windows (Direct X) which is free of any dependencies to GPU-rendering layers:

This sounds relatively painless compared to the alternatives, and I don't care about anything other than CLAP.

There is a note in the saw demo about windows build is TODO. Before I jump all over it, how kosher is this thing, it doesn't look maintained. Has anyone even built it in almost a year?

cheers