Support
Looper's Delight
|
Support |
|
|
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