Open echolevel opened 1 year ago
I think I've fixed that particular issue.
For anyone who's curious, the 303 (and TD-3) decouples its 'pool' of pitch data from its timing data, hence Pitch Mode and Time Mode as separate paradigms on the hardware - one of the toughest concepts to get used to when learning to program the 303. For me, anyway.
That means we can't have empty gaps in the pitch data, like we would if the pitch data was a sequence - it's NOT a sequence; the timing data is the sequence. The pitch data is just a bunch of memory for note pitches, 16 steps (2 bytes per step) long. So we can't have any whitespace in there, ie pitches that aren't wanted and shouldn't exist, otherwise the sequencer will just hoover them up whenever it needs a new pitch for an audible (ie non-rest) note.
So we have to bunch up all the notes, disregarding any un-set pitches aka empty 'steps' in the incoming MIDI, a bit like removing whitespace from a text document. Then we count how many steps were blank and we pad the end of that pitch memory chunk with the 303's default un-set note (MIDI note 24). And that makes things work properly, hooray etc. The reason I didn't catch this before is that I was mostly testing on sequences with all or most of the 16 steps in use; it really rears its head when you try a sparse, 8 or 10-note sequence with lots of gaps.
I think there are related things going on with accents and slides, in some situations. Comparing sent with received sysex tells me that the TD-3 fixes its tied note bits and maybe shuffles some other stuff around according to some rules I haven't fully understood yet - for example, an accent might be shuffled up correspondingly with a pitch because it's not possible for an accent to exist without a pitch...? I need to remind myself of which things get set in which mode on the h/w. I have a feeling slide and accent can only be set on pitches in Pitch Mode, and Pitch Mode has no concept of rests, because rests belong in Time Mode /:D\
Fixed for accents and slides.
Comparing the binary of a transmitted pattern with the binary of that pattern received back from the TD-3 will usually show identical bytes UNLESS the TD-3 interpreted a tied note (two consecutive steps of the same pitch with at least the first of those steps slid), in which case it'll shuffle some pitch, accent and slide bytes around in a way I don't fully understand yet...but it'll SOUND the same. So...don't worry about it, I suppose? Let me know if this becomes problematic.
Oops, not so fast. There's a bug where some NoteOns aren't properly detected and are put in the pitch array as nulls, therefore ignored when writing the final pitch chunk. Working on it.
Yeeesh...so it's all about exactly how you calculate the step divisions in MIDI ticks, and how you assign those divisions to NoteOn (or rest) events. I've made some improvements and I think it's pretty robust, but I'll leave this open for now.
Some notes that STING generates are just out of the 303's range (and therefore the TB-3's, though perhaps some other 303 clones have extended ranges that would cope with this?)
But aside from that, there are some other cases where pitches aren't being set properly, which means I'm not parsing the incoming MIDI properly, so I need to fix that. Needless to say, while the permutations of edge cases are nowhere near infinite, there are enough that it'll take a bit of testing to get right.
It's a known issue, anyway...