Maiden: development

A thread for those who have wanted to hack on, improve, and grow the maiden editor component of norns but weren’t sure how to get started - this is the place. Technical questions and discussion around improvement ideas are welcome!

The repository includes README files on getting started.

To kick off the conversation and to preview an awesome addition by @dansimco which just landed - maiden finally has a full dark mode coming.


Another thing on my todo list since the beginning is to put some guard rails around cmd+[ so I can stop backing out of the file I’m editing when I try to set indentation


that dark mode looks so nice! thanks @dansimco <3


Has dark mode been rolled out yet? I do see the option, but it does not ‘stick’, it stays white and when I go back to settings light is selected.

1 Like

No, it will come out most likely as part of the next update. It has just been committed to the main branch at the moment.

1 Like

Ah, funny that it is a visible option in settings then :slight_smile:

I like to drop document.querySelector('.repl-input').style.height = "10em"; into browser console when livecoding, simply to get more vertical space for the REPL.

1 Like

The visible option is for the code colouring which is a pre existing feature :slight_smile: . I didn’t touch that aspect, just the surrounding chrome of the app. So theoretically you could have dark ui with light code. Not sure if that’s desirable to anyone, but I didn’t want to remove control as part of this change. I suspect an ideal outcome would be to add an “auto” or “match system” option there. Or if no one cares for mix-and-matching light and dark mode we just use the dynamic colours for code highlighting too.


I’m thinking about adding a component that displays the Norns screen within Maiden.

Does this list of the pieces sound correct?

  • Go code that loops, doing whatever _norns.screen_export_png() does
  • A React component that refreshes that image at the same speed
  • More React code to put that component into the Maiden interface

If that’s right, I think I know where the React stuff should go, but what about the Go code? Would cmd/server.go be the right place?

1 Like

The maiden backend (server.go) doesn’t actually interact with matron directly. The front end react app is maintaining three channels of communication. One is HTTP to the backend to load the app, get configuration information, and trigger installation/removal/update of scripts. The other two are web socket connections to matron and supercollider (sclang) respectively.

I would anticipate invoking screen_export_png(…) at 15 fps from the front end would generate sufficient load as to render the device largely unusable since that places a blocking file write directly in the matron event loop. Doing so would have a severe impact on timing and responsiveness to physical device controls.

Out of curiosity is there a motivation use case? If the desire is for an easier way to capture the current state of the screen for easy download that could be achieved with less effort.

Ah ok, with that tip I was able to find the relevant websocket stuff, thank you.

The motivation here is just that it would be convenient for my dev workflow to get visual feedback right next to the editor. I can also imagine it being useful for live coding, but it’s definitely a nice-to-have rather than a necessity.

I could also do this with, but it seemed like it might be more efficient to fold it into Maiden directly (and avoid installing additional libraries, maybe?). For that project, they’ve set the default to 4 fps, at which they report up to 15% CPU usage. I’d make that tradeoff for dev convenience, but would want to be able to toggle it off when I’m not using it.

If you’re not opposed to the idea, I might give it a try to measure how bad the performance hit is (and also to get some front-end practice). Totally fine if you think you’d rather not go down that road, though.

I took a quick peek at what is doing and it is apparently using the screen export function. at 6a2fc4300869c2fa872e9852ff1bcfcf788c8b2f · schollz/ · GitHub

It is worth noting that in another thread someone was asking if there was a way to suppress the stream of <ok> responses in the maiden repl which result from injecting commands into matron via the websocket. In short there isn’t without making other changes in more core components.

In the interest of transparency I think it would be a significant amount of work to implement something which is efficient and clean enough that folks would be comfortable merging it into the core.

1 Like

Yeah, that stream of responses would be a big distraction. Great catch on that. Oh well!

I think a more efficient and flexible strategy for desktop preview of the norns screen might be to make a C mod that broadcasts the screen feed over the network as either a RTMP or NDI stream.

It’s on my list of hacks to try but I figured I’d cast the idea out there in case someone gets the chance to work on it before I do.

EDIT 9/16: I did get a chance to take a swing at this. Here’s a prototype mod for sharing the norns screen via NDI. Performance is quite good, 30fps with less than one frame of latency, and only taxes the norns CPU by an additional 1-2%.