"Real" emulation...

From: John Lawson <jpl15_at_panix.com>
Date: Sun Jan 7 12:27:10 2001

  While mulling over some ideas for software music synthesiser programs [I
just bought a copy of Reaktor - a software synth/sampler construction kit
of amazing complexity] I started wondering just how close to 'real' an
emulator ought to be. For example, the MiniMoog emulator has a replica of
the add-on A-400 oscillator, used to tune your Moog back up as it drifted
off pitch, which they all did more or less constantly. The documentation
mentions retaining this feature even though the emulation no longer
drifts.

  But: why not? Shouldn't it drift, actually?

  So I ask from a "purist's purist" view... shouldn't an emulator contain
"failure modes" common to the machine emulated? And if it "breaks", then
the poor "operator" is afforded the opportunity to diagnose and then
(hopefully) "fix" the problem.

  My experience with the various PDP-11 systems I owned was like this. I
spent a *lot* of time doctoring the hardware.

  The same thought could be applied to a software Moog Modular synthesiser
system. If a module 'breaks', you have to open up the code, find the
'defective' module and 'fix' it. One could continue this thought right
down to having models of components, a la SPICE and the other design
modelling software. Each component or module would then have a live/die
algorithm associated with it.

  Imagine how thrilled Tony Duell would be with a PERQ emulator that
exhibited random 'hardware' failure modes (based on maintenance histories)
that then needed to be repaired at the 'component' level. Running, of
couse, on a palmtop.

  Hopefully one could as well disable the "real-world hardware failure"
mode, in the case of wanting to just do something trivial, like program
the thing.

  Silly questions, but also maybe valid....

  Cheerz

John
Received on Sun Jan 07 2001 - 12:27:10 GMT