Presonus Faderport 2 Trouble

Hello there, can somebody please help me track down a problem with my Faderport-2?

I have a Presonus Faderport-2 connected and configured as active control surface in Ardour. I get MIDI events from it, seen in the MIDI tracer.

And it works PARTIALLY: hitting the Faderport’s “Prev” Button, the track above gets selected as expected, the fader moves on the device.

But hitting the “Next” Button does NOT work: in master mode (“master” button is lit) it just does nothing that I can see. But when in section mode (“section” button is lit), Ardour becomes unresponsive and crashes (dumps core).

I get this behaviour with Ardour-6.9 as well as Ardour-7.1.

Now, I already opened a bug report a while back (#8960) but as it seems that the Faderport is generally regarded to be working perfectly I think it has to be a problem with my system in particular, and I might as well try to narrow it down myself. Or even solve it, I’d like to use the Faderport!

But I’ll need some help, as I have no idea where I should start looking.

What could be causing these crashes? How do I narrow the cause down?

Please, any hint is appreciated! And please ask me anything you’d like to know. I’ll start with basic system information and the top of the stack trace from the core dump.

Ubuntu 20.04.5 LTS 64-bit
GNOME 3.36.8
Ardour versions 6.9 & 7.1
Using ALSA backend with raw MIDI (but already tried with external JACK and different MIDI systems)

 #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
         set = {__val = {0, 139858285922192, 12, 139858285922112, 46979119, 139858280672758, 206158430256, 139857221379816, 139857221379616, 7339277407984162304, 139857221379632, 7339277407984162304, 46979119, 94513459997787, 1, 101}}
         pid = <optimized out>
         tid = <optimized out>
         ret = <optimized out>
 #1  0x00007f334b1f7859 in __GI_abort () at abort.c:79
         save_stage = 1
         act = {__sigaction_handler = {sa_handler = 0x7f334b738740, sa_sigaction = 0x7f334b738740}, sa_mask = {__val = {94513464508408, 0, 0, 0, 0, 0, 0, 139858285952224, 24, 139857221380048, 0, 139857221380096, 94513449172859, 139858285905072, 6, 0}}, sa_flags = 4098, sa_restorer = 0x7f3300000000}
         sigs = {__val = {32, 0 <repeats 15 times>}}
 #2  0x00007f332f43b1c4 in ArdourSurface::FP2::FaderPort8::encoder_navigate(bool, int) () from /opt/Ardour-7.1.0/lib/surfaces/
 No symbol table info available.
 #3  0x00007f332f3fa4ea in ArdourSurface::FP2::FaderPort8::controller_handler(MIDI::Parser&, MIDI::EventTwoBytes*) () from /opt/Ardour-7.1.0/lib/surfaces/
 No symbol table info available.
 #4  0x00007f3353962113 in PBD::Signal2<void, MIDI::Parser&, MIDI::EventTwoBytes*, PBD::OptionalLastValue<void> >::operator()(MIDI::Parser&, MIDI::EventTwoBytes*) () from /opt/Ardour-7.1.0/lib/
 No symbol table info available.
 #5  0x00007f335395c973 in MIDI::Parser::signal(unsigned char*, unsigned long) () from /opt/Ardour-7.1.0/lib/
 No symbol table info available.
 #6  0x00007f335395cda4 in MIDI::Parser::scanner(unsigned char) () from /opt/Ardour-7.1.0/lib/
 No symbol table info available.
 #7  0x00007f3353fb4de4 in ARDOUR::AsyncMIDIPort::read(unsigned char*, unsigned long) () from /opt/Ardour-7.1.0/lib/
 No symbol table info available.
 #8  0x00007f3353fb3567 in ARDOUR::AsyncMIDIPort::parse(long) () from /opt/Ardour-7.1.0/lib/
 No symbol table info available.
 #9  0x00007f332f3fa624 in ArdourSurface::FP2::FaderPort8::midi_input_handler(Glib::IOCondition, boost::weak_ptr<ARDOUR::AsyncMIDIPort>) () from /opt/Ardour-7.1.0/lib/surfaces/
 No symbol table info available.

Is the device in Studio One mode?

For me (Linux, Ardour 6.9 & 7.0) Section > Next shows in Ardour’s MIDI Trace (decimal) as:
NoteOn chn 1 47 127
NoteOff chn 1 47 64
Section > Prev is note 46.
Channel > Next/Prev is the same as above, whereas your bug report says Next is note 25 for you. And Section > Prev for you is controller 60 not note 47. That strikes me as the device transmitting the wrong things, which suggests it’s in the wrong mode. But I’m no expert.

It works for me. I had to do a firmware upgrade on mine when I first bought it, but that’s because I couldn’t get it to work at all without it.

1 Like

Thank you very much for your reply!

The device is pretty much in “out of the box” state, so it being in a different mode is a very valid assumption. (Because it mostly worked I figured I was good with respect to firmware and basic setup. But maybe the different modes of operation are just almost, but not completely totally unlike each other…)

I’m hoping to find some time later to give it a whirl trying to set the mode, and see what happens. If not today, then surely at the coming weekend.

(It would be great if my bug report could concentrate on “Ardour shouldn’t crash” and this thread on “getting it to work for secke”. I’m hopeful.)

Fingers crossed but Studio One mode should be the “out of the box” state.

Hell yeah, it worked!

I’m a little embarrassed now because I didn’t think to try this before, but I’m also happy and relieved.

I think the device is probably one that got returned to the vendor, so somebody had likely already updated the firmware and switched modes.

I’m a little short on time right now, just wanted to give a quick update and show my gratitude to you, @johndev – thanks a lot, again.

I promise to post some details on the weekend, to wrap this thread up for posteriority.

1 Like

This problem is solved. Switching the device to “Studio One” mode made it work as expected.

(How to switch to Studio One mode: power the Faderport off, press and hold “Next” while switching it back on, buttons start blinking, hit “Solo”. That’s it.)

In short: when some of the controls on your Faderport work, but others don’t, or you even get a crash after pressing something, try switching to Studio One mode.

It seems my device was in one of the “MCU” modes (the Faderport manual names them “Logic”, “Cubase/Nuendo” and “Live”), as can be gleaned from the MIDI messages that are sent when the “Next” button is pressed. (I got the 19 7f / 19 40 sequence when I wrote my bug report #8960.)

The following snippets have been copied directly from Ardour’s MIDI tracer (Window→MIDI Tracer, Port: Presonus/midi_in 1). Each shows the captured events when simply pressing and releasing the “Next” button on the Faderport.

This is good (Studio One mode):

     5983875          NoteOn chn  1 2f 7f
     6006923         NoteOff chn  1 2f 40

This is bad (one of the three MCU modes):

     2494083          NoteOn chn  1 19 7f
     2494083         NoteOff chn  1 19 40

This is probably also bad (Pro Tools HUI mode):

     2698916      Controller chn  1 0f 01
     2698916      Controller chn  1 2f 41
     2698917      Controller chn  1 0f 01
     2698923      Controller chn  1 2f 01
     2709195          NoteOn chn  1 00 7f
     2805255          NoteOn chn  1 00 7f
     2901224          NoteOn chn  1 00 7f
     2997224          NoteOn chn  1 00 7f
     3093192          NoteOn chn  1 00 7f
     3189255          NoteOn chn  1 00 7f
     3285223          NoteOn chn  1 00 7f
     3381287          NoteOn chn  1 00 7f
     3477288          NoteOn chn  1 00 7f
     3573256          NoteOn chn  1 00 7f
     ... (device keeps sending this NoteOn event) ...