Desktop versions of norns

[Dewb]

There have been a few conversations lately about what to do about resurrecting/maintaining/rebooting the previous experiments around a desktop build of norns.

I don't claim any authority to make decisions nor am I volunteering to do all of this work. But here's a shower-thoughts level writeup of how I would approach things if I was going to sit down and tackle this problem today. Tossing it here as a straw man for discussion!

General principles:

1. Maintain script compatibility and core behavior (with the exception of scripts/mods that run shell commands, load DLLs, do other non-Lua things, or make assumptions about the host environment.)
2. Keep the desktop-only surface very small and isolated from core; make most improvements benefit hardware users as well. Spend as little maintainer energy on desktop as possible.
3. Don't do anything to throttle performance on desktop.
4. Avoid containerization/emulation on desktop.
5. Keep core dependencies (Jack etc.) as much as possible, even if they're non-native or non-preferred on some host OSs.

Phase 1

1. Add a new UI pane to Maiden that echoes the screen and allows the mouse or mapped MIDI controllers to manipulate the buttons and encoders. (This could be theoretically useful to and testable by everyone, not just desktop users.)
2. Add optional support for discovery of grids and arcs via serialosc zeroconf (also potentially useful on hardware for doing remote-device shenanigans.)
3. Replace guard #defines currently using NORNS_DESKTOP with the correct architecture or OS guard symbols, e.g. for ARM/NEON intrinsics.
4. Remove any desktop-specific interaction code from matron/crone, remove the NORNS_DESKTOP define entirely.
5. Use specific-purpose defines to cut out hardware-only features like GPIO, the wifi menu, monomeserial, etc.
6. Create a build target in waf for desktop Linux that sets the appropriate feature flag #defines.
7. Write up advanced-user instructions for running norns as a service on a Linux desktop using pre-existing Jack & Supercollider.

Phase 2

1. Start to isolate interactions with the filesystem/shell/etc. into a platform support layer.
2. Create build targets in waf for Mac and Windows desktop.
3. Use a lightweight OS-crosscompat library to provide Mac/Windows implementations of Linux sys calls, special dirs, etc.
4. Write up advanced-user instructions for running norns as a service on a Mac or Windows desktop using standard OS-specific distributions of Jack and SuperCollider.
5. Land the converged branch??

Phase 3

1. Bundle the norns process(es) with private SuperCollider and a browser canvas running Maiden as a single self-contained app install for non-advanced users, using a framework like Tauri.

[tehn]

Raising the bar for this project perhaps (absolutely, not perhaps) but completing the work begun in the converged branch would simplify the desktop process significantly by having one primary executable: the goal of this effort is to combine matron and crone which removes OSC inter-process communication and allows shared memory instead.

• https://github.com/monome/norns/tree/norns-converged
• a few issues regarding the work: https://github.com/monome/norns/issues?q=is%3Aissue%20state%3Aopen%20converged

[Dewb]

Yes! My previously expressed willingness to help land the converged branch still stands and I threw that in phase 2. Also might make sense to do that first.

[colinmcardell]

I'm also willing to help with getting as much of the converged branch work into main as possible. My instinct has been to uphold the behavior of code through unit tests to allow for minimal regressions when swapping out chunks of the codebase.

I've done some initial scouting around of the converged branch work as it stands, so I can work on putting together initial details and kick off a separate discussion on what bits of the work specifically (maybe all?, there is a good amount!), priorities, and how it might land.

[Dewb]

Started a new discussion about the converged branch here: #1879

[vehka]

I have some of the phase one stuff done – a working x86-64 Linux desktop (tested on Manjaro and Ubuntu 22.04) port of the new converged main (with SDL screen rendering and keyboard emulation of the keys and encoders, grids work too with no extra code). This required some portability fixes, which are not desktop-specific. I was thinking I'd make a separate PR out of them anyway. They build cleanly on top of the latest beta on my norns shield.

Based on the discussion in #1876, rest of my changes need extra work before they are PR ready. I suppose what Dewb wrote would be the way to go: instead of one big NORNS_DESKTOP switch, guard each piece by what it actually needs (the ARM/NEON code by CPU architecture, the OLED and GPIO by whether that hardware is present, the SDL input by whether SDL is on) and let a desktop build target switch on the right combination. Does that sound right? What about ssd1322 specifically? As tehn suggested in #1876, guards inside the .c & keep the includes, or the fuller split where the build target excludes the file?

Desktop Linux is an easy target because so much just works the same as it does on norns (jack, supercollider, grid detection), but if there's something I can do to pave the way for future Windows or MacOS ports (implemented by people who work on those environments), I'd love to take that into account. (Or for a future self-contained app as Dewb envisions for phase three.)

Perhaps it would make sense also to discuss about what's the point of the desktop port? I did it mainly because I want to develop scripts on my desktop, but now that norns is part of the desktop audio environment, the other possibilities are clearer to me: a non-DAW music-making environment that integrates nicely into the Linux audio ecosystem. A banal example: I can open the qjackctl graph and just connect the audio paths however I like. A self-contained norns "app" would be a step towards this direction even more, I suppose.

Finally, a caveat: my potential PRs would contain code that's generated with AI assistance. I'm just mentioning this since I know from lines how critical some of the contributors are towards this. (That's why I initially contacted tehn via email to ask if he'd prefer I'd just keep my stuff in a fork even without seeing the code.)