Marcin Pączkowski

> wasm seems to be a 2025 replacement for a native app Is this really a viable option for low-latency audio and native performance? Especially on resource-constrained devices? Note that...

> > My vote would be to re-visit removing this once/if wasm becomes a real alternative to a native app. > > My take would be to make this more...

It will take a few weeks before I can take a look at this code. Should this PR stay open for that time?

Thanks for the PR. With the amount of work before the release we may need to focus on functional (as opposed to "cosmetic") PRs, so this one may not make...

TL;DR: `Window.screenBounds.height - Window.availableBounds.top - Window.availableBounds.height` seems to be the way to get the offset for the height parameter, taking taskbar (and top bar) into account. Please test to confirm...

> `Window.availableBounds.top` returns `0` on Windows. The results are as follows: But you should use `Window.screenBounds.height - Window.availableBounds.top - Window.availableBounds.height`. It returns `48` on my Windows VM.

> Yes, the following is the code used for `FreqScope` on the three platforms in [#6909 (comment)](https://github.com/supercollider/supercollider/pull/6909#issuecomment-2946168963): I _believe_ you forgot to add the height of the Window to the...

I believe it should be ```supercollider window = Window("Freq Analyzer", rect.resizeBy(pad[0] + pad[1] + 4, pad[2] + pad[3] + 4) .moveTo( 5, Window.screenBounds.height - Window.availableBounds.top - Window.availableBounds.height + rect.height ),...

You probably need to debug it, checking the rect parameters after each step. I can't test right now.

When it comes to server meter, this PR assumes 2 ins / 2 outs; of course that's likely the most common use case, but when more channels are used, not...