As far as I understand, the current desktop Strudel app is just a Chromium instance of the strudel.cc website
as described on this page, there are a bunch of ways to run strudel:
- a website (works offline excluding samples)
- a PWA (same as website, but without the browser ui)
- a tauri app (actual binary that wraps the webapp in a native webview)
- a nativefier app (electron wrapper)
the tauri app will be discontinued + i don’t see a lot of benefit in the nativefier wrapper. i generally recommend running the strudel website directly or locally. but yes, in all cases you get the overhead of running a browser.
Also, I wondered if it’s possible optimize the “audio backend”. Is the code that creates audio, midi and osc independent from the parser
strudel is packaged in a modular fashion, see packages. the audio engine is called superdough, integrated to strudel in @strudel/webaudio. then there are separate packages for osc and midi.
… (which I imagine has to be implemented in JavaScript)? If so, could we port that layer to C++ for more performance?
that is partly true, the packages listed above are all written in JS, but the audio engine is part of the browser and written in C++ (both ff / chromium). the JS mostly schedules the built-in webaudio nodes. there are some custom nodes written in JS that run inside an AudioWorklet, the performance is still surprisingly good, as the JS will be JIT compiled by the browser on the fly.
As an experiment, i’ve implemented a version of superdough within a single AudioWorklet, it’s called supradough (yes it’s spelled differently), so the whole audio engine is really written in JS. it still runs ok-ish but the performance is still worse, as the JIT compiled JS code is a bit slower than the C++ bindings of the webaudio nodes.
If so, could we port that layer to C++ for more performance
if the above solution doesn’t sound optimal to you, we’re in the same boat. in general, i’d prefer to have a fully custom audio engine that runs natively + it can be compiled to WASM and run in the browser. i have done a lot of research in various directions, ( fyi checkout my posts about audio-dsp ), as of now (yesterday) i’ve started to implement superdough features in classic dirt (written in C), which is the audio engine for tidal before superdirt. feel free to contribute here, as there is a long list of things that can be ported.
writing a native desktop app in QT / C++
personally, I’m not super excited by the idea to write a custom gui in c++/qt, and I’d also view that as a serparate issue. although i’m not an emacs user like @jwaldmann , i’d agree that the most pragmatic solution would be to skip the ui and edit in your favorite code editor. as of now, there’s no easy to pickup solution for strudel to do that, so tidal is the way to go.
I can see scenarios where an install-free tool can be useful (workshops, beginners etc)
to get a quick setup for workshops, you might still test if you can get enough performance by unchecking “Disable CSS Animations” and “Highlight events in code” in the strudel settings + using zen mode to hide the ui.
JavaScript syntax, which makes it much easier to extend
i don’t think there’s an objective view on this.. i think JS is easier to pickup for the average person (more resources, less PhD level jargon), so it’s easier to extend in that regard + a lot more people already know JS. i still think haskell is a more elegant language, although i think it’s not very friendly for developers (lacks integration / tooling).
or is Strudel internally (or even visibly) using typescript? Then, OK.
no it’s using plain old javascript, so i guess it’s not OK then 
Tidal is much more efficient than Strudel
i think that’s pretty clear, although it should make sense to clarify the bottleneck(s). i think the bottleneck is mostly the audio engine, so if you run strudel with superdirt (or dirt), you can improve efficiency a bunch
, I’d be happy to look into it, and team up with anyone else interested!