MIDI on Windows with Program Change does nothing on Pedalboards or Snapshots

[raidolo]

Hi,

I've downloaded the latest build from the github actions, as suggested to enable MIDI on Windows.
Apparently Program Change commands does nothing.

I've tried to switch channels also, but without luck.

I?m not able to switch Pedalboards or Snapshots.

I send these commands on channel 1 and 2: PC 0, PC 1, PC 2, PC 3

The mod host and jackd verbose log show this for Channel 1:

PROTOCOL: response 'resp 0'
Jack: JackWinMMEInputPort::EnqueueMessage - enqueueing event at 1589830.981000 (frame: 4418425) with start offset '92063' scheduled for frame '4418421'
Jack: JackWinMMEInputPort::EnqueueMessage - enqueueing event at 1591071.851000 (frame: 4477975) with start offset '93303' scheduled for frame '4477929'
Jack: JackWinMMEInputPort::EnqueueMessage - enqueueing event at 1592002.796000 (frame: 4522653) with start offset '94235' scheduled for frame '4522658'
Jack: JackWinMMEInputPort::EnqueueMessage - enqueueing event at 1592805.869000 (frame: 4561201) with start offset '95038' scheduled for frame '4561202'

Instead for channel 2 it shows this:

DEBUG: RunPostPonedEvents() START
DEBUG: RunPostPonedEvents() Before the queue iteration
DEBUG: RunPostPonedEvents() Sending 'midi_program_change 0 1'
DEBUG: RunPostPonedEvents() After the queue iteration
DEBUG: RunPostPonedEvents() Sending 'data_finish'
DEBUG: RunPostPonedEvents() END
DEBUG: PostPonedEventsThread() looping (code 1)
PROTOCOL: received 'output_data_ready'
DEBUG: effects_output_data_ready() UI is ready to receive more stuff (code 0)
DEBUG: RunPostPonedEvents() START
DEBUG: RunPostPonedEvents() Queue is empty
DEBUG: PostPonedEventsThread() looping (code 1)
PROTOCOL: response 'resp 0'
Jack: JackWinMMEInputPort::EnqueueMessage - enqueueing event at 1566663.474000 (frame: 3306504) with start offset '68895' scheduled for frame '3306476'
DEBUG: RunPostPonedEvents() START
DEBUG: RunPostPonedEvents() Before the queue iteration
DEBUG: RunPostPonedEvents() Sending 'midi_program_change 1 1'
DEBUG: RunPostPonedEvents() After the queue iteration
DEBUG: RunPostPonedEvents() Sending 'data_finish'
DEBUG: RunPostPonedEvents() END
DEBUG: PostPonedEventsThread() looping (code 1)
PROTOCOL: received 'output_data_ready'
DEBUG: effects_output_data_ready() UI is ready to receive more stuff (code 0)
DEBUG: RunPostPonedEvents() START
PROTOCOL: response 'resp 0'
DEBUG: RunPostPonedEvents() Queue is empty
DEBUG: PostPonedEventsThread() looping (code 1)
Jack: JackWinMMEInputPort::EnqueueMessage - enqueueing event at 1567848.355000 (frame: 3363369) with start offset '70081' scheduled for frame '3363395'
DEBUG: RunPostPonedEvents() START
DEBUG: RunPostPonedEvents() Before the queue iteration
DEBUG: RunPostPonedEvents() Sending 'midi_program_change 2 1'
DEBUG: RunPostPonedEvents() After the queue iteration
DEBUG: RunPostPonedEvents() Sending 'data_finish'
DEBUG: RunPostPonedEvents() END
DEBUG: PostPonedEventsThread() looping (code 1)
PROTOCOL: received 'output_data_ready'
DEBUG: effects_output_data_ready() UI is ready to receive more stuff (code 0)
PROTOCOL: response 'resp 0'
DEBUG: RunPostPonedEvents() START
DEBUG: RunPostPonedEvents() Queue is empty
DEBUG: PostPonedEventsThread() looping (code 1)
Jack: JackWinMMEInputPort::EnqueueMessage - enqueueing event at 1570525.147000 (frame: 3491841) with start offset '72757' scheduled for frame '3491829'
DEBUG: RunPostPonedEvents() START
DEBUG: RunPostPonedEvents() Before the queue iteration
DEBUG: RunPostPonedEvents() Sending 'midi_program_change 3 1'
DEBUG: RunPostPonedEvents() After the queue iteration
DEBUG: RunPostPonedEvents() Sending 'data_finish'
DEBUG: RunPostPonedEvents() END
DEBUG: PostPonedEventsThread() looping (code 1)
PROTOCOL: received 'output_data_ready'
DEBUG: effects_output_data_ready() UI is ready to receive more stuff (code 0)
DEBUG: RunPostPonedEvents() START
DEBUG: RunPostPonedEvents() Queue is empty
DEBUG: PostPonedEventsThread() looping (code 1)

Is seems it reacts like in Linux, MIDI Channel 2 is in reality Channel 1 for ModHost

Let me know how can I help.

Cheers.

[raidolo]

Just to confirm that in Linux I'm able to switch at least the snapshots.
On my midi pedal I use channel 1 Program Change for pedalboards and channel 2 Program Change for Snapshots, I see this from the debug when using channel 2 for the snapshots:

PROTOCOL: response 'resp 0'
DEBUG: RunPostPonedEvents() START
DEBUG: RunPostPonedEvents() Before the queue iteration
DEBUG: RunPostPonedEvents() Sending 'midi_program_change 0 1'
DEBUG: RunPostPonedEvents() After the queue iteration
DEBUG: RunPostPonedEvents() Sending 'data_finish'
DEBUG: RunPostPonedEvents() END
DEBUG: PostPonedEventsThread() looping (code 1)
PROTOCOL: received 'bypass' '0' '0'
PROTOCOL: response 'resp 0'
PROTOCOL: received 'output_data_ready'
DEBUG: effects_output_data_ready() UI is ready to receive more stuff (code 0)
DEBUG: RunPostPonedEvents() START
DEBUG: RunPostPonedEvents() Queue is empty
DEBUG: PostPonedEventsThread() looping (code 1)
PROTOCOL: response 'resp 0'
PROTOCOL: received 'output_data_ready'
DEBUG: effects_output_data_ready() UI is ready to receive more stuff (code 1)
PROTOCOL: response 'resp 0'
DEBUG: RunPostPonedEvents() START
DEBUG: RunPostPonedEvents() Before the queue iteration
DEBUG: RunPostPonedEvents() Sending 'midi_program_change 1 1'
DEBUG: RunPostPonedEvents() After the queue iteration
DEBUG: RunPostPonedEvents() Sending 'data_finish'
DEBUG: RunPostPonedEvents() END
DEBUG: PostPonedEventsThread() looping (code 1)
PROTOCOL: received 'bypass' '0' '1'
PROTOCOL: response 'resp 0'
PROTOCOL: received 'output_data_ready'
DEBUG: effects_output_data_ready() UI is ready to receive more stuff (code 0)
DEBUG: RunPostPonedEvents() START
DEBUG: RunPostPonedEvents() Queue is empty
DEBUG: PostPonedEventsThread() looping (code 1)
PROTOCOL: response 'resp 0'
PROTOCOL: received 'output_data_ready'
DEBUG: effects_output_data_ready() UI is ready to receive more stuff (code 1)

When I send Program Change on channel 1 nothing is logged.

[falkTX]

What is the result here with the latest GH action builds?

MIDI was broken on windows, but that was fixed. with the latest build we should have even screenshots working now.
confirmation would be very welcome, though I plan to test this myself too soon enough.

NOTE: on macos and windows the MIDI devices are only scanned on start, there is no hotplug support for MIDI (exception is Linux builds)

[falkTX]

please try with 0.0.3 release https://github.com/moddevices/mod-app/releases/tag/0.0.3
thanks

[raidolo]

Testing commit f652eef on Windows 11.
Snapshot works fine on MIDI channel 2, below you can see the debug log of a successful snapshot loading via MIDI CH2 PC 0
I've configured MIDI Channel 1 for pedalboards, at the end of the log you'll see a a bunch of MIDI CH1 PC 0 messages, starting at this line:

Jack: JackWinMMEInputPort::EnqueueMessage - enqueueing event at 1384939.759000 (frame: 4536652) with start offset '94525' scheduled for frame '4536639'

I've tried to change the snapshot channel in the gui, just to see if it was correctly evaluated and it is, if you configure the wrong channel the snapshots won't switch. and I have the same message I got for the pedalboards on channel 1, only messages starting with:

Jack: JackWinMMEInputPort::EnqueueMessage

Like something arrives on but it's not evaluated (my guess sorry I didn't dig into the code yet)

DEBUG: RunPostPonedEvents() START
DEBUG: RunPostPonedEvents() Before the queue iteration
DEBUG: RunPostPonedEvents() Sending 'midi_program_change 0 1'
DEBUG: RunPostPonedEvents() After the queue iteration
DEBUG: RunPostPonedEvents() Sending 'data_finish'
DEBUG: RunPostPonedEvents() END
DEBUG: PostPonedEventsThread() looping (code 1)
PROTOCOL: received 'param_set' '0' 'level' '-11.304348'
PROTOCOL: response 'resp 0'
PROTOCOL: received 'patch_set' '0' 'https://mod.audio/plugins/CabinetLoader#irfile' 'C:\\Users\\raido\\OneDrive\\Documents\\MOD App\\user-files\\Speaker Cabinets IRs\\Mesa_OS_4x12_57_m160.wav'
PROTOCOL: response 'resp 0'
PROTOCOL: received 'patch_set' '1' 'http://github.com/mikeoliphant/neural-amp-modeler-lv2#model' 'C:\\Users\\raido\\OneDrive\\Documents\\MOD App\\user-files\\NAM Models\\Brunetti XL\\Brunetti XL Clean.nam'
PROTOCOL: response 'resp 0'
PROTOCOL: received 'param_set' '4' 'gain' '-0.100446'
PROTOCOL: response 'resp 0'
Thread setup with realtime priority successful
PROTOCOL: received 'param_set' '4' 'HPfreq' '37.506890'
PROTOCOL: response 'resp 0'
�[30;1mStaging model change: `C:\\Use�[0m
PROTOCOL: received 'param_set' '4' 'HPQ' '0.078125'
PROTOCOL: response 'resp 0'
PROTOCOL: received 'param_set' '4' 'LPfreq' '8235.938815'
PROTOCOL: response 'resp 0'
PROTOCOL: received 'param_set' '4' 'LPQ' '0.644531'
PROTOCOL: response 'resp 0'
PROTOCOL: received 'param_set' '4' 'q3' '1.108398'
PROTOCOL: response 'resp 0'
PROTOCOL: received 'param_set' '4' 'gain3' '4.660714'
PROTOCOL: response 'resp 0'
PROTOCOL: received 'output_data_ready'
DEBUG: effects_output_data_ready() UI is ready to receive more stuff (code 0)
DEBUG: RunPostPonedEvents() START
DEBUG: RunPostPonedEvents() Before the queue iteration
DEBUG: RunPostPonedEvents() Sending 'patch_set 1 http://github.com/mikeoliphant/neural-amp-modeler-lv2#model p C:\\Users\\raido\\OneDrive\\Documents\\MOD App\\user-files\\NAM Models\\Brunetti XL\\Brunetti XL Clean.nam'
PROTOCOL: response 'resp 0'
DEBUG: RunPostPonedEvents() After the queue iteration
DEBUG: RunPostPonedEvents() Sending 'log 0 Staging model change: `C:\\Use'
DEBUG: RunPostPonedEvents() Sending 'data_finish'
DEBUG: RunPostPonedEvents() END
DEBUG: PostPonedEventsThread() looping (code 1)
PROTOCOL: received 'output_data_ready'
DEBUG: effects_output_data_ready() UI is ready to receive more stuff (code 0)
DEBUG: RunPostPonedEvents() START
DEBUG: RunPostPonedEvents() Queue is empty
DEBUG: PostPonedEventsThread() looping (code 1)
PROTOCOL: response 'resp 0'
Jack: JackWinMMEInputPort::EnqueueMessage - enqueueing event at 1384939.759000 (frame: 4536652) with start offset '94525' scheduled for frame '4536639'
Jack: JackWinMMEInputPort::EnqueueMessage - enqueueing event at 1387407.229000 (frame: 4655071) with start offset '96992' scheduled for frame '4655035'
Jack: JackWinMMEInputPort::EnqueueMessage - enqueueing event at 1387871.522000 (frame: 4677357) with start offset '97457' scheduled for frame '4677355'
Jack: JackWinMMEInputPort::EnqueueMessage - enqueueing event at 1388280.511000 (frame: 4696988) with start offset '97866' scheduled for frame '4696986'

[falkTX]

there was an issue where opening the web gui and closing it invalidated the MIDI program setup, corrected in 0.0.5
so please try the last release to confirm the potential fix, thanks!

[raidolo]

What's the potential fix? Does that mean that now the pedalboards switching should work?

[falkTX]

loading the webgui and closing would turn off midi program listening, it was only enabled momentarily.

[raidolo]

Hey @falkTX any news on the Pedalboard switching via MIDI? I'm only able to switch the snapshots using MIDI Channel 2 at the moment.

[falkTX]

I thought that was working already with the last few releases, which one did you test with?

[raidolo]

I thought that was working already with the last few releases, which one did you test with?

I believe it was 0.0.11, I'll test again the 0.0.12 but since I didn't see any changes in the commits regarding that, I was assuming that part didn't change. I'll let you know tomorrow, I'll test both windows and Linux releases, just in case.

[raidolo]

Hi @falkTX,

I've tested both Windows and Linux with 0.0.12.
The Program Change MIDI command on channel 1 are not even logged in the debug log of MOD UI.
For the Snapshot on channel 2 I got this in the log:

DEBUG:root:[host] received <- 'midi_program_change 2 1'

And the snapshots changes correctly.

I know that the program change sent by my MIDI controller works fine, cause I'm using them in my modified Mod UI.
If you want to take a look at what I've changed in the Mod UI to get them to work to switch the pedalboards, have a look at this commit: mod-audio/mod-ui@a8b956a

It's a bit rudimental, I'm not a programmer, and the pedalboard name does not get refreshed when I switch from one to another. This cause some glitches when you want to save the pedalboard, you need to refresh the UI page first, otherwise bad things happen :) (I've also opened an issue regarding this in the mod-ui repo, regardin the load_bundle )

Could you please help on this?
If you need something from my side just ask...