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

Multioptional!
Have you already seen my last posting on velocity?

"Have you already seen my last posting on velocity?"  - Dominik

Just did!  Dominik, your videos are always really well done and very informative from both player and engineering perspectives!  I really like the running scope.

My own velocity sensing path has been drastically simplified (post 1443 in this thread) and I will draw the signal path out to better illustrate soon.  It is much more in line with what you are doing in analog, though your latest video is making me realize that the prototype velocity could use more gain.  I'm currently using the knee to gain up the velocity, and so there is a lot of interaction between knee slope and velocity gain that I'd like to address somehow.  The knee location is also variable, so the attack associated with it can be positioned in space, but it would be nice perhaps to not require it to be so fixed.  Velocity requires a lot of gain, and when doing this digitally that can easily lead to zippering, graininess, or audible steps in the field.  So there is some tension between envelope smoothness and attack sharpness.

Dominik, do you have any kind of knee in your volume response?  A player always desires linearity of the field itself, but adding a knee allows interesting dynamic variation and control, particularly for vocals and such.  And it can be an integral part of any percussive type playing as well if you place the knee before the velocity sensing.

Thanks. Yes, a scope is a nice thing to have i would say.

The knee. Nope, no knee. And i must admit that i have not understood it completely. Much of your work seems to be speech oriented. Where a word starts with a specific loudness. Is it that? Hm.. of course i think that my velocity feature covers this as well..  (how to disable auto smilies?)

Dominik, I'm studying your excellent video closely (what camera do you use?) but can't quite tell certain things from it due to the fast timing.  If you would be so gracious as to relieve my confusion:

1. It seems there is a diode or similar which favors the attack?
2. It seems there is a fixed RC decay time, could you perhaps tell me what that time (R*C) is?  
3. it seems that racing your hand towards the antenna can make the decay shorter?

Even though you don't use an explicit knee, I'm wondering if you are somehow (perhaps without realizing it) employing the non-linearity near the antenna?  If I jack the velocity up on the prototype I can get it to "trigger" anywhere, but that also makes the volume field pretty twitchy.

Thanks!

"If you would be so gracious as to relieve my confusion"

That is a funny request, almost confusing in itself coming from you. In my years of theremin study much of the stuff from europe was some kind of secret. Now our Russian explorers were always very giving in what they shared, stuff that was inventive and it actually worked.

T

Code Dump

High time that I posted my HAL and SV code (to date):  

HIVE  
SV  

It's not like there's anything secret in there, I've posted just about all of the background (ad nauseam) here at TW.  I suppose one can only hope their stuff is worth ripping off! :-)  The Hive processor was documented OK at one point but that long-ish paper has fallen far behind.  I need to write a book or two...

The SV archive contains all of my Hive soft processor SV code, as well as my SV code for the Hive peripherals necessary to implement the digital Theremin prototype (LC PLLs, tuner display interface, SPDIF TX, SPI master, LCD interface, rotary encoder interface, UART, etc.).  If you know what you are doing you could pump an FPGA demo board given those files.

The Hive archive has all of my digital Theremin software, as well as the C++ simulator / HAL assembler source code.   So if you are interested in soft processors, assembly languages / assemblers, command line interfaces, integer / floating point math packages, digital Theremin hardware / software, DSP, etc. you may find something there for you.  If you know what you are doing and have all the hardware peripherals attached to said pumped FPGA demo board mentioned above, you could program the soft processor within the FPGA via the serial port and TeraTerm (the assembler kicks out a TTL script for programming) and have yourself a working digital Theremin.

I'll probably post updated schematics as well soon.  Will most likely stick it all on github or similar when it's all closer to some kind of finalization.  FPGA pin assignments may likely change (like an idiot I clipped some I/O board header pins off too early on).

The electrical aspects of the project are fairly simple as these things go, but I definitely wouldn't recommend this as your first (or second) exposure to a soldering iron! And for the love of god promise me you won't even think of taking anything like this on without a scope...

Well I wish I already started looking into FPGA, which is on my bag of toilet paper rolls long TODO list (imaginary).
(one could always just build other peoples' stuff, but I'd like to understand at least on some level )

Yeah, open (for reading) github repos are free of charge, and having your development stuff insta-backed up from your project folder to servers that won't burn down with your house at the click of a button is nice (ok, maybe one has other worries if the house burnt down, but I think I would be even more depressed if I knew all of my years of development efforts were up in smokes, too )

It's also nice to use git not only with github to publish things, but to version-manage projects on your PC, really nice for looking for bugs, comparing older and newer versions of your files, etc. (I don't know about you, but EE's I know tend to shy away from such things, it's weird software dev stuff, my brother is one of them, so I'll mention it).
Granted, git does not do (larger) binary files well in the long run (binary is not their goal), but if you don't check in 500MB large files which are changed all over in bit pattern every day(1), it shouldn't be a problem.

As for publishing, there's also SourceForge. But their reputation kinda got scratches, they seem to look for abandoned (e.g. moved to github ) projects and add (optional) crapware to the installers...

(1) like the damn Siemens PLC project I once had to do: project file = giant encrypted binary blob, that changes in compressibility between 1 and 99 % after you add a word to a comment line somewhere and press "Save"...
If they have anything to hide, it's their atrocious software alltogether, couldn't they rather heavily encrypt that, so nobody has to see it...

"Well I wish I already started looking into FPGA, which is on my bag of toilet paper rolls long TODO list (imaginary)." -- tinkeringdude

FPGAs are a hard field to get into.  No good books that I know of either.  Best to look at other's real code I think, and have someone with experience explain their approaches, and the crutches they employ, to perform parallel logic design.  The real fun starts when you get to the point when you are bolting together well-written modules, but that can take years.  Once in, you find the field itself is mounted on a rocket that you can't possibly keep up with, which is discouraging and rather frightening if it's your job.

Having some conventional (serial) programming under your belt helps, but not perhaps as much as one might think as the skill sets are pretty divergent.  And after a few years of doing it you realize that state machines are something you will have to come to terms with again and again (and again) as there is no single right way to do them (the whole Mealy vs Moore thing is at best an academic distraction).

The truest goal of any kind of coding is to describe the solution in a way that is correct, safe, and readable / maintainable.  So aesthetics play into it, and one's experience level and aesthetics change over time.  With FPGAs you have I/O pin and inter-stage timing to worry about, as well as flop vs LUT ratio, and BRAM utilization.  A lot of rubber hitting the road.

I recommend Altera (now Intel, grr!) over Xilinx.  Every once in a while I get to thinking "Xilinx is the biggest, and they write awesome white papers, they must be doing everything better than everyone else" and then I give their new tool a spin with their latest economy FPGA, and find they don't support some essential language feature, and the design runs 25% slower than on the roughly equivalent Altera part, and the part itself costs 50% more.  It's a lot like Intel vs AMD when AMD has the upper hand.

IMO a big part of the opaqueness of the FPGA field is due to the lame, ultra expensive simulator everyone uses.  I can't stand ModelSim.

"(I don't know about you, but EE's I know tend to shy away from such things, it's weird software dev stuff, my brother is one of them, so I'll mention it)."

That's me too!  I completely understand the need for SW versioning, but the tools I've dealt with have been uniformly painful and horrible - way more trouble than they're worth, particularly on a small project.  SW types never seem to complain when forced to jump through millions of arcane hoops. ;-)

 but the tools I've dealt with have been uniformly painful and horrible - way more trouble than they're worth, particularly on a small project

Does that include clients like SourceTree, or the windows explorer integration like TortoiseGit? (the latter changes names / approaches for some things to be more like in TortoiseSVN, which some git purists complain about, I like its usability for the few standard things for everyday work, and use gitk as treeview, and resort to the console when necessary).

Of course it does make sense to look at how git works internally, to a certain extent, to be able to work with it effectively. Just trying to use a git client may be confusing otherwise. It's not quite self-explanatory.
I'll admit, it is some effort. I'm not quite a git expert myself, just some basic usage which suits my needs. Stackoverflow will, in most situations where I don't know, have a readily answered thread for "how do I achieve X in git".

Then I discovered my Synology NAS supports hosting a git server with some clicks. Mine has RAID-1 and I basically use it to store stuff I want to keep for a longer while. Now it's also where I most often push my work for backup from my PC.

SW types never seem to complain when forced to jump through millions of arcane hoops. ;-)

Tsss, don't mix up SW types with *Apple developing* SW types! Those are required to jump through hoops on a regular basis, because apple says so. It's part of the Apple developer bullying program. (I think it was called... something like that...)

But granted, git is somewhat arcane. But isn't everything that comes from the Linux world... those people (I mean those who dream in bash commands) are weird ones.

A Bit Better?

My ham-handed attempt at Pie Jesu: (link).  One take after an hour or so of total practice, and I added a bit of reverb in post.  Probably too breathy, and as usual I'm relying on the LED tuner and pitch correction internal to the prototype.  I fear I'll never be 1/10 as good as the incredible Amethyste (link) who absolutely kills on her Subscope + EH Talking Machine.  I should also note that some of my note cut-offs are a bit abrupt, and that's because I've got an experimental load in there that senses velocity in both directions.

As I hack my way through Nessun Dorma, I understand why the incredible Peter Pringle uses vibrato throughout (link) as it adds tons of vocal realism.  Also notice in that video the voice clearly goes from AH in the lower registers to OO in the upper registers.  I wonder if the TM is doing this or if it is the Theremin source voice causing the vowel shift?

Human vocals really make the Theremin fun to play!  I don't ever find myself reaching for the mellow or buzzy waveform presets, just the vocals.  When the voice I'm using starts getting old I switch to a preset of the other gender, or dial in a new one.  I wonder if the single TM voice gets tiresome?  They probably could have easily put tons of different voices in there.

===========

"Does that include clients like SourceTree, or the windows explorer integration like TortoiseGit?"  - tinkeringdude

Yes, opencores.org forced me to use TortoiseSVN (*spits*) to post early versions of Hive.  I never felt like I had any control over anything on that web site, screw up the text in a post and it's there forever, making you look like a big dummy.