24 motorized fader mixer with Arduino

Actually, I just read I can't use OSC to directly communicate pro tools and Arduino.

some info about MIDI vs. OSC here MIDIbox SEQ V4 User Manual --- OSC

So I will need tu use midi. The goal now is to communicate protools and arduino with a 1024 steps MIDI CC messages. I guess there is a lot of that in this forum.

::slight_smile:

U dont necessarily need to use the 1024 steps... U can use the 127 native steps on volume, as i would think would be better for you. Mind you , we are talking about several channels... And with arduino its easy peasy to do so.
And yeah, MIDI seems the only reasonable solution hence my question, as you mentioned multi DAW from the begining !
Anything i can be of help, just shout !!

My 'client' works in a proffessional mastering studio. He thinks is important to have 1024 resolution in its faders. I kind of understand him. Not that I can listen the 'jump' between one value and the next one in 128 midi, but sounds logical to have best resolution possible.
Any ideas on this? I thought there was more info about 10 bit midi but i was wrong.
I will keep research on. Whatever you can find related, is helpfull.

thanks for helping!

Problem is that midi will only work with 127 at the end of the day...So, as the last step is only 127 i dont see will make much difference even if you have a resolution of 127 thou before. My opinion of course !! Its 8 to 1, roughly !! That is the ultimate resolution in levels used by the DAW's anyway ! And i find it quite good, never had issues with it automation wise !
Most of the functions that use 14 bit are sys-ex commands, there are exceptions (pitch bend is 1) bit if it is volume mixing then 7 bit is all you get over MIDI and there is no other option.
Behringer's BCF/BCR's use a different controller of 14 bits, but its proprietary so i doubt you will get access to it ! Plus its only as a controller
So dont see any way around it !
The analog side of it on the mixer wont be different for it, so whatever audio is going in will be the same resolution wise when recording analog signals from outside !!! Maybe u should explain that to him .

PS- Was thinking about the Mackie control Protocol compatible with most, if not all, DAW's.
Uses, apparently, 0 to 1023 steps... BUT, keep in mind will be ultimately translated to the 7 bits resolution anyway, so would be the same as you doing it in your code !!

Problem is that midi will only work with 127 at the end of the day

Not strictly true. For a number of control changes, there are MSB and LSB messages, for example:

7 	00000111 	07 	Channel Volume (formerly Main Volume) 				0-127 	MSB
39 	00100111 	27 	LSB for Control 7 (Channel Volume, formerly Main Volume) 	0-127 	LSB

Not everything implements every possible message, but it's in the specification.

Problem is- to what extent can this be implemented into each and every channel he needs to ?!?

14 BIT CONTROLLERS

Controllers 0 to 31 were originally specified as optionally 14 bit resolution controllers. To use them as 14 bit controllers the msb is transmitted as one controller (0-31), and the lsb is transmitted as a second controller (32-63 respectively). Controller 0 and Controller 32 have been defined as a Bank Select that qualifies Program Changes [sic.] and both messages must always be transmitted together.

In practice, it was impossible to differentiate between 14 and 7 bit usage, so 14 bit resolution never really worked.

That is supposed to be a devices master volume only... So in a multitimbral device, the Volume controller messages are used to control the volumes of the individual Parts. So, we needed some message to control Master Volume. Now if he can t get it to somehow trick it into each channel ?!? is it even possible ?!

*PS- Im not an expert in midi protocol, but as far as i see it, it would entail "create" a virtual device for each channel. Maybe then you could use it... But im not sure how to go about it, tbh ! Will require a lot of digging into the midi protocol !

I havent heard of anyone who has successful managed to do it, and i know of many attempts... But, hey dont let that discourage you ! You might be the first one to sort it, innit ?!?

You might be able to...

Volume

Number: 7 (coarse) 39 (fine)

Affects:

The device's volume level. If a MultiTimbral device, then each Part has its own volume. In this case, a device's master volume may be controlled by another method such as the Univeral SysEx Master Volume message, or take its volume from one of the Parts, or be controlled by a General Purpose Slider controller.

Value Range:

14-bit coarse/fine resolution. 0x0000 to 0x3FFF where 0 is no volume at all.

NOTE: Most all devices ignore the Fine adjust (#39) for Volume, and just implement Coarse adjust (#7) because 14-bit resolution isn't needed for this. In this case, maximum is 127 and off is 0.

If that is so, then ignore the #39 and use the 7. Now to what point this will be straight forward i dont know.
I do know that several of the previous attempts i heard they always ran into some issues( not sure what) when trying to implement the 7 bits controllers... Now what that was, im not sure... You will have to do it by trial and error, i guess !

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 !!