Alternative (midi/osc) Grid Controllers (launchpad)?

[BjarneJensen]

Hi, I'm curious if we could get support for midi grid controllers beyond midi mapping. I did not have much luck with the vcv midi mapper, as it seems to want cc values, but my launchpad mini outputs notes on button press. I could probably get around this and expand its capabilities routing through max/ableton first, but I'm curious if there is a more direct solution that offers led feedback.

For now I have been using Oscelot to receive osc in vcv and node-osc to translate midi messages, send to osc, and light leds, but communication is only one way, so no led feedback.

Would it be possible to use a midi to osc converter to get monome-rack to recognize launchpad? It seems some multidirectional osc would be needed, especially for led feedback, but I do not know much about the serialosc protocol.

Is there just a port and osc address that I can listen to to get feedback and communicate with the virtual grid/devices?

Alternatively, could your virtual grid to have its own midi mapping context menu where you could set device in/out and map buttons and save presets? I am not familiar with vcv dev, so I do not know how much work these requests would be, but I'd be happy to help.

It would also be cool virtual grid had some standalone modes for midi connection to hardware/daw (ie; virtual launchpad).

Anyway thanks for the awesome tools. Like I said I am not familiar with vcv dev, so I may have missed something obvious or a module that could accomplish these tasks.

[Dewb]

Hi! Thanks for the detailed report. This issue has come up before on the forum; I think the right way to approach this is for VCV Rack to interact with the serialosc service, and support any hardware exposed through that service, rather than building alternative grid implementations. I believe there are some efforts underway to provide serialosc bridging for devices like the Launchpad, which would enable their use in not just Rack, but Max and other grid-consuming apps, without doing any extra work in this plug-in.

[Dewb]

Final word on this, I think:

• This plugin supports serialosc devices. If you have a controller that is not serialosc-native, look into tools that allow you to use your controller with serialosc.
• The plugin also supports standard Rack mapping of button controls using the standard VCV MIDI Map module and third-party MIDI Map alternatives like Stoermelder MIDI-CAT. It's not feasible to support LED feedback with this method because the buttons and illumination state of the grids are not necessarily linked, which violates assumptions that these modules make.

[VegaDeftwing]

I was working with this today and was able to get my Push2 to map using MIDI-CAT, however, you are correct LEDs don't work. I think this would be a valuable feature and wouldn't be outside the realm of reason to support now that you've added MIDI support to "faderbank" the code should be similar in nature. The bigger problem would be supporting the various weird ways controllers do feedback to light the LEDs and inconsistencies in the notes sent by each button.

Fortunately, off the top of my head, I can only think of two families of controllers I've seen widespread adoption of: The Ableton Push and various flavors of LaunchPad. I believe they use a slightly different mapping of notes to buttons, but I think it's just an offset, so that's easy enough to handle in code. The more complicated problem is lighting the LEDs, but in both cases I believe it's as simple as sending the note back on a specific channel and with a specific velocity. See https://github.com/Ableton/push-interface/blob/master/doc/AbletonPush2MIDIDisplayInterface.asc#Pedals for the push and https://fael-downloads-prod.focusrite.com/customer/prod/s3fs-public/downloads/Launchpad%20X%20-%20Programmers%20Reference%20Manual.pdf for the LaunchPad X (Which, for the 64 pads, should be common to all the LaunchPads)

I no longer have a launchpad (I just sold my Pro MK3 this week!) but I do have a Push2 and would be interested in adding support if you'd welcome the addition. I'd do my best to write it generically enough to make slapping Launchpad support in later easier, and this would certainly be a better user experience than trying to run a 3rd party program to fix the incompatibility. This is especially true for the Push, which only really likes to play nice when running though Ableton (And so using VCV Pro as a VST)

[Dewb]

Right now, I still think device translation belongs in the serialosc layer. But you're correct that the MIDI faderbank support hints that I am planning to soften that stance. I do have a Launchpad X and I occasionally have the urge to use it as a teletype controller alongside my serialosc grids.

Translation to MIDI is not rocket science; the challenging bit is implementing the grid splitting/merging necessary to use two 8x8 devices with a module that expects a 16x8 surface. This is a feature that is desirable for both serialosc-native devices and MIDI devices, and it's a UX challenge more than a coding one. Use cases include mapping two 16x8 modules to the two halves of a 16x16 hardware grid, etc.

I'm not likely to work on or merge anything w/r/t MIDI device interaction until a general system for split/merge is in place. You're welcome to hack around on your own fork of course.

Can you go into more detail about how the Push behaves outside Ableton? I'm not likely to want to merge anything that only works correctly in the VCV Pro VST.

[Dewb]

Another possible interesting direction that you could run with to address hardware support for these devices might be to create a separate grid device MIDI mapping module, as an alternative to VCV MIDI-Map or Stoermelder MIDI-CAT, that understands the MIDI hardware requirements of the Launchpad or Push and can target 64 consecutive parameters with decoupled LED feedback on any other module. This would not only enable you to use modules in this plug-in, but also other modules that have 8x8 or larger button grids.

[VegaDeftwing]

I thought about this more and started a quick PoC in Lua with https://github.com/Simon-L/ModScript and I'm thinking that it might need to be integrated into this plugin to avoid a polling loop causing either bad performance or bad latency. If it's in the plugin, it can just get events the same way everything else does. Thoughts?

[Dewb]

Testing with ModScript is a great idea! So there is going to be a latency/CPU% tradeoff in watching the grid module for changes from an external mapping module, but I don't see any reason why an efficient external mapping module couldn't handle this use case.

I whipped up a basic ModScript test script for the Launchpad X, and this seems to work with very little latency. By default, ModScript is fairly CPU hungry; setting a high block.frameDivider value is necessary to keep ModScript from stalling the audio engine. https://gist.github.com/Dewb/163a67b8dc3a5ca3e8a1939be7bc6270

I did have to make a change to the monome plugin to enable this, though -- right now, the grid LED states are not Rack "lights" so there is no way for ModScript to see them. I put in a quick hack for that in this branch, I'll see about getting a more efficient version merged in the future.

[Dewb]

The midigrid library for norns already embodies a lot of the necessary work in capturing the MIDI requirements of specific hardware (including all Launchpad models and Push2), mapping grid levels to palettes, etc. Since it’s also written in Lua, it might make sense to reuse in a ModScript solution.

[Dewb]

Reopening to track the task of exposing LED state as Rack lights for mapping.

[VegaDeftwing]

I found out about https://llllllll.co/t/toga-touchosc-grid-and-arc-controller-for-monome-norns/47902, a TouchOSC script that actually exposes a grid clone over OSC. It seems due to the way your grids look for a connection these can't show up easily though. I hope to find some time to look into your code myself to fix it, but if you get ambitious this looks like it might be the most elegant solution for most people.

[Dewb]

Yes, there is some discussion of this here: monome/serialosc#65 (comment)

Switching device discovery from port 12002 to zeroconf/mDNS is indeed in the long term plan but I would describe it as a “complete reimplementation of the discovery logic with new dependencies” rather than a “fix.”