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.

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 controllerSo 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- to what extent can this be implemented into each and every channel he needs to ?!?

Quote

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

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 !

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.

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..1023the 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 ;-) )

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

as driver i used the Arduino Motor Shieldwith 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 TIit has the Output Clamp Diodes build in - thats really cool - so you dont need so much things around. (i just missing the inverter thing)

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.

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?

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.

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

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