I’ll caveat this with it’s been a lot time since I’ve looked at the code… but from memory:
I believe it is just doing last note played priority (and that probably isn’t in the manual). What I don’t recall is how it handles the gate output when the notes are interleaved in mono allocation mode. For example if the MIDI events are:
- note on A
- note on B
- note off A
- note off B
…the device on seeing event 2 can change the pitch CV but it has no idea how long it will be until event 3 (note off for the first note) arrives. The code currently never lowers the gate output if the notes being played overlap.
Since the gate always stays on (in mono mode) that leads me to believe what we are hearing could actually the response time of the CV DAC (digital to analog converted) itself. All DACs take some amount of time to change their output from one voltage level to another. The oscillator being driven also plays a role in the response time, if the oscillator is digital then it will have a ADC (analog to digital converter) on its pitch CV input. An ADC used on CV inputs is likely to be polled at some rate (say 1kHz) and it takes some small about of time to do the analog-to-digital conversion after being asked to. This is a long winded way of saying that I believe there are technical reasons you are finding in more difficult to get a satisfactory progression of pitches when the oscillator is digital (like the disting).
Using an LPG or envelope to shape the amplitude a bit more will help mask the transition from one pitch to the next when the notes don’t overlap but given that gate always stays high if notes overlap then it won’t help much there (since the envelope won’t get re-triggered).
Another factor possible at play is the rate at which then MIDI data itself is being processed. Apologies for the technical digression again but here we go. The way USB works is that the host (ansible in this case) has to periodically ask the attached device(s) if they have any more data. A USB device buffer a small amount of data while waiting for the host to request more.
Currently the code checks for MIDI data every 8 ms. It is possible that in this case multiple MIDI events are getting bundled up together and the ansible is more or less handling them all at the same time which could possibly be the source of the jumpy pitch output.
I think the first thing to test will be speeding up the rate at which MIDI data is handled and seeing if that has a positive effect. Unfortunately I won’t be able to generate a modified build of the firmware for several days.
…thank you for making a recording. It really helped me get a sense of what you were reacting to.
I’ll follow up with a firmware mod to test as soon as I’m back in town.