-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Virtual MIDI not usable as clock/pmap source #1744
Comments
Probably a simple oversight and shouldn't be too tricky to fix if anyone wants to have a go |
Would be rad if so! I'm way out of my depth here, but one thing I noticed working on the related mod is that the virtual port gets added later in the boot process than physical ports (after the "system_post_startup" mod hook). Probably tangential but I figured it's worth bringing up if anyone is interested in a more general effort to close gaps between virtual and physical ports. |
Enabled system real-time messages but Norns system won't recognize this, pending a fix for monome/norns#1744 (comment)
i looked at this but only very briefly:
if (2) is true, then i can see how it would not work to drive MIDI clock. MIDI clock messages from connected devices are handled at a lower level in https://github.com/monome/norns/blob/main/matron/src/device/device_midi.c#L288 if i understand corretly, it should work fine to read clock messages from the the next step i had in mind was a proof-of-concept writing a small program to send periodic clock messages to the virtual device through ALSA rawmidi API. like starting from this example: https://ccrma.stanford.edu/~craig/articles/linuxmidi/alsa-1.0/alsarawmidiout.c ... i have not quite got that going yet but thought i might as well check back first to ensure we are on the same page. |
Thanks Ezra- you are correct about how CyberMIDI works. MIDI is encoded as OSC to send between devices. When it's decoded the I was able to successfully send/receive MIDI clock with a shieldXL which uses the So it sounds like this is just a limitation of my mod's implementation and not an issue with the |
ah ok, that explains why it would not work for parameter mapping either. (which i forgot to address.) the parameter mapping code also observes MIDI messages at a different stage in the pipeline than vports does. however unlike MIDI clock input, this is still happening entirely in the lua layer: .. so basically, i think all you would need to do to make parameter mapping work is to call however, making the mod able to drive MIDI clock events from lua would require changes to core: namely a dedicated FFI function to do that. we haven't seen a need for such a function before, but i at least would not be opposed to adding it. |
Aha! Thanks for the tip re: parameter mapping! Between this info and the upcoming Link improvements for clocking, feels like the need for any changes is greatly ameliorated on my end. TBH, it seems like a better solution than my mod is something like RtMidi which I assume would not have this issue as it uses ALSA. I'll leave that up to someone who knows what they are doing 😬 |
Yeah if you asked me to implement something like cybemidi, my first thought would be to do it as a daemon process connected to virtual port. Rtmidi or portmidi would be options for that, but for Linux only I don't think it's any less convenient to use alsa apis directly. But thinking about it, I think it would also work if cybemidi wrote to virtual device output, and then the daemon process did nothing but loopback on the virtual port, and then norns user would just select virtual device for input and everything works normally. |
What the issue is:
MIDI system real-time (clock) messages received by the "virtual" RawMidi port are ignored when clock source is set to MIDI. Likewise, control change messages are ignored when mapping MIDI to parameters.
How to reproduce it:
I'm using CyberMIDI (MIDI over OSC) to send clock/cc over IP. These message types are retrievable in LUA via midi.to_msg().
Why it's worth addressing:
The text was updated successfully, but these errors were encountered: