score

halp::rgba_texture::uninitialized_bytes bytes; void operator()() { if(bytes.empty()) bytes = halp::rgba_texture::allocate(800, 600); // or whatever resolution you wanna set // Fill in bytes with your custom pixel data here outputs.image.texture.update(bytes.data(), 800, 600); } }; inside such a template: https://github.com/ossia-templates/score-avnd-simple-templat... - multi-projector mapping: ossia actually does it directly! it's in git master, will be released in the next version. It also supports a fair amount of features that MapMap does not have such as: * soft-edge blending * blend modes * custom polygons * a proper HDR passthrough as well as tonemapping, etc. * Metal, Vulkan, D3D11/12 support (mapmap is opengl-only) * Spout, Syphon, NDI, soon pipewire video. Mapmap only supports camera input. * HAP and DXV, both decoded on GPU. * Smooth grid distortion. Here's mapmap grid distortion: https://streamable.com/1nhwxg vs ossia with sufficiently high subdivisions: https://streamable.com/hmb1jm * And of course as mentioned here hw decoding (for some years already), the new feature adds zero-copy when for instance using vulkan video and the vulkan GPU backend. * In addition pretty much every YUV pixel format in existence is GPU-decoded (https://github.com/ossia/score/tree/master/src/plugins/score...). In contrast Mapmap does gstreamer -> Qt ; everything including the Yuv -> RGBA conversion goes through the CPU. - How to feed BespokeSynth audio and possibly someday video? Pipewire and e.g. Helvum? yes, pipewire (or jack or blackhole on windows and macOS). Although ossia also supports, VST, VST3, LV2, CLAP, JSFX, and Faust and comes with many audio effects built-in already.

e than a c++ compiler for building my code) and that instantly solved so many problems it's not even funny - something that required maintenance multiple times a year (pretty much every time you want to use some new C++ feature and the code generator does not know yet how to parse a source file that contains this feature - I have issues open on the Qt bug tracker that are now well into their first decade) had its operational cost fall to 0. And moc is by far one of the most well-developed code generators I've had to use, so many others just fail on anything other than the "happiest path". The only vaguely tolerable experience I had was using CMake as a code generator as cmake works portably-enough on the platforms it supports (though there are oddities to take care of between MSYS2 CMake and MinGW CMake and MSVC CMake) but then there's a lot of people who will absolutely never ever want to touch this (https://github.com/ossia/score/blob/master/cmake/GenerateLic...) or this (https://github.com/ossia/score/blob/master/cmake/ScoreFuncti...) with a ten foot pole. If I could replace all this today with normal C++ code I absolutely would in a heartbeat, it would be an undebatable improvement even if it took three times as many LoC / tokens / cyclomatic complexity / whatever measure you want to use.

a GPU -> CPU transfer which isn't always free - Clips on the timeline are notoriously expensive to render. There needs to be some way to cache the contents of clips into a texture (Either directly or by making use of the GUI library's "damage tracking" which I'll get into later.) Audio clips are the biggest culprit, because rendering waveforms requires the CPU to first do a linear search through the source material for peak values, and then render the waveform pixel-by-pixel (or even better use custom shaders to send commands to the GPU). AFAIK a lot of DAWs perform a full scan when the file is loaded and save the result in a database or in a file next to it (e.g. Reaper's .reapeaks, Ableton's .asd...) so that you don't need to perform a complete rescan. In ossia.io I use three different algorithms / display methods depending on the zoom level used: at "far away" zoom it uses the minmax of the audio slices, at intermediary zoom it draws lines and when getting closer, it starts drawing individual samples. https://github.com/ossia/score/blob/master/src/plugins/score... - Automation clips can contain a bunch of bezier curves, which are slow to render. Convert those to line segments with an approximation setting that looks good enough and it'll be ten times faster (keep the bezier for your data model of course). https://github.com/ossia/score/blob/master/src/plugins/score... https://github.com/ossia/score/blob/master/src/plugins/score... - Piano roll clips can contain lots of little rectangles in order to display a "minimap" of the MIDI notes inside of it. oh damn yes, I spent so much time on this and it still needs so much optimizing... if someone wants to give a shot at it :D https://github.com/ossia/score/blob/master/src/plugins/score... https://github.com/ossia/score/blob/master/src/plugins/score... - On top of all this, clips can contain text labels which can also be expensive to render. Yep, made myself a few "cached text" Qt items over time as the builtin cache wasn't satisfactory https://github.com/ossia/score/blob/master/src/lib/score/gra... - The fact that a timeline is zoom-able also makes it harder to cache the rendering of clips. If the timeline changed its zoom level, all visible clips pretty much have to redraw all of their contents. yep - Piano rolls can also be expensive to render if there is a bunch of MIDI notes, especially if there are text labels on the notes. yep - If the user clicks on a folder in a sample browser containing hundreds or even thousands of files, allocating a label widget for each file in the browser list will be very expensive. Something like the list factory in GTK is needed here. yep, Qt's also able to cache this. Though for instance for Qt's QFileSystemModel I carry a small patch to disable any kind of sorting when there's more than a few hundred thousand files (which happens for large media libraries): https://github.com/jcelerier/qtbase/commit/9909c3c7902cf7a2b... and also worked a bit with upstream Qt to get it to improve (for instance it was regenerating regexes ALL THE TIME when filtering for specific file extensions) - We want to reserve as much CPU as possible for the actual audio processing. Ideally the GUI shouldn't take up more than one or two CPU threads. - On some platforms, we also need to make sure there's actually enough CPU left for 3rd-party plugins to render their GUIs. yep