AFAIK Carolina only uses the D-Lev pitch circle for coming in on pitch, not for active playing. That's pretty typical for players who have learned on an analog Theremin, where they have necessarily been guided only by fingering techniques and their ears. Many Thereminists plug a guitar tuner or similar into their Theremin for this, but those sorts of tuners are rather sluggish. When you have a highly responsive tuner, then playing turns into an almost "paint by numbers" experience, and you are much more aware of the key and other song structure.
There are 50 or so kits spread out all over the world, some in the hands of the world's best Thereminists, which has been quite gratifying. But the project has been in a bit of a hiatus while I do more R&D, and the current tariff situation isn't exactly filling me with enthusiasm. Enclosures and antennas have been a burden for some, a wine box build is probably your best bet. I don't mind supplying hand-wound coils and any guidance you may need. My contact info is on the support page.
The D-Lev has a fairly extensive MIDI implementation, and you can control any CC with the volume hand (7 or 14 bits), so perhaps something like this would be possible if the synth it's driving is flexible enough.
The problem with trivial ops like stack manipulations is that they don't really do anything useful, but they can take as long as multiply in the pipeline.
Stack machines made more sense when memory was limited (small opcodes) and there were no hardware multiplies, but these days they make no sense.
I don't understand all the vague nostalgia for something that never could have panned out outside of the creaky old Apollo flight computer or something.
A stack processor will always be less efficient than a two or three operand register-based processor. This is because all of the the registers can be used directly without any stack manipulations to access them, and the two or three operand operations usually include a move.
If you examine any stack language code, you should consider any stack manipulation to be a NOP type of inefficiency. And when a virtual stack machine is implemented on non-stack hardware, these inefficiencies are compounded.
I meant that he's a genius at the whole stack machine / language shaman thing.
32 bits are unnecessary?!? I suppose a 18 bit machine would run a lot "faster" than a 32 bit machine given certain data sets and loads, but I wouldn't want to do any audio DSP with it.
Multi-core F18A technology, each of which is a simple 18 bit processor. IMO, anything less than 32 bits (with internal 33 x 33 = 65 bit multiply) falls into the primitive category abyss.
Moore is an incredible salesman, I'll give him that.
I briefly skimmed [1] and their more sophisticated translation to a register VM yielded a 25% increase in code size, and not the 45% you stated? Regardless, VM to VM really isn't my point.
I still don't get the positives of why the programmer should be presented with a stack machine SW model when there is no stack machine type stack to be found in the HW. Programmers with no stack machine / language experience probably think (as I did at one point): "the stack on my HP calculator stack works great, why not base a language on that?" but it scales poorly, it gets really hairy if the stack is the only place to store things, and it's a major headache keeping the stack from going out of sync (hence Forth's clear I/O comments regarding subroutine stack use).
The Forth success stories tend to be really, really ancient, and therefore almost irrelevant. Much like Chuck's arguments for the merits of stack languages / machines. Processor pipelines have to be at least deep enough to do a wide multiplication or you're basically looking at a toy.
I actually have designed my own FPGA soft core barrel processor, it's a special blend of register and stack machine. The blend occurs by placing stacks under the registers themselves. I believe this allows a low register count, 2 operand architecture to be more efficient than it otherwise would be, which minimizes opcode size, and sidesteps most the crazy you get when trying to shoehorn most processes into a single stack environment.
But has clear downsides as well, the main one being the stacks can become easily corrupted by any process using them - this is true of any stack machine but you strangely never hear it come up in conversations with Forth types. Stack processors can eliminate much traditional processor state, but the stacks themselves contain state, which is often overlooked.
I would argue that a language targeting bare metal type applications should at least be minimally aware of that underlying hardware. A single stack "virtual machine" type language is generally a terrible fit for the 2 and 3 operand register-based processors which dominate the landscape.
Every interview of Chuck Moore that I've read has contained zero push-back for his rather wild claims. It's entirely possible for an industry to do go down the wrong path for a while, but at some point, if Forth and stack processing were the giant killers they were cracked up to be, you would see them enter and dominate at least some portion of the mainstream. You can't say they haven't been given enough time.
It seems there are many "Forth curious" programmers out there, but they aren't being given the full picture with the various puff pieces and vanity projects floating around that never really go anywhere. It's almost a culture of victimhood.
If you actually look at the way Forth works you'll see that every stack manipulation wastes code space and real-time. Since there is only one data stack there are a lot of stack manipulations going on. Forth programmers are aware of this and do their best to minimize them, which tends to make their incredibly cryptic code even more cryptic.
If the definition of a low level language is one that bedevils the programmer with minutiae, the Forth is the lowest of the low. I don't understand the fascination others have for it, and don't understand how anyone can like it after actually programming with it. It's horrible.