The JUCE 9 Preview branch is available now

[t0m]

This post is taken from the JUCE email newsletter.

To get these delivered to your email inbox, sign up here: Newsletter - JUCE

We are excited to announce that a JUCE 9 preview is available now on the juce9 branch of our public repository.

JUCE 9 focuses in on UI features and performance, embedded support and, as always, cross-platform compatibility.

Please take this opportunity to try JUCE 9 out and provide any feedback in this forum thread.

Improved SVG Parsing and Rendering

JUCE 9 now pulls in lunasvg as a dependency, bringing new features and improved SVG spec conformance.

More complex SVGs are now possible, including those that take advantage of radial gradients, blend modes, dashed strokes, stroked text, texture fills, miter limiting, clip paths and referenced elements.

SVGs are parsed into a tree of Drawable objects, which have been stripped of the Component base and moved into juce_graphics . This relocation allows juceaide (and therefore CMake) to run in headless environments such as embedded devices.

As a part of development, we built a custom app to test 70 specific features and regressions — including bugs you reported on the forum!

Variable Font Support

Modern fonts, especially those designed for the web, are frequently distributed as variable fonts.

Unlike traditional fonts, variable fonts bundle multiple styles (such as bold, italic, and condensed) into a single streamlined file.

Variable fonts allow font “axes” like weight, width, and slant to be set to custom values, giving designers full dynamic control over the appearance of the face.

For an example of JUCE 9’s new typographic capabilities, check out the FontVariablesDemo.

Improved macOS CoreAudio Support

The Core Audio implementation on macOS has been redesigned to use Apple’s aggregate device API, improving performance and reliability with aggregate devices.

JUCE 9 creates a private aggregate device that combines the selected physical devices into a single logical device presented to the framework. End users on aggregate devices get lower latency and more reliable drift-compensation than previous JUCE versions. We saw latency decreases of up to 11-25ms in our development, you can check out your hardware via JUCE’s AudioLatencyDemo (and let us know!)

Buffer size and latency reporting is also more accurate, helping to reduce unexpected behaviour and configuration mismatches for end users. In addition, channel naming has been improved when using aggregate devices: names now include the originating physical sub-device for greater clarity.

Software Renderer Improvements

JUCE 9 brings improvements to the software renderer, refactoring the internal structure of the PixelARGB class to better use vectorised instructions when filling colours.

We saw some operations such as image fills and image drawing achieve multiplicative speedups (2-4x) on our systems. On resource constrained environments, such as Linux embedded devices, you may see a substantial drop in the overall CPU usage of your app.

Improved Multitouch and Gesture Support

JUCE 9 now supports XInput multitouch on Linux, so any devices running embedded Linux can make use of multi-touch enabled displays.

JUCE 9 Windows applications and plugins now receive and process gestures from touch screens and touch pads by default. The old mode (where multiple touch points are reported) can be explicitly requested via the TopLevelWindow and AudioProcessorEditor classes.

JUCE 9 Work In Progress

All of the work described above is available today, in the JUCE 9 preview.

Other JUCE 9 work is underway, most notably AudioProcessor v2, the foundation for sample-accurate automation, unique CLAP features, and MIDI messages in UMP format.

APv2 will change how parameters are owned (and therefore how application code is written). In APv2, parameters live on the derived type (by value) instead of on the AudioProcessor. The current plan: existing AudioProcessor code will continue to work through a compatibility layer and adopting the new features requires porting your processor to APv2.

This is a large body of work that will land across followup releases. The piece most likely to ship first is multiple AudioProcessors in a single binary, useful for a synth and effects rack that share DSP, or for a “loader” binary that presents itself as several distinct products to the host.

[benvining]

Exciting work!

Are you looking for input about the design of APv2?

[t0m]

Not at the moment, but we’d absolutely welcome feedback as the first bits of the new implementation arrive.

[benvining]

Looking forward to it! Sample accurate automation might be my most anticipated feature.

[RolandMR]

Does the new SVG code take the viewbox into account when converting to a Path? Should we expect SVG drawing to look different in juce8 vs juce9 assuming we didn’t use any of the unsupported features like radial gradients, blend modes, dashed strokes?

Also, you didn’t bump the version number to 9, so we can’t #if JUCE_MAJOR_VERSION >= 9 to conditionally try out the new features.

[Toddler-Boy]

What about SVG blend modes? Are they all supported now? Are the new features hardware supported or are the SVG rendered into a bitmap via the software renderer first? Does the software renderer support those new blend modes then?

[bgporter]

Exciting! Looking forward to spending some time checking things out…

[leehu]

Great stuff. looking forward to this.

[daniel]

Great work!

Are there any plans to a cross platform way to do 3-D graphics?
OpenGL is deprecated for 8 years now and there is no access to the GPU whatsoever.
What would be your advice for rendering a 3-D scene (with immersive audio applications in mind)?

Cheers

[attila]

The supported blend modes are source over (the default), source, destination in and destination out.

The SVGs are parsed into Drawable objects and are rendered the same way as before, so it will use hardware rendering in almost all situations. The concrete exceptions to this occur under OpenGL: filling a two-point radial gradient (will use a software fill), and the blending operation of two layers. These could get hardware implementations as well later.

[daniel]

Nice! I assumed it would render in a texture/image, thank you for pointing this out!

[ImJimmi]

@t0m

SVGs are parsed into a tree of Drawable objects, which have been stripped of the Component base

Are there any changes to how we can specify the colour of SVGs? Specifically the ability to explicitly set the fill/stroke colour on specific elements, rather than having to use replaceColour()?

[attila]

You can mutate the objects directly. See the following rough example. However, with minimal changes this would work with JUCE 8 as well, so this probably isn’t really a change.

Note, that Drawable names aren’t unique because of the possibility of referencing and drawing a single SVG element in multiple places and in different ways, hence the following approach.

std::vector<Drawable*> findDrawablesByName (Drawable* d, StringRef name)
{
    if (d == nullptr)
        return {};

    std::vector<Drawable*> results;

    if (d->getName() == name)
        results.push_back (d);

    if (auto* composite = dynamic_cast<DrawableComposite*> (d))
    {
        for (int i = 0; i < composite->getNumChildren(); ++i)
        {
            auto children = findDrawablesByName (&composite->getChild (i), name);
            results.insert (results.end(), children.begin(), children.end());
        }
    }

    return results;
}

void udpate()
{
    drawable = Drawable::createFromSVGFile ("test.svg");

    auto hearts = findDrawablesByName (drawable.get(), "heart");

    if (hearts.size() < 2)
        return;

    if (auto* h = dynamic_cast<DrawableShape*> (hearts[1]))
        h->setFill (Colours::red);
}

[AdamVenn]

Are either of the following off my wishlist on the roadmap?

• Improved AAX automation accuracy
• Parameters based off doubles instead of floats

[fuo]

setBounds with floats would be nice also!

[davestarkey]

When you say “and MIDI messages in UMP format.”

What do you mean?

As you might know I have been struggling to get my UMP through juce.

[reuk]

@davestarkey

When you say “and MIDI messages in UMP format.”

This relates to the AudioProcessor, JUCE’s abstraction for audio plugins. Currently, AudioProcessor only supports MIDI 1.0, which means that plugins built on JUCE can only support MIDI 1.0 communication with host applications. We’re working on an upgraded version that will allow for MIDI 2.0 communication with hosts.

This is separate from the feature allowing MIDI 2.0 communication with hardware and other applications via ump::Input and ump::Output. That work is already available on the 8.0.13 and develop branches.

[ttg]

Are there any plans to a cross platform way to do 3-D graphics?

Semi related imho:

WebGPU

Not to be confused with WebGL, it’s not the same thing. I think it’s the future of general rendering, used natively and in browsers. It can render to ANY platform, and facilitates compute shaders out of the box. I won’t say too much here as there’s lots and lots of youtube examples of it. What google says about it: " WebGPU officially works on 5 major operating system families natively and across 4 major browser engines, enabling cross-platform development through underlying graphics APIs …

[jrlanglois]

@attila

The supported blend modes are source over (the default), source, destination in and destination out.

The SVGs are parsed into Drawable objects and are rendered the same way as before, so it will use hardware rendering in almost all situations. The concrete exceptions to this occur under OpenGL: filling a two-point radial gradient (will use a software fill), and the blending operation of two layers. These could get hardware implementations as well later.

Do the tester apps and/or demo have mechanisms to test and display the blend modes so we can see for ourselves?