Motorized Faders Linked to Computer Timecode

Hi,

I have an arduino uno and a motorized fader. How can I make a motorized fader that links to and moves with the timecode of a program like pro tools?

I have one of these:

Thanks,

I have an arduino uno and a motorized fader.

That not a fader, that's a motorized linear potentiometer.

How can I make a motorized fader that links to and moves with the timecode of a program like pro tools?

I guess you should first solve the problem of getting that timecode data out of your "pro tools". Once you have that solution you should make a "fader" out of your potentiometer. Then we think about how to control that from your Arduino.

If we were talking about audio editing software I'd say your best bet would be to do it over midi (good arduino shields and well developed libraries already in place) as these apps would all make it very easy to keyframe/create envelopes for midi output - but Im not sure if the same applies to pro tools? What sorts of parameters a natively assignable to envelopes or keyframe events?

Oh that linear motorized pot isn't a fader? This is why this forum sucks, because of answers like that.

What are faders made out of? Maybe they ARE potentiometers. And clearly that one has motor. That's why I picked it.

Your advice will be omitted from my intake.

I'm not trying to make a midi controller

buildafriend:
Oh that linear motorized pot isn't a fader? This is why this forum sucks, because of answers like that.

What are faders made out of? Maybe they ARE potentiometers. And clearly that one has motor. That's why I picked it.

Your advice will be omitted from my intake.

You're not going to build many friends here with that attitude, buildafriend.

FYI: Faders for audio applications require a logarithmic potentiometer. Pylon was kindly trying to inform you that yours was a linear potentiometer.

buildafriend:
I'm not trying to make a midi controller

I'm aware of that -- and I'm going to assume the curtness of your response was spillover from your reaction to the fader vs pot comment.

If this is an A/V application it stands to reason that controlling the movement of the pot may be accomplished most easily, both in terms of requisite circuits and coding, by taking advantage of midi. Using midi as a means to transmit the pot's motor control signals != "building a midi controller". Things that simply receive and respond to midi input are not midi controllers.

JohnLincoln:
You're not going to build many friends here with that attitude, buildafriend.

FYI: Faders for audio applications require a logarithmic potentiometer. Pylon was kindly trying to inform you that yours was a linear potentiometer.

this is not 100% accurate. there are tons of different uses for pots and faders in audio applications. you may only be familiar with what you've seen. call it a fader or a pot it does not matter. its carbon or conducive plastic with a wiper sliding around it. you can also apply voltage dividers into your pots to create sweet spots but this is not the purpose of this post. this is simply trivial and basic crap.

I'm glad you guys could let me teach you about this. Does anyone have an answer to my original question?

Do large format consoles use MIDI to control their motorized faders?

We did this back in the mid 70's at Neve - the 'flying faders' technology has been around for a long time. And our computer was a Data General 'Naked mini' iwth core memory... a modern small arduino is probably of similar power.

You can now buy such motorised pots from several sources. Some have linear motors.

If you want to do the mechanical work yourself by all means have a try - it isn't easy.

The control part is trivial by comparison.

And - to answer one of your questions - no . The early versions synchronised fader movements to SMPTE time code on one of the tracks of a multi-track audio tape recorder. I think professional versions still use a similar technique.

Allan

buildafriend:
Does anyone have an answer to my original question?

I do. But you've really kind of been a jerk so far and I don't want to get mixed up with some flame war if it isn't just exactly what you were looking for. I wouldn't post at all, but I thought it might help you see why all the folks with the real answers have been avoiding your thread. Maybe a little bit of an attitude change and getting over yourself just a little would get them back. Maybe not.

allan,

I've been experimenting with verilog, FPGA/CPLD technology, and the Xilinx ISE with the spartan line of chips while using Simon Monks book. I'm glad to see you have found great use for FPGAs and it seems like you could be a wealth of information for me. I have read what you are talking about with the Neve pots from a guy named Ian Thompson Bell who also used to work there. I've also read this in douglas self's small signal audio design book. I believe he was also busy in england back in the day. Ian posts in another forum. It does seem trivial to get this automation thing going since there are different paths. I'm sorry for seeming irritable if at all towards you there is just so much bad advice out there that it really does become troublesome to find good information. The mechanical end of it is no issue for me since my 3D design work seems to generally work out fine as well as my PCB design. There is a nice maker space only blocks from me.

Might I trouble you by asking which path you would take? The best advice I have been given so far is the following - But I'm still figuring out how to interpret it.

"You'll need to do something with the correct sample rate to read the pulses of SMPTE packets and save the state in an array. Then you parse the array to determine the time. After that, what you do with the time is up to you."

I would appreciate any advice from you. It's surprising that these things are still using STMTE. Part of me thought this would have faded with the use of tape machines.

-J

okay heres some info..

I've no idea if SMPTE code is still used ( it counted in frames : 24,25 or 30 per second - confusing, eh?)

  • I've been out of that industry for a long time - I did say 'similar' - you'd need some sort of timing reference.

Is your problem then just interfacing to such a standard time reference?

Remember an arduino has a very limited memory - you'll need a means of storing pot(s) movements against this time reference and over-writing that when the operator over-rides the previously stored sequence. SD card perhaps ?

Note I don't use the word 'engineer' for such a person... I bet few of them even know Ohms's law!

Allan

ps regards to Ian!

buildafriend:
I'm sorry for seeming irritable if at all towards you there is just so much bad advice out there that it really does become troublesome to find good information.

How does being a dick to people help you get better information? Just curious.

I concur.

I'm trying to be helpful and polite - but I do hope you'll improve your attitude, buildafriend, if you want want much help from the many high-grade professionals on this forum.

We don't wave credentials and degrees around, but you can bet there are plenty.

Allan

Okay I'll be more kind and appreciative.. Even after being called a dick.

I also don't flaunt my degrees or credentials. I'm glad to hear people are being humble.

It seems I need to interface SMPTE with the Arduino to control the motor. I have been advised to use the I2C protocol, does this sound like a good idea? I have to interface SMPTE to my computer somehow. I think I'll probably need a unit that does this to connect the arduino to. It sounds like I'll need an SD card as well to store the data. hmm.....

OK... make your project clearer. Presumably you want to synchronise fader movements to an audio playback..

Does the audio source have a timecode embedded in it ? Like the old SMPTE track of a muti-track tape machine?

If so you have to find what that code is and synchronise to it. There's nothing magic about SMPTE. Look it up!

If not you have to synchronise your audio playback and fader movements - perhaps by starting them together and doing your own timing within the arduino. And for editing, go to a pre-defined point eg 34.45 seconds into the track .... not so easy if the audio and timing are disconnected, as you may have to go back to the beginning to get the sychronisation accurate - pain in the neck if a CD stream, much easier if it's a file. That's eg a PC job - no arduino can handle files that big. Arguably the whole job would be better handled with a PC rather than involve an arduino. I bet there are applications you can buy to do this.

What is your audio source? can you go back/ forward a specific time? To a specific point?

Allan

OK... make your project clearer. Presumably you want to synchronise fader movements to an audio playback..
Does the audio source have a timecode embedded in it ? Like the old SMPTE track of a muti-track tape machine?
If so you have to find what that code is and synchronise to it. There's nothing magic about SMPTE. Look it up!
If not you have to synchronise your audio playback and fader movements - perhaps by starting them together and doing your own timing within the arduino. And for editing, go to a pre-defined point eg 34.45 seconds into the track .... not so easy if the audio and timing are disconnected, as you may have to go back to the beginning to get the sychronisation accurate - pain in the neck if a CD stream, much easier if it's a file. That's eg a PC job - no arduino can handle files that big. Arguably the whole job would be better handled with a PC rather than involve an arduino. I bet there are applications you can buy to do this.
What is your audio source? can you go back/ forward a specific time? To a specific point?

I need to do some research to help get you the right answers. I'll be back!

Have you looked into hui/mackie/prosonus or any other single fader units protocol way more accurate than 127 steps of midi, wondering if theres a better way to sample that data.

On another note, in my storage locker, I have a Neve V3 60 FF console,
Neve libra with Encore... the Encore looks like the faders used an optical wiper.
My SSL A series again is interesting too..magnetic induced coils, bloody things would creep by them selves if not calibrated and would also get stupid hot if not dialed in.
But for the most part.. almost all Large format consoles need to operate as a slave on a Smpte time based sync, someone needs to drive.. now we have MMC and other digital sync Midas over Ethernet is very cool too. $400 gets you a behringer controller that will do the job nicely to most DAWS. hence my large format consoles in storage LOL!!

SMPTE time code (the old style stuff), is an 80-bit code, that can be read bidirectionally. At play speed it’s a harsh waveform around 2kHz. Often clipped to get better edges in the reader.

I didn’t check the links above, but it does contain asymmetric preamble/sync blocks which allow you to determine the direction to read the bits (msb-lsb or vice-versa).

It doesn’t need an external reference, all you do is sample the ‘audio’ until you find one of the preambles - then start building up your time value.

There are several info bits that define info about the code block, and of course almost half the data bits are not for the ‘time’, but may be used to hold USER BITS... often reel numbers, date, or even time copied from a source medium.