DSP Robotics Support

Please, if anyone of the community has an electronics background and can read and comprehend this manual for the DOC of Ensoniq's ESQ1/SQ80 (model name ICS 1261), then step in and help! What I need to know is the start addresses and the lengths of the waveforms, the oscillators of this chip play. It is documented in detail, but I just don't understand it.

Even if you just get us one step further, that's would be double as far as we are now!

Please consider helping. Thanks!

(After you read the 12 pages, on page 11 there's the table that is meant to read the addresses and lengths)

http://buchty.net/ensoniq/files/ics1261.pdf

You may also want to have a look at this spreadsheet, that's said to contain "the layout of the multisample tables and raw wave parameters":

http://www.buchty.net/ensoniq/files/waves.pdf

Hi tulamide

I’ve been following the thread on the SynthMaker Bundle topic and got progressively more interested (as soon as you mentioned electronics actually), but I’d like a bit more time before I open my mouth. I’m not ignoring this and have some views which I need to support first.

Hopefully tomorrow…

Cheers

Spogg

Jeez this took me back to making my own microprocessor keyboard days.

Their system is so clever and it simply amazes me what they did to get so much out of such low clock rates and little memory. Fascinating!

First off, everything tulamide found out I agree with completely. I took my own path and came to the same destination.

What threw me for a while was that there seems to be an error in the chip documentation. If you have a larger wavetable you have to read it out faster to achieve a given pitch, not slower. They inverted the meaning. My guess is the document writer was not the designer.

Anyway, the WSR value in the spread sheet gives more information than we need in fact.

The lowest 3 bits (0 to 2) are for the resolution value and this is only needed for the DOC hardware to get in the right range for the pitch called for. Bits 6 and 7 are for the ROM address decoder, so again we don’t need them. What we do need is bits 3, 4 and 5. These 3 bits describe the code for table size (5 is the MSB). See the chip spec sheet table below.



The wave ROM is divided into blocks or "pages" of memory. Each page is 256 bytes long. A waveform can be made up of several whole pages concatenated, or can be a minimum of 1 page (256 bytes).

So we take the base address (starting address of the waveform) from the Wave ROM page in the spread sheet. Then we look at the 3 relevant bits (3, 4 and 5) to find the size of the whole waveform table, from the table above. Then we divide this size by 256 to find the number of pages used up. If we then add this value in hex to the base address we get the end of file/start of next wave in the ROM.

I’ve checked this method on several randomly selected entries and it’s always worked. I see that the later ROMs #2 to #4 contain much longer waves so there are fewer available in the memory space.

So, to sum up:

The start sample number for a waveform is the Wave ROM page number x 256 (all in decimal).
The end sample number is the start number + the sample number given by the table, based on the 3 bit code embedded in the WSR value. Of course it’s a zero-based count so the first sample is numbered 0.

Here’s a worked example:
If we look at ROM #2 “bowing 2” the WSR is 74h so the binary is
01110100
which means the length is referenced from xx110xxx and we look up 110 in the table to be a length of 16384 samples which is 16384/256 = 64 pages. In hex this is 40h. The base address of the wave in hex is 40 and, sure enough, the next wave starts at 80h. So this complete waveform starts at sample no. 16384 and ends at sample number 32767 (not 32768 because that’s the start of the next waveform).

I do hope this helps the cause!

Cheers

Spogg

Fantastic, Spogg!

I don't know how you made sense of the document, but everything you explained makes sense. I'm still not sure if I understand how the spread sheet works, but I guess it's asked too much to give me exactly what you did in the example?

So this complete waveform starts at sample no. 16384 and ends at sample number 32767 (not 32768 because that’s the start of the next waveform).

These numbers are, what I would use in the ripping code to extract the waveform. I just guess it, but it is a lot of work to get from the page numbers to these exact sample numbers?

Anyway, that was extremely helpful! It gives me hope to extract those pesky waves soon!

Thank you so much!!!

No probs! It “only” took me about 7 hours of reading, re-reading and analysing the chip data along with the spreadsheet! I did enjoy the challenge.

I’m a bit worried that you didn’t quite get the process for extracting the start and end sample numbers in the ROM image though. It’s not so easy to explain such a thing clearly.
One thing you can leave out is the number of “pages” in use. I talked about that for the detail of how I proved the method worked with the spreadsheet.

I’ll try another tack:

- Convert the Wave ROM page number from hex to decimal. This is the Starting position in the next step:
- Start of desired waveform index (sample 0) = Starting position x 256
- Length of waveform is looked up in the table based on the bits 3, 4 and 5 in the WSR entry. (I used the Windows calculator to convert the WSR value to binary first, so I could see the 3-bit code I wanted)
- End of waveform (final sample) = Start of Waveform index + Length -1

Maybe that helps?

I think you could write a bit of Ruby code where you input the base start value in hex and the WSR value in hex and, provided you have the lookup table involved, it could spit out the actual decimal start and end values for each of the waves.

As an aside, I read a lot of reviews and information about the SQ80 and it comes through that the noise waves are the weak spot for this synth. You will inevitably get a periodicity with such short noise bursts and even the Musician’s Manual hints at this. You could say it’s part of the “character” of the synth.

Please say if you need any more help with this project, and when you get those waves out I’d love to have the files. I quite fancy having a go at an “inspired by” version myself.

Cheers and good luck!

Spogg

Of course it's not the hex to decimal that's my concern. But the math to reach the start value. Let's see (and tell me where I'm wrong):

The first wave on the spread sheet is "saw". It consists of 9 waveforms, spreaded over the 16 keyzones. They are written as $34-$39, $18, $16 and $15. But when I look at "raw wave parameters", there is no $35 or $15 (for example). But if this wave uses waveforms that don't exist, how is that possible?

I'll look into this.

My task before was to get the actual full waveforms out of the ROM image. We can do this now (or you can!).

This question addresses the addressing (!) of them as keyboard zones. It's a different issue so I'll need some time to investigate...

Cheers

Spogg

Turns out that was an easy one

The hex value in the Key Zone sheet refers to the Hex index column A in the Raw Wave Parameters sheet. I checked a few and it works. Yesterday I added all the intermediate hex values to the sheet, as part of my personal clarification, and it turned out that 60h had not been written. I’ve attached the spogged sheet because it’s much easier to cross check between the two sheets. I’ve added “for Keyzone” in the header for column A.

If you want to know which waveform to use for a given preset and Key Zone you can now just look it up directly. There are no missing waveforms!

I should mention, not for you but for anyone following this topic, that as you go higher up the Key Zones more simple waveforms are used; very often a pure sine wave is called for at the top end. If you had a proper high frequency Saw wave its higher harmonics would cause serious aliasing artefacts, so they use waveforms with a reduced harmonic content. This is a really clever method of bandwidth limiting. Those Ensoniq guys were good!

In fact we probably don’t need to do that key zone based bandwidth limiting in Flowstone because we have the Float Array to Wavetable prim which automatically does this band limiting for us, but we need to have the keymapping for the synth in the musically useful range, assuming an authentic emulation is called for.

Just ask if you need any more help.

Cheers

Spogg

Spogg, thanks once again! The reason for my specific question is vital.

Back in the early 80's, memory (be it random access or read only) was very expensive. Ensoniq couldn't use modern wavetable synthesis. So instead they came up with a hybrid of multisampling that uses some properties of wavetables.

You will never be able (as a user of the ESQ1/SQ80) to access any waveform directly. The lowest building block you have access to are the waves. A wave is the result of the multisampling/wavetable hybrid. Therefore, to accurately recreate the ESQ1, it is vital to recreate all the waves exactly as they were generated in the original (using the raw waveforms as mutlisamples).

That's also the reason, why the spread sheet document starts with the waves, not with the waveforms. The latter are a lower layer, a pool, from which the actual waves are built.

The waves then are the building blocks for patches/programs/etc. Those are fed to the three oscillators.

Of course that means, we can't use modern wavetable synthesis, but have to use the same tachnique: playing looped samples of different kind depending on key zone.

A wavetable in Flowstone would create 128 harmonics-decreasing versions of the passed waveform, each version 2kB long, or something like that. Can you imagine the immense difference in quality, compared to just 6 samples of, say 256 bytes? No, wavetables are out of the game.

Simple and fictuous example: ESQ1 has awave called "saw". When the user sets one of the oscillators to use "saw", behind the scenes the pressed midi key is evaluated, and for keyzone 2 raw waveform 1 is played, while for keyzone 5 it might play raw waveform 9. That's how the ESQ1 works on that layer.

Your help is soooo precious. We got 4 or 5 steps further than we were yesterday. I'm now preparing the tool to rip the raw waveforms. Stay tuned! (And thanks for the fish )