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

"Try Qt. It's cross platform, and would allow you to make nice looking convenient simulator GUI." - Buggins

Yes, and thanks - it's probably time to try Qt rather than learn a new language that has Qt "native" and make C module for it.  There's something about python that I just can't warm up to, like it's just a pile of scripts and not really a language - though maybe that's the beauty part.  If it were strongly typed and had a compiler I might be a bit more enthused.

D-Lev & Telescoping Antennas

Thinking about it, a telescoping antenna would be a fairly trivial thing for D-Lev to support.  With analog Theremins, and particularly those with series EQ inductors, the intrinsic C of the antenna is fairly critical to the tuning process.  So you would have to make sure you extended the telescoping antenna fully, or you could instead use the antenna length as a tuning device (FreM did this), but it might be tricky because the intrinsic C has a magnified 3x influence over pitch (due to the "invariant" - FredM used a threaded rod for fine adjustment).  With the D-Lev you would just extend it to wherever, do an auto-cal, and except for a bit of possible gain / offset / linearity touch-up, it's game over.

Qt is also quite a beast on its own, though. And some of its functionality is now duplicated by current C++ standard, but I guess (haven't looked into it anymore) they make you use all the Qt stuff, as that's what works hand in hand with all the stuff that you actually need Qt for.
Wchich means you will be learning their stuff, instead of the new, equivalent, C++ standard things which you can use whatever library you will be using should Qt no longer fit your needs or be available on reasonable conditions, in later projects. (if you already are familar with C++11/14/17, and don't mind piling similar stuff onto that, it's no biggie I guess)

E.g.: smart pointers of different kinds, containers, string types, threads and other mechanisms for facilitating concurrency / synchronization primitives...
And there is the danger of making code that could/should be agnostic to that stuff dependent on Qt, because they, for reasons which are beyond me, defined all the basic types like int types as their special ones, with a Q prefix, e.g. Qint8 or so (instead of using cstdint - I guess old baggage from when it was not in the standard - although defacto standard names like uint8_t have been in existence for a long time).
Which means that when making independent modules, you'll have some fun casting at the interface boundaries, for the most mundane stuff. Not as serious a "problem" for primitive types, but std::string vs. Qstring and all the other things I mentioned, makes things more ugly.

And they infuse C++ with some weird-ish additions to enhance the language in some aspects (special syntax), which help do some things more easily, but to me, really highlight the cracks and gaps between this charade of trying make C++ seem like a modern language, and actual modern languages. Only one glance, if things suddenly don't work so nice, into the matryoshka template hell, used, among other things, to simulate a modern language, in the debugger and trying to make sense or see the really really really relevant data items of anything, and I quickly realized that that's not for me and, when I have the say, I'll use something like C# if a GUI is needed. Although e.g. you won't like that the best tool for that branch is visual studio, I can at least say I never felt like stabbing myself when debugging there, also because of absolutely useless error messages, because the real issue is buried around 5 corners.

Also, note that Qt is not free, for commercial products. (last time I checked)

But it certainly is a rich environment and covers A LOT of different terrain, no doubts about that. (I'm personally not exactly fond of the Qt Creator IDE, though :-P)

A not nearly as rich, but also not suffering from above problems, cross platform GUI option might be GTK+3. I haven't looked at that in a long time, and back then, only briefly, though.
But the sense I got when reading about peoples preferences is that Qt is mostly preferred because of the wide array of topics covered, not because GTK was worse at what it does wrt. the intersection between the two.

I mentioned Python as a reply to "scripting", and Python usually being characterized as a "scripting language", optimized for code brevity and quick results, not so much huge, complex projects (not saying that some don't do it anyway).

EDIT: as for "static typing / had a compiler": Not the first, but the latter - you can create executables. I don't know about the speed gain by that.
https://stackoverflow.com/questions/5458048/how-to-make-a-python-script-standalone-executable-to-run-without-any-dependency

"I mentioned Python as a reply to "scripting", and Python usually being characterized as a "scripting language", optimized for code brevity and quick results, not so much huge, complex projects (not saying that some don't do it anyway)." - tinkeringdude

Right, the conversation got a bit derailed there.  Thanks for your input!  It always amazes me how complicated GUI stuff is to implement (at least for me). Like programming languages, it seems like there should be one or maybe two "best" ways to do things that would trump all others.

If I Only Had A Brain

My nephew was whistling it on vacation, so I just started learning it: [MP3].

You can hack your way through a bunch of slow songs which don't have a lot of big pitch jumps, but when it comes to faster stuff you need develop some sort of pitch hand fingering technique (which I clearly haven't even started to think about).

[EDIT] And the whistle, being essentially a sine wave, is the most forgiving in terms of audible pitch mistakes (so it's my go-to voice when doing complicated stuff).

[EDIT2] It's amazing / annoying how the brain "paves over" lapses in song memory, and then hangs on to those learned incorrectnesses like a pit bull on a steak.

Whistle is must have for playing Morricone hits

Modulated Pulse Width Modulated Noise

Over the past few days I've been trying out some ideas I came up with on vacation for yet another attempt at creaky voice, but unfortunately none of them panned out.  Got one knob free on the noise UI page so I thought: why not give pitch axis modulation to the pulsed noise active time?  That way the active time could be duty cycle based rather than fixed time based, the whole thing would be more flexible, and I could get rid of a history register and a counter register in software (which felt like a kludge).  I was already using reversed exponential scaling for the fixed time knob, so it was a simple matter to offset (modulate) a reversed linear knob value with the pitch number, run it through EXP2(), then compare the NCO ramp to this value, killing the noise (-96dB actually so as not to make the SPDIF IC go to sleep) if the NCO ramp is less than the value.  I picked a 48dB range for the knob, which seems to be enough, but perhaps just barely.  Before this I was using 72dB for the fixed on time.

So now one can set pmod=0 to do noise enable as a pure % duty cycle of the oscillator; if pmod=32 then the enable width is fixed and independent of oscillator frequency.  Negative pmod values give a larger enable width duty with lower frequency, which doesn't seem immediately useful, but it's trivial to do so why not?

Here's the pmod noise doing a helicopter taking off: [MP3].  It's assisted by the noise filter set to 4th order low pass with a bit of pmod on the filter frequency, pseudo-stereo via the inharmonic resonator, and a bunch of bass and treble.  There's something about propeller driven vehicles that oscillator detuning (not used here, but essential to the "crop dusting" voice) and inharmonic resonator delay really makes come alive.  It's all about phasing I suppose.

More Bells

Three more small brass bells have been sitting here just asking for it (crying out to be synthesized):

The center one is very similar looking to the one on the right, but it has a much shorter decay time, not sure why.

And here are my very brief (spent maybe 30 minutes on all three, including all the recording and photography) attempts at synthesis of them: [MP3].  Real bell is first, followed by synth bell, then 2nd real bell, etc.

As before, I couldn't really nail the clapper attack sound nor the inter-beating of the resonances.  And my formants only go to 7kHz, so I'm falling back pretty heavily on the inharmonic resonator (of which I'm doing absolutely nothing to align the harmonics).  Are you enthused yet?!?   IMO, a lot of the beauty of a bell's sound is the inter-beating.  In much the same way that playing an instrument increases one's general appreciation of it, synthesizing a voice allows one to discover and therefore more fully value the sources of the aural pleasures it provides.

AFAICT (though I'm prone to false positives here!) the D-Lev hardware, firmware, and software are done.  I would need more computing resources to significantly expand the design, and I have no active plans to do so at the moment.  Still need a case design that will satisfy most players (hoping the vertical tour form factor works out), as well as some sort of preset librarian / editor software.

Post family reunion, but family is visiting for several days, and the SO and I are discussing even more get-away time shortly, probably light posting ahead.

How's this one for decay time?

Are you some sort of mad bell collector? I know no person who has such a collection
The sounds are pretty close, just the last one reminds me a bit more of a triangle, i.e. less massive than the real one. If the first one had a little of the extra high end chime of the last, it would also be closer? The one in the middle sounds closest to the original I think.

"How's this one for decay time?"  - tinkeringdude

I tried to synthesize it, but the audio in that video seems quite distorted and severely lacking bass and treble, which makes it really difficult to know what it really sounds like.

Though, in the process of doing so, I found a way to do the inter-beating of the harmonics: tune two formants the same and use pitch axis modulation to offset one of them.  So, thanks!