Hello all.
We’ve just published what will be the first of some periodic updates about our roadmap:
Please use this thread to provide any comments or feedback.
We are also continuing to experiment with various ways to provide cross-platform GPU-accelerated shaders, and we’ll add this to the roadmap once we have a bit more clarity about what will be involved.
That’s great! Thank you for being open about what you are working on.
And thanks for the topics, they seem very welcome and worthy tasks!
We will also use this opportunity to evaluate a third-party SVG parsing library to bring our SVG compliance up to date.
IME JUCE’s SVG functionality is better than most 3rd party libraries. E.g. ThorVG, ReSVG, etc. are purely CPU rendered to a bitmap image. This is way slower than JUCE’s current implementation that can make use of native, hardware-accelerated rendering (i.e. CoreGraphics, Direct2D). Many of them also support fewer features than JUCE does currently.
Appreciate that you used the word “parsing” not “rendering” so maybe a moot point - but I definitely wouldn’t want to see less SVG capability come from using 3rd party libs.
The one thing I’d love to see with SVG support is the ability to draw SVG from a juce::ValueTree, rather than a juce::XmlElement. This would allow SVGs to be updated by simply changing properties of the VT - currently if you wanted some sort of animated SVG you’d have to keep a copy of the juce::XmlElement and keep re-parsing the whole document to update a single property. If we could instead update a shared juce::ValueTree, only the property/node that changes would need to be re-parsed, and re-rendered.
So TL;DR, if you’re adding a new parser - please have it parse to/from a juce::ValueTree!
Do you have a timeline for Juce 9, since CLAP is noted, it’s probably something people would like some idea about. Is it likely to be 2025 or 2026?
At the moment I think towards the end of 2025 would be a reasonable, albeit very approximate, estimate. We are, however, dependent upon Microsoft for a MIDI 2.0 implementation, and any supporting any major change in one of the platforms JUCE works on would have priority over new features.
Go JUCE team!
I’ve heard this from others too. I’m personally happy except for this open BR I got snagged on: BR: SVGParser modifies svg colour making `replaceColour` inconsistent.
Are there any plans for any iOS/Android updates at any point?
In regards to better windowing, please add support for z-order between top level windows and tool. Dialog boxes and plugins opening under other windows, tricks with always on top windows etc are driving me insane. This isn’t a huge deal for plugin developers, but for multi window app developers it makes you app feel like amateur hour.
Isn’t it kind of a foot-bullet to be designing multi-window apps these days, though? Things are headed towards touch interfaces, and the window paradigm doesn’t seem to be future-proof in that context.
I’ve converted my own plugins to be single-window, multi-drawer and its resulted in a much better user experience overall. That doesn’t mean I’m not missing something about multi-window designs however, and I’d love to hear arguments for why the parent-/child- window mess should be considered a valid technique, going forward …
When writing a DAW, tool windows are the most natural thing, that is hard to avoid.
Hmm… I’d wager its worth the effort to avoid incorporating them into any new interface design effort, though. Any new DAW project should account for the future of touch-based interfaces …
But okay, its a hard problem to design modern UI’s, I’m just curious about how the decision-making process is executed, having rid myself of all child window relationships and replaced them with sliding sections in a single Window component. I feel like this was a massive improvement, but would be glad to have my hubris challenged with a counter example …
I agree 100% that in a plugin you are better off without secondary windows (and that is what I am doing all along).
But again, if you host third party plugins, there is no way to design that without floating windows:
Roland said himself
But JUCE is not limited to writing plugins
Why is MIDI 2 support for plugins blocked on Microsoft’s support for MIDI 2.0 devices? At least beta support for the developer previews would be welcome for apps that deal with MIDI i/o directly, while for plugins you’re not limited by Microsoft at all. AU supports automatic conversion, it’s not hard to do the automatic conversion for CLAP support, and VST3 doesn’t support MIDI in the first place while conversion between MIDI 2.0 and VST3 events is straightforward.
It would be fantastic for the ecosystem to move on from MIDI 1 in new software and let the JUCE layer handle conversion or defer to the OS where applicable.
It’s also confusing why this is related to sample accurate automation.
How MIDI 2.0 will be handled by DAWs and plug-in formats is still being figured out. There’s a working group within the MIDI association with all of the major plug-in format and DAW manufacturers in, and they’re working towards some shared standard or infrastructure, but there’s nothing set in stone yet. MIDI 2.0 support for plug-ins is not blocked by other work on MIDI 2.0 devices, but we’re much closer to having the latter in a state where we can finish it off.
Given how MIDI 2.0 is likely to impact the AudioProcessor class it is a good opportunity to simultaneously revisit sample accurate automation, as we will probably have to make some changes that could be used for both.
This. Considering that the Desktop plugin market is slowly dying in favor of the continuous and rushing increase of iOS and Android audio Apps, I’d say that things like CLAP and MIDI 2.0 should progress alongside an improvement of iOS and Android support, fixing things like a better file management, handling of on-demand resources, and many more missing features, not counting the support for Android Automotive.
Aside from that… reading “JUCE 9” soon after the painful release of JUCE 8 hurts big time.
May I suggest something? What about LTS versions? Looking at how many fixes that could be useful on JUCE 7 and how many are requesting a J7 branch, maybe having LTS versions could be something worth considering.
My 2 cents
Plus++
And for those who have (switched to) a “perpetual” Juce 7 license and who are not yet working with Juce 8, it would be a friendly gesture to have it available as a selectable branch in the online documentation.
Image handling needs some attention. It is not possible to load image data from files into images hold in main memory. The size limit of Direct2D backed bitmaps is a show stopper for us and prevents us from adopting Juce 8. We would be able to handle that at runtime, but if we can’t load PNGs into main memory and preprocess them, we can not deal with the situation really.
I’m happy CLAP support is finally on the roadmap, but at the same time quite disappointed it was moved to JUCE9 - which means an undefined and probably longer than expected wait. Given how many developers voted on the FR and that there is a 3rdparty implementation that could be used an a reference, this feels bad.
Desktop plug-ins are doing really well, growing, not dying. Anyway this is not a zero sum situation, both can be growing at the same time.
