View Issue Details

IDCategoryLast Update
0002488features2015-08-18 19:02
ReporterduffrecordsAssigned To 
Status acknowledgedResolutionopen 
Product Version2.7.1 
Fixed in Version 
Summary0002488: implement support for generic control surfaces that don't generate CC data
DescriptionI have a Roland SI-24 which integrates fairly well with Ardour, at least as far as the faders and transport buttons. However, the pan pots and jog wheel don't generate the sort of CC messages Ardour expects. When I trace the MIDI input, I see that they only generate two values--counterclockwise is 127 and clockwise is 1. So the pots can only pan hard left or hard right, and the jog wheel can only rewind or fast forward at maximum speed and can't stop. It would be nice to have a more flexible way of mapping controls. For instance, in Cubase each individual control can be assigned a channel and controller number, and it can further be set up as continuous, latched, or momentary.
TagsNo tags attached.

Users sponsoring this issue
Sponsors List Total Sponsorship = US$ 100

2009-02-07 19:33: duffrecords (US$ 90)
2009-04-20 09:13: spm_gl (US$ 10)
Users sponsoring this issue (Total Sponsorship = US$ 100)



2009-01-28 01:57

manager   ~0005648

I may even look at this after I can get rid of Quentin's bug with MIDI control. I agree it is useful, the main catch is of course how to handle the binding of controls, but should be doable.



2009-02-01 08:59

administrator   ~0005683

I don't even begin to understand how you want to see Ardour respond to these messages. The controller sends either 127 or 1 (notably not zero). What interpretation should be applied to that? Are you expecting ardour to starting ramping up the value of the controlled parameter? When would it stop? Please explain ...


2009-02-07 19:15

reporter   ~0005687

Last edited: 2009-02-07 20:11

For the record, I admit the implementation of this controller is not only cheap from a manufacturing standpoint, but counterintuitive (counting always starts with 0 in computer science). I wish I had known this prior to purchasing the device, but of course manufacturers typically publish only the most cursory hardware specifications.

My pan pots rotate continuously as a jog wheel does--that is, there is no mechanical limit at which point they stop. At each detent, they output a single value indicating whether the pot has been turned clockwise or counter-clockwise. The following is a bit of pseudocode which, I imagine, would allow the pots to function as they were intended. I'm not familiar with the Ardour code, so I'm making the potentially incorrect assumption that a track's pan position is represented by a 7-bit number, like it is in MIDI.

#define HARD_LEFT 0
#define CENTER 63
#define HARD_RIGHT 127

if ((controller_value == 127) && (pan_position != HARD_LEFT))
  pan_position -= 1;
else if ((controller_value == 1) && (pan_position != HARD_RIGHT))
  pan_position += 1;

The inelegant bit would be figuring out how to tell Ardour whether the controller outputs a normal range of values (such as 0-127) or merely two. Obviously this would be more complicated than the current Ctrl-middle-click method and would require an additional options menu.

As for the jog wheel, it also outputs 1 or 127 indicating it has moved either clockwise or counter-clockwise, respectively, to the next detent. I think its behavior should be dependent on the current state of the transport: If playback is stopped, moving the wheel to the next detent would increment the playhead position by a fixed amount. If it's playing or shuttling, it would increment the playhead speed by a fixed amount.


2009-02-07 20:11

reporter   ~0005688

When I mentioned Cubase in my original post, I meant to say that its control surface mapping is done in a separate window, which consists of a list of every programmable feature in the software (buttons, faders, knobs, even menu commands). Each feature can then be mapped to a controller number in a similar fashion to Ardour's Ctrl-middle-click method. The controller can then be further defined by specifying whether it is expected to behave as a continuous controller (0 through 127, like a fader), a momentary switch (my pan pots and jog wheel would fall into this category), or a latched switch (such as mute, solo, play, rewind, ff, etc.). One of the major advantages of this configuration is the flexibility to map an unused button to something that can't be Ctrl-middle-clicked, such as Undo or Zoom In or Zoom Out. Unfortunately, I'm not sure what would be the best way to determine the exact values generated by switches on different brands of surfaces. On/off might be represented by something logical like 127/0 or it might be 127/1 as Roland chose to do. Perhaps those values could be polarized:

controller_value = (controller_value > 63) ? 127 : 0;


2009-03-12 21:27

administrator   ~0005811

definitely v3.x stuff, where we have a much better codebase for generic "Controllables".


2009-03-12 22:48

developer   ~0005812

Are these values (127 & 1) constantly generated as you turn the control or does it just generate a single value when the control is initially turned and then silent for the rest of its motion?

If it's constantly generated then the time between the messages would give the speed and the value would give the direction. Quite sensible for a continuously variable controller I would have thought. This sort of thing would allow variable gearing of controls. Move it slowly get small increments, move it quickly get much coarser increments.

Just a thought.


2009-04-05 01:06

reporter   ~0005857

oofus, it's the first case you mentioned--as you turn the control it continues to generate a value at each tick. For instance, if you were to continuously turn the control counter-clockwise, you would see this in the terminal:


2009-04-06 23:26

manager   ~0005859

oofus you are dead on on all counts. I have been giving this some thoughts actually, it should be possible to automatically detect various types of controls without a complex dialog based on the pattern of MIDI received. If for instance all that is received is one unique message(For lack of a better term), it would bind to an incrememntal status. If two unique messages are received it would bind in a two way incremental status. If a range of messages are recieved ona single control, it would bind as appropriate as a CC etc. depending on the range received and control used. This could be expanded for more complex MIDI like the Logic protocol uses IIRC even.

Of course this is all only floating around in my head for the time being. Hopefully once I can start working on A3 on OS X over here I might look at implementing it, but it will depend on when that happens and how much else I have to work on.



2009-04-20 09:16

reporter   ~0005898

Have the same problem using our CS-10 (actually a CuePoint using Cs-10 emulation). The manual states the data is sent as twos-complement, I could post the details if it helps.


2009-04-20 15:30

reporter   ~0005899

It would be interesting to know what sort of messages your controller sends. Try tracing Ardour's MIDI input in a terminal and posting some details here. See the following post for more information:


2009-04-20 15:43

reporter   ~0005900

Last edited: 2009-04-20 15:45

Can't access the workstation at the moment, but I can quote the Manual:
"Technical Information about the Wheel in CS-10 Mode:
... The wheel count is in form of 2's Complement with bit 6 as the sign bit. Positive numbers are sent for clockwise rotation. The number sent represents the number of wheel counts accumulated since last transmission, (that is, a relative position count), much like what a mouse transmits. The resolution is approximately 144 counts per revolution, and transmissions are sent at about 10 millisecond intervals when the wheel is being turned."

The cc is 60h on channel 16, in the form "0BFh cc vv"


2009-04-23 10:26

reporter   ~0005903

The manual lies, it seems. Anyway, I had a friend hack the jackctlmmc app, off sourceforge. Now it works like a charm with my CS-10. The code ist available from his server at the moment, I'll put it up on sourceforge once I find the time. Here's the link:


2015-08-18 19:02

reporter   ~0017058

Now that Ardour 4 has been released, is anyone interested in taking a crack at this issue? I would happily increase my sponsorship amount if it meant I could finally use my control surface's pan pots.

Issue History

Date Modified Username Field Change
2008-12-11 02:18 duffrecords New Issue
2009-01-28 01:57 seablade Note Added: 0005648
2009-01-28 01:57 seablade Status new => acknowledged
2009-02-01 08:59 paul Note Added: 0005683
2009-02-07 19:15 duffrecords Note Added: 0005687
2009-02-07 19:33 duffrecords Sponsorship Added duffrecords: US$ 20
2009-02-07 19:33 duffrecords Sponsorship Total 0 => 20
2009-02-07 20:11 duffrecords Note Added: 0005688
2009-02-07 20:11 duffrecords Note Edited: 0005687
2009-03-12 21:27 paul Note Added: 0005811
2009-03-12 22:48 oofus Note Added: 0005812
2009-04-05 01:06 duffrecords Note Added: 0005857
2009-04-05 01:07 duffrecords Sponsorship Updated duffrecords: US$ 10
2009-04-05 01:07 duffrecords Sponsorship Total 20 => 10
2009-04-05 01:07 duffrecords Sponsorship Updated duffrecords: US$ 30
2009-04-05 01:07 duffrecords Sponsorship Total 10 => 30
2009-04-06 23:26 seablade Note Added: 0005859
2009-04-20 09:13 spm_gl Sponsorship Added spm_gl: US$ 10
2009-04-20 09:13 spm_gl Sponsorship Total 30 => 40
2009-04-20 09:16 spm_gl Note Added: 0005898
2009-04-20 15:30 duffrecords Note Added: 0005899
2009-04-20 15:43 spm_gl Note Added: 0005900
2009-04-20 15:45 spm_gl Note Edited: 0005900
2009-04-23 10:26 spm_gl Note Added: 0005903
2012-07-27 20:39 duffrecords Sponsorship Updated duffrecords: US$ 50
2012-07-27 20:39 duffrecords Sponsorship Total 40 => 60
2012-07-27 20:44 duffrecords Sponsorship Updated duffrecords: US$ 90
2012-07-27 20:44 duffrecords Sponsorship Total 60 => 100
2012-08-05 23:11 cth103 cost => 0.00
2012-08-05 23:11 cth103 Target Version => 3.X
2015-08-18 19:02 duffrecords Note Added: 0017058