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

Fred, I just put a spreadsheet at my digital Theremin design repository:

http://www.mediafire.com/?w36b3brqyg2g3

File name is "Theremin_Linearization_2012-05-26.xls".  It contains data from my prototype along with some simple calculations.

It looks like I can use a simple offset (which can be introduced when the calibration button is pressed) and two piecewise tilts to make it pretty linear.  Computational / hardware cost is a threshold, two adds, a multiplication, and five stored values.

I suppose most players want a certain tone spacing, so the stored values would be constant for them, with the calibration routine setting everything right at the start.  I'll try implementing this.

Dewster -

tried downloading from mediafire - but Microsoft Security Essentials alerted me to viruses / trojans etc.. I never clicked on the alert, but terminated using the task manager.. Scanning using my local (verified) security essentials, there was no record of these threats - so I suspect it is some bogus alert -

However, on trying again I found multiple instances of explorer opened on some quite dubious sites.

The Documents page in my element-14 site is free and absolutely clean - you can upload anything theremin related there, or you could open a seperate discussions topic, and add 5 documents to each posting so as to keep related material together. Just a suggestion - I hate having to deal with sites like mediafire where, even if nothing really nasty happens, one is bombarded with adverts and pop-ups.

It would be great if you could keep a copy of your digital theremin repository at Theremin General / Resources group or the Theremin Development group on Element-14.

I am not suggesting that the actual discussion gets moved to Element-14 (Things are quite dead there when it comes to involvement by anyone interested in theremins) but just that it is used primarily for safe, easy document storage.

Fred.

Fred -

I scanned the files with Avira and Malwarebytes and didn't find anything, not sure what's up.  I don't like all the ads & popups at Mediafire either - wish I would get off my ass and rent some web space already.  (I've still got my hate on with Verizon for taking away FTP access to the paltry 10 MB space given free with DSL accounts.)

Dewster -

Why not set up your own 'group' at Element-14 ? You could make this public, invite only, or even hidden... I have a hidden group at which I have uploaded all my 'work in progress' - its a great backup..

So far there seems to be no limit to how much I can store, even on my hidden group -

"I scanned the files with Avira and Malwarebytes and didn't find anything, not sure what's up." -

I think "whats up" is that bogus "virus detection" is being alerted from a pop-up hosted by mediafire - If one clicks on the pop-up you are taken to some site promoting a malware 'protection' or 'correction' program which will "find" and "correct" the non-existant malware on your PC, for a fee... It will seem like this program has found malware which your security software missed - when in fact there was no malware on your PC, it was all just a fictitious creation of this scam software.

I have had this kind of thing happen to me before - only worse.. The software claiming to detect and correct malware actually being malware! I am now extremely cautious whenever I get a malware warning - Bomb out of whatever initiated the warning (using task manager, or if this fails, turn off the PC) and then running a full scan with security essentials.

Fred.

"I have had this kind of thing happen to me before - only worse.. The software claiming to detect and correct malware actually being malware! I am now extremely cautious whenever I get a malware warning - Bomb out of whatever initiated the warning (using task manager, or if this fails, turn off the PC) and then running a full scan with security essentials."

I do a bit of PC repair on the side and know first-hand from whence you cometh.  Those infections can be some of the most difficult to remove because they sense when you're trying to get rid of them.  I've had best results crippling them with an initial blind-side maneuver, removing the bulk with Malwarebytes, and finally rooting out the remaining with a variety of obscure software tools (thank god for PC repair fora).  Task manager shouldn't be hidden behind such an arcane key combo.

I may give Element-14 storage a try, thanks for the gentle prod!

Back to linearity: I've played around with the spreadsheet some more and the upper / lower gain adjustment approach seems to be the most straightforward perhaps easiest to understand - rather like bass and treble controls with variable cutoff, but of course applying instead to linearity.  A single (or no) control would of course be best, and there may be some way to gang the numbers together in a function to accomplish this, but that's down the road.

I was thinking octave hand numbers fed to a bank of piece-wise gains set by offset adjustments would be the best, but having just three bands (where the middle band is only adjustable via the global DPLL cal offset) simplifies things enormously and looks good enough (on paper).  I'm trying to keep any adjustments here simple, and intuitive enough for the average interested user to perform.  Hope to have it coded today.  (Wrote a nice serial multiplier on Sunday that I'll be using - it will be a beautiful day when all programmable logic devices contain sufficient block RAM and at least a few multipliers.)

The simple hi - lo gain didn't work, and in retrospect for obvious reasons as the gain transitions are abrupt.  Interpolated hi - lo gains based on squares looks better on paper (spreadsheet).  Even better is interpolated hi - mid gain coupled with mid - low squared input gain.  Best is interpolated octave gains because it can accommodate almost any arbitrary input curve and isn't difficult to implement, but adjustment could be cumbersome because it requires a fair amount of informational feedback during the adjustment procedure (the input octaves don't mean anything to the player).

Yesterday I simulated a second order delta sigma DAC in Excel.  Pretty easy to implement in verilog and may do that today.  From an audio SNR standpoint it would probably be best to use a real DAC on the final product, but it might be fun to play around with the DIY logic approach for a bit.

I'm reaching the point where transition to a readily available FPGA eval board is starting to make more sense.  Hit the mother lode at this site:

http://tristesse.org/FPGA/CheapFPGADevelopmentBoards

Ideally the board would have a Xilinx Spartan FPGA, RAM, Flash, 16 bit audio DAC, a bunch of header I/O, and sell for $75 or less, but I don't think that product exists.

Also ran across the J1 stack based processor, which is quite intriguing:

http://www.excamera.com/sphinx/fpga-j1.html

One often wants/needs to serialize slower operations and stick them in cheap memory so as to take better advantage of the fast hardware, so I like to think about processors with simple instruction sets and structures, with high code density and ALU utilization.  One could spend one's entire life just thinking about processor architecture and have almost nothing practical to show for it at the end.

"One could spend one's entire life just thinking about processor architecture and have almost nothing practical to show for it at the end."

Yeah, too much complexity, too much choice - and too much committment / investment required in what one chooses - making it expensive if you get your first choice wrong!

Sorry I cannot help here - Perhaps the reason I like analogue and mixed-signal stuff is that one has a load of smaller blocks, each of which can be comprehended and designed independently..

Do you remember bit-slice archetecture? Many years ago I was quite excited by it - building your own MCU, configuring your own specific ALU.. It never caught on, but I wonder if FPGA could go that way - (perhaps it already has - I have not focussed on digital for years).

I admit that I am completely out of my depth when it comes to the technology you are using for your theremin!

Fred.

"Yeah, too much complexity, too much choice - and too much committment / investment required in what one chooses - making it expensive if you get your first choice wrong!"

Particularly for the software you've written for it.  One hardware change and you have to comb back through everything you've ever coded.

"Sorry I cannot help here - Perhaps the reason I like analogue and mixed-signal stuff is that one has a load of smaller blocks, each of which can be comprehended and designed independently.."

I used to be more of an analog guy, but digital for me has been surprisingly every bit as creative - if not more so.  Design the blocks and stick them together.  Though it's taken me forever to get a firm grasp on state machine / data path construction, as well as what constitutes a basic block.

"Do you remember bit-slice archetecture?"

Had an awesome boss and crackerjack head engineer co-workers who did DSP bitslice designs for some of the first digital studio mixing boards.  I'll have to look into it.

I put a spreadsheet with the file name "delta_sigma_dacs.xls" at the repository:

http://www.mediafire.com/?m8iwgugdd68i13f

It's kind of fascinating to plug various input values into the first and second order modulators and see what the output looks like.  I did one of these using analog components in grad school, with the output driving an LED and a speaker.  First order gives all kinds of tones, second order is much more stochastic.  I'm looking into adding dither to the second order so as to reduce spurs.

"Do you remember bit-slice archetecture?"

After looking into it a bit :) it seems to be a way for the designer to build data paths of varying widths with a single family of products, and a way for manufacturers to deal with the very limited pin counts of earlier IC packages (when you work with FPGAs you find out very quickly that pin management is something of a job in itself).

I'm always on the lookout for simple processors, because often much of the hardware in an FPGA design is underutilized due to low clock speed.  If latency isn't an issue, then why not multiplex the hardware with a processor construct?  But I'd like it to be really simple (stateless would be the ideal), not consume much in the way of logic (LUTs, block RAMs, multipliers), have compact op codes (internal block RAM isn't cheap), have high utilization of the ALU (the whole point), and probably most important: be easy to program at the machine code level so I don't need an assembler.

Ever since my first HP calculator I've been fascinated with stack machines.  With no explicit operands, a data stack, a return stack, and almost no internal state, one can have incredibly compact op codes - often 5 bits will do.  They can be very interruptable, and code factoring with subroutines is more natural due to the stacked registers.  I've studied many of these, and have coded my own and had them running on a demo board.  They are easy to implement but surprisingly rather cumbersome to program - one has to stick loop indices under the operands on the stack or in memory somewhere, and there are a lot of operations and time wasted on simple stack manipulation.  The tiny non-standard op code lengths produce a natural instruction caching mechanism, but multiple op codes per word is awkward when you want to manually change the code in any way.

If you are interested in processors and you've never looked at the Xilinx picoblaze, you should - it is a marvel of tiny engineering.  Kind of an overgrown register based state machine.  But the op codes are not powers of 2 in length, and addressing the registers bloats them out.

I'm coming to the conclusion that any serious processor has to have multiple registers with operand addresses in the op code - this allows for a move along with an ALU operation in a single cycle.  Self-evident to many I suppose, I'm so slow when it comes to the fundamental stuff.  After looking at the J processor I had a thought - why not do a 2 operand machine (source & source/destination address in the op code) with 4 generic registers, and have stacks under those registers with bits to enable/disable them in the op code?  A 16 bit machine with 4 bits for operand selection, 4 bits for stack enable, 8 bits for the operation itself.  Large literals would be in-line, small ones could be in the op code field. 

Anyway, it's this kind of massive side diversion that is (I hope not pointlessly) extending the design of my (mostly) digital Theremin, but I'm hoping to parlay much of the foundation established here into other designs.  And it's nice to revisit things I've spent enormous amounts of time pondering and tinkering with, but with little to show for it all at the end.  Though it does feel a bit scarily like answer C of that humorous Engineer Identification Test, where:

You walk into a room and notice that a picture is hanging crooked. You...

A. Straighten it.
B. Ignore it.
C. Buy a CAD system and spend the next six months designing a solar-powered, self-adjusting picture frame while often stating aloud your belief that the inventor of the nail was a total moron.