Let's Design and Build a (mostly) Digital Theremin!

That program here is also pretty neat, and also available for Linux:

https://sonicvisualiser.org/

Yes, thanks! 

I've got v3.0.3-4 from the package manager installed (why are so many of the programs in there kinda stale?).  It unfortunately doesn't display real-time FFT, which is what I often need when adjusting presets like the cello. 

Audacity has a fairly useful FFT view too (though also not real-time).

Pitch Preview Reux

Now that there will probably always be a secondary stereo D/A box in the D-Lev, I'm taking another look at the audio paths out.  And one of those paths is PP (pitch preview).  Right now I've got it switching the right side audio out and switching itself in when PP is enabled (when the PP level knob is non-zero).  I've had a bit of left ear trouble over the past few months (reduced HF content) which has made me realize how critical stereo hearing is to the intelligibility of speech (losing ~1/2 an ear seems worse than what one might imagine losing a whole ear would do), so I'm kinda questioning the whole "stick it in one ear" thing that many Thereminists seem to do with PP.  During the course of developing the PP system on the D-Lev, I've had some opportunity to try it out, and I can't say it is anything I would feel comfortable using, but perhaps much of that is because it is only being presented to a single ear?  And by itself?

So my experiment today will be to present PP to both ears, and as a mix rather than as a swapping out of the normal audio.  A mix might be the best way to go here, it seems it could be made low level and rather constant, which would allow it to "rear its head" during quieter passages more naturally.  Having two stereo outputs means I can present the PP mix to the headphone output while leaving the line level PA output untouched.  I'll have a mono mix option on the SYSTEM page if only a single stereo output is used, but I expect that won't be the norm going forward.

[EDIT] So here's an example of PP in both ears, with a "fluty" voice: [MP3].  The PP "voice" is set 1 octave lower, and has maximum harmonics, jacked up bass and treble, and a bit of vmod volume ducking and pmod bass end loudness accentuation.  Comments?

Stupid editor.  I had a long screed response written for you and it all just disappeared on me for no apparent reason.  So here is a much shorter version...

Your sample shows how I use it as well.  The separately adjustable timbre for pitch preview keeps it and the main audio separate in your head, and you can listen to a mix with a monitor right behind your head (and with both ears) and an audience would be none the wiser.  Those precious milliseconds of lead-in before the volume hand opens the gate can make all the difference, and a distinct timbre difference for the PP allows you to not lose sensitivity to the threshold of perception for the main audio volume.

I use an external analog mixer to do the mix, and although you have suggested having it software-settable on a per-preset basis, I think that having an analog pot to do the mix internally might actually be better.  Even if you choose to have a software mix, it should still have an analog vernier adjustment, so why not just do it all in the analog domain...  This would give you more time for developing presets, writing documentation, sorting your socks, etc... .

"Your sample shows how I use it as well.  The separately adjustable timbre for pitch preview keeps it and the main audio separate in your head, and you can listen to a mix with a monitor right behind your head (and with both ears) and an audience would be none the wiser.  Those precious milliseconds of lead-in before the volume hand opens the gate can make all the difference, and a distinct timbre difference for the PP allows you to not lose sensitivity to the threshold of perception for the main audio volume."  - pitts8rh

Yes, it was a conversation of ours that put the idea in my head to have PP a stereo mix rather than a mono switching in/out (thank you!).  I'm just sort of recreating the way you use it with an external monitor.  It makes a lot of sense.

"I use an external analog mixer to do the mix, and although you have suggested having it software-settable on a per-preset basis, I think that having an analog pot to do the mix internally might actually be better.  Even if you choose to have a software mix, it should still have an analog vernier adjustment, so why not just do it all in the analog domain...  This would give you more time for developing presets, writing documentation, sorting your socks, etc.."

It's actually already implemented in SW, and it was a pretty simple change.  I cleaned up some of the final audio path code associated with volume and mute at the same time.  (I'm back to looking at pushbutton debouncing...)

We should talk about the auxiliary DAC output: which one should be primary / line level / PA, which should be for monitoring / headphones, and how to handle level / muting controls between them.  Sometimes you want line level volume control at the instrument, but sometimes not.  I've seen a lot of variation here in keyboards we've owned.

I should add: digital control over volume probably isn't quite as bad as it may seem.  The audio path is 32 bits, and I knock this down to 24 bits right at the SPDIF interface.  So there is some headroom in the digital domain to lower the signal without degrading the SNR too much (though I'm not clear on how many bits of those 24 the SPDIF box actually "looks at".)

"It's actually already implemented in SW, and it was a pretty simple change.  I cleaned up some of the final audio path code associated with volume and mute at the same time.  (I'm back to looking at pushbutton debouncing...)"

Maybe I removed that RC filtering too soon...  Unfortunately putting it back in now is a little more effort that removing it, but it could be done.

"I should add: digital control over volume probably isn't quite as bad as it may seem.  The audio path is 32 bits, and I knock this down to 24 bits right at the SPDIF interface.  So there is some headroom in the digital domain to lower the signal without degrading the SNR too much (though I'm not clear on how many bits of those 24 the SPDIF box actually "looks at".)"

I wasn't implying that I had any problem with digital volume control versus analog, but whatever it is it I think the player should have a knob to control it.  But adding an encoder knob for controlling a digital mix is getting into D-Lev Version 2 stuff, and for that matter so is an analog mixer at this point.  Personally I think a first "design freeze" should be up to inclusion of stereo and the two supplementary pushbuttons that you wanted to take those functions off the encoder buttons, because those things can be done with the latest board designs.  I would also like to see some of these new ideas incorporated, but it really would be nice to get a stable hardware design, an enclosure, and a sound preset & documentation package wrapped up first before moving on.

"Personally I think a first "design freeze" should be up to inclusion of stereo and the two supplementary pushbuttons that you wanted to take those functions off the encoder buttons, because those things can be done with the latest board designs.  I would also like to see some of these new ideas incorporated, but it really would be nice to get a stable hardware design, an enclosure, and a sound preset & documentation package wrapped up first before moving on."  - pitts8rh

Agreed.  I'm just doing the last SW / UI stuff I can think of that really needs to be addressed for v1.0.  That's this PP mix change, proper pushbutton debouncing (which I'm sure it can be done in SW, the current debounce code just is too sensitive to the closed condition), and maybe taking a few user presets away to accommodate more system presets, all of which may take a week or so.  Then it's on to creating more presets and documentation.

Follow the Debouncing Ball

Full encoder pushbutton and GPIO debouncing is now implemented and running on the D-Lev.  Previously I wasn't debouncing the GPIO inputs at all, which is rather creepy considering one input is the external auto-calibrate for the axes.  The other is an external mute input, and I suppose if it flailed around a little it wouldn't be the end of the world (or your performance) but it's nice to have it fully conditioned as well.  The only encoder pushbutton in actual use is the one that performs the preset write, and I've seen it acting up at least once with what I presume was an ESD event in the room - the two step write process probably saved it from overwriting the current preset with whatever was dialed in, though what's generally dialed in is whatever voice is currently playing, so a wild write generally wouldn't change anything, but, you know, who wants wild writes happening?  The new debounce process here should improve the situation.

How do we debounce a bang-bang input, one that is either pulled high through a weak resistor, or pulled low via the very low impedance of the switch, and then double sampled to give a sharp digital threshold and eliminate internal metastability race conditions?  Previously I was depending on the only thing bringing the input low being the switch closure, and then continuously ORing the input for a while and then sampling & clearing, but that obviously isn't safe.  The right way is to stick a low pass filter with a time constant significantly longer than the bounce period on it, and then sample that at regular intervals.

You can use either a signed or unsigned first order filter, and I decided to go with unsigned because the input and threshold testing are simpler.  If the input is zero then we input a zero.  If the input is a 1 then we input a large positive value.  Then we do the filtering and examine the output to decide what to do from there.  The filter input values determine the filter output range, as the output range can't exceed the input under any circumstances.  I decided 16 bit accumulation in the filter was wide enough to accommodate a reasonable time constant of 2^-11, as the output maximum is then limited to 2^16 - 2^11, while the minimum goes all the way to zero.  Here is the filter with a somewhat shorter time constant, just to show you the response to the bang-bang input:

Above you can see it gives the characteristic RC charge and discharge curves.  The vertical axis here is 0, 1/3, 2/3, and full scale 2^16.

Above is the bang-bang response from 1/3 output to 2/3 output and back down to 1/3, and this directly shows the absolute minimum hysteresis time is approximately 2800 clocks.  It's clocked at 48kHz, so this corresponds to 17 Hz, or 58 ms, which seems like it should be sufficient.  Too much longer and the user might notice the lag, too much shorter and it might not sufficiently filter glitches and stuff (you always want to filter as much as you can afford & get away with).

The output of this low pass filter is examined by the code, and if it is above 2/3 the output is set to 1, if below 1/3 the output is reset to 0, and if neither of these then nothing changes, which provides a central 1/3 sized region of dead-band or hysteresis - this prevents chattering and makes it immune to input glitches shorter than 1/2 the minimum hysteresis period.  Finally, the set/reset output is resampled at 4000 / 48kHz or 12 Hz, with changes detected and passed on to the remaining logic (which operate at 12 Hz along with the rest of the UI controls).  In a perfect world we would resample at 2 x 17 Hz or higher, but missing the shortest event isn't really an issue for any of these on/off types of inputs.

It's sort of weird to think that you can take a noisy 0/1 digital input and de-noise it using the analog of an analog process after the fact - but you pretty much can!  It's all about the longer term average (and the Pentiums).

[EDIT] The whole situation with the GPIO, encoders, and pushbuttons is exacerbated by the fact that they are NO (normally open) rather than NC (normally closed) contacts.  This is done presumably to save power, but it raises the impedance of the resting states significantly, leaving them prone to interference.

Also, you'll note that I'm sampling the pushbuttons and GPIO at the PCM rate of 48kHz rather than the Hive core clock rate of 180MHz, which seems sufficient as these events are much longer lasting than encoder twisting (the encoders are debounced via the 180MHz clock).

Push My Buttons

Today I added two new pushbuttons to the D-Lev prototype control panel:

They are the red things a the lower left and right.  These are old Radio Shack product, quite possibly the bounciest, dirtiest, on-impedance-all-over-the-place, most vile pushbuttons ever made by mankind, so they should be good for torture testing my software debounce algorithm. 

So far I've got the one on the lower right working, it performs the auto-cal when pressed.  The physical positioning of this button is interesting because pressing it places the right hand in the pitch mid-field, so the "Pcal" encoder has to be adjusted somewhat to account for this.  But once it is adjusted and saved to slot 0 (which saves both the current voice and the system settings) then it doesn't need to be adjusted again.  I believe there is significant value in having the pitch hand positioned in a known, highly repeatable location like this while doing the auto-cal.

The one on the lower left will perform preset write.  The sharp observer will notice that the "Load" encoder has moved down one position on the LCD display, and the "C/wr" encoder has been replaced with a "Stor" encoder.  This is more or less how things used to be before I changed things to a single encoder load / store situation, which I found to be rather awkward and kinda dangerous if one is the least bit foggy when doing a preset write.  But this time I'm going to have Stor follow Load when Load is rotated (i.e. when a preset is loaded), and Load will follow Stor when a preset is saved.  This way the thing being edited will always be the thing just stored, rather than the thing just copied.

While I was "under the hood" I swapped out the (likely bootleg) Prolific USB serial cable with a (likely bootleg) FTDI USB serial cable, and I did this mainly to see if I could improve the power droop situation, as flexing the old cable at the USB connection showed a lot of iffy conductivity.  The good news is the power connectivity seems to be a bit better.  The bad news is software uploads slowed to a snail's crawl.  What was taking maybe 15 seconds with the old cable was now taking over a minute.  It seems the FTDI driver defaults to a timeout of 20ms for holding data in it's buffer before doing anything (buffering serial data in an interrupt situation is something you need to think long and hard about, and even then you'll almost certainly get it wrong) so I had to stick some arcane low-level instructions in my librarian code to reduce this to 1ms (it really shouldn't be any ms IMO).  Uploads are snappy once more.  I don't know why all low level PC hardware access is such a mine field of BS, it certainly doesn't have to be this way.  I do know that the Prolific and FTDI folks make this stuff exponentially worse every chance they get.  Never trust simple but critical low level stuff to screw-ups.

Roll-over

The reason normally open push-buttons are preferred is that normally closed push-buttons do not always make reliable contact especially with rapid pressing.

Your Big Bro