Feature Request: Ability to SendOSCMessages From MIDI Devices

[FunkybotsEvilTwin]

Right now, it appears that MIDI control surfaces in CSI aren't set up to send OSC messages. It would be awesome if we could trigger something like:

Bank1Button SendOSCMessage "/Pager 0' Feedback=No"

...directly from a MIDI surface and have it communicate with the OSC side.

Extend MIDI Interface Class to Accept OSC I/O Interface:
Modify the MIDI control surface class so it can accept an OSC I/O interface (or pointer) alongside its current MIDI I/O. This will allow it to forward OSC messages using our existing OSC I/O Manager.

Method Implementation:
Add a new SendOSCMessage method (supporting different parameter types like string, int, and double) to the MIDI control surface. These methods should delegate the OSC message sending to the OSC I/O Manager, similar to how it's done in the OSC control surface.

Integration with Widget Actions:
Ensure that widget actions that trigger OSC messaging (via the Do method or similar) call the new OSC methods when running on a MIDI surface. This should integrate smoothly with the current zone manager architecture.

Broadcast/Listen:
For full functionality, the MIDI surface should also tap into the Broadcast/Listen features when mirroring two surfaces.

[zeebyezon]

The role of CSI is to interpret movements from a control surface to send commands to Reaper, and get feedback from Reaper to send back information to control surfaces.
Can you explain the use case you have in mind? I don't see how it fits with CSI.

[FunkybotsEvilTwin]

Sure...

Background:

1. There is an existing set of SendMIDIMessage and SendOSCMessage CSI actions - these have existed for a while and generally work well
2. Those actions are designed to send arbitrary MIDI messages or arbitrary OSC messages - allowing users to trigger actions on the devices themselves from CSI
3. There is also existing "Broadcast/Listen" functionality that users like me and buschag use to pair up displays with our hardware MIDI Fighter Twister using OSC - so I've got an MFTwister and an iPad MFTwister (TouchOSC template) - this generally works well too
4. The MFTwister has 4 banks

The goal is to get the MFTwister hardware and MFTwister iPad (TouchOSC) bank in sync with each other. So if I press a "Bank button" on the hardware to go from Bank1 to Bank2, I can also have the "Pager" where each bank is on the MFTwister, update to the correct bank on the TouchOSC template. This way the iPad will move in sync with the hardware.

Issue:

The thing that prevents this from working within the existing CSI paradigm is that SendOSCMessage doesn't work when triggered from a MIDI surface. But in theory, there's also an OSC I/O manager in CSI. Hence, the suggestion is to extend the MIDI control surface class to support the existing OSC I/O manager and leverage that so OSC commands fired from MIDI surfaces could reach their destination.

[rwallingford]

The problem here is that a MIDI surface has no knowledge of the the IP address and port number of target.

A possibility would be for the UI for a MIDI surface to include optional OSC info in the MIDI surface class.
Basically the UI for MIDI would need a minimum of: the OSC IP address, tx/rx ports, and "Max messages"

But that is a lot of effort, and I am not a UI coding expert.
We would require a dev familiar with coding UI interfaces

[FunkybotsEvilTwin]

The way I saw this working was that the MIDI Surface would have to be Broadcasting to a Listening OSC surface. The MIDI surface would simply pass the OSC message through to the listening OSC surface, then, in theory, the OSC I/O manager would then be passing the messages along to the OSC surface at the IP address/ports it's been using.

I'm not sure that actually makes anything easier though! I know Broadcast/Listen is probably one of the trickiest sections of the CSI code to delve into, if not the trickiest.

But I'm totally good with tabling this request unless some brave soul felt like taking this on.

[GeoffAWaddington]

Why not make a new Action that takes a surface name and message for params. OnZoneActivation SendMessageToOtherSurface “X_32”, “/blah/blah” OnZoneActivation SendMessageToOtherSurface “X_Touch”, “09 04 ff”, something like that. Don’t think it’s wise to add OSC params to MIDI surfaces, you would need a collection, since a given setup might have numerous OSC devices. The parser could sort out whether it was a MIDI or OSC message and act accordingly. The parsing is already coded, have a look at SendMidiMessage and SendOSCMessage in manager actions, right at the top. If you attempt to call SendMIDIMessage on an OSC surface, nothing bad will happen, the default is to do nothing, so the OSC surface will just call the empty SendMIDIMessage defined in ControlSurface. A lot easier solution.

…

On Apr 5, 2025, at 1:52 PM, rwallingford ***@***.***> wrote: rwallingford left a comment (FunkybotsEvilTwin/CSICode#23) The problem here is that a MIDI surface has no knowledge of the the IP address and port number of target. A possibility would be to for the UI for a MIDI surface to include optional OSC info in the MIDI surface class. Basically the UI for MIDI would need a minimum of: the OSC IP address, tx/rx ports, and "Max messages" But that is a lot of effort, and I am not a UI coding expert. We would require a dev familiar with coding UI interfaces — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread. <#23 (comment)> <https://github.com/notifications/unsubscribe-auth/AGHT3WKTB5XAIH6UX33BLXT2YAC6DAVCNFSM6AAAAAB2IGXUAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBQHE2TONJTGY> rwallingford left a comment (FunkybotsEvilTwin/CSICode#23) <#23 (comment)> The problem here is that a MIDI surface has no knowledge of the the IP address and port number of target. A possibility would be to for the UI for a MIDI surface to include optional OSC info in the MIDI surface class. Basically the UI for MIDI would need a minimum of: the OSC IP address, tx/rx ports, and "Max messages" But that is a lot of effort, and I am not a UI coding expert. We would require a dev familiar with coding UI interfaces — Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGHT3WKTB5XAIH6UX33BLXT2YAC6DAVCNFSM6AAAAAB2IGXUAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBQHE2TONJTGY>. You are receiving this because you are subscribed to this thread.

[rwallingford]

Great thoughts Geoff.

Since I have an X32 which is OSC and an XTouch which is MIDI, I should be able to code this up

[GeoffAWaddington]

Actually, had a quick look, probably best to move the code after the // ignore button releases in each of the Do Methods in SendMIDIMesage, and SendOSCMessage. I think, at first glance, those methods should be defined in Control Surface to do nothing. Then, they could be overridden in MIDIControlSurface and OSCControlSurface. Then the Action Do method would simply be 2 lines, the ignore button releases and the call to the Surface to SendMIDIMessage or SendOSCMessage.

…

On Apr 5, 2025, at 6:33 PM, rwallingford ***@***.***> wrote: rwallingford left a comment (FunkybotsEvilTwin/CSICode#23) Great thoughts Geoff. Since I have an X32 which is OSC and an XTouch which is MIDI, I should be able to code this up — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented. <#23 (comment)> <https://github.com/notifications/unsubscribe-auth/AGHT3WL374LQKWM6QR5FWZD2YBDZHAVCNFSM6AAAAAB2IGXUAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBRGEYDCOBQHA> rwallingford left a comment (FunkybotsEvilTwin/CSICode#23) <#23 (comment)> Great thoughts Geoff. Since I have an X32 which is OSC and an XTouch which is MIDI, I should be able to code this up — Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGHT3WL374LQKWM6QR5FWZD2YBDZHAVCNFSM6AAAAAB2IGXUAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBRGEYDCOBQHA>. You are receiving this because you commented.