Control Surface Integration

Instructed by the Mixbus User Forum to share this here to bring to the attention of Ardour Developers, given that Ardour underpins MB.

Took some time this weekend to explore the improvements in MB12 related to integration between the software and a control surface. And while there is greater functionality than what was in MB11, overall it is a huge disappointment and can, at best, only be assessed as half-baked. One would hope, and think, that Harrison isn’t aiming for a reputation as creators of a half-baked DAW – the steady improvement to this point says otherwise.

MB12 represents a substantial improvement, but control surface integration is woefully deficient. As implemented, it renders the control surfaces role to secondary status (a useless desk object) behind the mouse and keyboard, the very thing adding a control surface to the mix is seeking to overcome.

And it comes down to what are the most fundamental and essential functions one should expects to occur intuitively and instinctively when using a surface controller. DAWs controlled by the simplest surface controller should support the following: fader banking (banks and channel), transport control, volume control, muting and selecting, and pan control. From that list, fader banking – effective and predictable – is foundational to all other functions, because it aligns the controller to the DAW software, and vise-versa, so the user is not guessing or searching to identify which fader correspond to the tracks present on the screen, nor needing to take unnecessary additional step to bring the two object in alignment. Unfortunately, it is exactly this critical foundation that MB12 fails to establish.

It must be agreed that the following scenario that user now experience with MB12 is ridiculous and nonsensical: A user can use his control surface to bank 24 channel, and in the case of a controller with flying faders and channel strips displaying track names, channels on the control surface are updated with track data, but the screen stays static. And only after the user selects a track is the software screen changed, but the selected track positions on screen is misaligned with controller, and being shown are channels unrelated to the bank in focus on the control surface – e.g. the leftmost channel on the screen does not match that on the controller. At times, what is showing on channel 1 on the controller can be 15 or more tracks to the right on the screens. That’s the MB experience MB user are being asked to accept. Sorry, that’s madness.

Here is a rough possible algorithm that demonstrated what’s desired and could be a fix. Regardless of how large a screen or controller one is using, navigation of the software with a controller lead to one to one coordination of both components, by always aligning the left channels of the controller and screen – not by haphazardly highlighting track, but by creating consistent, predictable performance of the controller and software.

lowBank = 1;
if totalTracks > totalControllerChannels then
highBank = abs(totalTracks / totalController Channels);
else highBank = 1;

function ShiftBankFull (Bank)
{
if Bank.direction == left then {
if Bank.bankInFocus == lowBank then { //check for low limit
exit; //do nothing if there are no more tracks to show
}
else {
Bank.bankInFocus = Bank.bankInFocus - 1;
Bank.leftMostChannel = totalControllerChannels * (Bank.bankInFocus - 1) + 1;
bankTo(Bank.LeftMostChannel);
}
}
else {
if Bank.bankInFocus == abs(Project.totalTracks / Controller. totalControllerChannels) then { // check for high limit
exit;
}
else {
Bank.leftMostChannel =
(Conroller.totalControllerChannels * Bank.bankInFocus) + 1;
Bank.bankInFocus = Bank.bankInFocus + 1;

		BankT(Bank.leftMostChannel);
	}
}

}

For single bank shifting, the algorithm is an extension of the above logic.

Set LowBank and highBank as outlined above;
firstTrack = 1;
lastTrack = Project.totalTracks;

function ShiftBankByOne(Bank) {
if Bank.direction == left && Bank.leftMostChannel != firstTrack then {
Bank.leftMostChannel = Bank.leftMostChannel – 1;
BankTo(Bank.leftMostChannel);
// e.g. when working with a 8 channel controller, channel 9 represent the beginning of bank 2, 17 the beginning of bank 3, an so on. If leftMostChannel becomes 8 because of a single track shift of the bank, the bank in focus is 1 (tracks 1 – 8). This ensures subsequent full banking is handle correctly.

	if Bank.leftMostChannel <= ((totalControllerChannels * Bank.bankInFocus) -1) 	then 				Bank.bankInFocus = Bank.bankInFocus  - 1;
	else if Bank.direction == right && Bank.BankInFocus == highBank then {
			exit;
		} 
		else { //do the reverse for the right
			Bank.leftMostChannel =  Bank.leftMostChannel + 1;
			BankTo(Bank.leftMostChannel);
			if Bank.leftMostChannel >= ((totalControllerChannels * Bank.bankInFocus) + 1)  then	
				Bank.bankInFocus = Bank.bankInFocus + 1;
		}
} else {
		exit;
	}

}

Showing up for the first time and roundly criticizing what we’ve done as “ridiculous and nonsensical” is not generally a great way to get us to pay attention to what you’re asking.

And it comes down to what are the most fundamental and essential functions one should expects to occur intuitively and instinctively when using a surface controller.

After a quarter century of DAW development, we don’t agree that this question actually makes much sense. What is “fundamental and essential” to you likely differs from another user - we’ve found this over, and over and over.

There are numerous control surface users who do not want the GUI to follow the surface display, and many others who consider it absolutely essential that it does. You haven’t heard from the former group, and I would guess you’re in the second. Calling other people’s preferences “madness” is again not a particularly strong way to get what you desire implemented.

We added an option with our Mackie Control Protocol support so the surface follows the selection status. We have not added, but might consider an option so that the GUI follows the surface display.

There’s also disagreement whether or not, if the user has banked the surface to an “off-count” position (e.g. the leftmost fader is bound to channel 3), a “full bank” should move to the next “whole bank” (i.e. the leftmost fader is now bound to channel 9) or by a “whole bank” count (i.e. the leftmost fader is now bound to channel 11, for an 8 fader surface).

On top of all this, current MB and Ardour releases have a fundamental bug in banking that came about because I spent too long away from that code, and while fixing something else forgot the basic concepts the code was using for banking. This bug was (probably) fixed a few hours ago.

Finally, different control surfaces in Ardour/Mixbus were implemented by different people, and have different banking behavior. The FaderPort series, for example, will never bank in a way that moves the “highest/rightmost” channel left of the right edge, whereas Mackie Control Protocol devices will do so. Neither decision is right or wrong, but different people will prefer each, and yet others would just prefer absolute consistency.