#185

Wow - you’ve really been blazing with norns!! I’d seen a little bit while I was iPad only. So cool what you’ve been accomplishing. Thanks for sharing all your progress.

Actually, it is really stunning how far everyone has gotten in a few weeks. This platform is really awesome. :slight_smile:

Thx!

2 Likes
#186

Here’s a gist of the OSC stuff I got working (I’m a total OSC noob, so I hope I’m doing this right)

#187

FYI - I still experience lockups every time I boot up and connect to a wifi network. When I reboot, it works… but norns shows me a failed response even though I can connect via maiden, add and edit scripts … but now I can’t run scripts via the maiden interface.

And today for the first time norns forgot my wifi network password.

But spacetime and patterning work like a champ!

#188

whats you thoughts on this?

you mentioned (in another post) Supernova was not working on the rPI/Arm , but when I did a bit of ‘googlefu’ it was really unclear why it doesn’t work - is is a bug, that no one is interested in looking at ? or something more fundamental? do you have any references to the issues?

Approaching: norns
#189

[ mod: moving this to Development ]

[ed: sorry linked to irrelevant GH issue]

my information could be out of date. it wasn’t working in 2015 and author tim blechmann indicated that it would not in near future. our attempts to compile so far have failed. there are discussions about it on sc-dev and sc-users but gmane email archives are having one of their periodic conniptions and i can’t view them.

maybe others here have more knowledge to add. if supernova can be made to work on ARM that would be great.

multiple scsynth instances connected with jack
https://github.com/monome/norns/issues/417

1 Like
#190

yeah, my ‘quick search’ on the issue basically found little…
as much as I could glean it was…

https://github.com/supercollider/supercollider/issues/1818
but this basically was, an old compiler, and tim said ‘whats the point’ , the BBB is single core (valid, but not what is the issue!) , so it was marked as ‘wont fix’

and another thread
https://github.com/supercollider/supercollider/issues/1990
which said they got it to compile on rPI3 and it seg faulted, to which the solution was : turn off supernova (as this was not the OP original requirement )

do we have any other references/details on what the issues might be? is its something worth looking at?

seems like an interesting way forward, but not if there are some fundamental issues that we are not aware of?

(on your GitHub issue @simonvanderveldt seemed to say something on similar lines ?! )

UPDATE: ok, so did a quick look thru the Supercollider issue list, no mentions of rPI/arm/Supernova except the above - so would seem perhaps if it can be compiled on arm with latest compiler, on a rPI3 (so multi core makes supernova interesting) perhaps it can be added as an ‘issue’ , at least to get some thoughts on if something is likely to be fundamentally problematic, or its just a ‘bug hunt’

3 Likes
#191

threading in matron…

so devices have their own threads, which post to the event queue, which then gets picked up by the ‘main thread’ which is running the event_loop()

my question is… when a lua script is running, is this running in this same main thread (event_loop) ?
and also is it always a synchronously run to an event?
(e.g. the lua calls to grid calls, might be happening in response to a metro , or key event)

Im asking, as it looks to me (as far as ive found) that thread safety is maintained by a producer consumer model via the event_loop() - correct?

1 Like
#192

yes

yes, and its a good point - we really should not be doing heavy blocking things in lua callbacks at all, because they will stall the event loop, maybe leak memory and other bad things.

yes, thread safety is maintained by the event loop. no, it’s not dependent on the (multi) producer / (single) consumer model. (as far as i can tell, it would still work if the main thread also produced events, and/or if the device threads also consumed them.)

incidentally, i did get supernova compiled on the rpi yesterday. did not have time to actually try using it. hope to find time today.

4 Likes
#193

A few MIDI questions - I was working over the weekend to get some basic MIDI functionality hooked up on my newly-arrived norns. After a bit of fiddling, I was able to see MIDI devices (I tried a few but was mostly working with a MIDIfighter twister). However, I was unable to receive or send MIDI data from a SuperCollider context, nor was I able to any messages being received from the command line. I got ALSA resource warnings in some cases, so I wonder if there’s some contention issue happening?

  1. Can anyone describe the MIDI configuration of the Norns? Anything I should know about routing etc?
  2. I saw some in/out ports for SuperCollider itself, but these don’t appear to receive anything either - are these being used?
    I should note that, for the MIDI devices I tried that produce note events, Norns did appear to respond to them as expected, for the instruments support it (seems like just Earthsea?)
  3. I noticed that not all USB ports behave the same - can anyone give a rundown of the differences between the four usb ports?
1 Like
#194

afaik, the idea is you do all the midi stuff on the lua/matron side , this has midi support - which you can see in a few scripts. Idea being you then use that to send command/parameter to the engines in sc
Not sure if anything has been done explicitly to support midi on the crone /sclang side. Though I guess it should be possible ?!

#195

take a look at the earthsea.lua script as an example

local function note_on(note, vel)
  if nvoices < 6 then
    --engine.start(id, getHz(x, y-1))
    engine.start(note, getHzET(note))
    start_screen_note(note)
    nvoices = nvoices + 1
  end
end

local function note_off(note, vel)
  engine.stop(note)
  stop_screen_note(note)
  nvoices = nvoices - 1
end

local function midi_event(data)
  if data[1] == 144 then
    note_on(data[2], data[3])
  elseif data[1] == 128 then
    note_off(data[2])
  elseif status == 176 then
    --cc(data1, data2)
  elseif status == 224 then
    --bend(data1, data2)
  end
end
-- "status" here is the Decimal value for the midi message (note-on, note-off,etc).

then you could send some midi like this:

midi.send(midi_device, {144, note, velocity})
-- 144 is the Decimal value for the Note On message. 
-- more info here https://www.midi.org/specifications/item/table-2-expanded-messages-list-status-bytes
1 Like
#196

That was my assumption regarding parameters. I was looking into this partly because what I was trying to do goes beyond straightforward one-way cc message passing, and partly because I have extensive MIDI control code in SuperCollider that I didn’t want to have to (or simply wouldn’t be able to) re-write in Lua :slight_smile: . I’m not so familiar with MIDI on Linux, so I have no idea whether the issues I was encountering were specific to configuration things on the Norns (e.g. it holds exclusive access to all MIDI devices because of code in XXXXXX.lua), or just a case of Linux-being-Linux.

Rather than mucking in the woods of ALSA configuration (my least favorite Linux hellscape…), maybe I just try piggybacking on the code @okyeron pointed out, pass raw midi_event data over via osc, and re-trigger MIDI events as needed on the other side (and cross my fingers about latency). That would at least bootstrap a few things…

#197

Ok here’s a little improvement on the above - so you don’t need to know the status bytes

mymidichan = 1

midistatusbychan = {
    -- note-on, note-off, cc, bend
    {144, 128, 176, 224}, -- 1
    {145, 129, 177, 225}, -- 2
    {146, 130, 178, 226}, -- 3
    {147, 131, 179, 227}, -- 4
    {148, 132, 180, 228}, -- 5
    {149, 133, 181, 229}, -- 6
    {150, 134, 182, 230}, -- 7
    {151, 135, 183, 231}, -- 8
    {152, 136, 184, 232}, -- 9
    {153, 137, 185, 233}, -- 10
    {154, 138, 186, 234}, -- 11
    {155, 139, 187, 235}, -- 12
    {156, 140, 188, 236}, -- 13
    {157, 141, 189, 237}, -- 14
    {158, 142, 190, 238}, -- 15
    {159, 143, 191, 239} -- 16
}

local function midi_event(data)
  if data[1] == midistatusbychan[mymidichan][1] then
    note_on(data[2], data[3])
  elseif data[1] == midistatusbychan[mymidichan][2] then
    note_off(data[2])
  elseif data[1] == midistatusbychan[mymidichan][3] then
    --cc(data1, data2)
  elseif data[1] == midistatusbychan[mymidichan][4] then
    --bend(data1, data2)
  end
end

EDIT: My kingdom for a lua switch statement.

#198

also FWIW

~/norns/lua/midi.lua

is where the midi stuff gets setup if that helps at all

1 Like
#199

Some ideas
http://lua-users.org/wiki/SwitchStatement

1 Like
#200

Searching for a better answer of getting midi happening from inside sc I found this:

https://forum.bela.io/d/168-using-alsa-midi-with-supercollider

supercollider code shows that it uses the ALSA snd_seq_ API, while MIDI on other Bela programs uses the lower level snd_rawmidi_API.

Which might be what’s happening here.

in the matron/device/device_midi.h there’s this:

struct dev_midi {
    struct dev_common dev;
    snd_rawmidi_t *handle_in;
    snd_rawmidi_t *handle_out;
};
1 Like
#201

We could probably use some more functions in midi.lua to wrap up all those status codes and bytes hey :smile:

1 Like
#202

I expanded the midi functions I posted earlier and actually tested it. Works ok to get notes and ccs from my Block controller.

Here’s a gist with those funcs.
https://gist.github.com/okyeron/b3e498cbf4b195a130fbb9ba875092c0

I also noticed something - order of function declaration seems to matter in lua - I had the function midi_event(data) before note_on() and it wouldn’t work properly (nil values)*. I’m guessing this is a “lua thing”

(Please note I’m a hackish scripter so I don’t always know what I’m doing or understand how all this stuff is supposed to work)

2 Likes
#203

yep. i know @tehn plans to tackle scope rules in lua in a future study but in the meantime, you’re spot on. in your gist, midi_event(data) is defined as a local function, and in lua locals need to be declared before they can be used. were midi_event(data) global (e.g., the local keyword removed) you wouldn’t have that restriction. (but then you’d be sticking your function into the shared global namespace :smirk:)

1 Like
#204

Ah, glad to hear you’ve got it working with a Block - that was one of the devices that prompted my question. My usage of it is particularly weird though, as I’m (a) sending custom-ish MIDI data from the block, packed into CC messages and unpacked in sclang, and (b) sclang is sending output amplitude back to the block at ~30hz for display.