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

"Ever since my first HP calculator I've been fascinated with stack machines."

http://obswww.unige.ch/~bartho/stakflow/index.htm

"when you work with FPGAs you find out very quickly that pin management is something of a job in itself" - Dewster

Yeah - I can believe that! The PSoC (1) was advertised with pin reconfigurability as a selling point - whilst this is generally true, as soon as you get to doing anything complex with the part, you quickly find that its not so true.. I spent more time trying to connect pins to UM's to actually use the resources in the chip, than I spent on other configuration / coding issues.

I understand (and from examining the data, it looks to be true) that the new PSoC 3 + 5 pins are almost absolutely definable.

For what I do with them, the processor has only a minor role - mostly, I configure the chips to be "hard wired" as circuit blocks (analogue and digital) which operate without reference to the processor - the only time the processor acts is to reconfigure these 'blocks' when a change is initiated by the user - for example when the register (as in octaves are raised or lowered) is changed.. The processor is continuously scanning the inputs (doing debouncing , reading the A/Ds, determining wrong-side-of-null etc) and when action is required, initiates the required action/reconfiguration - this takes a few microseconds. Nothing related to the audio is ever 'produced' by the processor.

I have looked at the PSoC 3 + 5 thinking that I may (with their much faster processors) be able to do some 'signals' stuff with these  - in particular, doing some DSP in combination with the analogue filters I can construct in these chips, to implement controllable vocal formants.

But, certainly for now, if I do get back into business, I will stay with analogue and mixed signal.

The main "wall" I face is maths - DSP is too maths intensive, and whilst I can get enough of it to understand whats going on, I cannot do anything clever.. The TM showed me just how far I am from even being a DSP hobbyist, let alone an engineer!

What is really needed (IMO) is a team of engineers (and competent thereminists as consultants), sharing ideas and competence, and developing a 21st century theremin which uses the best of technology.. Alas though, I do not see this happening - we are all stubborn gits at heart - with our own particular preferences and irrationalities.. More time would probably be spent discussing (arguing!) than achieving anything - And "the inventor of the nail" would get the brunt of our scorn!

Fred.

Gordon,

Opening:

http://obswww.unige.ch/~bartho/stakflow/index.htm

The first image I saw (before I read the title) looked like some weird theremin design - Two "antenna" symbols sticking out the top of some 3d interconnected sub-circuits.

Really took me back, your article! All that stuff I used to work with daily, but have almost completely forgotten -

Now, when I look at a flowchart, my brain first assumes its a schematic ! LOL!

Fred.

"Ever since my first HP calculator I've been fascinated with stack machines."

http://obswww.unige.ch/~bartho/stakflow/index.htm

Ha!  I do have several Forth books, and have read a lot of stuff on Chuck Moore's web pages.  Being a procedural rather than a symbolic language, I find it very difficult to read.  I know it has to be 100% postfix to work, but this puts the branching words (if, then, etc.) in places where they don't necessarily make sense from a linguistic point of view.  Also, having simple stack manipulation consume the same real time (in a hardware stack machine) as an arithmetic operation strikes me as inefficient.  Finally, the stack gymnastics necessary to produce compact code often tend to obscure the algorithm being implemented.

I'm all for what they are trying to accomplish (simplify the lowest level, bring cheap computing to the masses, stick it to the man, etc.) I just wish I could appreciate it more for what it is.

Fred. Hahaha. Yes. (Although I thought it looked more like a trumpet.)

Also, not surprising that they look like schematics - Forth is one of the few (if not only) languages devised by an engineer rather than a computer scientist.

Dewster. Yes, it is an inscrutable language. It's assembly language for a stack machine, so really ought to be compared to register machine assembly languages for legibility purposes. (Although these days C is probably the closest most programmers can get to the hardware and that's not exactly the most legible language in the world either. Well, it baffles the heck out of me, anyway.)

It is possible to optimise Forth to remove stack shuffling inefficiencies - certainly Forth Inc. Forths do that - just as it is possible to optimise much of that inefficient shunting data in and out of registers in a register based machine - but I appreciate the simple and direct one to one correspondence between the written code and what the computer does. And that it acknowledges that the programmer is the smart one in the relationship, not the computer. Pretty much the same things that I appreciate in the theremin! (The downside is that the burden of responsibility is on the programmer/thereminist is greater - no lovely hand-holding here.)

"The downside is that the burden of responsibility is on the programmer/thereminist is greater - no lovely hand-holding here." - Gordon

Hand-holding, when it comes to programming, is, IMO, a pain in the but. My main programming language is C, combined with assembler - "plain" C is about as close to machine level as one can get, and (IMO) is ideal for coding MCUs..

But it is C++ (particularly microsoft variants - but also any OS centred variants [apart from unix, which C was written for]) which I dislike - One is not developing code with these, one is patching preconstructed objects together.. its (to me) a bit like painting by numbers, fine if you like the picture and the colors provided.

To me, C++ is just overwhelming and unreadable, but C is almost like a legible form of assembler - I quite often plan my project code in C, then use this as a "plan" commenting out the C lines and substituting more efficient assembler code to do the function.

I only briefly played with Forth, and really liked it - It was well suited to the TMS9900 I was using at the time, as this operated with multiple stacks and had specific opcodes to allow rapid context switching (it was a lovely processor IMO) - But this was back decades ago (I used a teletype as my I/O back then - for developing code, and we tended to write our own interpreters and compilers - or just code in octal!)

And yes - Euclid's trumpet does look like one of your flowcharts - or is that one of your flowcharts which looks like a trumpet?

Incomprehensible!

Fred.

"But, certainly for now, if I do get back into business, I will stay with analogue and mixed signal.

The main "wall" I face is maths - DSP is too maths intensive, and whilst I can get enough of it to understand whats going on, I cannot do anything clever.. The TM showed me just how far I am from even being a DSP hobbyist, let alone an engineer!" - FredM

Fred, have you read "Musical Applications of Microprocessors" by Hal Chamberlin?  Rather dated now, but a total classic.  He shows how to implement a digital state variable filter among other things (I have a spreadsheet of this in my digital Theremin archive).  Written from the hardware designer perspective.

Another big DSP influence on me was a paper by Ensoniq & Lexicon designer Jon Dattorro:

https://ccrma.stanford.edu/~dattorro/HiFi.pdf

He has some papers describing effects design that look interesting:

https://ccrma.stanford.edu/~dattorro/EffectDesignPart1.pdf

https://ccrma.stanford.edu/~dattorro/EffectDesignPart2.pdf

https://ccrma.stanford.edu/~dattorro/EffectDesignPart3.pdf

"It's assembly language for a stack machine, so really ought to be compared to register machine assembly languages for legibility purposes." - GordonC

True that.  Though it occurs to me that register names in assembly are a first step towards the symbolic representation of variables.

What do you think about a machine with 4 generic stacks?  Perhaps using stack 0 to push the interrupt return PC, but otherwise completely interchangeable.  Opcode looks like this:

 [15:8] [7:4] [3:2] [1:0]

 opcode s-bits dest src

Where the s-bits, when set, make the source and destination stacks behave like simple registers, otherwise the behavior is pop for source & push for destination (push/pop for destinations which are used also as a source for two input operand operations).

Mr. Moore's F21 processor design uses a single register as a pointer (among other things) and I've often thought that this should perhaps be a third stack.  4 stacks might remove the need for all those nasty "pick, roll, over, etc." stack commands.  Even on an HP, when I find myself needing to doing a roll I generally get completely confused and have to start over.

"Fred, have you read "Musical Applications of Microprocessors" by Hal Chamberlin?" - Dewster

Yes! - I got this book many years ago (1983?) first edition, it has been a bible! - Pages are all detatching from the binder, and have been frequently re-glued!

And yes - the whole "Digital Synthesis and Sound modification" section is a goldmine - without it, DSP would be even less comprehensible than it is. Back then (80's) I played a bit with some of the concepts, and later got a AD "Shark" DSP DK.. But, at that time these were "hobby" activities in my "spare" time - When working in electronics / programming in my day job, I lacked motivation - so went out and bought synths, and played them instead.

I will certainly look at the links you provided, Thanks!

Fred.

>> Updated:

Yeah - those articles made me feel old and stupid! Like the DSP stuff in Hal's book - I can understand it, but am not able to visualize it.. When I am dealing with circuits, I can "see" the flow of electrons and "hear" the sounds, and am able to change things and 'invent' other ways to do it..

I am slightly autistic, and have been told that this "visualization" ability is not uncommon with autistic people - Alas, for me, it does not extend into mathematics or DSP - It is limited to processes I can mentally model - and these are electronics, some physics, and mechanical processes.

My best bet is to just stay with what I am good at - and at some future time get someone else to add DSP stuff to what I design.

Fred.

"Though it occurs to me that register names in assembly are a first step towards the symbolic representation of variables." - Dewster.

Well, yes, a fixed number of global variables that are constantly being hijacked for any and every purpose. Eek. So what do you do to maintain their integrity and make them local variables, useable for recursive and reentrant code? Push them onto a stack! 

"What do you think about a machine with 4 generic stacks?"

4 stacks? That sounds like a lot to me. Once I had need of a third stack, and that was somewhat esoteric. The quick version is that I was writing a non-deterministic string pattern matching language as an extension to Forth. (The third stack was for internal use only, not available to the end-user.)

(What the heck does that mean? Non-deterministic - some problems can't be solved without hindsight. Say you are packing for a holiday and you have room in your luggage for either an umbrella of a bottle of suntan lotion, but not both. You don't know what the weather will be like. How do you choose? Simple - pack the umbrella, and if it turns out that that it was a lovely sunny holiday after all, turn back time to when you were packing your bag and pack the suntan lotion instead.

Turning back time is not practical in real life, but when the vast majority of your world is a data stack and a return stack that manage the flow of data and control respectively, it's possible to maintain a history stack that lets you keep a record of how the other two stacks have changed over time and backtrack them to an earlier state. It's rather mind-boggling to do - implementing a practical set of optimised(*) non-deterministic control structures took me about a year of evenings and boiled down to less than 10k of source code(!) that was so far beyond inscrutable as to beggar belief. If you're curious, a chap called Chris Jakeman created an ANSI Standard implementation with documentation and examples that can be downloaded here. It includes my original non-standard code for GemForth on the Atari ST.)

(*) Pruning the history stack as you go along makes backtracking very quick.

"Even on an HP, when I find myself needing to doing a roll I generally get completely confused and have to start over."

Needing to do a pick or a roll is often a sign that you are already confused and ought to start over again! My pattern matching language extension had neither. :-)