It is quite handy to use RPi as a USB host with routing from device to device (using ‘aconnect’). That was working well on clean RPi image, but not on Norns (I have DYI Shield).
I’ve got: Connection failed (Resource temporarily unavailable).
I guess this is normal since Norns has control over MIDI resources.
Is there any way to achieve this functionality via a script or some configuration change?
Thanks! Still puzzled though.
Passtrhough is a library for other scripts, I don’t see any standalone GUI.
Monitor cant route between devices, only between channels of a single device.
Do I miss something?
i think this would have to be a new project which builds off of the approaches outlined in those scripts – @eigen’s definitely identified the best candidates for inspiration.
out of curiosity, are you just looking for a standalone script with GUI which is basically a 4x4 matrix where you could connect elements of the four MIDI slots to each other (notes, cc’s, clock signals, etc)?
If there are specifics with respect to what the desired MIDI router should do I think this would also be a nice real world use case for leveraging sky - the high level event processing framework which is lurking within norns at the moment.
Tangentially related, before turning my RasPi3 to norns i used orca-c from the command line and was also messing around with MIDI to/from SuperCollider. That doesn’t work with norns, but i should try stopping the norns prosesses (by maybe bringing down the norms systemd service), and seeing it that let’s me connect to MIDI from other programs.
agreed! @infinitedigits had been cooking up a method to “batch add” initializations for library files like Passthrough to all scripts in a code folder. seems like it’d help with this situation, where a specific utility is globally useful to a subset of users. Zack, any leads / thoughts?
but also, just to confirm we’re following the same procedure, if you have Passthrough already installed through maiden then you only need to copy/paste these two lines right under the script’s header:
local passthru = include 'passthrough/lib/passthrough'
but if you’re using a ton of scripts that get updated a lot, i get that it’s a non-ideal. it might also be good to bump threads for your favorite scripts and ask the authors to include this in theirs:
if util.file_exists(_path.code.."passthrough") then
local passthru = include 'passthrough/lib/passthrough'
that code will check to see if Passthrough’s installed and if so, initialize it.
i agree that robust MIDI traffic management would be awesome, i think it just opens up a lot of design considerations, which might be nice to gather some feedback on:
i don’t use a lot of interconnected MIDI devices, but is a standard use case having a MIDI keyboard connected to norns that you’d also like to route to a non-computer device?
what other devices or programs come to mind when you think of this functionality? eg. is the way that Ableton Live handles MIDI routing the standard we’re discussing? or the MIDI thru of a Digitakt?
since the DEVICES > MIDI menu can manage many devices (currently 4, soon 16), would ideal functionality include:
the ability to direct MIDI traffic from one device to many?
the ability to assign each connected device a passthrough destination?
since the code itself is already done, technically not difficult. @nattog might want to take a PR on as the library’s author. it sounds like @ngwese also has something brewing that might fit the bill, as well
I had thought about adding it into the main Norns codebase but I’d seen a fair bit of conversation about changes to the midi / devices settings and hadn’t wanted to step on anyone’s toes if they were working on it already. If I’m mistaken, I would love to contribute something.
i guess i’m overkilling it though lol. i have been importing “libraries” by doing as suggested in a previous thread - basically to merge it upstream (i.e. add it to the codebase or add it to the script). i’ve basically avoided doing global imports to avoid errors. if you want to do global imports i think you can edit startup.lua but i haven’t done this for reasons below.
the libraries i import - middy for parameter mapping, norns.online for script sharing, and a soon-to-be-named script for a grid drum machine, all basically hijack some component of norns (midi, osc, grid, etc.) while within a host script. a global import does not check if the host script already utilizes one of these components so its possible a host script might get your global import and get mad when it tries competing to use midi+osc+grid. passthrough might fall into competing with midi here. though, if you have know-how i think this is not a big issue to debug…but it might make give unsuspecting script authors headaches when they try to debug for folks doing global imports.
basically, i haven’t found a lot of uses for a global import. though there might be a reason for one - i’ve found it easy enough to edit the scripts. in practice actually, i edit a lot of scripts i download to get them to startup in a way i prefer too. i love to git install and have my own “branch” which i can mess with can still keep it in the cloud too.
passing MIDI events through to the first connected output device, might be a more generally useful default… except, many scripts send MIDI but don’t handle it, so we need to at least provide device selection for routing… and before you know it, we are indeed building a full midi routing solution into the norns system, complete with UI and state management.
anyways: no, that is not on the roadmap. given a bulletproof design proposal for making it work, i don’t see why it couldn’t be added. (the roadmap, such as it is, is about more large-scale features and architecture changes.)
I guess it depends. Everyone is going to have a different scenario, so the answers to these questions would vary.
In my particular scenario, I’m setting up a small DAWless setup. I have an OP-Z that I want to use to sequence a Summit and use Norns as the central station for both, sometimes sampling, others sequencing or doing other stuff (I’m still exploring the ecosystem). I’m keeping it USB to reduce cables and stuff.
I can of course connect directly the OP-Z via USB MIDI to the Summit, but having to add a USB hub while having a Fates seems like a miss opportunity to me.
Also, I’d like to explore something like having the OP-Z sequencing a bass line on one part of the Summit while Norns is doing less conventional sequencing on the other part, etc.
I’m sure more complex scenarios will arise in time, but for now I simple passthrough between devices is enough. Even though Norns is more than capable of replicating the capabilities of a “smart” MIDI hub such the Blokas Midihub it doesn’t need to get that complex.
For now, I’m adding Patchthrough via Maiden to the scripts I’m testing.
My thoughts of adapting Passthrough as part of the core lib would be to add in only the main functionality (routing). Passthrough lib throws in a few extras (scale quantization, and event callbacks for example) which I feel may be unnecessary in this use case. Something a bit like the mix page in that you have direct control over each audio source, but toggling midi traffic in a matrix of ports.
The primary reason I wanted to build something like Passthrough was for this (routing a keystep to octatrack, with midi clocking in the reverse direction)
I’m following this thread because I have ordered the 128 grid (should arrive in a week) and I was planning on using it with a hardware synth via MIDI DIN.
I don’t have a Norns (waiting on it to be back in stock) and I don’t use my laptop so I’m wondering if I will be able to use a Midi host like the Kenton
To sequence and control my midi synth with the grid?
Sorry if this question has an obvious answer.