Presonus Faderport on a Mac

I picked up a Presonus Faderport for fairly cheap on a whim, figured as a midi device it would probably work fine.

But of course I’m hitting some stumbling blocks getting it to work in Ardour on my mac. (Haven’t tried it on my main linux box yet.) I’ve read the manual, but the “generic midi” section isn’t written yet. I read the parts for other devices anyway for ideas.

The FaderPort has the latest flash updates, and has been tested with Reaper on the same machine… it works just fine.

I’ve tried connecting it up to ardour with midi patchbay.app a number of different ways, primarily mapping to all of the following… ardour_in, ardour_out, control_in, and control_out. Oddly enough when I crank the fader up to the top, the solo for the main track comes on. Other than that, nothing.

I tried following some instructions for assigning controls manually, but ran into a “no middle button on this mac, and no 3-button mouse in the house” problem. So I don’t know if that’d work or not if I get another mouse.

I experimented with seeing if it’d work in “mackie” mode, even though as far as I can tell the mackie protocol it supports is a different one than the one that works with the BCF2000. (I’m fuzzy on this HUI vs MCP or whatever business.) I was suprised to discover I was able to eliminate the error message I’d get when choosing “mackie”, by making some linux vs mac guesses when editing ardour.rc. But I wasn’t suprised when it didn’t work anyway.

I have googled for more info… the only useful hit points to another thread here (http://ardour.org/node/1354 ) where it is said that something was “clarified on IRC”. I actually posted to that same thread, but for some reason it doesn’t show up as recent anywhere, and I later noticed it was under the linux section so I was semi-off-topic there anyway. So I’m reposting under mac instead.

So I have a handful of questions, hopefully simple ones.

  • I’m not privy to whatever was clarified over irc… And am really curious. What was it?

  • Am I getting anywhere close with my efforts? Just pointing me in the right direction would help.

  • Is this product a likely dead end, or can it be made to work? I read on one hand that it is midi, and any midi gadget will work. But then I read other stuff about all kinds of problems with controllers.

  • Should I just return it and grab something already known to work? It’s not too late for that yet… and it looks like support for the TranzPort and AlphaTrack are much better. (Or might be soon?) And the BCF2000 in Mackie mode looks excellent. A bit bigger than what I was wanting, but it might work for me fine. I have 3 “stations” I want to be able to work from (behind the drumkit, middle of room, and on the desk) but a 15ft combo power/usb cable might be all it takes to reach all of them. (That’s around the limit for usb, right?)

Lastly, I just read another post about generic midi for another device, and how to get around the middle-click thing on a mac. I’ll be trying that tonight…

Thanks!

I’m not in the right frame of mind to comment on the whole story here, but let me just note that Ardour’s support for the Tranzport and Alphatrack are Linux specific. On OSX, the devices simply exist as devices that send (and to a limited extend, can receive) MIDI, and nothing more. To whatever extent it can emulate a Mackie Control Protocol device, then Ardours MCU support will work with it - check a very recent forum thread for notes on getting that set up.

The middle mouse button is kinda required in order to be able to do a small variety of things, the most notable is bind midi controls. So some of of using a 3 button mouse or emulating the middle mouse button would be needed in most cases. You could conceivably get around this by manually editing session files to include the bindings you need, but in most cases people understandably don’t want to do that and it is easier to spend $10 to get a three button mouse these days.

In as far as Mackie Protocol, what Ardour supports is the Logic Protocol. However there are many similarities between this and the actual Mackie Protocol, to the extent that something like the Faderport may work, for fader control and buttons, but the LCD probably won’t work. I would need traces of the fader and buttons to tell you for sure what would or would not work. They can be obtained via the “Trace MIDI” command in the options dialog for the MIDI tab, and the output is on the Console.app

Chances are, if the product can be put in a standard MIDI mode, where it just sends out standard MIDI CCs or similar, then it will work with the generic MIDI. There are limitations to what our generic midi can handle at the moment, but most of the time, standard MIDI control surfaces don’t run into them. They are limitations in dealing with some non-standard (At this time) ways of mapping controls to signals and a few more advanced things.

   Seablade

OK, I think I see a cause for some of the weirdness, perhaps all of it. And just now reading your post, you are right… it’s getting midi.

A note is being sent every few seconds. This is what makes the “operate controller now” dialog disappear so quickly. I’m positive that many times I thought I’d assigned a control, it had actually recieved that note and accepted it before I got my fingers to the controls. But even when I’m pretty sure I’ve beat it, the control doesn’t work. (Just trying the “play” button for now.) I’m never quite sure if it got my button/fader, or that repeating note.

I also think the fader jumping around may have been because that repeating note got assigned to the fader, and it must have been reacting to it as it was being sent.

It has to be coming from the FaderPort… tried on another machine with no midi anything else at all, and see the same thing from both the ardour midi trace and when using aseqdump:

ardour: control input: Channel 1 NoteOn NoteNum 0 Vel 127
aseqdump: 24:0 Note on 0, note 0, velocity 127

Speaking of aseqdump, I tried almost every single control (didn’t touch any of the 4 fader mode buttons) while running that, recording what I was doing and what the output was. When I tried doing the trace in ardour I saw it was doing the same thing, just the output is arranged differently of course. Would that be OK to send, or do you want me to do it over again in ardour? :slight_smile:

FWIW, here is what I was getting on startup…
ardour: [INFO]: Ardour will be limited to 1024 open files
loading system configuration file /etc/ardour2/ardour_system.rc
loading user configuration file /home/user/.ardour2/ardour.rc
ardour: [INFO]: No H/W specific optimizations in use
ardour: [INFO]: looking for control protocols in /home/user/.ardour2/surfaces/:/usr/lib/ardour2/surfaces/
ardour: [INFO]: Control protocol Tranzport not usable
powermate: Opening of powermate failed - No such file or directory
ardour: [INFO]: Control protocol powermate not usable
ardour: [INFO]: Control surface protocol discovered: “Generic MIDI”
ardour: [INFO]: Control surface protocol discovered: “Mackie”
==> session control, open existing (just one stereo track with imported audio)
loading bindings from /etc/ardour2/mnemonic-us.bindings
Loading session /home/user/ardourtest using snapshot ardourtest (1)
Loading history from ‘/home/user/ardourtest/ardourtest.history’.

Since it said it found mackie and didn’t complain about it (this is another box, vanilla ubuntu with built-in audio), I tried Mackie mode again… easily came on with no errors. None of the controls actually work, but I do get results from the trace… like this:

==> press and release “stop”
[b0 0f 0e] control for rotary [b0 0f 0e] is null
[b0 2f 43] control for rotary [b0 2f 43] is null
[b0 0f 0e] control for rotary [b0 0f 0e] is null
[b0 2f 03] control for rotary [b0 2f 03] is null

No matter what I hit or move, I get a set of messages like that (usually four). It’s always a similar pattern, like this:

[b0 0f “xx”] control for rotary [b0 0f “xx”] is null
[b0 2f “yy”] control for rotary [b0 2f “yy”] is null
[b0 0f “xx”] control for rotary [b0 0f “xx”] is null
[b0 2f “yy”] control for rotary [b0 2f “zz”] is null

Anyway, thanks! And I’ll send you that aseqdump version of my test run.

Hmm several things.

One the binding window shouldn’t disappear until you have operated a control. If it is disappearing earlier, then Ardour is getting a MIDI signal from somewhere.

The Trace will provide a log, you will need to annotate what you are doing in each section, but you can email it to me if you want… seablaede at gmail. Note the extra ‘e’ in the name.

From your descriptions of the fader, it sounds like it may be using a 14 Bit message, not a simple CC message, but that will be obvious from the trace log.

   Seablade

Thank you both, very much. Good to know. As for linux vs mac support, linux is more important to me. I just tried the mac first, since they provide drivers for it and I could test it with other stuff.

But I had to switch gears a bit anyway… The wife needed the macbook this evening, so I took it upstairs and plugged it into my main machine (rme hdsp, ubuntustudio, etc).

To my delight it was discovered just fine and was available in qjackctl to connect to. Started ardour from the console so I could see messages.

Trying to get it to work I tried two different approaches… generic midi and mackie. The results for generic were odd… I was able to middle click to assign controls, but the “operate control” dialog would dissapear very fast. Wasn’t sure if that mattered or not, but via holding ctrl w/my elbow (ha) I did make sure to operate the fader and transport buttons while it was still there each time.

Didn’t work, but it do some interesting things. After assigning the fader, the fader in ardour would behave erratically… Jumping all the way down, then to about -10, then back down for example. Sometimes when moving or even just touching the faderport control, but sometimes just changing focus to another strip. Couldn’t get anything consistent or repeatable though. Tried to do rec/mute/solo buttons, but they wouldn’t do anything at all. The transport buttons were weird. Assigned stop and play, and at one point they’d both work as a sort of “play”, but only if play had already been rolling. (Hitting either would make it jump back to wherever playback had originally started.)

Overall pretty weird and nonfunctional, but at least it is obviously talking to it at some level.

Trying to enable mackie mode hit a simple dead end. It kept saying on startup that the device was already in use, and then that it wasn’t defined (I suppose because it was busy, it wasn’t created or something… The lines were definitely in there and correct.)

Ran out of fiddling time… Will read up some more on getting the mackie mode further along. There is no lcd, so no worries about that. I don’t know if that will work in the end anyway… I’ve read that it does HUI, whatever that means. Not sure how that relates to MCP, whatever that is, or to Logic.

I managed to find the midi trace options… in the “windows” menu item, under “preferences”. Didn’t get a chance to try it yet though. I’m curious what is going on in generic midi mode to cause the odd behavior.

That leaves me with one question... is it normal or possible that the fader and pan pot do not send any midi data out unless they first know where they are, based on what they have coming in?

I actually would need to look it up, but no I do not believe this is the case. The fader I think always reports based on absolute position, and the pot only reports increment/decrement IIRC, at least in the Logic protocol that we follow, and I believe it is similar in the Mackie protocol as well, though would have to test.

At this point I'm trying to weigh the probability of this being made to work in the near future (maybe even attempting to fix it myself), against returning it and spending over double to get a slightly less convenient (sizewise) but immediately functional and well-supported BCF2000. It's not critical to have it right away or anything. Just trying to figure out what I'd be happier with now vs long run.

Well to be honest, I wouldn’t hold your breath on this working in the ‘near’ future. Unless John ducks in here, which has happened on occasion and is bored enough to work on it again, it will be a while before I get a chance, I have to many things on my plate lately that I need to finish up before I could start on this which would likely be rolled into a larger update to the code and MIDI in general hopefully, so probably not before A3. If you want to try it yourself feel free, Ill try to keep an eye out and test patches to make sure they don’t break anything existing in the logic protocol. But I won’t be able to get to it within 2 weeks certainly, it will likely be quite a bit longer for me.

  Seablade

PS That particular code(The Mackie Control) is a bit on the convoluted side and it can be hard to follow, so don’t feel frustrated if you can’t do so easily right off. One of my goals is to try to simplify it greatly, we will see if I get a chance.

Many thanks to seablade for looking at this, and questions answered. Most intriguing is one of his theories for lack of fader/pot and related functions... mackie mode in ardour is expecting a console with 8 channels, not one. So it could be sending commands to channels that simply don't exist on the faderport.

I haven’t looked at that code in a bit, and don’t have time to right now, but if memory serves I believe John coded in a check based off the value of the XML for the BCF which has 8 faders(No Master) and the Mackie which has 9(So it does have a master fader), but that is the extent of it. I don’t think the thought of a single fader controller using the same protocol ever crossed our mind.

   Seablade

I’ve been experimenting and poking around some more. I’m looking around in mackie_protocol.h (go easy on me if I’m way off, I’m not really a programmer!) and noticing the bits that appear to refer to ardour talking back to the unit.

The controls that do not respond to changes in ardour are all right here:

// strip/route related stuff
public:
/// Signal handler for Route::solo
void notify_solo_changed( Mackie::RouteSignal * );
/// Signal handler for Route::mute
void notify_mute_changed( Mackie::RouteSignal * );
/// Signal handler for Route::record_enable_changed
void notify_record_enable_changed( Mackie::RouteSignal * );
/// Signal handler for Route::gain_changed ( from IO )
void notify_gain_changed( Mackie::RouteSignal *, bool force_update = true );
/// Signal handler for Route::name_change
void notify_name_changed( void *, Mackie::RouteSignal * );
/// Signal handler from Panner::Change
void notify_panner_changed( Mackie::RouteSignal *, bool force_update = true );
/// Signal handler for new routes added
void notify_route_added( ARDOUR::Session::RouteList & );
/// Signal handler for Route::active_changed
void notify_active_changed( Mackie::RouteSignal * );

While this stuff works fine:

// global buttons (ie button not part of strips)
public:
// button-related signals
void notify_record_state_changed();
void notify_transport_state_changed();
// mainly to pick up punch-in and punch-out
void notify_parameter_changed( const char * );
void notify_solo_active_changed( bool );

Just looking at it kinda reflects differences in operation I’m seeing in sections of the unit. The “global” ones work well, including the buttons lighting up to match changes/clicks in ardour.

The “strip/route” ones function only partially or worse…
All of the ones using ( Mackie::RouteSignal * ) work, but don’t light up to match.
All of the ones using ( Mackie::RouteSignal *, bool force_update = true ) don’t work at all.

Looking elsewhere in there I get a rough idea of the organization and yeah… it looks like the stuff that relies on ardour talking back to it on a per-strip basis (showing mute/solo/red status) doesn’t work. But stuff that is just a simple command to Ardour from that strip (changing the mute/solo/rec status) does.

That leaves me with one question… is it normal or possible that the fader and pan pot do not send any midi data out unless they first know where they are, based on what they have coming in?

Nothing at all comes out of those controls in mackie mode, whether in ardour or just aseqdump. But I’ve seen them working fine in Reaper on the Mac, so… it’s gotta be something like that.

At this point I’m trying to weigh the probability of this being made to work in the near future (maybe even attempting to fix it myself), against returning it and spending over double to get a slightly less convenient (sizewise) but immediately functional and well-supported BCF2000. It’s not critical to have it right away or anything. Just trying to figure out what I’d be happier with now vs long run.

Haven’t made up my mind yet. I’ve still got a week or two, though. :slight_smile:

Thanks!

OK, I think we’ve got this thing partially figured out.

It can work in three modes. The best bet for making it work so far seems to be putting it in mackie control mode, then setting up ardour to talk to it as if it were a mackie mcu.

NATIVE MODE

Native mode appears to be proprietary… it generates midi messages, but they look like this:

==> press and release “play”
control input: Channel 1 Controller 15 Value 14
control input: Channel 1 Controller 47 Value 68
control input: Channel 1 Controller 15 Value 14
control input: Channel 1 Controller 47 Value 4

Worse, it generates the following midi note every few seconds (like a heartbeat), making it nearly impossible to attempt to assign controls manually in ardour. This “heartbeat” will be read and accepted by the “operate controller now” dialog before you get a chance to do it yourself. Then ardour will continue acting on that input every few seconds, until disconnected from the faderport.

control input: Channel 1 NoteOn NoteNum 0 Vel 127

Ignoring that heartbeat, most but not all of the buttons do generate their own midi messages. The fader only generates them for touch and release (it is touch sensitive). Movement does not result in any messages at all. Same goes for the pan knob and the mute/solo/rec buttons… no messages.

In short, “don’t even try to use this mode”.

HUI MODE

I know nothing of this mode other than some software uses it, and supposedly this device will switch to it automatically when told to by that software.

MACKIE CONTROL MODE

Hitting the right combination of keys puts the device in mackie control mode. The “heartbeat” goes away, and the midi messages look more normal, like this:

==> press and release “play”
control input: Channel 1 NoteOn NoteNum 94 Vel 127
control input: Channel 1 NoteOn NoteNum 94 Vel 0

The fader no longer sends touch and release messages, and still does nothing for movement. The pan knob still does nothing, but the mute/solo/rec buttons do send midi now. Not great, but potentially useful.

MAKING IT WORK

First you need to flash it with the latest firmware from Presonus. (I’m not sure the mackie mode exists as originally shipped.) This requires running a utility that comes with the mac and windows drivers.

Then plug it in, and change it to mackie control mode:

  • hold down “stop” until “output” and “undo” start blinking
  • pressing “output” will switch to mackie mode
  • pressing “undo” will cancel and stay in native mode
  • once in mackie control mode it will stay there until it is disconnected, at which point it will revert back to native mode.

Note: These instructions were found on page 15 of version 2 of the faderport manual, which is available on their website. The chapter title is “2.2.4 LIVE! Setup”, for working with Ableton Live! This section is not present in the original manual.

Now follow the instructions in the ardour manual for setting up a mackie mcu or bcf2000. http://ardour.org/files/manual/sn-mackie.html

Now start up ardour. Do not manually connect any midi in qjackctl or midi patchbay.app, it’ll be connect automatically.

Under “options-control surfaces”, make sure “generic midi” is not checked, and check “mackie”.

Now you have a semi-functional FaderPort, with the following caveats:

  1. No fader. Sorry.
  2. No pan. Bummer.
  3. Mute/Solo/Rec buttons don’t light up, even though they work
  4. Ardour and the Faderport don’t follow each other when selecting tracks
  5. The four window view buttons don’t do anything
  6. The four fader mode buttons don’t do anything
  7. The mark button doesn’t seem to work

Other than that, all good to go! Which means at least in linux, it is currently good as a nice transport pad with wonderful (and colorful) buttons… but not much else. :slight_smile:

Haven’t tested it in mackie control mode on my mac yet. Haven’t tested it with mackie emulation set to bcf, either.

Thanks paul for pointing at mackie control mode… at the time I wasn’t sure if the device truly had that mode, but it turns out after a flash update and new manual, it does.

Many thanks to seablade for looking at this, and questions answered. Most intriguing is one of his theories for lack of fader/pot and related functions… mackie mode in ardour is expecting a console with 8 channels, not one. So it could be sending commands to channels that simply don’t exist on the faderport.

Hopefully it is something like that, and not something unfixable with the way the faderport works.

Years later, I discover that the Faderport is a HUI-emulating device and thus there’s no particular reason to expect it to work with Ardour at all, except to the extent that Mackie Control was inspired by HUI and overlaps with it in a few places. This may change …