cpplinks VS JUCE

For more compilers correctness* resources see https://github.com/MattPD/cpplinks/blob/master/compilers.correctness.md

As for linkers and loaders, see https://github.com/MattPD/cpplinks/blob/master/executables.linking_loading.md

More: https://github.com/MattPD/cpplinks/blob/master/atomics.lockfree.memory_model.md

Take the red pill and see how deep the rabbit hole goes... https://github.com/MattPD/cpplinks/ https://github.com/shafik/cpp_learning

Further readings: Book recommendations in https://github.com/MattPD/cpplinks/blob/master/compilers.md#books as well as program analysis resources (in particular lattice theory, type systems and programming languages theory, related notation): https://gist.github.com/MattPD/00573ee14bf85ccac6bed3c0678ddbef#program-analysis-resources

Microarchitectural performance analysis research is a pretty active and interesting area--see also: https://github.com/MattPD/cpplinks/blob/master/performance.tools.md#microarchitecture

For more on GDB see: https://github.com/MattPD/cpplinks/blob/master/debugging.md#gdb

FWIW, here are general C++20 Talks -- and more feature-specific talks: coroutines, modules.

Compiler courses: https://github.com/MattPD/cpplinks/blob/master/compilers.md#courses

You can definitely start putting C++ into your embedded projects, and get familiar with things in an environment in which you're already operating. A lot of great C++ code can be found with motivated use of, for example, the platformio tooling, such that you can see for yourself some existing C++ In Embedded scenarios.

In general, also, I have found that it is wise to learn C++ socially - i.e. participate in Open Source projects, as you learn/study/contribute/assist other C++ developers, on a semi-regular basis.

I've learned a lot about what I would call "decent C++ code" (i.e. shipping to tens of thousands, if not hundreds of thousands of customers) from such projects. I would suggest finding an open source C++ project, aligned with your interests, and study the codebase - as well as the repo history (i.e. gource) - to get a productive, relatively effortless (if the interests align) boost into the subject.

(My particular favourite project is the JUCE Audio library: https://juce.com/ .. one of many hundreds of great projects out there from which one can also glean modern C++ practices..)

Here's a link to their website: https://juce.com/

It seems like most audio plug-ins are built in C++ inside an audio coding program called JUCE, so maybe if I could open up the exisiting code inside that and then output it as an AU instead of a VST that could 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/