The README files in the git repo have information on getting setup. https://github.com/monome/maiden/blob/master/README.md

If the goal is to focus on just the front end web app you can likely skip setting up the go toolchain and look at just the front end portion which is in the app sub directory. The README file there has more details. https://github.com/monome/maiden/blob/master/app/README.md

I believe all the contributors to maiden have in general used macOS or Linux. In general I’d expect using Windows would work once the toolchain is setup. The development workflow is setup such that one can avoid installing any of the toolchain directly on the norns device.

3 Likes

You could create a new config that sets the fontSize setting, which ace uses (the code editor library maiden is built on top of). Here is a simple codepen I found that shows all the possible ace settings.

Basic changes needed would be:

  • Add a new configure-item section to this react component that gives fontSize some options here
  • Set a default fontSize here
3 Likes

I could use the text a bit darker…

1 Like

Anyone thought of building an audio editor for Norns. A script that would allow cropping/chopping of samples. Could be really useful for editing stuff recorded to Norns tape for use in other scripts.

10 Likes

Is it possible to display .svg with Cairo ? I guess it is, but would it be possible to add this option to Norns ?

the other day I went down a little rabbit hole of graphics formats to see about displaying pixel art. XPM/XPM2 seemed like it might be an interesting format to read/script via lua.

googling SVG and Cairo shows svg2cairo and libRSVG

also a simple stupid single-header-file SVG parser?

3 Likes

Thanks for sharing these links @okyeron I’m too dumb to implement this by myself atm I stick to screen.move and screen.text in my scripts but it’d be cool to have the ability to add svg graphics to the interface sometimes. I tried little animations/visual feedbacks with a dedicated metro but that’s using CPU for nothing…

it shouldn’t be hard. @artfwo did some proof-of-concept bitmap rendering a while ago IIRC…

generally, it should not be a problem to expose additional cairo methods to the norns lua API. but probably important to remember the single-threaded limitations if one intends to do heavy format-parsing stuff from lua main thread - which is to say, heavy stuff on metro or event handlers might mean you miss UI events and maybe leak memory. (also, accessing the cairo surface is supposed to be thread safe but in practice appears not to be).

2 Likes

While on topic… is it possible to render negative text on screen? Could be useful to navigate custom UIs. :slight_smile:

Docs say current lowest text color value is a light grey (dim white). There’s are examples in the current dust scripts where navigation is helped by changing values from dim to bright when scrolling thru the available selections. Ex: flin, ANDR

Edit: thinking about this, I wonder if a negative text color value would produce black?

You can place elements with screen level “0” over brighter ones to make it negative

2 Likes

Just a heads up:

I set up PHPStorm (from JetBrains) - one of the IDEs in the Intellij branch - to SFTP into norns today. Worked great. Saves new/modified scripts directly to norns.

I added a Lua plugin available for the IDE, so with it and the SFTP capability, I’ve got a capable dev tool.

3 Likes

Would it be possible to read a MIDI .mid file into memory and then direct that output to the already existing midi functions?

EDIT - looks like aplaymidi would get the job done from the command line…

but I can’t get it to route to a port norns is using (with a plugged in midi device) - error: Cannot connect to port 20:0 - Resource temporarily unavailable

Is the alsa Midi Through port enabled or accessible from norns?

EDIT 2: OK - looks like the thru port or VirMIDI ports won’t show up to norns because they are not USB. @zebra - do you think it would be possible to extend this to see the thru or virtual midi ports?

midi support is kinda limited to one port,
[ https://github.com/monome/norns/issues/536 ]

would be good to fix that, some debate re:method

but tbh i am not a big midi user, no skin in the game

my guess is that the cleanest way would be using jack

2 Likes

I think that might be a different issue (specifically where a device has multiple ports - i.e subdevices).

What I’m looking at now is that virtual devices (VirMIDI) or MIDI Thru are not seen by norns - I believe because it’s only looking at usb devices as valid (I think due to check_dev_type() function in device_monitor.c.).

Some nomenclature problems here with the terms port and virtual meaning different things depending on the context.

oh, yes indeed sorry i didn’t really address the question directly.

you’re quite right, norns only registers MIDI devices that show up through udev - that is, USB devices.

IMO, the linked issue and this issue have the same solution - use jack or something to register matron as a listener for all midi events, regardless of their lower-level origin.

1 Like

I’m getting mixed results from MIDI out in a script I’m working on. Notes are choppy or missed altogether. I think it’s do to note_off being sent to soon after note_on.

Has anyone a suggestion for how to better handle this? Mark Eats’ loom handles it perfectly, but I’m still studying his code for how he pulls it off. In the meantime - wondering if other solutions exist.

Thanks.

Yes, if the note_off message is sent directly after note_on (milliseconds), its length is so short that you’ll have the impression the note message is missed but I don’t think that’s the case (it also depends on how the external instrument handles midi messages, a Nord Drum 2 for example doesn’t really care about notes off). You can check with a software like Midi monitor or use a simple print() somewhere in your function to check in the console if the message is sent.

There are many ways to give a length to your note message. One way is to use a metro. It really depends on what you’re trying to achieve, which source is triggering the note/driving the sequencer etc.
My answer is a bit messy but I’d be happy to help via PM or in another thread if you need :wink:

A bit off topic, but generally, I use something like this to keep track of the active notes. It's easier for handling the notes on and notes off
notes = {} -- store the active notes in this table
   m.event = function(data)
  local d = midi.to_msg(data)

  if d.type == "note_on" then
    local note = {d.note, d.dvel}
    notes[note] = note
  elseif d.type == "note_off" then
   local note =  d.note
    notes[note] = nil
  end
end

Then use two functions one for playing (note_on) and another one for stopping the notes.
Looking at loom.lua, Mark Eats seems to do something like this, too. See lines 203, 225 and 508 of the script

2 Likes

Is there a rough estimate for the 2.0 beta? No expectations at all, just was going to budget time in the coming weeks to make some tweaks on my looper script that uses softcut heavily, and I wasn’t sure if I should just wait since it would need updating for the 2.0 changes. I saw on the updated API on the wiki, but haven’t attempted to pull the 2.0 branch.

And I think is how the loom code I referred to to OP handles this. Thanks. Will delve in. Thanks!

1 Like