score VS nix-bundle

https://ossia.io uses widgets and qgraphicsscene for the main UI rendering and Qt rhi for the GPU pipeline, and it's performing well enough for our use-cases - I was working on it on a 1080p screen on a Pi4 recently and it certainly felt much much faster and responsive than chrome on the same hardware.

I use it for live c++ recompilation in https://ossia.io - all the code is in there. https://github.com/ossia/score/tree/master/src/plugins/score-plugin-jit/JitCpp

> I feel like visual programming gets a bad rap because of things like this. As an electronic engineer that used to love LabView and life long user of NI Reaktor and Max/MSP, those tools are fantastic if you don’t approach them with an imperative programming mindset.

aha, in the long run I ended up making https://ossia.io which is as VPL as it can get. Yet it still embeds a LOT of textual languages.

For me both VSCode and CLion lag heavily.. whenver I tried CLion it was completely unuseable on my project https://ossia.io which is only 500kloc (and I try to try it pretty much once a year since it was in beta)

https://ossia.io does some of it, I've been working on a new release that also supports the whole QtQuick stack in the node graph items but you can already combine videos & shader effects

In https://ossia.io with PCH, using clang, ninja, mold, and some artificial split in shared libraries for development builds, I get a compile-edit-run cycle of a couple seconds in general... I wouldn't say it's too much of a problem if you use the tools already available

If you're interested in multimedia https://ossia.io is always looking for new contributors!

I develop https://ossia.io with Qt and it works as I want it to

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

- 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)

- 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.

I admit that there is an element of, "but I chose an obscure and challenging linux variant, waaah why isn't it supported" here, but (a) there's currently no flatpak and (b) when, for goodness sakes, will major linux projects begin packaging for Nix/NixOS as a matter of course?

It's not hard, and the benefits go far outside merely supporting Nix, as e.g. a flake.nix file would allow this project to generate docker images, and appImage images, as basically afterthoughts. (See e.g. https://github.com/matthewbauer/nix-bundle.)

Nix flake support would also provide a perfectly reproducible build environment, which can help clarify dependencies, and thus help the project build achieve idempotence, but I'll save the full shill for some github issue.

In fact, I'm inclined to roll up my shirtsleeves and help make this real.

https://github.com/matthewbauer/nix-bundle perhaps?

Another way to approach this would be to advocate Nix as the build system for Flatpak or AppImage. Don't know what the status is of nix-bundle, but if it is possible to turn a Nix package into an AppImage with little extra work that would be ideal.

Somewhat related, I wanted to mention nix-bundler it allows to wrap an application with nix into a single file.

Nix itself is more focused on "distribute from this host with nix, to this other host with nix".

Though, here is e.g. https://github.com/matthewbauer/nix-bundle, which is supported as an experimental command in nix 2.4.

I believe this tool does: https://github.com/matthewbauer/nix-bundle

Yes, it's extremely powerful once you truly understand Nix.

There are efforts to improve documentation, but it still is lacking (I think the biggest problem is that Nix is so big, not just the OS but it can be utilized as a build system).

Just with NixOS is not exactly clear how can you for example build your custom image.

I think https://nix.dev/ is approaching the documentation from the right direction.

There are also many pieces that people built that you need to find.

For example some things that I found accidentally:

* https://github.com/matthewbauer/nix-bundle

* https://github.com/cleverca22/not-os

Unfortunately those side projects often have even worse documentation.