Adjust tuning per-key (for non equal-tempered music)

[snickell]

I've been inspecting the source code, and it looks like it would be pretty straightforward to implement custom tunings (similar to the prophet v3's custom tuning feature) of each of the 12 notes in the scale.

I'd be happy to implement this, but I haven't purchased a p600 yet, and I was hoping with your knowledge you could confirm if this is a valid/sane project before I start!

[snickell]

Ideally I'd like to repurpose 12 of the pots to adjust the tones while in a tuning mode.... are all the pots accesible to sampling from the Teensy's DAC?

[gligli]

It should be doable, and yes, all the pots are sampled, no hardwiring.

[snickell]

Cool!

I think there's three sub-features here:

1. Implement support for receiving MIDI "bulk tuning" MTS SysEX messages: see http://en.wikipedia.org/wiki/MIDI_Tuning_Standard and http://www.midi.org/techspecs/midituning.php
2. Implement on-p600-ui for tuning by rotating POTs
3. Implement on-p600-ui for tuning by entering just-intonation frequency ratios on the keypad

I'll go into more detail about my proposed UIs for 2 & 3 in another comment.

[snickell]

Oops, fat-fingered it.

[snickell]

And, potentially (if I can figure out a technical approach to this despite polyphony), a 4th sub-feature would be "live tuning of all 12 notes in the octave", a mode where every key on the synth behaves as normal, except changing the pitch-bend permanently retunes all oscillators associated with the last-key pressed.

If I can find a way to do it, I can see this last mode enabling really precise and interesting microtonal performances on the synth.

[snickell]

I think I'm going to start by implementing MTS support, if only because there are fewer decisions to be made!

[snickell]

(btw, this code is a pleasure to work with gligli, very clean)

[gligli]

Thanks, one thing to keep in mind is that code speed matters a lot, especially all that is in the timer interrupt handler. If you hook a frequency meter to "cassette out", you can see the rate at which the main loop runs, if it falls below 40hz, pot stepping becomes really obvious.

MIDI and tuner code isn't that resource hungry tho.

4th will be really hard to implement I think, also given the limited UI, it might be better to focus on the most important features you want to add.

[snickell]

Do you use IRC or another form of chat? It'd be interesting to talk with you about this, as well as some higher level questions (e.g. why not use a 32-bit ARM + an RTOS to make performance+events easier: is 5V I/O the main issue? pin-compatibility? etc). Also like to ask questions about the interrupt design, etc.

Performance: yup, I've been thinking about performance as I've gone through this, and while I haven't been able to test on a live board, I was actually surprised by how much performance you've already gotten out of the AVR. Features 1 through 3 shouldn't be very performance sensitive, because all the "normal" synthesizer knobs can be "off" during them (e.g. while it is not ideal, I think its ok for the synth to not respond for a short time while processing the occasional MTS sysex). Feature (4) would obviously be much more performance sensitive.

Live tuning feature (feature 4): yes, I would only attempt this last. That said, for my use-case, I think its actually the most interesting and useful feature as it would allow microtonality to be used/played intuitively in a performance context, enabling a whole new kind of synthesis in the high-harmonics (LPF & FM are both very very auditorily interesting when you can tune frequencies of a chord interval against eachother).

The most obvious difficulty that occurs to me with feature-4 would be the many oscillators involved (across 6 voices), and keeping them sanely synchronized. One idea would be to actually measure, computer and store 1st&2nd derivative of the effect of CV on each oscillator's actual output-frequency. Depending on the linearity of the system, we /might/ be able to achieve a system where rather than "tuning" oscillators based on a set frequency table, we can actually pick any arbitrary frequency, and "jump" the oscillator straight to this frequency? This might improve the tuning accuracy of bends in general too?

[snickell]

@gligli : stupid question... how do you receive "printfs" from the teensy (in #ifdef DEBUG blocks)? Does this transmit to the USB and receive on a serial console of some kind?

[gligli]

Yep, in DEBUG mode, messages go through USB, you can read them using: http://www.pjrc.com/teensy/hid_listen.html.

I am on efnet IRC, nickname GliGli, also on irc/msn/skype if you prefer.

Basically, yes form factor and 5V I/O was why I chose to use the Teensy++, it makes the upgrade really easy to build / install.

[snickell]

Thanks! I'm about 50% done with the MTS feature.

As a long term idea, it seems tractable to design+have-fabbed a board that accommodates, say, a Teensy 3[1], and includes a 5V<->3V buffer IC on the pins. The board itself is easy of course, the hard part would be finding a small manufacturer who is willing to do the soldering (so its viable for the many people who don't want to solder the parts.... though the buffer IC board could probably be done as easy-enough-to-solder-by-hand through-pin work, it'd still be a fairly large number of solder joints, and the risk of people having one-bad connection and stuff is pretty high).

A 5V buffer board that adapts a Teensy 3 should be a relatively sane circuit, though there may perhaps be issues with oscillation to consider.

[1] Teensy 3 is just one you could use, but it might even be interesting to use a Cortex A8/9 that includes FPU and a DSP. You could turn the synth into a fully featured digital-analog hybrid... you could even host e.g. supercollider on it (which has been ported to the A9's dsp), and load custom easy-to-program super-high-quality supercollider pathces into the LFO circuit etc... sky is the limit.

On Sat, Jan 25, 2014 at 12:24 AM, GliGli notifications@github.com wrote:

Yep, in DEBUG mode, messages go through USB, you can read them using: http://www.pjrc.com/teensy/hid_listen.html.

I am on efnet IRC, nickname GliGli, also on irc/msn/skype if you prefer.

Basically, yes form factor and 5V I/O was why I chose to use the Teensy++, it makes the upgrade really easy to build / install.

— Reply to this email directly or view it on GitHubhttps://github.com/gligli/p600fw/issues/12#issuecomment-33283971 .

[snickell]

PR for the MIDI Tuning Standard support sub-feature: https://github.com/gligli/p600fw/pull/16

[flocked]

Teensy 3.1 is 5v tolerant. At least the digital pins. not sure if the analog pins are needed…

[flocked]

Also would the 34 i/o pins enough? How many is the p600 needing?

[snickell]

5V tolerant is only the inputs, but I assume the p600 will require 5V output as well.