Patch Data

[M1DHB]

Thank you for your help and ongoing support of the really useful POD-UI.

I've been able to set up my PODxt with Pod UI and a Paint Audio Midi Captain 10 foot switch. the Footswitch is running Midi Captain has Midi-Captain-Max firmware which is bidirectional. It is very programmable and works really well.

The Footswitch LEDs and the PC patch change numbers synchronize with changes on the PODxt and Pod UI.

The only thing missing is that when POD-UI or the PODxt exchange patches the LED's on the Midi footswitch can't synchronise. Since the SysEx data stream that is sets up POD-UI or the PODxt contains (I'm assuming) a packed set of CC values the Footswitch doesn't recognise them.

I wondered if you can tell me how the CC data is formatted for the Patch transfer or where to look for the information?

Also I wondered if POD-UI could output the raw CC values after a patch is changed? What do you think?

Thanks Again

[arteme]

Wow, nice setup! The PODxt patch dump does indeed contain packed data and it is pretty straight-forward. The patch data comes as a SysEx message:
0xf0, 0x00, 0x01, 0x0c, 0x03, 0x74, <id>, <160 bytes of data>, 0xf7

The PODxt controls are described here: https://github.com/arteme/pod-ui/blob/master/mod-xt/src/config.rs#L200, the interesting parts for you are cc: ... and addr: .... Actually, you almost do not need the addr: ... bit since for PODxt it is always <CC value> + 32. This way you can cherry-pick the control value you would like to track from the <160 bytes of data>.

For example, the "reverb enable" toggle is CC 36, address 32 + 36 = 68. That will be byte 68 in the data part of the message, and since data starts on byte 7 of the SysEx message, is will be byte 75 of the message.

Of course, pod-ui can also be rigged to output specific CC values after an patch load if you like...

[M1DHB]

Of course, pod-ui can also be rigged to output specific CC values after an patch load if you like...

Thank you for your quick reply.
If pod-iu could output the cc for the toggle settings when a patch change updates the UI that would be awesome.

I currently have Compressor, Stomp, Mod, Delay, Gate, EQ & Reverb controlled from the Midi Captain Footswitch.

The Midi Captain LED responds to the incoming midi that matches its Button Config. It ignores the rest.

Here is the Reverb config

Since sending the same CC value twice (for example CC 26 127 "Reverb ON") doesn't cause a conflict if Reverb is already ON it should work OK (in theory :)

I hope this is possible. The pod-ui and midi-captain-max really work well together. It makes the PODxt amazing to use.

[M1DHB]

I've been looking for some kind "on the fly" midi translator to capture reconfigure and send the extracted CC.
I think something could possibly be done in Python with the mido library but I doubt it I could code anything that would be robust enough to really be useful.
The only elegant way is within pod-ui and my programming skills are not anywhere close to good enough.

[arteme]

Thank you for the idea. While I add this to pod-ui itself, here's a python script that does extraction (using mididings package)
podxt-sysex-to-cc.py

After you run this, don't forget to connect the MIDI in/out pair (for me, this is displayed as "mididings" "in_1"/"out_1") to the respective in/outs on your computer.

One thing, though. How do you synchronize or program change? A PC message on its own doesn't trigger a "get edit buffer" sysex message...

[M1DHB]

Thank you for the podxt-sysex-to-cc.py. I will give it a try. I'm setting up pod-ui on a linux machine (I currently run it on Windows 11) but I I don't think mididings is available on Windows.

Re triggering the "get edit buffer" sysex message. I initially thought of just using the Load Patch or get Edit buffer button on pod-ui.
I thought that would at least be able to set all the LED's with on button.
TouchOSC can send Sysex messages and the Midi Captain MAX might do it in the future.

My first step is the extraction. So I'm looking forward to trying podxt-sysex-to-cc.py.

A little bit of python to listen for a PC in the range 0-126 which sends the Load Patch Sysex string might work. I think I'll give that a try.

Thanks for your support.

[arteme]

You can modify the run(...) part of the script to send a "get edit buffer" sysex message on program change events:

run([
    SysExFilter(PODXT_DUMP_HEADER) >> Process(extract_ccs),
    Filter(PROGRAM) >> SysEx([0xf0, 0x00, 0x01, 0x0c, 0x03, 0x75, 0xf7])
])

[M1DHB]

That looks great, thank you for your help.
I'm not making much progress because I've been plunged into networking chaos by a change in Internet Service Provider :(

[M1DHB]

You can modify the run(...) part of the script to send a "get edit buffer" sysex message on program change events:

run([
    SysExFilter(PODXT_DUMP_HEADER) >> Process(extract_ccs),
    Filter(PROGRAM) >> SysEx([0xf0, 0x00, 0x01, 0x0c, 0x03, 0x75, 0xf7])
])

Thank you for these scripts. I added the modification to run as you kindly suggested and it works really well :)

It took me some time to get the script working on my Linux Laptop as mididings isn't available on Windows. I just worked through the errors etc to get the mididings dependencies resolved. It was a good workout for me as using uv was new and I was able to become more familiar with the linux midi tools like midisnoop and QjackCtl for the routing.

I really appreciate your help.
Thanks Again