Hi all,
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?
Either passthrough or monitor could be used for this purpose.
But they take up you app “slot” (only 1 app runs at a time on norns).
EDIT: I stand corrected, only monitor is an app. passthrough is a lib.
Some apps such as b-b-b-b-beat, beets or stjoernuithrott seem to embed lib passthrough, possibly to let USB midi devices communicate while the app is running.
Latest firmware update seems to embed some changes that could ease making this global but I could be wrong.
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)?
Like @eigen and @coolcat said, Passthrough is intended as a lib - which allows us to tap into MIDI at the script level with event callbacks.
I like @dan_derks’ matrix idea, I had a similar idea if ever I would build out Passthrough as a standalone script.
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.
Would be happy to help / experiment with ideas.
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.
I’m looking for a simple way to connect devices, even without filtering or modifications, just everything. Ideally in the background, but a script would do. Any chance I can use aconnect?
As for the look and feel, I was thinking about this - https://github.com/nuc/Midi-Connector, but now I like the matrix view better 
this stuff is thankfully manageable on the scripting level without extra invocations. this helps keeps things usable by all folks
you could spin up a small routing utility using the techniques listed here: https://monome.org/docs/norns/study-4/#long-live-parts-of-the-80s
following that study, here’s a MIDI matrix router without much fluff:
hope this helps get you started!
I’m interested in playing with this as I may have a use case to try it out. Can you point me to any documentation or examples? If not I can of course just read the code.
My use case would involve some filtering/translation.
Also looking to have Norns as a (simple) USB midi router. Patchthrough is great but adding it to every single script that I’d like to use seems a bit overkill.
@dan_derks, it seems to me that this sort of functionality (MIDI routing) is better served at Norns level, instead of at the script level.
How hard would it be to incorporate something like Patchthrough to Norns at a settings level? Is that something in the Norns roadmap?
I’m thinking at the most barebones approach to add a “Connect to” in the DEVICES/MIDI screen.
hi Victor!
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'
passthru.init()
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'
passthru.init()
end
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:
DEVICES > MIDI menu can manage many devices (currently 4, soon 16), would ideal functionality include:
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.
one notion: we have default handlers for events like MIDI and HID, which are overwritten by scripts. the default handlers are no-ops or nil. (re-assigned in these cleanup functions.)
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.)
Hey Dan! thanks for the reply.
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.
Hope this helps!
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)