DJing Discussion

This area is for discussion about DJing in general. Please remember the community rules when posting and try to be polite and inclusive.

FS Vinyls

Dj Stubby 11:58 PM - 10 August, 2004
Hey I was reading up on Skratchworx and I saw the Final Scratch has 3 types of Vinyl now. Check it out.

www.skratchworx.com

www.finalscratch.com

They have standard and thin vinyls now with "Lead-in grooves". SSL responds fairly well at the beginning but does have trouble reading the vinyl occasionaly. Just wondering if SSL is gonna have something like this in the future.
nik39 12:04 AM - 11 August, 2004
What feature from the "new" FS vinyls is missing on SSL?
radish 1:53 AM - 11 August, 2004
The 3 types are - Thick, Thin, and "New". I got the new ones when I bought FS (what a waste of money!). They are basically like the thin ones, but with a special timecode in the lead in so FS can tell when the track is about to start, and the display shows you moving up to the start. Not sure how useful it actually was though, I haven't missed it.
Steve W 2:27 AM - 11 August, 2004
Sounds like the "New" FS ones are like the standard Scratch LIVE control records, which have 3 seconds of control signal in the lead-in.
BadCompany 6:37 AM - 11 August, 2004
... lol i dont see why this is new... i rememeber this was present in FS 1.0
nik39 8:03 AM - 11 August, 2004
Quote:
... lol i dont see why this is new... i rememeber this was present in FS 1.0


Nope, this "feature" with lead in graphics has been introduced in FS 1.5.x.
DJCQ103 9:46 PM - 12 August, 2004
Hey has anyone tried using FS vinyl with Serato. Does it work?
lo-fi 9:48 PM - 12 August, 2004
Quote:
Hey has anyone tried using FS vinyl with Serato. Does it work?


Won't work. Two completely different systems - one is called timecode and the other is called 'not timecode' or noisemap.
Shaun W 11:30 PM - 12 August, 2004
Quote:
Quote:
Hey has anyone tried using FS vinyl with Serato. Does it work?


Won't work. Two completely different systems - one is called timecode and the other is called 'not timecode' or noisemap.


We call it a "control signal" :D
nik39 3:15 AM - 13 August, 2004
Quote:
Two completely different systems - one is called timecode and the other is called 'not timecode'


lol :D
AJ 6:01 PM - 13 August, 2004
Quote:
Quote:
Hey has anyone tried using FS vinyl with Serato. Does it work?

Won't work. Two completely different systems - one is called timecode and the other is called 'not timecode' or noisemap.

Actually, ours is called a maximal-length pseudo random bit sequence, it is generated using a linear feedback shift register. See why we haven't really been throwing the name around? That's why I came up with the name NoiseMap - it is pretty close to describing the code concisely.

We came up with this idea, and in our opinion it is vastly superior to timecode. The basic reason is that it has way more redundancy - each error in the sequence has a much lower impact than it would in a timecode. I can go into the details if anyone is interested.

As for whether the FS record will work - to an extent they probably do. We use a quarter-cycle phase quadrature sine wave to track direction and speed, and FS must use the same - I mean it's obvious right? What else would you use? The difference would be in the frequency and possible the direction. This means that although absolute position detection could never work (because timecode =/= noisemap) relative mode should work, but probably at the wrong speed and maybe in reverse.
nik39 6:56 PM - 13 August, 2004
Quote:
Actually, ours is called a maximal-length pseudo random bit sequence, it is generated using a linear feedback shift register. See why we haven't really been throwing the name around? That's why I came up with the name NoiseMap - it is pretty close to describing the code concisely.

We came up with this idea, and in our opinion it is vastly superior to timecode. The basic reason is that it has way more redundancy - each error in the sequence has a much lower impact than it would in a timecode. I can go into the details if anyone is interested.

So the idea is basically, get a code which has as much entropy as possible, or in an n-dimensial vector space let them have as much distance as possible...?

If you have more details, dont hesitate, I like those maths talkings :)

Quote:
As for whether the FS record will work - to an extent they probably do. We use a quarter-cycle phase quadrature sine wave to track direction and speed, and FS must use the same - I mean it's obvious right? What else would you use? The difference would be in the frequency and possible the direction. This means that although absolute position detection could never work (because timecode =/= noisemap) relative mode should work, but probably at the wrong speed and maybe in reverse.

Why is it obviuos that you should use a quartert-cylce phase quadrature sine? And what is so special about? What is it anyway? I thought (from the analysis dj ville e has done some time ago) that its a simple 5kHz sine wave?

What is the reason that you have splited the timecode in a left-side part and right side part? It should theoretically work with one mono signal, or?
AJ 5:33 AM - 14 August, 2004
Quote:
So the idea is basically, get a code which has as much entropy as possible, or in an n-dimensial vector space let them have as much distance as possible...?

Sort of. The idea is to get a sequence of bits in which you can find your position uniquely in the shortest number of bits, without having to synchronise. The problem with a timecode is that you have to know where each code ends and the next begins. With the noisemap you don't have that problem because the code is continuous. At any position in our noisemap, you only have to read 20 consecutive bits to find your position, with a timecode you have to wait until you find the start of the next code, and then you have to read bits until you have an entire code. If you want to make sure you don't make a mistake, then with timecode you have to read another entire code sequence, or several. With our noise map, each bit that you read adds more confidence to the reliability of the position.

Quote:
Why is it obviuos that you should use a quartert-cylce phase quadrature sine? And what is so special about? What is it anyway? I thought (from the analysis dj ville e has done some time ago) that its a simple 5kHz sine wave?


It is just a simple sine wave, at 1kHz. I just meant that one channel is one quarter cycle ahead of the other, which is why you get a circle when you plot x vs y. It's special because when you play it backwards, the sense of which channel is in the lead changes. Or, think geometrically, the point in the circle rotates in the opposite direction. It is the same technology that has been used for decades for this type of problem, the ball mouse is a perfect example.

Quote:
What is the reason that you have splited the timecode in a left-side part and right side part? It should theoretically work with one mono signal, or?

<sigh> At the risk of sounding like a broken record (LOL!), we don't use a timecode. Furthermore, we don't split it into the left and right channel. There is one bit per cycle which is evenly spread across both channels. If you only had a mono signal, you could stil decode the noisemap, but you would not have instantaneous direction information, that is what the quadrature is for.
Stuart Ramdeen 11:08 PM - 15 August, 2004
Quote:
maximal-length pseudo random bit sequence
inear feedback shift register
quarter-cycle phase quadrature
as much entropy as possible, or in an n-dimensial vector space


holy crap. I don't think I've ever heard many of those words. I'm scared

:-D

s
DJ Dynamight 3:05 PM - 16 August, 2004
yea...the knowledge in this place gives me a warm and fuzzy feeling inside...lol
nik39 1:45 AM - 9 March, 2005
Quote:
We came up with this idea, and in our opinion it is vastly superior to timecode. The basic reason is that it has way more redundancy - each error in the sequence has a much lower impact than it would in a timecode. I can go into the details if anyone is interested.


AJ, can you maybe explain why it gives more redundancy?
AJ 2:11 AM - 9 March, 2005
Wow, talk about digging up an old thread.

Basically the redundancy comes from the fact that a noisemap is a bit sequence where every code completely overlaps the previous code except for one bit. Like this...

0001101010101001101101100010101 ... code 1
0001101010101001101101100010101 ... code 2
0001101010101001101101100010101 ... code 3

where I have made bold each code in the sequence one at a time to show how they completely overlap. Compare this to timecode...

0000000010010110 0000000010010111 0000000010011000
0000000010010110 0000000010010111 0000000010011000
0000000010010110 0000000010010111 0000000010011000

So imagine if one of the bits in the sequence had an error, in a timecode it would screw up a whole code sequence, until you hit the beginning of the next whole code but in the noise map the bit directly after the error bit would be the start of a new code every time. Basically every bit in the whole noise map is the start of a new code so you can drop in anywhere and start decoding.

Does that make sense? There is also more redundancy in the way that we encode the actual bits, because we only encode one bit per cycle, whereas the FS timecode attempts to cram as many bits as possible into a small time segment.
nik39 3:00 AM - 9 March, 2005
Quote:
So imagine if one of the bits in the sequence had an error, in a timecode it would screw up a whole code sequence, until you hit the beginning of the next whole code but in the noise map the bit directly after the error bit would be the start of a new code every time. Basically every bit in the whole noise map is the start of a new code so you can drop in anywhere and start decoding.

Okay, as far as I understand this affects the latency in the way that a correct absolute timeposition can be read faster... but I wouldnt call this a redundandy feature. Or?

Quote:
There is also more redundancy in the way that we encode the actual bits, because we only encode one bit per cycle, whereas the FS timecode attempts to cram as many bits as possible into a small time segment.

Doesnt this make work against the attempt to read faster an correct absolute position code (with the help of the shifted/cyclic timecode)?

Does this mean...
1kHz carrier = 2000 half cycles/second, so you need 20 consecutive bits, then you need 20 half cycles, equals to 10 full cycles which gives 100 absolute position codes each second, which means it takes 10ms to read the controlsignal properly?

From what I can see with the FS2 cds I have here they use one bit for each half cycle, if its a "1" the amplitude is three times higher than with a "0". I can see smaller and bigger amplitudes in SSLs control signal, but the difference is very little. Whats the reason why this difference is small/wouldnt it better to have bigger differences like in FS2 to make sure a "0" is can be distinguished from a "1"?
AJ 3:49 AM - 9 March, 2005
Theoretically this sounds like a good idea, but in practise it cause harmonic distortion because you can't follow the most important signal closely enough. The most important signal is the carrier. In usual timecode applications, the carrier signal is not important at all, but when you are scratching or even just playing audio the purity of the carrier signal is extremely important.

In this application, the position is secondary to the carrier because the carrier is measured a hundred times more often than the position code.
nik39 4:23 AM - 9 March, 2005
BTW, I have measured the SSL latency, and with a USB buffer size I get 8ms (about 354 samples) until a signal comes in, and until a proper signal comes in it takes 10ms (about 443 samples).

With FS2 and the lowest latency setting I still get 22ms (about 955 samples, first signal) and 24ms (about 1097 samples, proper signal) and that is with the lowest latency setting! (latency with highest setting 108ms!)

So in terms of latency FS2 has not improved. Sad.
s42000 5:31 AM - 9 March, 2005
Quote:
BTW, I have measured the SSL latency, and with a USB buffer size I get 8ms (about 354 samples) until a signal comes in, and until a proper signal comes in it takes 10ms (about 443 samples).

With FS2 and the lowest latency setting I still get 22ms (about 955 samples, first signal) and 24ms (about 1097 samples, proper signal) and that is with the lowest latency setting! (latency with highest setting 108ms!)

So in terms of latency FS2 has not improved. Sad.


Nik .. with that said I wonder how its doing backspins and the other stuff you mentioned in a previous post better than SSL ... voodoo ?
s42000 5:40 AM - 9 March, 2005
Refer to this thread for Nik's finds on FS2 ..

www.scratchlive.net
c-j 4:18 PM - 9 March, 2005
Quote:
I wonder how its doing backspins and the other stuff you mentioned in a previous post better than SSL ... voodoo ?


Is it?
c-j 4:27 PM - 9 March, 2005
Ahh - checked niks thread...interesting.....

FS2 didn't work for shit on my laptop, pops and clicks and stutters being understatement of the year - I use the same laptop for SSL and SSL sounds rich, full, detailed and I never notice any pops clicks or anything - YAYY!

I mix into regular vinyl too and the sound quality is not really different - regular vinyl 12"s are just a lot louder. (subjectively at least and on the meters - I don't want to argue tech stuff and mixer line channels being crap and all that)

Sound is awesome.
nik39 8:13 PM - 9 March, 2005
Quote:
Nik .. with that said I wonder how its doing backspins and the other stuff you mentioned in a previous post better than SSL ... voodoo ?

s42000, misunderstanding I guess, you should read my post thoroughly:

Quote:
1st backcueing:

Quote:
2nd sound quality.

Those (and other things) mentioned in the post have nothing to do with latency. Latency is a different subject, and I havent commented on it (except when I said "scratches sound great", they do sound quality wise).

Still questions?
lancota 12:30 AM - 10 March, 2005
Well, mucho kudos for you gettin FS to work on your system and I'm glad you happy with it!

I for one never really had to much trouble with FS1.5, aside from the arifacts (poping, garbled noises every so often). What royally pissed me off is their support... and they still haven't done a thing for that.

I'll keep SSL, specially since it's working perfectly for me these days. I only wish a lot of other people had the track record wtih FS2 like you did nik, some of those thread scare the crap outta me over at the forums....and I don't even own FS!
nik39 1:01 AM - 10 March, 2005
Quote:
What royally pissed me off is their support... and they still haven't done a thing for that.

Absolutely. My problem with FS1 was never solved neither by stanton nor my NI, allthough it has been proven that the h/w was faulty! A big **** off goes into that direction!! The german distributor (NI is based in Germany as well!!) helped me, a sad story.
JamisNemo 3:10 AM - 4 April, 2007
Wow you are all gonna love me bringing this back out of the graveyard of time but I'm stumped on this lfsr stuff.

From what I understand from lfsr's any position in the sequence depends on three things: the taps used, the previous bit sequence and the seed with which the code was created.

How is it possible then to get position data out of this?? You'd need to use a huge lookup table to find yourself within 2^20 locations in the sequence (assuming a maximal tap sequence was used and there are 20 bits in a hunk of data)

How is it possible to get such low latency if you use a lookup table??

thanks for the info and sorry again about dragging this up. I like thinking about this kind of stuff.

~jamis
nik39 9:43 AM - 4 April, 2007
Quote:
How is it possible to get such low latency if you use a lookup table?

No need to do a linear search, binary tree lookup takes exactly 20 steps. You could use an intelligent data structure which uses 20 different binary trees, or link them in a intelligent, efficient wayy.

I dont understand what you mean with "taps used" and "seed". What do you mean?
JamisNemo 3:46 PM - 4 April, 2007
The Rane Scratch code was created using a 20 bit Linear Function Shift Register. The basics of LFSR generation can be learned here (be careful, there is a mistake in the animation...):
en.wikipedia.org

The code uses high and low pulses to represent a 1 or a 0 respectively. One bit is represented in the wave form as a peak and a valley combined - one cycle. The left channel and the right channel have the exact same wave form on them except for a 90 degree phase shift. This shift can be used to figure out which direction the needle is moving in the groove.

The seed of the Rane Scratch code is, in a way, the very first 20 bits on the record... well if you take the needle and try to find the very beginning of the record by back cueing slowly you'll probably find that the needle runs off the edge of the record before the code stops.

By downloading a recording of the Scratch code cd that can be found here:
www.rane.com

it's possible to get a clean wave form of the first 20 bits in in the sequence. This is, for all reasonable uses, is the seed.

There are algorithms that can take a size-able chunk of code created using an LFSR and then give back the bit size and where the taps are taken from in the code. Using this information it is possible to create an exact copy of Ranes code. I won't post the taps here I'm sure Serato/Rane wouldn't like that too much and it took me some time to figure it out but really it was just a fun test to see how exactly LFSR's work.

After thinking about it more last night I figured that a lookup table wouldn't be all that slow. It's possible to step through the entire LFSR code in under a second (that's 2^20 bits). I wish there was a way to calculate the position in an LFSR using the seed and the taps and the distance out from the seed but a lookup table does seem rather manageable.

Rane really does have their act together. Using and LFSR takes a large number of noise checking and data accuracy technics from the communications field and applies them to better tracking and position error checking.

What does somewhat disappoint me is that they don't really need to have an external box for all of this. It should be possible to plug two turntables into two sound card inputs and then have the audio go to the mixer from the sound card outputs. No extra box or cables in the dj booth. It'd be just the same amount of cables as having a computer and two turntables hooked up to the mixer.

By including the "magic box", Stanton/NI, Serato/Rane and all of the other (about 4) companies that create control vinyl can up the price of the setup well over $200. If were possible to use these magic boxes in the way they were originally designed (a 4x4 usb audio interface.... two stereo inputs two stereo outputs) their price may be a *bit* more reasonable... but in my opinion, after learning what I have about Stanton/NI and Serato/Rane, I must say it's kind of cagey to charge a list price of $800 for either option with the audio interface combined with the price of the software.

Along with this, It should be extremely easy to allow either box to work with either software... but they're competitors so the options available to the public are diminished even more.


Thanks for the information! It was a fun task to figure it all out and Rane/Serato, very good thinking on the choice of code. It is really much more intelligent then the others out there.

p.s. I haven't figured out how the scroll section on the record works yet... I haven't looked at it yet...
nik39 5:12 PM - 4 April, 2007
Thanks for the wiki link, now I know what you mean with the terms.

Quote:
After thinking about it more last night I figured that a lookup table wouldn't be all that slow. It's possible to step through the entire LFSR code in under a second (that's 2^20 bits). I wish there was a way to calculate the position in an LFSR using the seed and the taps and the distance out from the seed but a lookup table does seem rather manageable.

One second for one lookup is by far not sufficient, remember you have like 1000 a second. But as said before, use a binary tree to represent 2^20 combinationas, use 20 different trees (or a data structure which uses pointers to pack all 20 trees into one) and you can find out the proper position within 20 edge traversals, which should be more than sufficient.


Quote:

By including the "magic box", Stanton/NI, Serato/Rane and all of the other (about 4) companies that create control vinyl can up the price of the setup well over $200. If were possible to use these magic boxes in the way they were originally designed (a 4x4 usb audio interface.... two stereo inputs two stereo outputs) their price may be a *bit* more reasonable... but in my opinion, after learning what I have about Stanton/NI and Serato/Rane, I must say it's kind of cagey to charge a list price of $800 for either option with the audio interface combined with the price of the software.

You have to keep in mind that with the box you charge (thats the only way to make money, if you give away the software *and* all updates for free!) you have to pay *all* costs, R&D, marketing etc. Remember... they are constantly updating the software, and they havent charged a single cent from the users which bought the box 3 years ago. So that may explain the price. Also Rane is known to give superiour customer service. This has to be funded - by sales. Thats how it goes.

Quote:
Along with this, It should be extremely easy to allow either box to work with either software... but they're competitors so the options available to the public are diminished even more.

Yep.


Quote:
p.s. I haven't figured out how the scroll section on the record works yet... I haven't looked at it yet...

I think this is just a part of the 'timecode' which is used for scrolling. So the original maximum control-signal sequence goes about 17:28 minutes, you use the first 15 minutes for 'normal' control and map the remaining 2 1/2 minutes to scroll selection.
JamisNemo 6:58 PM - 4 April, 2007
Quote:
One second for one lookup is by far not sufficient, remember you have like 1000 a second. But as said before, use a binary tree to represent 2^20 combinationas, use 20 different trees (or a data structure which uses pointers to pack all 20 trees into one) and you can find out the proper position within 20 edge traversals, which should be more than sufficient.


Since the time it takes to count up through 2^20 is less then one second, I'm sure it wouldn't be any issue at all to do a lookup 20 deep in a tree.

So, I agree, it is doable! :D

Quote:
You have to keep in mind that with the box you charge (thats the only way to make money, if you give away the software *and* all updates for free!) you have to pay *all* costs, R&D, marketing etc. Remember... they are constantly updating the software, and they havent charged a single cent from the users which bought the box 3 years ago. So that may explain the price. Also Rane is known to give superiour customer service. This has to be funded - by sales. Thats how it goes.


ah true... and I'm sure a bunch of people would rather have a usb box to plug into their laptop instead of trying to get a multiple input multiple output sound device on their own.

Quote:
Quote:
Along with this, It should be extremely easy to allow either box to work with either software... but they're competitors so the options available to the public are diminished even more.

Yep.


Maybe now that the whole final scratch thing is falling apart with regards to support maybe rane will make some hack that lets users use final scratch vinyl as well as rane...... even if the final scratch code isn't as good...


Quote:
Quote:
p.s. I haven't figured out how the scroll section on the record works yet... I haven't looked at it yet...

I think this is just a part of the 'timecode' which is used for scrolling. So the original maximum control-signal sequence goes about 17:28 minutes, you use the first 15 minutes for 'normal' control and map the remaining 2 1/2 minutes to scroll selection.


That's what I was guessing and also why I haven't bothered looking at it yet.

thanks for the discussion!
nik39 7:11 PM - 4 April, 2007
Quote:
Since the time it takes to count up through 2^20 is less then one second, I'm sure it wouldn't be any issue at all to do a lookup 20 deep in a tree.

I am not talking about a linear search, don't know if that is clear or not.
cmos master 11:45 PM - 11 May, 2007
Wow Rane! Nice work with the LFSR idea.

So for those of you wondering why the latency is so much less with this LFSR design vs the lookup table design from FS here is my modest attempt at a simple explanation:

LFSR:
You need a minimum of 20 bits that match an LFSR code(the output of the LFSR changes to let you know you are in sync), of course it doesn't always happen with the first 20 bits because you might have some bit errors, so it won't sync until you get at least 20-bits in a row without errors. Once they sync, they still have to do error checking to account for single bit errors and such, basically this is the same thing as CRC. You might be familiar with that term from TCP/IP. So most of the time, clean record, clean needle, clean power, 2kbits each second, it takes about 1/100th of a second to sync, or 10ms.

Lookup table:
You have to wait for several whole timecodes to be read in by the SW to make sure they are in the right order and to find your location in the table. The time codes stream in serially, so you have to figure out where the boundaries are by reading in several codes and trying to match that sequence of codes to somewhere in your table. Two slow things, 1) reading in a few codes 2) hashing through your table. I don't know how they did their timecode design or how many bits per timecode, so I can't say exactly what the expected delay should be, but it will behave much worse with bit errors than lfsr. Meaning you need to have a better needle, cleaner Vinyl, etc.


Hopefully that gives you a bit more layman's explanation to why LFSR is twice as fast, and stemming from that thought, why Rane/Serato is a cut above...
nik39 11:49 PM - 11 May, 2007
Quote:
ou might be familiar with that term from TCP/IP. So most of the time, clean record, clean needle, clean power, 2kbits each second, it takes about 1/100th of a second to sync, or 10ms.

1kbits ... 20ms.
nik39 11:50 PM - 11 May, 2007
Oh, and BTW, this was Serato's idea, not Rane's ;)
cmos master 11:53 PM - 11 May, 2007
wait, i thought a half cycle was a bit....
nik39 11:56 PM - 11 May, 2007
Quote:
Does that make sense? There is also more redundancy in the way that we encode the actual bits, because we only encode one bit per cycle, whereas the FS timecode attempts to cram as many bits as possible into a small time segment.
cmos master 11:57 PM - 11 May, 2007
to clarify, I said

2kbits/sec = 20 bits in 1/100th of a second = 10 ms
cmos master 11:58 PM - 11 May, 2007
Huh, that seems confusing to me, since you have a positive half and a negative half to a sine wave, why wouldn't they take advantage of that?
s42000 8:19 PM - 29 June, 2007
*smiles*

*smiles again*

Every time I have a headache I come to this post. Calms the nerves :)

Carry On!
DJ_Mike_Coquilla 4:09 PM - 10 July, 2009
Wow, lotsa knowledge throwin down up in here
DJ_Mike_Coquilla 4:10 PM - 10 July, 2009
[Stares closely @ the groove of the control vinyl]
Carldee 2:08 PM - 6 August, 2009
+1


And there was me just thinking it was a 15 minute long "Beeeeeeep"
Konix 2:26 PM - 6 August, 2009
Talk about bringing a thread back from the dead. An oldie but a goodie. Lots of knowledge and info here.
nik39 1:13 AM - 19 December, 2011
g33kt4Lk
WarpNote 12:08 PM - 19 December, 2011
Quote:
g33kt4Lk

Watchwww.youtube.com
dave 6:03 PM - 19 December, 2011
Quoting AJ in this thread, back in 2005
Quote:
Wow, talk about digging up an old thread.
msoultan 2:52 PM - 12 February, 2012
I apologize if I missed it, but is there a reason that the code can't be extended to, say, 60 minutes?