Best practice for wysiwyg GUI dev?

General JUCE discussion
21

I have no idea how complex your plugin is going to be, but I can tell you from 20+ years experience that GUI code (not just drawing, but the actually handling of events, updating when presets get loaded, interaction with the user etc.) is around 10x as much code as the DSP stuff.

So constantly belittling the job and calling it “overhead” and treating it as an afterthought will bite you in the ass. Big time. Once you’ve finished the DSP part and tested in in various DAWs etc. around 10% of your work is done. Then the real work starts.

There is no solution that will simply work. We have a mix of hand-coded components, only the “layout” part we put in a JSON file. So then we go over the arrays inside the JSON, find the appropriate component in our hierarchy and apply the coordinates from the JSON (with some helpers, so we can use neighboring components X/Y, etc.).

Other might automatically layout depending on formulas, other hard-code their coordinates directly. Others use XML files or or or. There is no “one solution fits all”. This is not HTML/CSS.

11 Likes
22

In the past I’ve found that GUIs take a similar time to develop, about 90% of the overall development time. More recently however I’ve been trying to stick to a strict MVP architecture as well as using TDD. Now, the front end stuff only takes up about 50% of my time, 25% on writing tests and the remainder on everything else. Overall, I develop at lot faster now having utilised these practices (assuming I actually bother to finish a project).

Worth noting that I tend to design as I develop so that will contribute a lot to the GUI development time, but is possibly counteracted by the fact that none of my GUIs are particularly complex.

But in general, I very much agree. If you’re developing a serious product, the front-end isn’t just something you can leave to the last minute. Full slices are the way to go :pie:

2 Likes
23

Thanks for your reply and I don’t doubt your experience. However, with all due respect, aren’t we all here to develop audio plugins? If so, shouldn’t that be the real work?

My end users will see the GUI less than 1% of the time they spend actually using my plugin. Given that, is spending +90% of my development time on the GUI really a good investment? I accept that it might be necessary (with current tool sets) but it’s definitely prudent to look for a better way.

24

Again: it depends on the complexity of your plugin. If it’s relatively simple, so just an array of dials with a couple of switches, then you might get away with a lot less UI work.

The problem here is that you’re giving a very strange impression here. If the UI is not complex at all, then the time you’ve spent here arguing about it would have been enough to probably implement it.

If it’s more complex, at least your questions point that way, then you have to accept that a significant amount of time will be spend coding the UI, not DSP.

That’s a bold assumption. What gives you that idea? Let’s say your DSP algorithm is similar to somebody else’s, who put a lot of thought and time into their UI. Given that all else is equal, which plugin would the end customer choose? The pretty one with a cool UI, sporting real-time audio visualization, tooltips, and novel new controls, or the one with the 10 dials and two switches?

I think you clearly underestimate the appeal of a professional-looking UI.

So either you have something simple in mind, then why would you need a WYSIWYG editor? Or you have something more complex in mind, in which case you have to accept that it’s a LOT more work than you think.

In both cases: stop belittling people, concepts, and arguments. It doesn’t help you.

I’m out. This is not very productive.

3 Likes
25

1000000x this! Doesn’t matter if 99% of the time users won’t see your UI, the very first impression they are going to have of it is an image of the UI on a website somewhere. If it looks amateur or like a “programmer design” it will turn people off before they even get to listen to your amazing DSP.

I have nowhere near the same length of experience as reFX, but I wholeheartedly agree with the assessment that UI tends to be the longer slog. Of course you want the DSP aspect to be 100% perfect, and depending on how long the DSP took will affect the ratio of DSP/UI coding effort, but as you already know it’s just bloody time consuming to do simple things like layout components (and hence you’re looking for a shortcut) so it’s very easy for the ratio to favour the UI aspect. Even with a shortcut available I still believe it’s naïve to think that UI is ever going to be the quicker part of plugin development.

I’ve recently got finally fed up of this same tedious issue (component layout) and decided to create a system that allows for realtime editing of values in debug builds (similar to JUCE_LIVE_CONSTANT), that can then be saved to a file for inclusion into the final product. I plan to make it open source once it’s been battle tested since I’m sure it’s such a common pain in the arse that I’d like to make other developers lives easier.

4 Likes
26

That would be great! I’m sure many would find it very useful.

27

That’s exactly what PluginGuiMagic does and a bit more.
It is open source but for commercial use I ask for a moderate contribution (dual licensing like JUCE).
See Foleysfinest.com: PluginGuiMagic or

2 Likes
28

It looks really cool what you’ve done Daniel, but for my use case it’s overkill.

What I’ve been developing is very minimal in scope and implementation, just slightly more useful than JUCE_LIVE_CONSTANT (eg. no need for 4 separate entries for a x, y, w, h set of values used to position a component, all appear in the editor window on a single line). Comparing the two yours is definitely superior, in terms of how it’s implemented (my editing system is not particularly well organised for instance) and the scope of what can be achieved (I think yours would be really useful for people who want to quickly get a UI up and running, especially “noobs”). I will link to your project for people who want something more comprehensive, but would not like a return link since you’d be shooting yourself in the foot regards potential license sales, which I think you deserve considering the obvious amount of work you’ve put into it :slight_smile:

29

Agreed, if you want to do single size only then it’s easy enough to just hard code after you figured the right numbers out.
I think moving forward a system should support the modern layout mechanics like FlexBox.

1 Like
30

Hi reFX,

Thank you for this comment, I see now that I need to provide some more context, if just to clear the air here.

I’ve been looking at JUCE for a week now (yes, I know a whole week!) and in that short time I’ve come to love it. The only drawback I see is the lack of a GUI visual editor, which is why I created this thread. In fact, it may be more than a drawback, it may be a deal breaker for me but let me explain.

I’m an independent developer in the audio plugin area. I’ve spent 3 years so far working on this part time, the typical evenings/weekends grind. In that time I’ve already had to move platforms twice and for reasons I won’t go into I’m now faced with that again, which is why I’m looking at JUCE. But I’m going into this fork in the road with eyes wide open, doing the best I can to make sure my next platform will carry the plugin down the road for several years.

I love my current platform and (in hindsight) it has a great GUI dev tool that’s allowed me to spend less than 5% of my dev time on the GUI. Yes, it’s a very basic GUI, it wouldn’t impress any developer on this thread but it’s perfectly functional and very intuitive (according to my test users who say no instructions are necessary). The gist of how it works is as follows, you write a GUI specification in very simple ‘pseudo-code’ and then run that through a GUI renderer. The renderer presents a ‘dead’ GUI that is otherwise exactly what you’ll see when the pseudo-code is actually translated/compiled and run (wysiwyg). And of course the renderer runs very fast, a minute or 2 per “change”.

If I stick with this very basic but perfectly functional GUI, I could port it to JUCE and have a first release with actually ZERO additional GUI work. So what’s my problem?

Well, that’s only the starting point. I easily have another year, probably more like two, of additional DSP work. This is pure DSP work is in the form of feature improvements, new features and of course the inevitable bug fixes. These will all require changes/mods to the GUI and yes, I would even like to make it look better in general.

So my problem is this, if GUI dev on JUCE takes 50%-90% of my dev time, and I have a full year (or more) of DSP only dev work, that means my second release could take 2-9 years to complete. Obviously that’s not viable and so JUCE may not be for me.

I share all this to show I certainly didn’t come here with intentions of wasting anyones time or being condescending or belittling to people I don’t even know.

Hope that clears up my motives, this will be my last post on this thread. I still haven’t made up my mind on whether or not to use JUCE though.

31

Recompiling my entire plugin’s native C++ code after changing one or two things in the GUI typically takes under a minute. It sounds like this rendering helper may actually be slower than just recompiling your code! It is certainly adding lots of complexity…

32

I would suggest to use the juce::GenericAudioProcessorEditor for developing.
You can use it by simply putting this line into the createEditor() method:

juce::AudioProcessorEditor* MyPlugin::createEditor()
{
    return new juce::GenericAudioProcessorEditor (*this);
}

That way you can already control all parameters in your plugin.

Once that works you can decide if you want to spend the time for a nicer arrangement or even hire some developer for the GUI, which in your case seems very reasonable. That way you can focus on the audio task that you enjoy.

4 Likes
33

@benvining: Build and launch my App in Xcode’s debugger on my old MBA (after changing a color for instance) takes 15 seconds (i measured it right now)! :wink:

@tcupolo The ratio depends of the task. I spent 6 years to refactor the core of a software in order to switch the GUI to JUCE. I hope i’ll do the GUI within 1 or 2 years. Of course not a professional aspect at first. But since it is a free software…

1 Like
34

Yet another reason why your components should be as self-contained as possible and preferably have no dependencies outside library code.

If you’ve got a whole bunch of classes depending on each other, you end up with massive compilation times… The Mediator Pattern can help!

1 Like
35

For writing standalone components like envelopes or custom sliders, in the past I used the projucer build tool. Especially it was nice for quickly tweaking magic numbers. I believe that is deprecated now, so an alternative I use is JUCE_LIVE_CONSTANT, also a very helpful tool.

36

In all fairness, C++ is pretty awful for anything declarative. I think it’s disingenuous to say this is not HTML/CSS, when HTML/CSS is used to build quite more complex UIs than most audio plugins. Juce is not more “serious” or anything for its lack of UI tools -it’s just a lack.

Also, the mindset here is often very business-centered, but there are other reasons for getting into development. Sometimes you’re making a tool for your own workflow, or the people you work with, that may or may not have a commercial offshoot, and even then may still be a secondary business. And there’s something about the immediately commercial approach that favors UI-as-advertising in a way that reminds me of the so-called loudness wars. In my own work, I find myself coming back to rather neutral UIs, that don’t pick for me the MOST IMPORTANT function taking up half the space, that don’t populate the screen with elements that are neither functional nor blank, that don’t impose an extremely specific aesthetic that most often won’t match what I’m doing at all, or other stuff I’m using. Some well known pieces of software have been rather destroyed by designers treating professional users as kids, to put it bluntly. There’s a good case for humble UI design, and it would certainly benefit from some tools, particularly if an MVC/P approach with passive views is followed.

2 Likes
37

Could have just stopped there :wink:

1 Like
38

I like it though, Frankenstein and all :sweat_smile:

1 Like
39

Just my message in this thread to support the work of @daniel , which is very promising.
I am an user of PluginGuiMagic in my experimental plugins and I use its forum to propose and discuss about new possible features. @daniel dwelt a great deal on his work and needs to be recognized. :slight_smile:

Also, some opensource plugins using PluginGuiMagic are also available. They are very nice and intuitive both for DSP and GUI. See here: Chowdhury DSP - Products

5 Likes
40

I’d like to add something because I have the feeling that this thread might give potential newcomers to JUCE a wrong impression. Some could come to believe that a disproportionate amount of time is needed even for a relatively simple GUI.

As a newcomer myself (to both JUCE and C++), I have found it very easy to set up and customize GUI elements. JUCE provides pretty much everything one might need in terms of buttons, sliders, menu boxes, etc. and for the most part it’s as trivial as specifying where one wants an element to appear. Also, they can all be easily customized by simply looking through the source code, finding the methods one wants to change, and overriding them in one’s own code.

It’s really not hard or time-consuming and the tutorials are a quite excellent place to get started. I don’t see this as an area where JUCE is lacking, neither in features nor ease of use, quite the contrary!

7 Likes