For indie I agree, actually it could be a bit much for people earning almost nothing yet, but for pro I think there is scope for a higher fee or more tiers.
I don’t expect output to scale linearly with effort, but I would be interested to know why you feel we are at the sweet spot. I feel as though there have been some real pains this year that would have been eased with more staff on hand. For example we have almost 6 months of useful updates locked away in the dev branch due to some late breaking issues, surely more internal QA with human-led testing on broad test surfaces would have helped avoid that or allowed scope for a stable/testing/unstable branch structure, so that side of the team I would like to see growing and I have no problem with being asked to pay for it. We could go heavily into the specifics on that topic and more examples but I don’t want to divert onto specific topics as I think my view is broad general enough not to need to derail the thread.
I’d like to know if the team feels they could usefully do more with, to be blunt, more money and more people because I think the survey suggests may of us would be fine about that even if our instinctive reaction is that a higher price is resolutely bad.
Could maybe up the prices but then add an additional tier below Indie, Starter perhaps, for people who’re just starting out. Allow say one product with at most 1k users, something like that for half the price of the indie license?
When I first shipped my first JUCE plugin it was hard to justify the license fee at that point since I was just making them in my free time and had no idea if I’d even make enough to cover the license fee, so a lower tier to help me ease into it would have been really nice.
Same. The current entry price would have been far too much for me at the time, but releasing as open source would have really not been compatible with my ultimate objectives. I’d like to see a softer entry point for newcomers that don’t view this through a business expenses lens, for a young coder struggling to pay their rent this is a high price and probably discourages them from using it. Now I’m better established I’m happy to support those folk indirectly with higher upper tier rates. Conversely those mega firms pulling in tens of millions annually could (should?) pay more than I can justify.
Many thanks for your work and for sharing your future plans. You are an A team!
The most prominent of these is a new way of creating GUIs based on the built-in webviews provided by each platform we support. The intention here is that by providing infrastructure around the creation of the webview and bindings to the javascript running inside it, the development of UI elements can take place entirely within the webview. Not only does this enable interoperability with industry-standard design tools, it also removes the requirement for GUIs to be written in C++.
I’m a bit skeptical about web UI’s. Maybe I’m biased because of my miserable experience with the latest Windows 11 native apps (e.g. Photos app, task bar) or my 300eur Android phone, but I have a feeling that UI latency/responsiveness is often not taken as seriously as it should. In particular, I think this is important for audio applications where the user is expecting the sound to react “immediately” to what they change in the interface.
Is your new infrastructure built with a low UI latency in mind?
Thank you so much for this update @t0m and the amazing work you and the team are doing.
Personally I’m not very excited about the WebView stuff - to me a browser UI is quite a heavyweight object to have in a plugin even though it’s obviously useful for some things.
I’d rather see much more effort going into improving the native way of rendering UI.
I believe there’s a lot of room to improve in the rendering of JUCE Components both from a backend perspective, like Metal, Vulkan, etc, and the high level interaction (better juce::Graphics interface that can easily translate to efficient shaders on all backends).
Anyway, I’m excited about MIDI 2.0 and happy to see you’re still going strong in 2023!
Same.
Also, the wording in the posts above suggests that it is based on the current WebBrowserComponent or similar concept, which ultimately means that the embedded browser is provided by the underlying OS, meaning that there could be subtle rendering differences between platforms, etc.
Yeah I’d rather just see the native techniques being improved first as it feels like a more solid foundation. I gather the options for bringing these modern drawing frameworks into Juce have all been looked at, and they’re not appealing for various reasons though. There are lots of pros and cons using a browser. The main benefit being in my mind that all systems have a browser that will usually take care of all of the GPU / optimisation acceleration features we want without the Juce team having to do it.
Presumably this will use the system default browser, and that gives me some concerns. Does the user’s choice of browser affect the browser used? If it does, that’s a large test surface (now we have to test our UI in all of the less well used add-on browsers that people my favour like Opera, Firefox, etc). Even if not it could still be a fairly wide target, Windows / Edge, macOS / Safari, Linux could be an interesting one and how far back do we need to check this works in, a Win 7/10 user may be on a pretty old version of IE that’s not coming from the Chromium tree and many macOS users stick on old systems for a long time which we’ll need to start to investigate for HTML/JS/CSS compatibility as their built-in Safari will be old. Actually that seems like quite a painful set of test surfaces.
We’ve also got the potentially interesting case where something as simple as an OS browser update could break drawing/layout in plugins, and we all know how finicky browser standards compliance is at times. I can see myself doing it the old fashioned way out of fear of the unknown for a long time, the consequences of going this way could just give us a different problems (but at least for Juce that moves the problem away from the framework itself).
What is not easy about using juce for the UI ? You are saying that juce sucks for making UIs. I can’t stand those memory hungry patchworked together with millions of javascript libraries web desktop apps, sorry.
If i want that, i could compile juce to wasm as library and include it in React. Don’t force me to go the webview route. This way juce UI will die.
You have a unique product that stands out the market, don’t make the mistake to be just another average tool for the mediocre.
Ease in terms that non coders can do the UI.
If you do the UI yourself you probably don’t care, but in a bigger company you would be happy that the UI designer does the UI without involving developers.
100 % agreed.
Although to me the solution is not a web browser, but a more lightweight engine like my plugin-gui-magic. This still leaves the possibility to add high performance visualizers in.
But hope not to derail the conversation.
Speaking as someone who uses JUCE both as an indie plugin developer, and at my day job making desktop apps - I’m looking forward to seeing improvements to both approaches to UI.
In my day job I work closely with some fantastic designers who I regularly have to disappoint by telling them certain things aren’t feasible. They use Figma which has a big ecosystem of tools that make it seemless to work with a web front-end, combined with tools like react you can get a really sleek workflow. Our mobile teams are using react-native and are able to build their front-end 10x faster than us on the desktop teams.
As an indie plugin developer I really don’t want to use a web front-end as that adds so many extra technologies and dependencies. At the moment my tech stack for my plugins is C++ + JUCE, I don’t really want it to become C++ + JUCE + Typescript + SCSS + HTML + react + vite + ... as that’s way too much to maintain in my free time.
So I think the upcoming work in JUCE 8 is 100% the right first move by the JUCE team to enable a large chunk of teams to start building the next generation of fantastic audio apps, but I would also like to see improvements to the native UI approaches as mentioned about.
Side note, but one of my big motivators for JIVE was that by having a higher-level, more declarative approach to building UIs it makes it easier to make changes to the underlying renderer. I’d like to look at offering native hardware-accellerated renderers like OpenGL, Direct3D, Metal, etc. If anyone has any ideas, or previous experience doing this sort of thing please feel free to get in touch
You can already do web UIs with react native and have juce running inside. But then if we go that route, i would expect the team to deprecate and then definately remove the juce_graphics and juce_gui_basics related modules, why wasting 2 times the effort and money and bandwidth they don’t have.
Why not using existing tools that can target layout definition + code. Figma for example, we use that to generate the look and feel for juce components and how the app is composed.
I totally subscribe to this approach. Designers can produce SVG’s with their go-to software. Webs or any other intermediary format are already a higher abstraction that distracts them, so in my opinion, if the goal is to speed up the creation of beautiful UI’s, an ultimate solution would be to generate C++ code in (pre)compile-time from SVG files.
Are they going to maintain both UIs technologies ? What a waste of resources. Especially considering other frameworks which can integrate native code already exists out there and are already established (one example that comes to mind, react native + web ui https://tamagui.dev/).
