overtone VS JUCE

Are you talking synthesizers? If yes, then Overtone is a great project for that, if you are OK with using clojure.

I've never actually used it myself. I've preferred systems that talk to SuperCollider, like overtone, because it's already rock solid and has lots of good DSP built in.

Thanks. I don't know to what extend its "better-because-of-clojure" but I also found overtone https://github.com/overtone/overtone which should be good fun (though the underlying synthesizer is supercollider/C++).

You might want to look at Overtone, which is a clojure environment built on top of overtone, and which integrates with processing and a few other similar things.

https://overtone.github.io/

> I'm fluent in Python but find the use of colons is the real sticking point.

The you'd probably have hated its predecessor which was all about the parentheses: https://overtone.github.io/

It's too bad that superficial stuff like which characters you need to type is holding you back. Getting used to Ruby when you're familiar with Python is no big deal. I would just stick with it

There's a project you may find interesting: https://overtone.github.io/. Besides sound/synthesis stuff, it has https://github.com/overtone/midi-clj library, which allows you to write MIDI as lisp (Clojure, to be precise) code. Emacs has great support for Clojure programming (via Cider), and REPL-based development is perfect for writing music.

overtone, in clojure and using the SuperCollider engine

It's overtone.live that has a problem with windows, as documented here . It's used in the overtone playground project and that's probably the reason why I couldn't get it to work.

JUCE:

http://juce.com/

Tracktion:

http://tracktion.com/

Both very powerful audio frameworks - JUCE does plugins and audio drivers and low-level DSP, oh my - and Tracktion does all the stuff a DAW needs, on top of JUCE.

There are tons of ways to contribute, from building open source samples, to testing, or even adding functionality. Both dev teams are open to good quality PR's being submitted and both frameworks have excellent communities that will get you started: http://forum.juce.com/

These are cross-platform tools which offer Audio developers an extremely powerful toolset. By contributing to either (or both) frameworks you will be massively contributing to the audio world - so many plugins use JUCE these days!

> Juce has a CoreGraphicsMetalLayerRenderer which I believe uses Metal to render CoreGrapghics primitives.

This class is part of a JUCE demo app, and you can read the source code to it if you want. [0] It uses CoreGraphics to render the graphics on the CPU, and then uploads it as a texture to the GPU so it can be used as a CAMetal layer. So, no, the graphics are still rendered on the CPU, with compositing being handled on the GPU.

> For example, I heard that UE4->UE5 removed the GPU tesselation support

I know it's confusing, but GPU tessellation is a completely different thing. The word "tessellation" in graphics means "turn into triangles". In a 2D graphics context, we're turning splines and curves and 2D shapes into triangles. In a 3D graphics context, GPU tessellation refers to a control cage mesh which is adaptively subdivided. These two have nothing in common except that triangles come out the other side. I am not aware of anyone who has tried to use GPU tessellation to render 2D graphics.

GPU tessellation failed for a large number of reasons, but slow performance was one of them. So, you know, doing this sort of work efficiently on the GPU is still an open research problem. Just because it's not efficient to do it on the GPU does not mean the performance overhead is negligible. For rendering big complex vector graphics, tess overhead can easily outweigh rasterization overhead.

[0] https://github.com/juce-framework/JUCE/blob/4e68af7fde8a0a64...

When we talk about 2D graphics as a research problem, we're talking about native rendering of splines and strokes. JUCE does not have GPU-accelerated splines, it flattens the path to lines and rasterizes the coverage area into a texture.

https://github.com/juce-framework/JUCE/blob/2b16c1b94c90d0db...

https://github.com/juce-framework/JUCE/blob/2b16c1b94c90d0db...

It also does stroke handling on the CPU:

https://github.com/juce-framework/JUCE/blob/2b16c1b94c90d0db...

Basically, this isn't really "GPU accelerated splines". It's a CPU coverage rasterizer with composting handled by the GPU.

You linked to the compatibility-renderer. But JUCE also has platform-specific rendering modules.

CoreGraphicsContext::createPath will convert the CPU spline segments to CG spline segments which are then rasterized by CoreGraphics using Metal on the GPU.

https://github.com/juce-framework/JUCE/blob/2b16c1b94c90d0db...

Sure.

The device definitions come as GDTF files, see the spec and other projects that utilize GDTF here [1]

Juce framework [2]

OrganicUI [3]

[1] https://gdtf.eu/docs/list-of-projects/

[2] https://juce.com/

[3] https://github.com/benkuper/juce_organicui/

Juce

You could checkout JUCE.

C++ is. as others have said, king in this domain. Lots of VST/AUs are built using the JUCE framework.