Go Down

Topic: Motorized Faders Linked to Computer Timecode (Read 619 times) previous topic - next topic

buildafriend

#15
Oct 13, 2017, 02:18 am Last Edit: Oct 13, 2017, 02:44 am by buildafriend
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.....
It's not a matter of what can or can't be accomplished. It's a matter of how much time you have in conjunction with your willingness, and budget.

allanhurst

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

buildafriend

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!
It's not a matter of what can or can't be accomplished. It's a matter of how much time you have in conjunction with your willingness, and budget.

studiopaul

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

lastchancename

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.
Q: How many searches did you make before posting this question?      A: none
At the very least, take a guess at the solution, then we can help move forward from what you know already.

studiopaul

#20
Oct 13, 2017, 06:38 pm Last Edit: Oct 13, 2017, 07:03 pm by studiopaul
SMPTE needs to be generated or striped to tape (old days) so need a generator that was sometimes run in sync with in house sync (broadcast house mainly)

Then a console reader or other sync unit could lock to the code. MASTER > SLAVE or a jam sync variant.
 
MOTU units used to have a generator and could sync to a unit...
I thought the OP wanted to use with large format console (usually a vintage console).
Now if not interested in using older tape machines, why bother, if using a DAW, there has to be a better protocol than 127 steps of midi also.

I think that at this point if you could generate something more like the newer Beringer xcontrol.
Klark Technik or say a mackie hui  those protocols are moderately improved based upon 1980s technologies... not ply time reference and fader positioning but what the fader is going to do,, read write its time position based upon the timeline.. if it can be switched to use other functions, say a plug in..
I know they updated Flying Faders with a new module to do something like this but not that advanced as I think it was still a MIDI implementation .
 

buildafriend

#21
Oct 13, 2017, 07:54 pm Last Edit: Oct 13, 2017, 07:59 pm by buildafriend
Just chiming back in to mention that I have a MOTU HD 192 AD/DA system.
It has system word in and out and an AES word clock input.
Still doing research here...
It's not a matter of what can or can't be accomplished. It's a matter of how much time you have in conjunction with your willingness, and budget.

studiopaul

digital sync so there are no digital drop outs "pops and clicks" is more a word clock sync and usually part of the house sync, digital equipment hand shaking such as digital converters say i wanted to convert madi to aes/ebu through an external box and then maybe the aes to analog..thats mostly digital processing to keep clocking of ones and zeros in order ...

Timing and positional reference in terms of location play rewind mmc smpte LTC and many more were used.. but new time stamp protocols.. for example most new codes are passed through ethernet or usb...a program map is used... example from behringer xcontrol (yes cheap crap but works well)

"Supports HUI* and Mackie Control* protocols for seamless integration with every compatible music production software"

its back to my point that these companies that are so called leaders in the field are writing hui codes and if your a manufacturer and want to use the code, you may need to License it...from digidesigm/AVID.. Klark technik etc..question is ..are there developer hacks or a way to read the real time info..??




allanhurst

I'm going to a Neve re-union tomorrow... perhaps if I talk to the guys there I'll catch up with modern techniques...

Well out of date!

Allan

studiopaul

Grab me a few of the beer can size capacitors for the flying fader card rack!! lol,  wheres the event?

allanhurst

#25
Oct 14, 2017, 01:39 am Last Edit: Oct 14, 2017, 01:43 am by allanhurst
The Plough, Shepreth, 2pm onwards.

Make it if you can.

Allan

buildafriend

I would value being able to go to such a gathering. I hope you both enjoyed it! 

I would like to do this the oldschool way, just like as if a tape machine track had the stored data. Obviously the SMPTE data will be generated from a computer instead of a tape machine but I see no need to change the protocol from the console end since flying faders in the 80's seemed to work just great on SSL consoles coming from tape machine SMPTE. Perhaps it is worth investigating some SMPTE systems from old tape machines. I will need a schematic. Any advice on which one might be nice to look at? I bet Studer had some good stuff for this. Seeing a schematic would also help me to learn the pinout and nomenclature of the physical connections. Learning about some chips that are designed to help with this would also be a good idea. No idea what chips to look at, besides of course the Arduino and the mentioned SD card.

Just like how a video has a certain number of frames per second, time code is defined by video frames. ( which was pretty much mentioned already ) But the number of frames can vary, depending on the video format. These differences are applicable to SMPTE, because it also varies. There are several types of SMPTE: 24 frames per second (fps), 25fps, 30fps, and 29.9fps (or 30fps drop )

^ okay so in reference to that information I need to pick my fps. 30fps sounds good to me. Any objections or theories on what might be a better choice?

-SMPTE is time that starts at zero. Just like in real time, SMPTE has hours, minutes and seconds. SMPTE's maximum value is 24 hours, like there are in a day. But there is a difference from our typical imperial time: frames. The terminology came from the broadcast industry. All of these determinations were dependent on the state of the broadcast standard: PAL, SECAM, NTSC, which in turn are based on 50Hz and 60Hz electrical frequencies.

-A system called Bi-Phase Mark is used to code a bit into an LTC signal while LTC stands for Linear Time Code.
 
- Bi-Phase Mark works like this ( it is also known as Differential Manchester according to Wikipedia ) https://www.youtube.com/watch?v=du_boiwX1yU

-An LTC frame is 80 bits long.

In SMPTE (or LTC), the receiver counts the moment it receives the first bit of an 80-bit packet as the start of the frame

How are these packets generated?

-SMPTE time is coded by the BCD (Binary Coded Decimal) method. In this method, four bits are allocated for every tenth decimal numeral. In each frame, the first 26 bits are allocated to the time information, followed by 32 bits of user data, and concluded by the synchronization word (the last 16 bits). The synchronization word is used to identify the frame's boundaries and is always set to: 0011 1111 1111 1101.

That's all I've got for now, and still I have no idea how to put this all together. It still just feels like pieces of a puzzle to me.

It's not a matter of what can or can't be accomplished. It's a matter of how much time you have in conjunction with your willingness, and budget.

buildafriend

#27
Oct 14, 2017, 11:17 pm Last Edit: Oct 14, 2017, 11:22 pm by buildafriend
"OK... make your project clearer. Presumably you want to synchronise fader movements to an audio playback.."

^ yes 100% correct. I would like to start with one fader to get the programming started and eventually move on to many more faders.

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

To make things easier I would like to assume it is an old tape machine. I say this because obviously these old consoles that linked to tape machines are still in use by many people.

"If so you have to find what that code is and synchronise to it. There's nothing magic about SMPTE. Look it up!"
I listened to this and tried. it's in the previous post.

"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."

I don't think we will have to do this since previous LTC will be available.

I need to add that usually in professional videography the LTC is in the metadata on the audio file, in this cause I think since the sounds are usually recorded into the DAW, the timecode is made by the software and then linked to the entire session. Before starting any modern recording session with even mildly professional software you need to choose a bit depth and sample rate. I generally use 32 bit float for bit depth and 192kHz for my sample rate. I'm purely guessing that my MOTU AD/DA that handles the bit depth and sample rate generates the oldschool LTC no matter what sample rate or bit depth I choose. I might be able to confirm this with the product support team. 

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

Yes to all of this question. My audio source is from the MOTU HD 192 as far as the fader movements should be concerned and the LTC will sync with it.
It's not a matter of what can or can't be accomplished. It's a matter of how much time you have in conjunction with your willingness, and budget.

lastchancename

#28
Oct 14, 2017, 11:19 pm Last Edit: Oct 14, 2017, 11:29 pm by lastchancename
SMPTE LTC has no dependence on the tape decks you are using.
They simply carry the 'audio' as a spare track, and record or play it exactly the same as any other track.
All the timecode gear is external to the tape transport (unless it's fitted as an option).
The only electrical connection between the timecode equipment and any transport(deck), is the ability to push or pull the capstan servo to aid in synchronisation.
One thing to keep in mind, is that as a high-modulation analog audio signal, there is high risk of crosstalk or leakage between channels/tracks.

EDIT add: The raw LTC signal when it leaves the 'generator' is usually between 0 and +6dB (0.7 and 1.0V p-p) as a square wave!
This ends up being naturally rounded and clipped by the capacitance of cabling and electronics limitations (not to mention the tapeitself), so your reader/decoder should be designed for significant signal loss and shape/peak degradation.
It's not rocket science, but needs to be designed.
Also, consider that the nominal 2kHz stream goes well out of the audio spectrum when spooling/shuttling the tape.  Hence wideband amplifiers etc, but the decoder also has to figure out how to handle these surges well  over 20kHz when moving the tape.
Q: How many searches did you make before posting this question?      A: none
At the very least, take a guess at the solution, then we can help move forward from what you know already.

allanhurst

#29
Oct 14, 2017, 11:37 pm Last Edit: Oct 14, 2017, 11:38 pm by allanhurst
Quote
Grab me a few of the beer can size capacitors for the flying fader card rack!! lol,  wheres the event?
Been there  - nice to meet some old colleagues.

I gather a few of my old designs - AIR Montserrat for example of which Neve made 3 - are still in use. Not bad for 40 years on......

Allan

Go Up