I’m working on setting up TouchDAW (an Android application) that uses Mackie protocol with Ardour on Linux. In general things are working quite well.
There is some odd behaviour and I’m reaching out to find out if this is a bug or intentional. The short summary of the issue:
TouchDAW is connected to Ardour
TouchDAW is setup to use the main DAW control window (i.e. the mixer/transport/button view)
Bidirectional control between Ardour and TouchDAW is working as expected
In Ardour, select Window → MIDI Tracer, then select the “mackie control out” port
Now select the “Pan” button in TouchDAW
Non-stop “Channel Pressure” messages will now be flowing (one message for each active channel strip; if you disable the channel strip the message stops for that strip)
For example, with 2 channel strips (Audio 1 and Audio 2), the following sequence is non-stop:
If I disable all channel strips in Ardour, the messages stop. Also, if I select “Track” mode on TouchDAW, the messages stop.
Something seems to be triggering Ardour into this non-stop Channel Pressure message mode, only when “Pan” mode is selected via Mackie control.
Invoking Ardour with debug messages from the shell I’m seeing the following fragment repeated in the output log corresponding to the MIDI Trace messages:
DEBUG::MidiIO: midibuffer 0x5765c976b930 push event @ 0 sz 2 0xd0 0x0
DEBUG::MidiIO: midibuffer 0x5765c976b930 push event @ 0 sz 2 0xd0 0x10
DEBUG::MidiIO: MidiPort mackie control out 0x5765c976b930 pop event @ 0[mackie control out] (global 2415404, within 1024 gpbo 0 sz 2 0xd0 0x0
DEBUG::MidiIO: MidiPort mackie control out 0x5765c976b930 pop event @ 0[mackie control out] (global 2415404, within 1024 gpbo 0 sz 2 0xd0 0x10
I’m using Ardour 8.9, locally built.
Is this behaviour expected? I don’t have a real Mackie controller to test against. I did install TouchDAW on another mobile device and had the same result.
Huh, interesting. I looked at the “mackie control in” using the built-in MIDI Tracer and an external tracer, and I don’t see any messages flowing in while the output Channel Pressure messages are flowing.
It does feel like TouchDAW is sending something, but I’m struggling to see how it could be sending it.
I’m pretty confident now that the issue is not exclusive to Ardour. I just reproduced the exact same output results using Reaper, although I didn’t need to muck with the “Pan” button. Something else just triggered the non-stop messages, and they are behaving exactly as Ardour is – one Channel Pressure message per track.
I’m not familiar with Ardour’s code base, but the following backtrace is from a JACK session, triggered from a custom function I had put in to trap:
#1 0x00007ffff6db1a4f in ARDOUR::MidiBuffer::push_back (this=0x55555ed1dd70, time=0, event_type=Evoral::LIVE_MIDI_EVENT, size=2, data=0x7ffeb405a000 <incomplete sequence \320>)
at ../libs/ardour/midi_buffer.cc:184
#2 0x00007ffff6a64be6 in ARDOUR::AsyncMIDIPort::flush_output_fifo (this=0x55555ed516a0, nframes=1024) at ../libs/ardour/async_midi_port.cc:88
#3 0x00007ffff6a64d9d in ARDOUR::AsyncMIDIPort::cycle_start (this=0x55555ed516a0, nframes=1024) at ../libs/ardour/async_midi_port.cc:125
#4 0x00007ffff6f6aed8 in ARDOUR::PortManager::cycle_start (this=0x555557d92f20, nframes=1024, s=0x5555583040b0) at ../libs/ardour/port_manager.cc:1306
#5 0x00007ffff6aa5321 in ARDOUR::AudioEngine::process_callback (this=0x555557d92f20, nframes=1024) at ../libs/ardour/audioengine.cc:534
#6 0x00007fffec0c99a0 in ARDOUR::JACKAudioBackend::process_thread (this=0x555557a6cc80) at ../libs/backends/jack/jack_audiobackend.cc:929
#7 0x00007fffec0c98ec in ARDOUR::JACKAudioBackend::_process_thread (arg=0x555557a6cc80) at ../libs/backends/jack/jack_audiobackend.cc:904
#8 0x00007fffec7a964d in ??? () at /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so
#9 0x00007fffe71657b6 in ??? () at /lib/x86_64-linux-gnu/libpipewire-0.3.so.0
#10 0x00007ffff2e9ca94 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#11 0x00007ffff2f29c3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Something seems to be invoking the process_callback() with apparently bogus data. I tried with an ALSA connection as well, and got the same results. I’m suspecting Pipewire at this point.
After more digging, it turns out the constant Channel Pressure message per channel strip is not a bug. I think it’s expected behaviour, and the usage of the Pan button in my situation was unrelated/irrelevant.
When a channel strip is selected (via any means, and not in Track edit mode), the DAW LED signal level is sent to the surface controller (TouchDAW in this case). The signal level is specified using the MIDI Channel Pressure message.