Archive of the former Yahoo!Groups mailing list: MOTM

previous by date index next by date
previous in topic topic list  

Subject: Re: [motm] MOTM-650: load custom tunings?

From: Neil Bradley <nb@...>
Date: 2015-06-02

> One thing I find inconsistent; say you tune to just intonation, the
> pitch wheel remains equal temperament semitones. If your playing style
> uses a lot of bends, that's a problem. Bending to some intervals will
> sound really bad, while others will be usable. Wouldn't it be possible
> for the 650 pitch wheel setting to reference the tuning table, and look
> up/down x number of ratios to find the correct stopping pitch?
>
> Mentioned this to Paul last week, he says that old processor is already
> pushed hard, but maybe Neil would know some fancy code that could do it?

Before I delve into some details, I haven't touched the code in 13 years
nor do I have any intention of doing so ever again. Further discussion may
be interesting, but ultimately just an academic exercise since there's no
possibility of a revisit.

I worked with Robert Rich on the microtuning implementation. At the time,
the topic of pitch bend with microtuning did come up. Keep in mind, this
CPU has 64K of flash, 1K of XDATA RAM, and 256 bytes of internal RAM. A
16x16 bit multiply requires slightly over 1ms of execution time. Divides
were even worse.

The issue is that it would require divides or multiplies in order to
translate linear->nonlinear DAC scaling each time the pitch bend is moved.
The entire portamento/glissando code must now understand the nonlinear
nature of glide, which means a lot more multiplies, moreso than available
compute power. Multiply that by 4 voices and it's a real problem.

The other option for getting rid of the multiplies is a step rate being
created, but that's far larger than the RAM that's available. IIRC, There
was about 30 bytes left.

I've been asked to open source the MOTM-650, which I can't do since I no
longer own the license for it (I sold the company that does) and a lot of
the code in the 650 was used in a product that's still shipping.

Paul is right. The CPU is already pushed extremely hard, especially when
the arpeggiator is running. The entire time critical codebase was written
in 8051 assembly language. It was all we could do to get it to work as
well as it did on that old CPU.

-->Neil

----------------------------------------------------------------------------
C. Neil Bradley - Excessive process falsely elevates the incapable and ties
the hands of the exceptional.