Has anyone here ever made a frequency detector?

Here is a picture of the timecode phase, left is considered first in line and should cross the threshold first when the record is moving forward, when the record spins backwards the right phase will be "in the lead", that lets the computer know to play the record backwards.

I just can't get a handle on this right now.

everything in reaktor is generally comparisons between values, not linear time comparisons.

anyone got any ideas about how to measure leading phase like first and second?

This has to be done in core to provide full audio rate detection and response.

I'm kinda lost on this one.

I think I'm just over-complicating it like I do sometimes, the answers probably staring me in the face and I just can't see it.

 

can you post a file that is just a few seconds of both left and right channels of the timecode? and maybe another with a few seconds of scratching (just for fun)?

 

no, here check it out. i cracked it. you just add in an extra 90 degrees to one side and then you get skinny circle or fat circle. i mean doing math at zero crossings would work but this way is like having fun too

 

here is the audio example, with some scratching.

Andrew, I'm looking at that ensemble I don't know if its the right thing or not, but thanks for the help.

EDIT: for some reason the forum won't accept the audio file upload, so here is a DL link.

http://www.mediafire.com/file/7p4iswc3der3d3v/Timecode+Scratch+Test.wav.zip

 

Right now I've got the audio to gate module and the timer to frequency module giving me perfect pitch tracking, I just need to compare time between them and it seems so simple yet I've got no solution at this point.

 

sorry for the ugly picture.

i layered the two signals on top of each other. i boosted the right channel so i could tell the difference between the two. here you can see that the blue signal (right channel) should be greater than the red signal (left channel) when the blue signal is crossing zero, from negative to positive (green circle).

however, if the signal were travelling backwards, if you found a zero crossing from negative to positive (purple circle), then the red channel would actually greater than the blue channel.

so you can check the right channel for a zero crossing from negative to positive. when one occurs, you compare to the left channel (no math!), if greater than the left channel, moving forward, if less than the left channel, moving backwards.

just a guess, haven't tested it.

 

you can get much better pitch tracking than that, btw.

that way will cause a lot of jitter.

just as an example of an improvement, but you'll probably still find other issues:

https://www.adsrsounds.com/reaktor-tutorials/frequency-detection-in-reaktor/

since you know the waveform type, with a bit of algebra you should be able to calculate the exact moment the waveform crosses 0.

 

Great tutorial, Thank you.

 

its the phase relationship between left and right channels.

the timecode is locked in a 90 degree relationship, but the polarity changes when the direction of your device changes. so, because they are ninety degrees out of phase if you put a 90 degree phase shift on just one channel with an allpass filter, now instead of the relative phase being static it will alternate between 0 and 180 when the direction changes. now you have fat circle going forward and skinny going back

 

awesome!!!

I study this and see how I can use it in core, this whole thing needs to process and shift at audio rate.

It's still a matter of creating a detection trigger, but I'll work on that.

Thank you very much.

 

I've got them phase aligned going forward and out of phase going backward, but the compare module doen't show any changes.

I've got before and after oscillascopes showing the proper effect, both audio signals are running into a compare module, when traveling forward they are in perfect phase alignment and all is well, when I play the audio backwards the oscillascopes show the waveforms being 180 (roughly) out of phase from one another, but the compare module does not respond to this and change its outputs.

I'm off for the nigh on this thing, but thank you both for all your help.

 

i got it working, it sounds alright, but it could be massively improved.

on the easy front, you could check frequency and direction at every zero crossing (there are 4, 2 for each signal). that would probably improve things drastically.

more difficult is, there is a problem when the frequency gets very low - since we only update frequency on a zero crossing, the updates get slower with lower frequencies, which leads to lower accuracy.

since the left signal is a sine wave and right signal is a cosine, i'm sure there's all sorts of pretty tricks we can do. at any given point in time we should be able to use trig to calculate the exact phase, and determine the difference in phase from the previous sample. which should give us instantaneous frequency detection. cool!

even the 'improved' frequency detection in the tutorial i posted is pretty basic, but it actually seems to do okay which honestly surprised me, keeping within 99-101% of the target speed during the un-scratched part of the sample.

 

looking closer at the waveform, it's surprisingly complex, though!

it doesn't, for instance, have a constant amplitude. instead, there are two amplitudes that interchange, and the pattern seems to be encoding some sort of data or something because it's fairly complex, or maybe i'm not looking at enough data.

to take a random snippet,

6 hi, 4 lo, 1 hi, 2 lo, 1 hi, 1 lo, 1 hi, 1 lo, 2 hi, 1 lo, 2 hi, 4 lo, etc.

the bad news is, not sure we can really do the fun trig stuff before we work out what's going on with that! some sort of binary encrypted timestamp mayhaps?

 

what are you looking at? i wanna see

 

the file michael posted in post #24

 

Traktor has a relative and absolute mode settings, in relative mode it simply tracks speed and direction to control the playing song with the vinyl timecode control.

In absolute mode there is a system in place to determine whether the vinyl is 1min, 2min, 3:15Sec into the track, the relative mode is fine to play with but NI are very protective over the absolute mode encoding, I imagine the waveform amplitude patterns may have something to do with that, which I will not be messing with.

Relative mode is all I need or want here.

 

Michael is rel mode = incremental mode?

 

Sort of, in relative mode the vinyl onlt tracks speed and direction, it does not track absolute position.

In relative mode the vinyl record can be at 6 min in and be controlling the first 30 sec of a song.

In absolute mode the vinyl timecode acts more like a real record, where 6 min into the timcode vinyl will automatically jump to and play the 6 min mark of the song in traktor.

It's a little different than incremental mode on a mouse or something, but still very similar.

 

yeah, i'm not interested in decoding absolute mode, just saying that the varying amplitude makes it harder to do any fancy trig tricks.

 

And the cue list supports the rel mode?