As you might know (if not, have a look at page 202 of
your manual :) the waveform can range between 0 and 255 - normally, the
user can access only 0 to 74 (SAW to DRUMS5) on the SQ80, or 0 to 31 (SAW to) on the ESQ1. Each of these waves is in fact a "virtual" waveform made up of 16 multisamples built from individual key zones with 8 semitones resolution. This zone entry points to a waveform parameter set (raw wave, coarse & fine tune plus an additional parameter).
How to access
Normally, we can't access waveforms above 74 (SQ80) or 31 (ESQ1) -- but by editing program dumps we can. If you want to experiment yourself, the oscillator waveforms are stored at positions 0x56, 0x60 and 0x6a of an SQ80 toolkit's program dump (or at these locations plus P times 102 if you want to edit bank dump files, P is the program number ranging from 0 to 39). The OS is prepared
for these unusual waves since it lists them as WAV075 to WAV255 (ESQ1: WAV032 to WAV255). But what does happen internally?
Tech Talk (referring to SQ80 OS 1.8 / ESQ1 OS 3.5)
Looking at the OS sources, we know that the wave number is multiplied by 16 and taken as an offset to the multisample table base (pointing to the appropriate waveform -- read: multisample), the played note (MIDI key value) is divided by 8 to get the referring offset to the respective raw sample pointer (multisample zone) -- this pointer now is multiplied by 4 and taken as an offset to the raw sample parameter base. (Confused now? Read again slowly }:-)
Now, what a "hidden" waveform really does is just pointing somewhere "behind" the multisample table accessing a whole 4k memory area of ROMLOW as multisample table . These values are taken as an offset for the raw sample parameter table : If the addressed raw wave is between 0 and 150 just the ordinary waves with their parameters are accessed, between 150 and 255 we point somewhere "behind" that table into other tables or even menu routines which results in wrong wave offsets (accessing wrong pages), incorrect wave sizes and weird playback frequencies.
From this it's clear that these hidden waveforms might sound different on diverse OS releases as that tables and code behind the wave might not be the same on the various OS revisions.
Why are the hidden ESQ1 OS3.5 waves more usable than their SQ80 OS1.8 counterparts?
ESQ1 OS3.5 is a backport of SQ80 OS1.8. Interestingly, the Ensoniq engineers -- while removing all other unnecessary parts like the floppy menu routines, certain keyboard processor communication, and also the extra wave names for waveforms 32-74 -- left the multisample and raw wave tables intact. This means that WAV032 to WAV074 on the ESQ1 are still using "sensible" multisample zones and, likewise, also sensible raw-wave paramters. It's just that the corresponding raw waves are not present, therefore waveform memory access gets mapped to the ESQ1's 64kB of waveform memory.
For the SQ80, however, the first "hidden" wave is WAV075. By doing so, four sets of raw-wave parameters are interpreted as one multisample set, therefore giving a very uneven wave-to-zone assignment for those 8-key wide multisample zones.
So what does it sound like?
With the exception of WAV032 to WAV074 on the ESQ1, these hidden waveforms are mostly rather unusable in a musical sense since the waveform changes drastically from one sample zone (8 keys) to another. But if you stay within a zone you can get very athmospheric, dense and noisy sounds- sometimes you hear the waves you already know but somewhat distorted, crackling or with a underlying hiss. If you are composing "ambient" music such as Future Sound of London (just to name an example I like very much) you might find these waveforms useful (especially when playing melodies you get some sort of rhythmic "wave sequencing" due to jumping between very different waves).
What about expanding waveform memory?
Looking at the OS, that's a straight-forward task: We just need to point to different memory locations holding multisample zones and raw wave parameters. Unfortunately, however, there's not much space left in the OSROMs so we need to do this in an extra memory area or using some more elaborate hardware hack not wasting about 2kB just for sample management. But the hardest part is making the DOC address more than 256kB of memory. In fact, it is only designed for addressing 128kB of memory in total! For the SQ80, the Ensoniq engineers were already using a hack by interpreting the fourth (and therefore unused) audio channel address as an additional waveform address.
|