has anyone looked at the distribution of linux that FinalScratch comes with?
I read on their website that you basically install their distribution of
linux and use it, along with their program for selecting audio files, to
play their electronic turntables. I'm just wondering if there was anything
in particular they tweaked for realtime response or if they used the same
low-latency patches as the rest of us?
In case you've never seen it in action, final scratch is a record sized disc
that you place on a turntable that reports it exact position to some sort of
computer interface. The position signal is then used to control playback of
audio files (pcm or mp3) on the computer. You load a file into the program
and mark a certain point as the current point on the record and then the
playback and cueing of the file can be done entirely on a regular turntable
as if you were playing a record. Given that this is just a piece of
hardware, I'm wondering what would stop you from hooking up the hardware to
a regular version of linux.....
besides using a proprietary interface i mean.
--jacob robbins:::::::
_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
What am I missing here? I don't mean to tell the direction from the time,
but to tell the position from the time. The sawteeth all look the same,
right? Don't we need to tell position somehow?
-----Original Message-----
From: Steve Harris [mailto:S.W.Harris@ecs.soton.ac.uk]
Sent: Tuesday, October 08, 2002 8:59 AM
To: 'linux-audio-dev(a)music.columbia.edu'
Subject: Re: [linux-audio-dev] Final Scratch, custom kernel?
On Tue, Oct 08, 2002 at 07:17:43 -0600, Cornell III, Howard M wrote:
> But encode the time so that it can be read forward or backward.
You dont have to, because you know what direction its being read in from
the saw.
An obvious problem is if you jump, then hold the disk and let it turn
slowly, it might take a fair turn before the position can be read...
45rpm = 1 1/3 sec per rev
assume 2400 baud timcode, 16 bits of timecode info (inc. stop bits etc)
= 13.3ms for 2 whole timecode blocks
therefore (max) 1/100th of a revolution to pick up the timecode position
= 1" at the edge of a 12" record. min would be 1/2"
hmm... that doesn't sound too bad to me, and you may be able to get better
than 16bits @ 2400 baud.
- Steve
> It doesn't need an extension to the API, you just have to be able to make
> input -> input connections. I belive that makes more sense in an abstract
> sense (eqivalent to wiring it that way in hardware) and internaly (reduced
> complexity).
This will work if the powers that be agree to allow input -> input
connections. If not, there is another way. In a hardware mixer,
many-to-one connections always require a bus, which is nothing more than
a unity gain summing node. Since jack performs unity gain summing for a
many-to-one connection, then the buffer that the sum is written to could
be redefined as a bus. Then any client could read from the output port
of this bus. I am not necessarily in favor of this, nor am I against
it. I don't know enough about coding to have an opinion either way.
What I do know is that this approach preserves the output -> input
semantics.
Tom
But encode the time so that it can be read forward or backward.
-----Original Message-----
From: Steve Harris [mailto:S.W.Harris@ecs.soton.ac.uk]
Sent: Tuesday, October 08, 2002 2:52 AM
To: linux-audio-dev(a)music.columbia.edu
Cc: Paul Winkler
Subject: Re: [linux-audio-dev] Final Scratch, custom kernel?
On Mon, Oct 07, 2002 at 02:33:54 -0700, Paul Winkler wrote:
> Encoding stereo to an LP is no problem - the needle vibrates along
> two axes. There's a limit to how much stereo separation you can
> get (I forget, it might be like 40-45 dB) but that shouldn't be
> too hard to account for.
OK, but as long as there are no other restrictions on the channels it
should be no problem, something like a saw on one side (to detect speed
and corresponding carrier wave speed), and an AM modulated timecode signal
on the other.
Use the say to calculate the carrier wave for the 2nd channel, then decode
the timecode.
- Steve
Tk Ecasound 0.6.0 was released!
Dowload it: http://www.sourceforge.net/projects/tkeca
Changes:
- Options button works . Allows to edit ecasoundrc file
- Entry for selecting current directory
- Bug fixes on "Save as" button, open file where there was an existing
project, play with choosing a different device (<> /dev/dspN)
- Autodetect external audio editor and ladspa directory
- Visual changes in effect windows
Regards,
Luis Pablo
Cobertura especial de la Copa Mundial de la FIFA Corea-Jap�n 2002, s�lo en Yahoo! Deportes:
http://ar.sports.yahoo.com/fifaworldcup/
Interestingly enough, the FinalScratch system does not allow cueing to
different positions in the record by lifting the needle up off the record. I
saw Richie Hawtin playing on one in DC and I didn't realize what it was at
first. I was really perplexed because it seemed like everytime I looked up
he was just at the beginning of a record: the tonearm was always very far
out towards the edge of the record. Then I figured out that he was using
final scratch because he was picking the tracks from a laptop nearby running
a program that was basically two lists of tracks. I didn't even think the
position signal was running through the audio, I thought they had a separate
system magnetically measuring the record position. But it must be something
like the saw tooth signal described in this discussion.
I wouldn't worry too much about using the cueing of the needle on the
record to move through the track. It's more useful on a real record because
different sections of a track actually are visible to the naked eye on black
vinyl, which jogs your memory into remembering the layout of the track. The
final scratch record must have a single loop out at the edge of the record.
Such a loop is called a locked-groove when put on a real record: certain
styles of dance music have a convenient bpm that allows putting a complete 4
bar pattern into one seamless loop towards the end of the record (the
middle). I've only encountered this in techno tracks. There can be a
complete track which ends by moving into the lock groove which plays
endlessly until the dj stops the record. The beat must perfectly fit one
rotation of the record in the lockgroove or else the rhythm will be broken.
The same constriction applies to making a lock groove of a control signal. I
am convinced final scratch records have a few locked grooves of a control
signal at the edge of the record.
Adding positional cueing would be a nice feature but consider some of
the following circumstances: -you have to put a lock groove at the end of
the spiral groove anyway or else you limit the length of track that you can
control to some arbitrary amount of time. -if you try to get around this by
making a 30 minute track you'll find that the groove is cut smaller so that
the record will wear faster and will skip much easier when you scratch it.
This is why dance singles have one 6-10 minute track cut on the entire side
of a 12" record; record wear is a factor for a dj playing a track many times
and bigger grooves hold up longer to repeated playing. They will also sound
better longer which is not really an issue here. records tend to wear by
pushing towards the outside of the groove from centripedal acceleration. -if
you make a 10 minute position-coded section leading into a lock groove you
will have to have the standard width of the 10 minute section map to the
length of the entire track being played. This means that moving the needle
to the middle amounts to saying "move 50% of the way through the track"
(which is pretty useful). But it's probably going to end up being easier to
cue through the software. Hell it will be easier to do everything through
the software. The only advantage I see a turntable controller having is for
scratching effects and for dj's who don't want to carry a lot of records.
And maybe for beatmatching audio files but programs are leaning towards
doing that ahead of time (GDAM). As such I wouldn't worry too much about the
positional thing, in favor of getting very tight velocity response for
scratching and beatmatching. 8 ms will kill you in beatmatching and final
scratch has to have closer than 8 ms "grip" on the audio file being
controlled. ~4 ms off is audible phasing. I think it's very interesting to
investigate it but it might be easier to just cut a lock-groove control
signal and not bother about encoding digital signals on a record.
---jacob robbins;;;;;;;;;
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
---------- Forwarded message ----------
Date: Mon, 7 Oct 2002 23:07:47 -0400 (EDT)
From: J.F.Quackenbush <hormonex(a)yankthechain.com>
To: linux-audio-dev(a)music.columbia.edu
Subject: Re: [linux-audio-dev] Final Scratch, custom kernel?
On Mon, 7 Oct I wrote:
records include stereo information by having different sounds on each wall
of the groove. It seems like teh easiest solution would be to just write
SMPTE LTC to one side and something like word clock or black burst on the
other.
<relurk>
I just read this and realize that I was wrong as this reads. One track is
recorded in the depth of the groove, the other in the width, so the needle
vibrates up and down and side to side simultaneously creating two separate
signals. just wanted to clarify.
<relurk again>
--
/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\
YankTheChain.com - You can pretend we're not here. That's what I do.
http://www.yankthechain.com/http://www.digitalblack.org/
I read:
> Well i guess encoding absolute time should not be too hard.
> A simple solution could be to have the two stereo channels with different
> frequencies, with the ratio corresponding to the radial position.
forget it there is no such thing as a clean channel separation on
vinyl.
regards,
x
--
chris(a)lo-res.org Postmodernism is german romanticism with better
http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)
here's how i do it:
1st channel:
1.5khz control tone
2nd channel:
bits encoded as follows:
0 : 1 3khz cycle
1 : 2 6khz cycles
marker: 1 1.5khz cycle
so each timecode looks like this:
marker cycle
encoded 0
checksummed bit sequence
encoded 1
marker cycle
each one ends up being about 8ms. so my "latency" is better than theirs!
[i'm pretty sure finalscratch's 12ms assumes the record is moving at
normal speed]
since the frequencies are multiples of each other, the crosstalk from the
cutting head or even from the cartridge that gets used is mitigated
the 0 and 1 starter bits help figure out what's going on depending if the
record is playing backwards or forwards
counting zero crossings works...but don't forget to filter out the low
frequencies [like 80hz and below], since the noise from the person's hand
will fuck things up
i'm fiending to buy one of the finalscratch control records [the guys at
platinum are telling me they're gonna be like 25 dollars], to see what
they're doing
--
John Ketchpaw
kungfu(a)alumni.cmu.edu
On Mon, 7 Oct 2002, CK wrote:
> I read:
> > Well i guess encoding absolute time should not be too hard.
> > A simple solution could be to have the two stereo channels with different
> > frequencies, with the ratio corresponding to the radial position.
>
> forget it there is no such thing as a clean channel separation on
> vinyl.
>
> regards,
>
> x
>
> --
> chris(a)lo-res.org Postmodernism is german romanticism with better
> http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)
>
>