#1

Has anybody had any luck using SuperCollider’s MIDIOut on a norns with an IConnectivity Mio interface?

I’m using MIDIOut to send midi events from a SC pattern in order to control a hardware synth. The exact same patch works coming from macOS (the synth makes noise), but when coming from inside a norns Engine, it doesn’t do anything (the synth is silent). Adding .trace to my pattern shows that the MIDI events are firing from SC as expected.

Note: I’m sending MIDI from SuperCollider rather than the lua scripting layer because I have some patterns that would be hard to express in lua.

Update Jan 23

Following up, it seems like something in the norns environment matron automatically connects to all midi devices and renders them “unavailable” for SuperCollider.

If I run norns/stop.sh, then run a pure SC file (no Crone) using sclang my-midi-script.scd, it works: It connects successfully to the Mio interface and successfully sends midi control to my synth. I can also see the midi messages coming to/from this interface using aseqdump. However, if I run the same SC from inside a Crone engine, the MIDI connection fails with “MIDI (ALSA): connect failed (Resource temporarily unavailable)”, and aseqdump will error with a similar message about it being unavailable.

I tried running _norns.midi.remove() from maiden on that midi device’s index, and that doesn’t seem to change anything.

Is there any way I can convince norns to leave this device available for SuperCollider?

1 Like
Supercollider tips, Q/A
#2

no, there is not. the matron process is holding onto the alsa rawmidi device handle.

in next major revision we will add customizable device monitor logic allowing you to ignore devices. but i don’t think this is a good idea and i find it doubtful that you can’t do what you need by either (1) generating patterns in lua (which has coroutines and easily supports stream/generator constructs) or (2) looping events from SC back to lua through a poll.

if you use SC for your MIDI I/O, your script becaomes less shareable without a good amount of work, b/c other users of your script lose the abliity to manage their own device connections from the norns menus.

if you are going down the road of not using matron for musical logic, i’d say just go all the way and don’t run the norns stack at all. see norns-lowlevel if you want examples of rolling your own components for the norns screen/keys/encoders and use the device as a .scd launcher.

PS: obviously this is a norns-specific question, but since you put it in the general supercollider thread, norns devs are not seeing it. (in fact i am going to split it to its own topic under Questions… @terribleben paging you from new topic.)

2 Likes
#3

Thanks for the response. (And sorry about the earlier topic confusion, thanks for moving these posts.)

I did eventually find the matron device monitor logic and see where it connects to all new midi devices.

I’m not attached to doing the MIDI I/O in purely SC, and sending events back to lua through a poll seems reasonable as a fallback option. Thanks for the suggestion. This issue emerged just because it’s hard to write norns engines directly on a norns, so my workflow mostly consists of writing pure SC on a macbook for the entire sound design process, then adding a minimal lua layer directly on norns at the last second.

Note: The SC patterns in question are reasonably complex, making heavy use of the various P* methods. Do you have a particular example in mind for expressing similarly complex patterns in lua?

1 Like
#4

porting Patterns:

well, i do understand that the Patterns system is powerful and i agree that if you are composing musical structures primarily with Patterns that it would be onerous to have to “port” them to lua.

i might be up for taking a speciifc example and working through it. (not today though, maybe over weekend.)

if there are specific functions missing from the norns lua stack (like, i dunno, list processing stuff?) then we are always accepting contributions to norns/lua/lib.

using polls:

again i shoudl probably write up a specific example. and honestly i don’t use Patterns much, largely because i find it clumsy to assign arbitrary actions to the results of a pattern in complex structures (like usin lots of Ppar). in fact i can’t remember the syntax for this off the top of my head… something about defining a custom .play method in an Event…?

there is also the virtual midi device on norns, lately added. you could try looping back through that.

we don’t recommend doing this. best practice is to put all your musical / synthesis logic in a hardware-agnostic “kernel” class, and wrap that in a thin Engine_Foo class for the norns-specific glue.

for example: sway/lib at master · carltesta/sway · GitHub

3 Likes
#5

These are helpful ideas. I think my preferred path to start will be to investigate the poll option, because it better suits the way I’ve been composing. Though if I dead-end there then I’d look more deeply into porting some of these patterns completely to lua.

Aside: I was able to get a very bad, unrecommended solution to work for freeing up the midi device in question, by modifying matron’s device_midi.c to recognize the name of this specific device (mio) and avoid connecting to it. This does work! However, I realize that this isn’t a useful solution for the community since it undermines the portability of the SC engines I’m working on. So I’ll be looking into the other recommendations next.

#6

if it seems needful / useful, there isn’t any technical barrier to adding something to the midi API requesting matron to free a device handle (or all device handles.) i’m gonna punt the decision on whether that’s a healthy thing to have though.

(BTW, i do totally understand the desire to ignore the lua parts of the system and do everything in SC. i think really allowing this to happen smoothly would require reworking the architecture quite a bit, to be someting more like organelle: the hardware-specific parts would be in a separate process with OSC or some other interface. [ok no - we’re talking about SC, so OSC is what yr stuck with.]

this is actually not a difficult thing to do - the main burden would be the large number of drawing commands, and the crone audio stuff if that’s desired. personally i’d be happy to leave it to motivated members of the community; supercollider is actually sort of a value-add given that the main initial goal for norns was to support MLR-style digital tape stuff, and turning it into a totally SC-focused system feels like something outside of our core development goals.)

2 Likes