PCM midi note vs logfreq_coef[0]

[bwhitman]

If a midi_note is set for PCM, it may not be the right freq as logfreq_coef[0] may be adjusted from that oscillator from a previous note on. From dan: This is a consequence of (ab)using the “frequency” of the note to be the playback sampling rate of PCM voices. Instead, we should let the frequency calculation do its thing like for any other instrument, then at the last moment convert the requested frequency, the “base note” of the patch, and the sample rate of the patch, into an effective playback rate

[dpwe]

Here's what I commented on commit 145283a:

I want to wind this back. The problem is what happens if an osc has both freq=xx and note=xx specified. Previously, the two inputs would combine - set freq=1000 then send a note-on with note=72 (where ZERO_MIDI_NOTE is 60), and you get a fundamental frequency of 2000 Hz. With this change, you just get regular MIDI 72 (523.3 Hz) and your freq parameter is ignored. I can add a test for this.

The problem arose when an osc was being used for PCM, then reused without resetting. Currently, pcm_note_on checks if logfreq_coefs[COEF_CONST] is unset (0), and sets it to the frequency derived from the current note if so. Then, the second time that osc is used, the logfreq_coefs is set, so the behavior is different; if the osc is being used for a different PCM voice, or the same voice with a different note, it will have the wrong frequency. That's why the Drums synth used to explicitly set freq=0 in every note-on (which is an effective work around).

The real fix is to clean up how the PCM oscillator handles frequency and note-on. It should be looking at msynth[osc].logfreq, not the components of synth[osc].logfreq[]. But because of the way the PCM oscillator converts a target fundamental into a sampling rate (which no-one seems to understand at the moment), it's not completely straightforward.