View Issue Details
|ID||Category||Date Submitted||Last Update|
|0002488||features||2008-12-11 02:18||2015-08-18 19:02|
|Fixed in Version|
|Summary||0002488: implement support for generic control surfaces that don't generate CC data|
|Description||I 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.|
|Tags||No tags attached.|
|Users sponsoring this issue|
Total Sponsorship = US$ 100
2009-02-07 19:33: duffrecords (US$ 90)
2009-04-20 09:13: spm_gl (US$ 10)
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.
||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 ...|
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.
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;
||definitely v3.x stuff, where we have a much better codebase for generic "Controllables".|
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.
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:
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.
||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.|
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:
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"
||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: http://nichtcool.de/dl/dev/jackctlmmc-cc.zip|
||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.|
|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|