DSP Robotics Support

Spogg wrote:I agree the float arrays are the purest form, the real deal for sure, and that's why I wanted them! The WAVs are the common currency for sound files though, so I want them to be as good as possible, for eveyone to use as they wish.

This and the explanations from your former post:

I see and understand what you headed for, and, as I said in my other post, that's the most original you can get with .wav files. Also, everything you said about playing the waveforms at corect pitches is just as true as what KG said a week or so ago. Unfortunately that doesn't touch my point.

Every .wav file has a base pitch, a tuning, so to speak. If you don't enter one it is put to middle C (that's what Christian referred to). So, in a sampler the files will be interpreted as being equal to Midi key 60. But you didn't alter the rate, you just told the .wav header, the content would have been sampled at 44.1 kHz, while it actually is sampled at 38something kHz. In result, in a sampler, played at key 60, the content is played at a rate of 44.1 kHz and therefore faster than it should. Faster means at a higher pitch. People who don't use the material as we do, need to know that to accommodate the files (For example those who want to use them in a sampler).

Now I don't know the original pitch, Ensonic recorded the waveforms in, and it doesn't matter much, as long as the difference between 38 and 44.1 is pointed out.

Real world example: Import one of the .bin waveforms with the correct parameters (8-bit unsigned integer @ 38.something kHz) in an audio editor (for example the fantastic Wavosaur). Now load the same sound from your .wav files. Loop both and play them one after the other. Hear the difference in pitch?

That's my only concern. The people out there that are not plugin developers, but want to use the .wav files as they are. Not us.

I use an old copy of Sound Forge. I did what you said and compared the pitch of a .bin file with the same .wav file and they both played back at the same pitch.

So I downloaded Wavosaur (really good BTW). I imported the .bin file and played against the .wav file and still got the same pitch.

So what am I missing here? Did you do this yourself and get different pitches?

Cheers

Spogg

Edit: I used organ.1 file as a test. Also what you say definitely applies to the one-shots and these have that semitone shift and fine tune parameters. I was only talking about periodic oscillator waveforms.
Edit 2: I missed the step of specifyng the 38Khz sample rate when importing. That does give a different tuning, as expected. But if imported at 44100 the tuning is identical. Where does that leave us?

Spogg wrote:Edit 2: I missed the step of specifyng the 38Khz sample rate when importing. That does give a different tuning, as expected. But if imported at 44100 the tuning is identical. Where does that leave us?

Of course it is identical, if you import it twice as 44.1kHz. Why shouldn't it? But that's not what it is about.

What you hear from the 38kHz is the original pitch (whatever it may be). Somebody that uses the .wavs you created without altering them, will hear a wrong base pitch. So we need to inform alongside the .wav files, that each .wav has to be corrected by (whatever it is exactly, but) something like 2.2 semitones.

EDIT: I'll try another example. Let's assume the original pitch (as heard in the 8-bit 38 kHz file) by sheer luck is exactly middle C (60). When they play your file, they hear a pitch between D and D# (62.2, a value that doesn't exist for midi keys, of course). So they have to set the key in the file to D (62) and finetune by 20 cents. After those actions, when played with midi key 60, they hear C (as they expect, when using the C-key).

Well it seems I exposed my ignorance to the world again.

I spent yesterday afternoon looking into this and, as is to be expected, you are right.

I’ve never been too interested in pro samplers before, but it seems their interpretation of a wav can vary.
Kontakt, for example, can take a short wav file and recognise it as a single cycle waveform and render it correctly to keyboard pitch. The very excellent and free TX16Wx doesn’t do this. In fact I found I had to increase the pitch by +19.77 semitones to get it to match the FS reader and the corresponding audio clips from YouTube. I can’t even begin to see where that figure comes from but it was certainly required, based on my comparison listening tests.
I did a try adding the token “C4” (middle C -60) to the file name and it recognised it, but the exact same offset was still needed.

So I would bow to your superior knowledge and insight, and suggest you present these files to Rainer in whatever way you think will be helpful to wav users. I would still like the interpretation of those semitone shift and fine tune parameters for the one-shots and loops for the SQ80 ROMs.

At least I’ve learned something new, and thank you for your patience in taking time to explain it more than once.

Cheers

Spogg

I hoped to wait with an answer, until Rainer answered me (he is very quick in replys). And it worked. I just got answer.

Let me first say that I use the TX16Wx as well, not on a daily basis, but often enough. For me it is the most complete, feature-rich, free sampler you can get. It's interface sometimes frightens me, but that's not because of a bad design, but because of the many possibilities you have to tweak samples and sounds to your likings.

Now to Rainer. He thanks us for the files and will put them on his page. He also will have a look at Christian's files (he didn't before, just uploaded them). He also confirmed that a waveform can always be ended by stop-bytes, but never start in between pages, and that Ensoniq did it exactly as we found out. The most interesting remark came at this end of that section. Translated to English, he said: "This DOC was never really meant for Synthesizer/Sampler. In my opinion, it was developed primarily for the (never released) Drummachine 'Ensoniq Pro-Cussion'."

That would indeed explain a lot (for example the ease of use when we deal with one-shots in contrast to the looped waveforms). Couldn't find much information on that Drummachine, but here's at least some info and images of the prototype: https://encyclotronic.com/drum-machines/ensoniq/ensoniq-pro-cussion-r22/

The last point is of course the semitone and finetuning thing. He only wrote one sentence, followed by a list of Assembler-like orders for the chip. His words and the list:

"According to the ROM, the semitones actually are included in the semitone-calculation, but the finetunes are raw values for the increment:"


I'm not sure, of course, but it seems the last section is most important. If I read it correctly, first the DOC freq most significant byte (I'm pretty sure it is the midi-compliant msb/lsb, not the bits) is set, then the finetune value is read, added (added? to what?), then the LSB is set, then the MSB incremented (by what? obviously not the raw finetune value, that one was added to something before) and finally again the LSB set. I hope you can un-puzzle this?

...

Thank you so much for this tulamide!

I spent some hours on this yesterday and made some progress.

I determined the relationship of the resolution code (bits 2-0 of the WSR) to the octave shift:

001 No shift. For most of the waveforms and all the ESQ-1 ones.
010 -1 Octave
011 -2 Octaves
100 -3 Octaves

-3 is the largest Octave shift listed in the spreadsheet. With reference to the Musician’s manual, the user is expected to change the OCT on the front panel beyond this to get the most appropriate sound. Examples given are for Kick and Piano.
EDIT: Unfortunately this octave interpretation may be incorrect!

Last thing I realised, and this is now confirmed by Rainer’s contribution, is that the Semitone and Fine tune are register values for frequency, just like the resolution is for octaves, and don’t directly relate to tuning offset in musical intervals. Why didn’t I realise this before?
At this point I need to look carefully at his code to see if I can understand the translation to musical terms. Once again, this only applies to the SQ-80, since all the ESQ-1 files have no burned-in tuning offsets.

Another important thing I found is that the sampled sounds for loops and 1-shots were all recorded originally at 44100Hz, which is not surprising since CDs had been around for some time in the mid-80s and that was the digital audio standard. I did this by scanning the single shot and looped files at 44100 (sample pointer increment was 1 in FlowStone) and checked the pitch against the reference oscillator, taking any octave shift into account.

So I’ve more work to do on this somewhat forensic task, but we make good steps.

Regarding the sound, I’ve listened to my tool with no interpolation and it sounds exactly like that VSTi plugin. But neither sound like the YouTube sound clips, in terms of artefacts. I’m not convinced, at this point, that this is all down to YouTube’s audio compression or the video creator’s ADC but I can never know for sure. It’s just that, on headphones, I can hear an unpitched buzz (doesn’t track with the pitches played) which sounds so typical of de-multiplexing glitches.
I tried an emulation of this with a statically clocked sample and hold setup, at a wide range of frequencies, but the sound was not the same by any means. So that needs more work. It could be down to CPU interrupts or lots of things.

If you want to be really puzzled like I am, take a zoomed-in look at the waveforms in the sound clips for SINE. All seem fairly ok until you examine the lowest frequency, which is at a lower amplitude and truly dreadful in terms of shape. I don’t think that is down to any audio compression artefact, or the instrument’s Low Pass filter, but I don’t know why it looks like that at this point. This is very relevant for an ESQ-1 emulation of course.

In the background I’m wondering about the best way to implement the multi-sampling aspect in Flowstone. If you have any thoughts or solutions please share. Some “waves” have only 1 waveform, and some have many and that makes things more tricky I think.

A few days back I sat down and went through Christian’s waves list and filled in all the missing waveforms, labelling their keyzone ranges for each waveform. Of course I was using his waves at that point, so I need to repeat the work (damn!). I did find several big mistakes and omissions, by comparing every keyzone for every Wave on the spreadsheet.

I’ll post again if and when I make progress.

Cheers

Spogg

When I look at the code it seems that there are more octave options. One reads "if octave >= 2" for example. So you might be correct with your edit, but I have no clue currently. But I will have another go at it.

Regarding the video. I really think you are a little bit too focused on that one video. You don't know anything about that ESQ1 (broken jacks?), the recording situation (broken cables?), the recording item (cheap soundchip A/D?), etc. I do hear what you talk about, but you don't know the source of it. You just assume it's the ESQ1's internals.

Over the last couple days, I've gone through over a dozen of videos, all presenting the ESQ1 in one form or another. Your video link is the only one that has this weird sound. The only one. Unfortunately it is hard to get a hand on uncompressed material. I found a sine example in .au format, 8 bit @ 22050 kHz, and even that was a clear sound. However, the example was, according to Wavosaur's spectogram, a C4 (the fundamental and strongest frequency was 261.63 Hz). You can hear (and see) quite some ambient noise, but it is not nearly as strong as in the video, and also not of the same type - it is really more like noise from recording and low frequency sampling.

Don't base your work on just one video. That's all I want to say

Can't say I understand 90% of what you guys are talking about, but as someone who did 20 years as a professional recording engineer, I second tulamide's caution about the sound on that video; my first impression was "geeze, how is this guy recording this - sounds like shit". Maybe even with the synth plugged into some poop speakers, then recorded with the mic in his laptop. It certainly didn't sound at all like a quality recording. There are endless ways to get audio from a synth's output to a video's soundtrack, and when an amateur does it who knows what was involved. Given the poor picture quality, it's safe to assume the audio capture was not done very skillfully either.

My 3.33 cents.

You guys are blowing my mind with the effort you're putting into this.

Thanks, Kevin!

Also, I found more info. On the user side (and I don't see why that shouldn't mirror the internals somehow), you could transpose the Oszillator three octaves down or 3 octaves up. Together with the 0 position, that makes 7 steps, and that falls well within the 3bit encoding (2**3 = 8). Semitones were set directly (11 steps) and finetuning provided 32 steps.

Original German text wrote:Drei Menüpunkte stehen zur Tonhöheneinstellung zur Verfügung. Mittels OCT kann man den Oszillator drei Oktaven nach unten oder drei nach oben transponieren. Mit SEMI kann man in elf Halbtonschritte verändern und FINE nimmt eine Feinverstimmung in 32 Stufen vor.

That makes a minimum of 3 bits for the octaves, 4 bits for semitones and 5 bits for finetune. (Although it seems the values are read as bytes, when looking at the code) I hope this helps somehow?

@Kevin: Thanks so much for your input Kevin. This reinforces what tulamide said in the first place, so I’m now completely convinced. Your explanation also fits with the low frequency sine wave amplitude and shape: poor speakers and a poor microphone could easily lead to such a result. In addition to that, it would be very surprising if a company like Ensoniq sold such a crappy sounding synth, with no bad review comments to follow on. So that’s one thing to cross off the to-do list. YAYY!!


@tulamide: this tuning thing is driving me crazy, but I won’t give up. Well, maybe by Christmas.

The octave switching is easy enough. You just double or halve the step value to move up or down 1 octave, and that fits nicely at the bit level for the counter registers.

But you have no such luxury and convenience for semitones, even if the hex value is a register value and not a “number of semitones” value. Here’s my current thinking (which may change by lunch time):

The hex semitone shift value, if applied to the sample address accumulator, would provide a fixed offset to the step value. But to stay in tune across the keyboard the step value has to change with pitch. Let’s say we have 1 sample clock per sample, so the sound plays at its native pitch. Then if we double the step size to 2, it plays 1 octave higher (for half the duration). Now if we add an offset of 0.33484 the step size will increase to 1.33484, so C plays as F. BUT if we add the same offset to 2 we get a step size of 2.33484 and this is not the note F, 1 octave up. In fact we need a step size of 2.66969 to get F, 1 octave up. So clearly the hex semitone tuning does not, after all, relate to a counter register offset. Or maybe my binary arithmetic is dodgy and you can explain how it could...

Some time ago I looked at the idea that the semitone and fine tuning related to the front-panel steps, but I dismissed this because I couldn’t find any relationship. The closest I came was a signed 8 bit code, as I mentioned before, but this only worked for 2 waveforms, and if I multiplied the result by 2. Maybe I should re-visit this because I can’t make it work out with the counter step size offset.

More work needed…

Cheers

Spogg