I’m trying to get my arms around the best way to create a GUI visually. It seems JUCE’s built-in GUI editor should be the way to go but I’m not finding a project that actually shows it used that way and some forum posts indicate it’s now deprecated.
While digging for a good video on this, I came across “foleys_gui_magic” module that appears to be a GUI WYSIWYG editor for JUCE plugins, inside of Xcode. Its demos do look impressive but it overrides some of JUCE’s top level classes, which is concerning as that could easily cause problems.
Just looking for a ‘best practice’ here for developing my AUv3 plugin GUI, I used a completely different WYSIWYG GUI tool for my older AUv2 plugin.
Coding->building->running->repeat in Xcode seems too klunky.
I prefer to develop the UI outside of JUCE using Figma, or some other UI graphics application. When the GUI is ready I simply bring the assets into my app. I have yet to find a faster way of developing a UI.
Nope - JUCE doesn’t have any asset loaders. That being said, you could create your own Figma wrapper/asset loader using its REST APIs, which emulate SVG and CSS fairly closely.
OpenGL is a rendering pipeline, not an asset loader.
Figma may be overkill for what I’m doing, a simple GUI for a plugin app. Still I’m willing to learn more because I’ve lost my simple wysiwyg tool for the GUI. The Figma website states:
" What can I do with the Figma API?
The Figma API supports read access and interactions with Figma files. This gives you the ability to view and extract any objects or layers, and their properties, so you can render them as images outside of Figma. You can then present your designs, connect them to other applications"
I don’t mind using an online tool but can someone explain how this is done with JUCE?
If writing a ‘wrapper’ is required, it’s probably just as much work as writing and testing the GUI code within JUCE/Xcode but introduces a new source of bugs.
Disclaimer: I’m an audio DSP guy, everything else is just overhead to me that I’m trying to keep as minimal as possible.
I try to keep everything as flexible as possible. When the first tutorial was plenty lines of code that you had to copy into specific places of your juce::AudioProcessor I decided recently to make it easier and provide the foleys::MagicProcessor, where those prerequisites are already built in.
It should still work by copying the snippets into a regular juce::AudioProcessor, but it is so much easier to simply inherit the foleys::MagicProcessor.
It is only a problem if you need to use a different framework, that also inherits juce::AudioProcessor.
But I am very interested in criticism and the problems that arise of that decision.
Well that sounds like movement in the right direction. I’d suggest you put out a simple example that shows how to transition from a standard JUCE GUI (generated straight out of the Projucer) to your GUI. The fact it’s wysiwyg inside Xcode is very appealing to me and I’ll bet many others.
However, statements like “it should still work by copying…” do not give me confidence. I ( & most independent developers I know) have enough work on our plates to get the thing we’re doing (audio DSP in my case) right. Short version: it needs to be rock solid, is it?
If not, don’t feel bad, JUCE has had the advantage of many users over many years moving it closer to that ideal.
I just want to say, this sounds a bit condescending. Daniel does not owe you anything here, and he doesn’t need to defend or explain himself. His code is available on GitHub for you to inspect yourself: https://github.com/ffAudio/foleys_gui_magic
/shrug It seems that this lands somewhere between the top of OP’s head and infinite space… Meaning they’re in for a lot of digging if they want to have shortcuts.
I’m just assuming, but it seems to me that OP’s intention is to de-risk and reduce their own mental overhead. If that’s the case, then going the manual route (like we all do) is the best method. Why? They have a lot to learn about the framework as it stands - it’s not a small hill.
In an ideal world, every asset and UI element could be dynamically loaded and mapped to a piece of data as part of JUCE - or use something like what Daniel provides that already does that (eg MagicProcessorState).
react-juce lets you write JUCE front-ends in React:
I couldn’t say for sure, but I bet there’s some GUI editors for react apps you could use to generate the react code and then import it using react-juce. I don’t know if they’d be 100% compatible but maybe worth investigating if you’re looking for something other than C++ to write front-ends
No worries, everybody can choose their tools. I completely understand the concerns. It is annoying to change the tools halfway through a project, if it is even possible at that stage.
So is it rock-solid? Certainly not. Which software would you call rock solid? Even bug-free?
It doesn’t exist if it is more than producing the fibonacci numbers in an endless loop.
Juce is not bug free (apologies if that hurts somebody), Logic is not bug free.
I do my best to improve things as good as I can as soon as I become aware of shortcomings.
That’s all I can do.
The sources are open, you can also fix yourself if necessary.
But I have to agree with @jrlanglois , if you want total control, that means roll your own. There is no shortcut.
First let me apologize if my comment came across to you as condescending, it wasn’t meant to be. As I understand it, you only offer paid support so naturally I wanted to know how likely that would become necessary. I think that’s a fair request to make before committing to using it - although I probably could have worded it better.
I think your tool is very appealing and fwiw it appears to fill a needed niche here but I am concerned about it’s maturity. I guess I should have amade it clear that I don’t want to spend any time studying your code or fixing any potential problems with it. My reason for that is simply that I have a big enough mountain to climb with my own code (in other areas). Lastly, your code is further along than my own so I’m not being condescending with regard to my question about your codes maturity either. Yes, all code starts out immature and buggy.
Again, I’m really an audio DSP guy just looking for the best tools to simplify the requirements of developing my plugin app that I view as overhead, like GUI development.
I feel you. In summary to what I said before; the manual route is the simplest (in my experience).
It gives you full control over the UI, and gives you the easiest way to access and manipulate your data. We’re all more than willing to help guide with this on the forums. This casts away the overhead of learning combined modules and strategies, all the while learning JUCE itself.
That being said, I’d like to circle back to this:
Coding->building->running->repeat in Xcode seems too klunky.
I think it’s hard to put a number on maturity. I have a few users who use it in their products, but I cannot say if that counts for you. I guess everybody needs to make their own experiences.
As for the support policy, I do my best when I get aware of problems, there is also a forum with support, currently mostly from my side, but I hope that the community will grow over time.
The paid service would come into play if I shall look into specific problems or investigate in client code.
Lately I had to break things to improve the overall deployment, that also happens. I can only say, I do my best to make everybody happy, but I am a mortal human.
But I don’t want to hog your thread any further, apologies that my story took over so much of the thread.
You design/draw your UI elements using an graphics application. Then you use the exporting images in JUCE. All of the approaches mentioned here are valid but this one means I can work more easily with UI designers.
I know we’re getting off-topic here, but I think you’re ascribing more malicious intent to the OP than is necessary. At least in how I read the thread, simply asking the author of a tool (that they themselves promote around here on occasion) about the maturity of the tool is reasonable. Not sure why it wouldn’t be.
This forum has always been a friendly place where people generally assume the best. I’d hate to see that go away.
You might also want to check out the live constants macro (JUCE_LIVE_CONSTANT). It can be very useful during the development of a GUI and greatly reduce the number of “Coding->building->running->repeat” cycles when tweaking parameters.
