Implements the MIDI tuning standard

[snickell]

Preliminary implementation of MTS.

Limitations:

• Only receives MTS bulk tuning messages.
• Tunings are not saved at this time.
• Only uses the first 12-scale degrees of the MTS (and repeats them for other octaves)
• Impact on "untuned" mode (equal tempered) is mainly an extra 256-bytes to store the tuning. Also takes an extra 32-bit divide operation in tuner_computeCVFromNote(), but this would be easy to optimize out later.

Minor changes to DEBUG:

• More granular "#define DEBUG"
• Configures stdio (e.g. stdout, printf) when DEBUG is defined. Printf makes it much easier to format complex debug information. Only adds 200 bytes to the debug firmware image.

[snickell]

I can send an example sysex .mid file that retunes the keyboard to anyone who wants to try it out, or you can generate one using Scala (or other software that supports MTS).

[snickell]

I wonder if tuning should actually be stored with presets rather than in settings. It does make a lot of sense to associate a particular tuning with a particular configuration of the filters and other parameters (to make overtones that match the tuning).

I think in this case what would make sense for this is to implement a "uses equal tempered" boolean that allows the preset to use less flash if saved without a custom tuning.

I'm also wondering how tight the SRAM is in the current version? Without major rework to how tuning is done (which I'm considering....) it will be difficult to use more than 12-tunings anyway (since tuner is relative to the octave currently). So storing the extra 116 tunings is a big waste of SRAM, but I was planning to implement that later. Maybe its unnecessary, and the best compromise is to not allow full custom tunings.

[snickell]

Here's a link to an MTS Sysex you can use to test this patch: https://dl.dropboxusercontent.com/u/5048927/wtp-mts-sysex.mid (tuning is "the well-tuned piano" by la monte young)

[gligli]

Well, I wanted to release a 2.0, as current code seems stable overall, but didn't have lots of free time these last weeks.
Still, if you're ok with it, I think I won't merge this until 2.0 is actually out.
Left for 2.0 are some minor tweaks, and doc update. Hopefully I can work on it soon.

IIRC, SRAM has at least 1KBytes free, and I didn't really try to keep it low, so you should be able to use 256 bytes of it for tuning.

Right now, each patch is stored in 1 flash page, so it can't be more than 256 Bytes, so storing full tuning per patch will be a problem I think...

Being able to printf() is cool, by the way, I thought it would be too costly, but apparently it's fine :)

[snickell]

Definitely a post-2.0 feature.

On Sun, Feb 2, 2014 at 8:49 AM, GliGli notifications@github.com wrote:

Well, I wanted to release a 2.0, as current code seems stable overall, but
didn't have lots of free time these last weeks.
Still, if you're ok with it, I think I won't merge this until 2.0 is
actually out.
Left for 2.0 are some minor tweaks, and doc update. Hopefully I can work
on it soon.

IIRC, SRAM has at least 1KBytes free, and I didn't really try to keep it
low, so you should be able to use 256 bytes of it for tuning.

Right now, each patch is stored in 1 flash page, so it can't be more than
256 Bytes, so storing full tuning per patch will be a problem I think...

Being able to printf() is cool, by the way, I thought it would be too
costly, but apparently it's fine :)

Reply to this email directly or view it on GitHubhttps://github.com//pull/16#issuecomment-33905032
.

[snickell]

Hi GliGli, what's your current thinking on this?

I've also just implemented an interactive retuning mode: a performance page button that allows you to adjust the tuning of the last-held-note using the "data pot" (speed).

[gligli]

Hi, 2.0 will be out soon (weeks at most), I think this can be merged after that (for 2.1).

[gligli]

Ah damn, I totally forgot to merge this one just after 2.0!

[snickell]

Heh, I forgot too. What should we do? Maybe I should update patches to work
on your latest git rev? Or should I wait for a later time?

On Sun, Sep 21, 2014 at 5:41 AM, GliGli notifications@github.com wrote:

Ah damn, I totally forgot to merge this one just after 2.0!

—
Reply to this email directly or view it on GitHub
#16 (comment).

[gligli]

I think it would be probably easier to merge it now, as future changes could make it harder to merge.

[snickell]

@gligli: I rebased this off your current master, and it seems to be working correctly, so I think this is ready to merge after more than a year ;-)

[gligli]

Ok cool, thanks!

[snickell]

righteous! thanks for your support on this: I believe that gligli p600++
now has the honor of being the first analog synth since the Prophet-5 to
support exploration of alternative tunings.

I'd also like to enable UI support for adjusting tunings live in
performance: good for some reaaally cool drone/noise music. For UI I was
thinking that if you 'double click' the 'Tune' button it could go into a
live 'pitch wheel adjusts tuning of last note pressed' mode (and maybe
blink the tune button while in the mode to let you know you're in a mode).

Would a 'double click on tune to enter live tuning mode' UI be compatible
with your plans?

I can imagine 'double-clicking' potentially being a useful UI feature to
have available as the feature-list grows..... e.g. maybe it would be useful
for the sequencer or arp buttons too. One limitation is we could only use
double-click on a button where instant response is not required, but e.g.
for tune adding an extra 300ms delay before tuning to detect a possible
second press doesn't seem like a big deal.

On Fri, Apr 24, 2015 at 10:59 AM, GliGli notifications@github.com wrote:

Ok cool, thanks!

—
Reply to this email directly or view it on GitHub
#16 (comment).