#32

Pretty sure I have seen something like that around… hard to remember in which script I last spotted it tho so if you do come across a reference, would be v handy!

#33

Ok so I’m doing this in my Torii script when setting up the params for changing grid devices:

midi.update_devices() should help for either/both your midi_device and midi_interface params?

Also - looking at Passthrough.device_event(data) I’m not seeing anything obvious that would send to all channels. Wouldn’t that need a loop? I don’t think there’s any kind of “Omni” channel in the core midi library.

#34

Yup - looks like it! To be honest i hadn’t tested that functionality as i’d lifted that chunk from elsewhere mostly… my bad! Maybe i should remove it… or add a loop in. An omni channel would be a good addition to the core midi lib

1 Like
#35

looking at the core midi lib, I don’t think there’s an easy way to do this since the midi spec doesn’t really include a separate channel for all/omni. (investigating further). For now I think it’d need to be done at the app layer with a loop to send to all channels.

#36

I’ve made an update this evening - this fixes the issue of the devices and interfaces events not targeting the right functions. So this should work as expected on script launch now. Thanks for the prompt to fix that.

As for the other issues. I haven’t yet a solution for refreshing the available midi devices. I’ll keep trying but I couldn’t get the params options to update when devices are added/removed. If you can find an example where this works well, let me know! And I removed all as a channel option for now. It would be great to support it properly, but for now I wanted to ensure that the core was behaving as it should and keep ‘work in progress’ features far from causing people issues!

1 Like
#37

I updated and this still doesn’t seem to be working for me – still have to switch away and back to get data sending through. Just a minor thing, really.

Makes sense to me – this is a great utility (seems like it would be a great add to main norns under midi devices @tehn?) just hope that all becomes workable as it’s my primary use case right now :sweat_smile:

#38

Weird - did you update it inside the scripts that you’re using it in? Or are you trying with the example script in the Passthrough repo? Just tried with my setup and it’s working here.

I’ll keep looking into all :slight_smile:

I wasn’t certain whether to suggest rolling it into Norns core midi although it could be nice. I haven’t really checked or tested Passthrough with scripts that use MIDI input/output in parallel since it wasn’t particularly relevant for me, and I wonder if having it in could create some hiccups for folks. I even was doubtful whether to add the repo to the community catalogue since the example script does nothing else :smiley:

#39

Yes – I only have it in MLR right now, so overwrite the existing lib passthrough.lua with the new one. Confirmed it’s new because all is no longer there. Do I need to update anything inside the code?

I tried with both my Midi Fighter Twister and Qunexus sending to Digitone.

Good point about possible interactions with midi scripts. That could get very confusing, or requiring those scripts to assume control of the system somehow.

#40

Alright i’ll try to reproduce …

#41

I just tried it with MLR and it works instantly.

Can you show me your implementation in MLR?
Mine is this:
L24: local Passthrough = include("lib/passthrough")
L362: Passthrough.init()

and can you double check that you’re using the same contents in lib/passthrough.lua as what is on master on github? Feel free to send me the entire copy you’re using either here or on PM and I can take a peek.
Sorry for the trouble!

#42

No trouble at all. It works now. :slight_smile:

Deleted and reinstalled MLR, then added the lib and code back in. I had L24 same as you, but had what you note as L362 at L370 under init = function(). Put it as you note and voila. Thanks!

#43

Glad it’s working for you now :slight_smile:

1 Like
#44

i’m wondering if there’s sufficient validation for some sort of UI to “load additional lib” or something.

my gut feeling is that unless it’s very well designed and considered there will inevitably be difficult code conflicts to resolve.

i do think the MIDI devices section could have a couple util functions added, such as port redirection (like this lib does). it’d also be nice to have a little midi monitor built-in to the menu.

5 Likes
#45

@Frederickk has made a great update to Passthrough, which allows for user event callbacks to be defined in your scripts, alongside a couple of nice bits of polish. This allows you to hook into the MIDI event stream in Passthrough, and define your own behaviours.

Update in Github repo linked in the top post or install using Maiden catalogue.

2 Likes
#46

does anyone know what the best method to pass midi through my norns (fates) and back into my octatrack would be? i have octa midi going through a digitone and then model cycles which send midi thru to the norns which goes into the octatrack. I also have a nanokontrol running midi into the norns. I would like to be able to pass the midi from the octatrack back into itself through the norns and have the ability to control my octatrack with the nanokontrol through the norns as well.

i have tried unsuccessfully to use this script. Cant figure out how to add the code to another script without getting a run error. but i dont really need it to be attached to any particular script if that isnt necessary. is there a way to pass midi from either device port straight through the norns without any particular script running? or is there a way to do that with this script?

#47

Passthrough was initially built to pass MIDI into an Octatrack I was using. If I’m following correctly, I think you are looking for multiple devices (Nanokontrol + model cycles) to be supported with an interface (Octatrack). Passthrough doesn’t currently support this, although its a good feature request that I’ll try to get round to implementing. I believe there was talk of creating this kind of routing as part of the core Norns MIDI feature set, but I haven’t really followed so unsure of the status there.

Am interested what are the run errors you are getting, there are instructions for implementing it in scripts.

#48

thanks so much for this @nattog! was able to get a Midi Fighter Twister hooked up to a Zoia no problem, and was able to do what I was hoping would work out of the box - using the same cc to control norns and zoia params. (I’m still new to MIDI; this is probably an obvious use-case)

1 Like
#49

First of all, thank you for making this! I’m also using Norns to broker messages between my MFT and Zoia (as well as control some params on the Norns).

Just confirming something before I go deeper down a rabbit hole: Are CC messages unidirectional (Device --> Interface)?

I’m trying to have Zoia send MIDI CC back to the MFT (to update knob state) and I don’t seem to be able to. I am able to send CC to the Zoia via the MFT, but when I try to send CC from the Zoia it never reaches the MFT. I’m able to sniff the MIDI CC coming from the Zoia on the interface I’m using using MONITOR-MIDI so I know that I’m at least sending CC from the Zoia into the interface but I’m assuming that those control messages aren’t passed along.

Would love to see this kind of thing built into the MIDI implementation, the flexibility that would afford is kind of mind-blowing.

1 Like
#50

It’s certainly possible - with Passthrough interfaces already send clock events to devices so it’d be simply a case of expanding the interface event function to handle CC. I’ll likely make an options param for CC message direction too. I’ll aim to get round to it soon.

2 Likes
#51

That would be spectacular! I’ll make sure I’m watching the GH repo (and this thread). I doubt that I could figure out how to implement the expansion of the interface event function myself but I’ve been looking for a good practical entrypoint to LUA so maybe I’ll be able to actually contribute!