Today's issue is overlapping notes, by which I mean two or more overlapping instances of the same MIDI note on the same MIDI channel. The typical behavior is, when one the overlapped notes ends, it cuts off the other instances, even though they still have more duration to go. This causes unexpected rests (gaps) in the audio.
Some synths (e.g.Yamaha) do the right thing: they keep a reference count for each note on each channel, and only release a note when its reference count transitions to zero. But many hardware and software synths (including Reason) don't do this, so one can't count on it.
Many techniques I use (e.g. position modulation) create overlapping notes constantly, and the inability of most synths to handle it limits the usefulness of Polymeter. So I propose to handle overlapping notes in Polymeter. There are two approaches, and I propose to support them both.
The first approach is this: when a note is ending and would otherwise cut off another instance of the note, don't send the Note Off, instead defer it until the other instance ends, and when it does, send both Note Offs at the same time. This requires reference counting and is very likely what Yamaha does internally. It scales, in the sense that it can handle any number of overlapping instances.
The second approach is, when a note is about to start and would overlap another instance of the same note, send a Note Off for the first instance, before sending the Note On for the new instance. This effectively prevents the overlap before it happens. This method very likely won't sound the same as the first one, because the Note Off will trigger the release stage of the earlier note. But in some cases it may be preferable.
The first approach could be called "poly" because it allows the increased polyphony caused by overlapped notes. The second could be called "mono" because it imitates the behavior of a monophonic synth that can only play one note at a time.
Neither approach is hard to implement, though they will add some overhead of course and should certainly be optional. The first approach is more expensive in that it actually requires TWO counts for each note / channel: a reference count, and a count of the number Note Offs that have been deferred and remain pending. I don't see a way around that.
