[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Date Index][
Thread Index][
Author Index]
Re: Building a rackmount looping computer as an alternative to the Receptor for Mobius
At 04:56 PM 10/14/2005, phaslem@wightman.ca wrote:
>a few people have argued against a software looper... but when I had my
>edp
>apart, my tech friend said "lets see, here's your processor, here's the
>ram,
>here's the software... looks suspiciously like a dedicated computer to me"
Well, yes of course! And by that simple evaluation, your dishwasher,
television, and anti-lock brakes are also computers. They all have a
processor, memory, software, etc. So does a ton of other stuff lying
around
you.
Except for really ancient devices from more than 25 years ago, all the
loopers we discuss here are software. Some of them run in their own
dedicated hardware, and some do not. This is why software upgrades are
available for "hardware" loopers like the JamMan, Repeater, Boomerang, and
the Echoplex.
>Why not set up a laptop or rackmount computer as the dedicated looping
>machine?
One reason not to (besides some of the others discussed) is the same
reason
why you would not want a windows/mac/linux computer controlling your
anti-lock brakes. There is more to computer system architecture choices
than just having a cpu, memory, and some software code. Once distinction
in
computer systems design is whether it is a "real-time" system or not.
In computer engineering terms, a Real-Time System is defined as one that
will respond to an event and execute the required function within a
guaranteed amount of time. No matter what else the system is doing, it
will
respond in time to every command. A non-real-time system does not make
that
guarantee. It might respond in time, but it might not if it is busy with
something else. So when you brake hard and the wheels start to lock up,
sensors warn the real-time brake computer, and it responds very quickly to
prevent you from losing control and crashing. If it were a non-real time
system and it happened to be busy downloading a new security update for
you
at that moment, or checking its temperature, doing some other function,
well too bad, the brakes will have to wait and you might die. You probably
wouldn't want that.
While not quite so life-and-death critical, all electronic musical
instruments are similarly designed as Real-Time computer systems. The
hardware architecture is designed for real-time, it runs a Real-Time OS,
and the software applications and functions running on top are tuned to
this real-time environment. These electronic instruments are designed this
way because musicians care a lot about rhythmic accuracy, and they want
their instrument to respond in time so they don't get off the beat.
If a drummer is playing a little bit ahead of the beat to get the right
feel, he wants it to come out that way every time he strikes the pad. He
won't be happy if 1 in 10 drum hits come out behind the beat when he
played
them all ahead of the beat. When a keyboard player plays a chord, he wants
the notes all coming out together as he played it. He won't be happy if
most of the notes come out together but some notes come out a little bit
late. And of course nobody is happy if some audio samples don't come out
in
time and there is a pop through the speakers. A real-time system can
guarantee that none of these problems happen.
Synchronization is also important, as we often have multiple devices
working together at the same tempo and rhythm in our music. As
synchronization commands are coming in, we want all the devices to respond
accurately and stay together in tempo. Otherwise we might get drifting or
rhythmic flams or whatever. A real-time system can guarantee that every
time a sync command comes in, the system will respond in time to match the
rhythm. And when our device is the one sending the sync commands to other
devices, The real-time OS will also guarantee that it sends them reliably
on time. There won't be "jitter" due to some commands going out a little
later than others.
And so it is with Looping. We want our looper instrument to work in a
reliable real-time fashion. We are constantly tapping buttons and
executing
functions on our looper in time to music, and we want it to respond
reliably every time. We won't be too happy if one time out of every 20 it
waits an extra 40ms to react when we press record. or if 1 in 500 times it
waits an extra whole second. We want it to react fast and responsively and
reliably the same every time. We also want it to synchronize reliably,
whether master or slave.
So if a Real-Time system has all these neat advantages, why isn't
everything designed that way? The reason is, if you wanted to make a
general purpose computer that could support many types of applications,
allow all sorts of different peripherals, run all sorts of different
programs, be easy to program, etc., a Real-Time OS would just not be
practical. It is too unforgiving and difficult to work with, and there is
no way you would be able to get all that stuff to work together smoothly
and be easy to program for others.
And so that's what you have with your PC. Windows, Linux, and MacOS are
all
non-realtime operating systems. They can't guarantee that every command
will always be executed in a specified time. But in turn you can use it to
browse the internet, do your accounting, write a novel, play doom, listen
to music, watch a DVD, change your graphics card tomorrow, etc etc etc. It
can do some of everything. It even has some pseudo real-time features,
with
interrupt classes that allow for higher priorities. A smart programmer
will use those to improve their performance when some sort of real time
action is needed. But ultimately the system reserves the highest
priorities
for itself, and there is no guarantee that something else won't get in the
way and delay your function longer than you expected. You can disable
stuff, uninstall stuff, remove the spyware, tweak it this way and that,
and
it might work better. But in the end you still don't have a real-time
system and there is still a real probability that some commands won't get
the real-time performance you want.
So, what performance is really required? Every time this comes up I hear
somebody whine about how they don't notice any problem with using their PC
for music. And probably they don't, but I usually check what they do
musically to see why. Mostly I notice two things. One is they have limited
their music to fit the limits of the PC, such that they really aren't
doing
anything that requires tight rhythmic interaction. For example, rather
that
performing a percussion part, they queue up a percussion loop several
beats
ahead. And the second thing I notice is some of these people just don't
have a very good sense of rhythm anyway and probably wouldn't notice if
something was off by 40ms. (haha, sorry, just being needless mean there.:-)
What the musical science and psychoacoustic types say is humans can detect
10ms of latency between an action and hearing it. Less than that and you
can't tell. More than that and people can hear it, but they can
adapt. HOWEVER, (and this is the key part), humans can detect variations
in that latency as low as 1ms. This is especially true of musicians who
have a well-trained sense of rhythm. This variation is also called jitter,
and you can't adapt to jitter. If the jitter is too big, the musician will
have a hard time playing it with the rhythmic feel they want and they will
find this instrument to be irritating.
So those are the specs you would target if you were trying to design a
good
real-time electronic musical instrument. You would use a real-time
hardware
design, a real-time operating system, and you would design it to guarantee
somewhere around 1ms of latency for all commands the user can execute, at
all times. This is what we did in the EDP for example. The Echoplex
responds to any command from the front panel or footpedal within 1.5ms,
guaranteed. For midi it is even faster since it doesn't need to debounce a
switch. For that I think it is guaranteed at 0.5ms. No windows, macOS, or
linux machine can come even remotely close to that kind of real-time
performance. The raw latency is much higher, but worse, the variability in
latency is a LOT higher. There is always a significant probability that
some action will come later than you expect.
So there ya go. if your sense of rhythm sucks, perhaps a laptop looper may
be just the thing for you! (sorry, just being mean again :-)
>It would cost what, 12 or 13 thousand to duplicate what mobius will do
>with edp
>units! and that doesn't even consider the nightmare of trying to wire up
>and
>control 16 edp's
Well, you also have to consider the whole ethical dilemma there, and what
your conscience allows.
>When you start comparing what you can do with the software vrs the
>hardware
>versions, I think the software will win out...
As noted before, They are all software. That already did win. Everything
has a computer in it, running software.
Or probably you mean "the PC platform hardware will win out." In that
case
I have story for you. For most of the last 10 years I've been engineering
and architecting PC platforms. There's always some project going on to
design a "PC that does it all", and takes over some bunch of functions
from
something else. The PC is going to replace the TV, DVD player, vcr,
telephone, thermostat, home security system, washer/dryer, car stereo,
your
girlfriend, blah blah blah. Never happens. Sure some people get enamored
with this idea and there are always a few people who do this, but even I
never stuck a PC in my living room and tried to pretend it was better than
my TV and Tivo. (I sure wish my marketing teams were right about this
stuff, because I would be a lot richer.) In the end it comes down to user
interface and applicability to the job. The device designed just for the
job will do it well and people find it satisfying and usable. The general
purpose device may be able to do many different jobs, but it does none of
them particularly well. Jack of all trades, master of none.
And so this idea of making the PC do everything is kind of an old, yet
tired dream that keeps coming back. It is kind of funny to me to see
musicians coming to it so many years after other industries stumbled
around
with it and couldn't really make it happen. But when I look around me, the
real direction I see is not centralizing everything in one place. What I
see is decentralized - a variety of small, portable devices, well made for
their application, well integrated into their environment, and everything
networked and able to talk to everything else. It's about ipods and cell
phones and car navigation systems and PSP and Tivo even smart
refrigerators. The guy who said the network is the future was the smart
one. Music gear will eventually catch up, but I expect it will be years
late, as usual.
kim
______________________________________________________________________
Kim Flint | Looper's Delight
kflint@loopers-delight.com | http://www.loopers-delight.com