24 motorized fader mixer with Arduino

Anyway, hope this helps...
I think you might be able, actually.
*THIS IS THE REST OF THE INFO ON THE PREVIOUS QUOTE

Taken from MIDI Specification

Controller Numbers

A Controller message has a Status byte of 0xB0 to 0xBF depending upon the MIDI channel. There are two more data bytes.

The first data byte is the Controller Number. There are 128 possible controller numbers (ie, 0 to 127). Some numbers are defined for specific purposes. Others are undefined, and reserved for future use.

The second byte is the "value" that the controller is to be set to.

Most controllers implement an effect even while the MIDI device is generating sound, and the effect will be immediately noticeable. In other words, MIDI controller messages are meant to implement various effects by a musician while he's operating the device.

If the device is a MultiTimbral module, then each one of its Parts may respond differently (or not at all) to a particular controller number. Each Part usually has its own setting for every controller number, and the Part responds only to controller messages on the same channel as that to which the Part is assigned. So, controller messages for one Part do not affect the sound of another Part even while that other Part is playing.

Some controllers are continuous controllers, which simply means that their value can be set to any value within the range from 0 to 16,384 (for 14-bit coarse/fine resolution) or 0 to 127 (for 7-bit, coarse resolution). Other controllers are switches whose state may be either on or off. Such controllers will usually generate only one of two values; 0 for off, and 127 for on. But, a device should be able to respond to any received switch value from 0 to 127. If the device implements only an "on" and "off" state, then it should regard values of 0 to 63 as off, and any value of 64 to 127 as on.

Many (continuous) controller numbers are coarse adjustments, and have a respective fine adjustment controller number. For example, controller #1 is the coarse adjustment for Modulation Wheel. Using this controller number in a message, a device's Modulation Wheel can be adjusted in large (coarse) increments (ie, 128 steps). If finer adjustment (from a coarse setting) needs to be made, then controller #33 is the fine adjust for Modulation Wheel. For controllers that have coarse/fine pairs of numbers, there is thus a 14-bit resolution to the range. In other words, the Modulation Wheel can be set from 0x0000 to 0x3FFF (ie, one of 16,384 values). For this 14-bit value, bits 7 to 13 are the coarse adjust, and bits 0 to 6 are the fine adjust. For example, to set the Modulation Wheel to 0x2005, first you have to break it up into 2 bytes (as is done with Pitch Wheel messages). Take bits 0 to 6 and put them in a byte that is the fine adjust. Take bits 7 to 13 and put them right-justified in a byte that is the coarse adjust. Assuming a MIDI channel of 0, here's the coarse and fine Mod Wheel controller messages that a device would receive (coarse adjust first):

0xB0 0x01 0x40

Controller on chan 0, Mod Wheel coarse, bits 7 to 13 of 14-bit

value right-justified (with high bit clear).

0xB0 0x33 0x05

Controller on chan 0, Mod Wheel fine, bits 0 to 6 of 14-bit

value (with high bit clear).

Some devices do not implement fine adjust counterparts to coarse controllers. For example, some devices do not implement controller #33 for Mod Wheel fine adjust. Instead the device only recognizes and responds to the Mod Wheel coarse controller number (#1). It is perfectly acceptable for devices to only respond to the coarse adjustment for a controller if the device desires 7-bit (rather than 14-bit) resolution. The device should ignore that controller's respective fine adjust message. By the same token, if it's only desirable to make fine adjustments to the Mod Wheel without changing its current coarse setting (or vice versa), a device can be sent only a controller #33 message without a preceding controller #1 message (or vice versa). Thus, if a device can respond to both coarse and fine adjustments for a particular controller (ie, implements the full 14-bit resolution), it should be able to deal with either the coarse or fine controller message being sent without its counterpart following. The same holds true for other continuous (ie, coarse/fine pairs of) controllers.

Here's a list of the defined controllers. To the left is the controller number (ie, how the MIDI Controller message refers to a particular controller), and on the right is its name (ie, how a human might refer to the controller). To get more information about what a particular controller does, click on its controller name to bring up a description. Each description shows the controller name and number, what the range is for the third byte of the message (ie, the "value" data byte), and what the controller does. For controllers that have separate coarse and fine settings, both controller numbers are shown.

MIDI devices should use these controller numbers for their defined purposes, as much as possible. For example, if the device is able to respond to Volume controller (coarse adjustment), then it should expect that to be controller number 7. It should not use Portamento Time controller messages to adjust volume. That wouldn't make any sense. Other controllers, such as Foot Pedal, are more general purpose. That pedal could be controlling the tempo on a drum box, for example. But generally, the Foot Pedal shouldn't be used for purposes that other controllers already are dedicated to, such as adjusting Pan position. If there is not a defined controller number for a particular, needed purpose, a device can use the General Purpose Sliders and Buttons, or NRPN for device specific purposes. The device should use controller numbers 0 to 31 for coarse adjustments, and controller numbers 32 to 63 for the respective fine adjustments.

This is where the problems seem to stem from...
Some devices do not implement fine adjust counterparts to coarse controllers. For example, some devices do not implement controller #33 for Mod Wheel fine adjust. Instead the device only recognizes and responds to the Mod Wheel coarse controller number (#1). It is perfectly acceptable for devices to only respond to the coarse adjustment for a controller if the device desires 7-bit (rather than 14-bit) resolution. The device should ignore that controller's respective fine adjust message.

Last night turned the cubase on ( i normally use analog circuitry and an Alesis HD 24 ) and was checking a few things , while thinking, so here it goes...

  • You will have to make sure that when controlling a VST( cause he will want to use vst's, i guess) that they accept the #7 controller, otherwise youre done straight away. And i guess thats where things have gone wrong in the past.
    -Make sure it is not gonna mess up with connected MIDI instruments ( this i think wont be a problem, unless on specific cases).
    Try to enquire also about the other main DAW's while you're at it, maybe ?!? I know its for pro tools, but you can always use it later on others;Logic Pro seems to be compatible.
    -Also something i couldnt check , as i dont use pro tools is- will the issue of master/slave become reality ?!? As im not sure if taking over the faders will force you also to "master" into transport controls as well. If so, you have another issue.( this one i dont think will be an issue at all, but hey i dont use pro tools)

Just some question you might want to answer , that might or not be relevant !!
Bless

Woah iyahdub, thats tons of usefull info. thanks a lot! it will take some time for me to read and understand it.

resuming, as I understand:
Midi protocol has different types of CC. I can use 'coarse and fine adjustments' to send (and recieve?) 14 bit CC messages. If I use CC #33 w/fine adjustment, protools will probably recognize it as Mod Wheel. I should use some 'empty' CC # then and set fine adjustment for it.

I will try this later. I a bit busy lately, but I want to get to it done next week.

On the other way, i've been trying different PID setups to control the fader motor. It still needs a lot of work, but I think I'm in the right way. I will upload the code when I get it to work properly.

thanks for helping, I hope to have some good news next week

cheers!

Hi @All :slight_smile:

thanks Mytx for your info about your project.
(he answered to my project info/ request)

i have an motorfader - and a arduino sketch that controls it.
My actual working state is as following:
you can set the fader to a position:
driveTo(900); // 0..1023
the software runs a speed/ distance map.
so if the fader must move a long way it will drive with maximum speed - and when it comes nearer to the target position it will slow down.
with this system i get a relative small tolerances. ( i think its 2% - on an 100mm fader means 2mm :wink: )

at the moment i work on the packaging into an arduino lib.
will be ready the next days. (i hope :wink: )

I used this fader:
Sparkfun Slide Pot - Motorized (10k Linear Taper)
and there are also some with audio taper profiles:
Sparkfun Slide Pot - Motorized (10k Audio Taper)
this things are from Top-Up-Industries
an other motorized fader from ALPS

as driver i used the Arduino Motor Shield
with this i can drive two faders.
my next step on the hardware side will be also to use an L293D QUADRUPLE HALF-H DRIVER from TI
it has the Output Clamp Diodes build in - thats really cool - so you dont need so much things around. (i just missing the inverter thing)

sunny greetings

stefan

I understand that the only issue u might have will be pro tools itself... As long as he recognize the 14 bits controller, you will be laughing... Wont necessarily mean that will be compatible with other DAW's though...
As i see it you would only have issues with the 14 bit implementation as long as you were to be expecting to use it with different ones, at different times, and only then you would have an issue as not all will accept it and recognize it. But in this case it is only for one exclusive (the DAW, ) so you will have that side shortened...If it does accept it, you sorted ! And my guess is that it will accept it !!
So, seems that side will be cool.
As to the rest, keep us informed please ! Now im definitely curious.
As midi goes, i will also be working with it soon, hence all this info.

hi folks

welcome s-light. I wonder, how often can you set a new destination point for you fader? are you using PID?
I've been trying usin PID but still can't make it work properly beacuse of PWM outputs and conflictive frequencies. I know I could set up a PID correctly but i'm still trying. I tried also to make a PID with digital outputs instead of PWM outputs, but it was preaty messy.

Right now this is my situation:
Arduino <--> motor fader

  • Got the position data coming from the fader
  • Got the DC servo spinning bi-directionally (with L293D H-bridge)
  • Couldn't manage to set PID correctly to make the fader go where I tell him to go with another analog input (potentiometer). Maybe this is because I don't know how to callibrate PID. Anyone understands this?
  • Couldn't manage to read Touch Sensor signal. I can't get the chips that I need for this yet.

Arduino <--> Pro Tools

  • Just did investigation, and I think software will be able to read 1024 resolution midi messages with 'fine adjustment' settings. Didn't tried it yet though.

iyahdub, my particular project it's Pro Tools based. So I don't mind if it doesn't works with other DAW's.
are you planning to start some motorfader project soon as well? or just getting in 14- bit midi messages?

!!!

hey :slight_smile:

thanks for the welcome.

@Mytx what do you mean with PID? i dont knwo the term?
tomorrow i can upload a video of the current state of my project.

to the TouchThing:
in the Playground are two interesting options for Touch / Capacitive Sensing:
[Capacitive Sensing Library by Paul Badger](http://Capacitive Sensing Library by Paul Badger) a full library - but if i understand this right it needs a lots of time...
Native Capacitive Sensors without additional Hardware really basic - just a function and a short piece of wire..
i do not have tested them yet - i will com to this point on my list earliest at the end of the year.

i hope one of this things work for you and the fader - and let me know i am interested too^^

sunny greetings

stefan

hey stefan, here is some info about PID

PID Arduino Library: Arduino Playground - PIDLibrary
WIKIPID: PID controller - Wikipedia

As I understand it, PID is a mechanism or a system that gets two values, compares them and calculates an error. That error is the distance between one value and the other. In our case, is the distance between fader position an desired fader position. This system tries to reduce that error in different waysbeing 'tuned' with 4 variables.
Reducing that error would mean for us, taking the fader to the desired position or taking desired position to the fader. As desires can't be handled by Arduino yet, the first option is the one we care about.

thats what I can hardly understand about PID, I recommend you to read Arduino's site for real information.

::slight_smile:

hi Mytx,

thanks for the explanation :slight_smile:
i think the idea to use a PID is good idea - but eventually over-sized :wink:

the trick at my concept is: the motor controller is set to active state if there is a new target value.
than it drives in the right direction to reach that point.
the speed with which the fader drives depends on the remaining distance - long distance = fast; short distance = slow;
if it is near this point (+- 1 Digit) (or an timeout occurs as example if the fader is blocked mechanically) the controller stops the motor and sets itself to standby.
in standby it waits until the state is set to active.

so at the first test i tested this without the active thing. than the fader is oscillating (drives a smal step to far - the controller switches the direction and it will drive the next step to far...)

so this system is not a real pid or something similar - its much easier and justs needs an activation.
it is not always active...

i hope i have the time to make the video this evening -
for the library there are some small things i have to do and if this is finised i will realeas it - i will let you know^^

sunny greetings

stefan

Hello,

The API was probably running Flying Faders from MartinSound.

There is a nice article here
http://www.martinsound.com/ar_fly01.htm

Those faders were 10 bit. I have used Flying Faders on the Neve and the equivalent on the SSL. Both are high level consoles like the API.

Pro Tools uses 10 bit (1024 steps) today. The Mackie HUI is usually quoted as 9-bit. The spec i have been reading shows that it send a 7-bit MSB and 7-Bit LSB or 14 bits. It would be hard to make use of that data on a regular fader, but the HUI does have a 'Fine' mode.

All this is probably just academic above 10 bits. (0.1dB steps) Using MIDI controller data like CC 7 (Volume Control) is normally 7bit and you can definitely hear the stair stepped volume settings in a mixing application.

On some keyboards the mod wheel(CC1) or data entry slider(CC 6 ) may send MSB and LSB. Mod wheel MSB is CC1 and LSB is CC33. Pitch bend is almost always 14 bit centered at 8192. You can use the full range if you take the mechanical spring off that snaps it back to center. :slight_smile:

Your mastering engineer is right, in a pro audio setting, 10-bits is needed. That said, plenty of useful things can be done at MIDI 7-bit. I just wouldn't try to market it to the pro audio world at less than the current industry standard.

Keep us apprised of your progress!

From my MIDI notes:

MSB 1-21 0 0 Bank Select (MSB) Never re-route anything to Controller 0
1 1H 1 Modulation Wheel or Joystick (positive polarity) (MSB)
2 2H 2 Breath controller sometimes Joystick (negative polarity) (MSB)
3 3H 3 Early DX7 Aftertouch 0-127
4 4H 4 Foot Pedal (MSB) Don't mess with it
5 5H 5 Portamento Time (MSB) Only use this for portamento time
6 6H 6 Data Entry (MSB) Better leave this one alone too.
7 7H 7 Volume (MSB) Software Mixer warning
8 8H 8 Balance (MSB) Some synths use it
9 9H ???
10 AH 10 Pan position (MSB) Software Mixer warning
11 BH 11 Expression (MSB)
12 CH 12 Effect Control 1 (MSB)
13 DH 13 Effect Control 2 (MSB)
14 EH 14 Undefined
15 FH 15 Undefined
16 10H 16 Ribbon Controller or General Purpose Slider 1
17 11H 17 Knob 1 or General Purpose Slider 2
18 12H 18 General Purpose Slider 3
19 13H 19 Knob 2 General Purpose Slider 4
20 14H 20 Knob 3 or Undefined
21 15H 21 Knob 4 or Undefined

22-31 are undefined
LSBs may or may not be implemented. Have never seen 46-63 used as LSB

33 21H 33 Modulation Wheel (LSB)
34 22H 34 Breath controller (LSB)
35 23H LSB for 3
36 24H 36 Foot Pedal (LSB)
37 25H 37 Portamento Time (LSB)
38 26H 38 Data Entry (LSB)
39 27H 39 Volume (LSB)
40 28H 40 Balance (LSB)
41 29H LSB for 9
42 2AH 42 Pan position (LSB)
43 2BH 43 Expression (LSB)
44 2CH 44 Effect Control 1 (LSB) Roland Portamento on and rate
45 2DH 45 Effect Control 2 (LSB)
46 2EH LSB for 14
47 2FH LSB for 15
48 30H LSB for 16
49 31H LSB for 17
50 32H LSB for 18
51 33H LSB for 19
52 34H LSB for 20
53 35H LSB for 21
54 36H LSB for 22
55 37H LSB for 23
56 38H LSB for 24
57 39H LSB for 25
58 3AH LSB for 26
59 3BH LSB for 27
60 3CH LSB for 28
61 3DH LSB for 29
62 3EH LSB for 30
63 3FH LSB for 31

You may want to emulate the HUI protocol. That would make you instantly compatible with most DAWs. It has been reverse engineered in several places on the web.

Ok, enough for now...

Most of that info we had got there( check previous posts) and these models were sold as spares ( that been all confirmed).
Now theres likkle bits of info you brought might be useful, but he will only be implementing it in this unit... So even the fact that many synths wouldnt be compatible wont become a problem at all, it seems !
Thanks for your input !!

Sorry about the delay. I've been on vacation 8) .

RBBlackstone, welcome and thanks a lot for sharing your research.

I'm still a little stuck with hardware until I get some parts from US (touch sensors)

I will get on this project more often from now on, so you'll get some news from me soon..

Has anyone else started their own motorized fader project based on this topic?

My Arduino Board burned out because of an electric storm over Buenos Aires... such bad luck

So I can't test anything new until I get a new one :frowning:

Well, I'm back! and with lots of good news.
After burning the motor fader that I was using (still dont know how it happened), sent it to TKD Japan to repair (is a really old model), got it back and started all over again.

The new setup is divided in 3 modules of 8 motorized faders each.
Hardware:
Each module will have an Arduino MEGA witch will recieve all 8 analog signals from each linear analog output from faders, and will output 2 PWM signals to control each servo.
I'm using H-Bridges to control the servos and I'm planning to use tlc5940 to be able to output the 16 PWM signals I need (2 for each servo, this part is the only one I still need to test)
I would also need 16 digital inputs of the arduino mega for the capacitive sensors.

Software:
Each Arduino will be loaded with HIDUINO firmware (GitHub - ddiakopoulos/hiduino: Native USB-MIDI on the Arduino) witch enables to see each board as an HID midi device.
Now, all faders will output Pitch Wheel messages (14-bits) in different channels (from 1 to 8) and I will set up the modules in ProTools as 3 different control surfaces, recieving and sending MIDI to each Arduino Board with MackieControl protocol, witch is already desgined to assign automatically each Pitch Wheel message to channels fader control (no midi mapping needed and 14 bit resolution, that will be reduced to 1024 step resolution because thats the maximum resolution for analog inputs on the MEGA)

I don't have much time now to explain it better, but already tested most of the parts of this setup and seems to work ok! The software and communication part is working entirely, still need to resolve the design of the Shield for each MEGA, and test the TLC.

We are close to have a full working Arduino based 24 motorized fader professional mixer! I'm so excited to finish it and see how it's used by the community!

Cheers!

I attached the actual protoboard setup, without the TLC

Mackie control it was, then... Midi, while viable, wouldnt have been as practical, i guess ! Nice one, and do keep us updated !

Techylah:
I'm thinking that you want to control these while the music is going through them.
I would create an AC signal, much higher than the audio range, say 100-300khz or more and capacitively always mix that in with the audio.
The audio signal from each fader then gets split. The high frequency AC signal gets filtered out, full wave rectified and capacitively filtered to provide a DC signal of "where" each fader is. The faders are non-linear, since they have audio taper, but interestingly that doesn't matter for this app. Your Arduino simply reads and samples these 24 DC voltages and stores them for re-use.

100kHz is too close to the ADC input bandwidth of professional audio equipment, usually 96, 192 or even 384kSPS.
Surely all the mixing is done in software anyway, the faders just generate a DC signal? Suppose it depends on the
antiquity of the hardware!

Anyway are there links to the datasheets for some of this hardware?

iyahdub:
Mackie control it was, then... Midi, while viable, wouldnt have been as practical, i guess ! Nice one, and do keep us updated !

It still regular MIDI! What the Mackie Protocol does is to automatically connect some specific MIDI data to some specific DAW software controls.
I did some reverse engineering and connected a SAC 2.2 (midi controller for DAWs that works with some different protocols including Mackie Control). Then assigned this control surface into live as a Mackie Control surface and monitored MIDI activity. I found out this way that Mackie Control protocol reads Pitch Wheel midi messages from channel #1 to #8 and automatically uses this messages to control faders from track 1 to track 8 of the software (in this case, Ableton Live).
So, what you need to do to control track faders using Mackie Control protocol is to format each fader to send Pitch Wheel messages in different channels (from 1 to 8). Channel #9 is Master volume control.

This is the way to control 8 faders using Mackie Control protocol, but I needed to control 24 tracks.
Unfortunately, this protocol works with an 8 track + master limit, but there is a way to get through this.
In the same SAC 2.2 Controller, I have some track bank navigator, witch allows the user to navigate through tracks and use them to control tracks from 9 to 16, for example. When I monitored this function, I saw that the Pitch Wheel messages from the fader never changed (still Pitch Wheel messages from channel #1 to #8), and the only difference, is that I've pushed this track bank navigation button. I monitored the midi message of this button and I've got a midi Note #47 on.
So what I realized is that if I send this note on message, I get automatic bank change and control the next 8 channels.
Then, I configured in Ableton 3 different Mackie Control surfaces, recieving MIDI from 3 different ports.
The first Mackie Control surface (faders 1 to 8) will recieve and send MIDI to Ardunio #1 port
The second Mackie Control surface (faders 9 to 16) will recieve and send MIDI to Arduino #2 port, and it will automatically send one Note on #47 message as soon as it gets connected, to do the bank navigation and control channel volumes from 9 to 16.
The third Mackie Control surface (faders from 17 to 24) will recieve and send MIDI to Arduino #3 port, and it will automatically send two Note on #47 messages as soon as it gets connected, to do the bank navigation and control channel volumes from 17 to 24.

I tried this with a virtual controller I made in Isadora and it worked perfectly! I can simultaneously control 24 different track volumes in ableton live, getting this midi data from 3 different ports through Mackie Control protocol.

Hope my explanation is understandable! Please let me know any dobut about it.

Hi guys!

I am working with Mytx in this project, and because of speed needs we decided to move to the Arduino Due platform.

We checked and there seems to be libraries for both the capacitive sensing and the tlc5940.

We finally got our ands on a Due and started trying the capacitive sensing, but we can't seem to make it work at all.
It gives us "-1" no matter what.

Tried different timeout values and different pins, but nothing changes...

Anyone knows anything about it?

Any help appreciated!

#include <CapacitiveSensorDue.h>

/*

  • CapitiveSense Library Demo Sketch
  • Paul Badger 2008
  • Uses a high value resistor e.g. 10M between send pin and receive pin
  • Resistor effects sensitivity, experiment with values, 50K - 50M. Larger
  • resistor values yield larger sensor values.
  • Receive pin is the sensor pin - try different amounts of foil/metal on this
  • pin.
    */

CapacitiveSensorDue cs_4_2 = CapacitiveSensorDue(44,45); // 10M resistor between pins 4 & 2, pin 2 is sensor pin, add a wire and or foil if desired

void setup()
{
Serial.begin(9600);
cs_4_2.setTimeout(100);
cs_4_2.calibrate();
}

void loop()
{
long total1 = cs_4_2.read(50);

// Serial.print(millis() - start); // check on performance in milliseconds
// Serial.print("\t"); // tab character for debug windown spacing

Serial.println(total1); // print sensor output 1
}