[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 
>apart, my tech friend said "lets see, here's your processor, here's the 
>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 

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 

One reason not to (besides some of the others discussed) is the same 
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 
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 
respond in time to every command. A non-real-time system does not make 
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 
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 
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 
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 
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 
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, 
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 
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, 
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 
anything that requires tight rhythmic interaction. For example, rather 
performing a percussion part, they queue up a percussion loop several 
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 
real-time electronic musical instrument. You would use a real-time 
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 
>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 
>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 
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 
something else. The PC is going to replace the TV, DVD player, vcr, 
telephone, thermostat, home security system, washer/dryer, car stereo, 
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 
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 Flint                     | Looper's Delight
kflint@loopers-delight.com    | http://www.loopers-delight.com