Programming a Theremin via MPLab

Hi there,

I have been wondering if it is possible to program (and not just building it by copying it from a magazine) a theremin using a PIC Microcontroller and a C++ program like MPLab for example ?
Has anyone of you ever tried ? Since I am not very familiar with programming yet, what are the possibilites and advantages by doing so ?
Hope to get some useful respond !
cheers,
pete

I would say that is a NO.

The theremins that have any sort of MIDI interface only have MIDI out. You can't control the theremin from the MIDI port, you can only use the theremin to control other MIDI devices.

If you are trying to construct a theremin using a PIC, you will most likely go to a lot of trouble to build something that's only good for making "spooky noises", not for playing music on.

Don

"Has anyone of you ever tried ?"

Yes - In my opinion, If you want a real Theremin, dont waste your time with this approach. I did not use a PIC for my original Theremin designs, but did a lot of development using PSoC.. Using a processor is worthwhile AFTER a more-or-less conventional Theremin 'front-end' has done most of the work .. but using the processor to do the 'front end' (capacitance sensing etc) is a minefield.. particularly if using slow MCU's like 8 bit PICs or PSoCs.. The new PIC32 IS up to the job, but still requires enough external circuitry to make its cost and complexity not worth the effort

1.) You will need a capacitance sensor circuit of some kind - but to get useful signal, you will discover that you need to build a 'conventional' heterodyning Theremin anyway.. After this, you can feed the difference signal to a slow processor for conversion to MIDI or other protocol (I2C to drive DAC etc).

2.) For audio output, I have found that staying with analogue is far better.. The only REALLY useful thing I have found to use a processor for is Auto-calibration.. Where the processor can correct for changes, and also provide linearity correction - but even here, there are analogue techniques which do the job better.

There are "direct digital" approaches [PSoC CapSense for example] (this is where I started, and wasted a lot of time) - but these lack resolution unless large integration times (>10ms) are involved, and have limited sensing fields.

There are "Theremin" controllers based on this technology, but they have about 30cm linear playing fields, 60cm max.

Unless you are trying to do something special (like sensing a vector field as I am doing with
Epsilon (http://www.epsilonsynth.com/home)) there is little point in employing a processor..

Just for the record.. Epsilon is now using a PIC32 and MPLAB is being used for development.. but the project is going slowly - I am concentrating on taking modules developed for Epsilon and packaging these as a Theremin Developers kit. C++ is not ideal as a lot of 'machine level' programming and interrupt handling is required,and C++ constructs, whilst great for higher level programming, add an unnaceptable burden to limited resources of a small MCU.. You cannot apply normal "good" programming practices - for example, parameter passing causes extra instructions which can be eliminated by using global variables - but global variables can be more easily corrupted so are avoided in "good" programming.. The 'scope' of variables is an area C++ is quite strict about. For anything less than PIC32 or DSPIC, a mix of C and Assembler is required, with all ISR's written in assembler.

FredM,
You should stay more guarded about the facts that you have discovered about Theremin design.
You revealed much in that last post.

Good Luck!

teslatheremin

"FredM, You should stay more guarded about the facts that you have discovered about Theremin design.You revealed much in that last post."

Thank you, TeslaTheremin.. I know you are right - but it is difficult for me to be 'sensible'!.. Actually, I hate the idea of keeping ideas under wraps, I hate the whole concept of IP and patents, in fact - I hate almost every idea linked to capitalism and business - LOL!

We hold everything back by keeping secrets.. I have ideas, but am sure at times these ideas are not implemented in the best way, simply because I lack some special expertise.. Oh, I SO wish there was a community of creative musical instrument designers, builders / testers and a means to get a living from doing this stuff which did not involve competition or secrecy!

As they say ... the devil's in the details!

While it may seem that Fred spilled everything in his post, it is a far cry from knowing the approach to getting the thing actually working!

There was a comedy troupe back in the 1960s (Fireside Theater, I think) who coined a line in one of their bits I love to quote: "Everything you know is wrong" It seems to apply many a time when you are so sure you know how something works or how it could be done better. :)

Don

"As they say ... the devil's in the details!"

You are absolutely right on this, Don! .. I would not be able to get much from what I posted.. but it might have got me thinking about "the devil" and saved me a lot of time, had I read a posting like this before I started.

The digital / computation route looks easy when one does not account for real world factors - get an oscillator whos frequency depends on sensed capacitance, feed this into the processor, get the processor to determine (from max and min values sensed) what the 'present' value is, and process this value to apply correction for non-linearities etc.... All simple...

Until one starts dealing with reality.. input frequency at (say) 285 to 295kHz.. 14 bit required resolution on output signal.. conversion of inverse square input function to linear / log / exponential outputs (to drive MIDI or 1V/Octave output, Direct volume drive, direct pitch oscillator drive)..

Doing the above with an 8 MIP processor (or 4 MIP in the case of PSoC) does not give time to service ISR's let alone do the computation, unless one has a large pre-devider on the input signals.. And this adds unnaceptable latency to the process.

I just want to warn anyone looking at going down this path - help them avoid wasting the time I did - I do not want to put anyone off exploring the idea.. There are ways to make things easier - and I am happy to divulge some of these ideas.

Fred wrote:

"Doing the above with an 8 MIP processor (or 4 MIP in the case of PSoC) does not give time to service ISR's let alone do the computation, unless one has a large pre-devider on the input signals.. And this adds unnaceptable latency to the process."

This is why all the effects pedals use DSP processors. Other than turning LEDs on and off and displaying simple screens, 8-bit general purpose processors and microcontrollers are pretty much useless. (Imagine trying to run something like Windows XP on a Z-80! :) ) When MIDI was first developed, people could barely get enough speed with 12MHz 8051 microcontrollers to send MIDI commands in something that had tolerable latency.

I'm still the new-kid-on-the-block when comes to theremins, but I think the real charm of the theremin is that you are working right at the point of generation of the sound -- it's as raw as you can get and still be electronic. But it's not just tweaking the big rotary knob on a bench oscillator ... you have to work with the nuances of 2 oscillators fighting against each other.

To draw a further analogy, it is like working with the sound right at the bridge of a guitar as opposed to just before the power amp stage inside the guitar amp!

Don

can actually someone here come back to my question ?
I am not a computer / electronic geek so most of the stuff you guys write down here I don't (and hopefully will never) get anyways. I just want to know how to make a theremin with a simple Microchip Processor and a C++ Program like MPlab (that's just because I have to do cause its part of my course).
thanks

microprocessor or PIC Microcontroller ... whatever the difference is