It took a while... but finally some work in progress

YUP! :piñata:

12 Likes
3 Likes

I’ve been very curious about Rive for a while. Last time I looked it wasn’t clear if it would be suitable for integration with JUCE or plugin development.

Do you have a link to a repository? What’s the YUP framework?

It’s still under heavy development but you can have a look GitHub - kunitoki/yup: YUP is an open-source library dedicated to empowering developers with advanced tools for cross-platform application development.

After the JUCE8 announcement and the removal of the ISC licensed modules, i took the chance to take these out of JUCE7, fork them by applying any improvement or fix that the JUCE team refused to take in and i injected my homebrew gui layer based on the Rive renderer. It’s very rough around the edges but it is already very capable and performant, it gives you the ability to render Components with a similar API of JUCE (but it’s a complete rewrite from scratch), plus it’s fully open source and it can target web (via emscripten) and you could use it to load Rive artboards with state machines controlled animations and events and attach them to your business logic.

While people will be busy doing wonky webviews react modules to display glitchy controls, we can already do animated GUIs controlled by state machines implemented by artists in Figma and Rive and import them into a 120FPS backed application framework :smiley:

I hope more people will be interested in having a completely free and open source framework for desktop, web and audio plugin development that is building on top of the JUCE foundations. Much like what CLAP is for audio plugin development.

13 Likes

Looking super interesting!

Is it possible to embed Rive Component into Juce Component hierarchy?

I know it’s against general intention of the library, but would be nice to support this use case as well.

It should be possible but only when juce uses gpu accelerated contexts. Requires a MetalView on Apple or a DirectX11 context on windows or OpenGL context anywhere else

Congrats.

Looking at the GitHub repo, it seems rive is mentioned everywhere but no link to Rive. I guess it’ll be nice adding some hint of what Rive is for newcomers to the repo.

Searching for Rive suggests this is a commercial product for designers to make frontends. Except of the renderer, it doesn’t seems to be open-sourced. Isn’t this basically moving some commercial lock-in from JUCE into Rive?

yes, definately. But only your artist need a Rive license, not anybody in your development team that accidentally touched “the framework”.

Looks super interesting!
I was trying to test it but on Mac with CLion none of the projects was building out of the box either with Ninja generator or the Unix Makefiles generator.

The example app, for example fails with:

/Users/eyalamir/Code/yup/thirdparty/rive/include/rive/rive_types.hpp:16:2: error: "can't determine if we're debug or release"
#error "can't determine if we're debug or release"

With the command line, things were building correctly, so I’m guessing there’s something happening on the platform detection part of the script.

Can you try adding -DCMAKE_BUILD_TYPE=Debug when configuring your cmake project in CLion ? It seems CLion still have some issue with multi config cmake configurations.

No change.

Also CLion already adds this by default - I’ve never had any project with this kind of issue and I’m building quite a lot of cross platform libs here, so I’m assuming there’s something non-standard happening in the specific Yup scripts.

(Ninja and Unix makefiles are not multi config generators).

yeah it could be, even tho i’m using generator expressions for setting defines for debug and release, will check why this happens

Should be fixed in latest master, check if it works for you

Looks great now! Thank you for the quick response.
I’ll be following this project closely as it looks very promising and well done.

(Also check out my pull request regarding .gitignore)

1 Like

Thanks, it means a lot to me :pray:

Very cool. Is it possible to embed custom visualisations such as spectrum analysers, filter responses, compressor meters…that kind of thing?

Something like…here’s a draw context and here’s a bunch of vector drawing primitives?

Yep it’s totally possible

    void paint (yup::Graphics& g) override
    {
        float xSize = getWidth() / float (renderData.size());

        yup::Path path;
        path.moveTo (0.0f, (renderData[0] + 1.0f) * 0.5f * getHeight());

        for (size_t i = 1; i < renderData.size(); ++i)
            path.lineTo (i * xSize, (renderData[i] + 1.0f) * 0.5f * getHeight());

        g.setStrokeColor (0xff4b4bff);
        g.setStrokeWidth (5.0f);
        g.strokePath (path);
    }
3 Likes

Nice work. Do I understand it correctly that the RIVE renderer is only optional and you can still write your UIs in C++ code?

Also do you have plans for adding other plugin formats than CLAP?

Yes, we use the rive renderer to render vector graphics. The loading and usage of rive artboards is completely optional. Both things can be mixed, you could have a c++ custom rendered component side by side with a rive made piano keyboard for example

Yes but at the moment i won’t focus on it because i want first make sure the UI/render layer is ready for prime time.

3 Likes