Tap write mode #13
Tap write mode #13
Conversation
… code into a better structure
| // There most likely is a more elegant way. | ||
| // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
| // Check if we can place the note on the current step: | ||
| if (ppqn_count%(pattern_scale[pattern_buffer]/4) < (int) (pattern_scale[pattern_buffer]/8)) { |
There was a problem hiding this comment.
I'm wondering if allowing later hits to be in the current step would help account for some of the mechanical lag inherent to using the shift button. This would be pretty dicey for the 1/32 scale, but it may help nonetheless.
There was a problem hiding this comment.
my original implementation was more like 2/3 instead of 1/2 of a step..
didn't work intuitive, thats why i probed the 606 to find out how the "official" logic works
There was a problem hiding this comment.
So basically adjusting this to be more tolerant just doesn't work intuitively either, best bet if to remove the physical switch or get used to it (I already have :))
Yocto/Mode_Pattern.ino
Outdated
| SR.Inst_Send(1<<selected_inst); | ||
| PORTB |= (1<<2); | ||
| delayMicroseconds(10); | ||
| PORTB &= ~(1<<2); |
There was a problem hiding this comment.
What happens when the PPQN count interrupt triggers here? It seems unlikely to occur, but it might be worth considering. Quickly masking the interrupt seems like a bad idea, but I'm not sure what else to do.
There was a problem hiding this comment.
I've been thinking about this one over the past couple days. It seems like the best behavior for this "corner case" would be to send the trigger pulse while the shift register only shows selected_inst, then rewrite the shift register with the pattern data and send the "normal" trigger pulse. To do this would require changing the interrupt priority and rewriting some of this code. This may also introduce a double-hit on selected_inst (or maybe not, depending on the time between pulses!). That seems like a lot of work though, especially if the code pretty much works to way it is. What do you think?
There was a problem hiding this comment.
I think it's a lot of work :)
|
I really like the changes you made to the step length buttons behavior. Regarding the actual tap entry, it does feel a little wonky. I've added some comments in the code where we can hopefully hash some of that out. |
…possible double trigger for now
|
I just added 2 more commits,
Personally I like how it works now, so I won't really expand on it any further unless bugs are found. |
This is an implementation of "Tap Write" mode.
Usage:
In pattern edit mode, while the pattern is running, press the "shift" button to enter notes in real time for the currently selected instrument.
Bonus: new instrument clear functionality: In pattern edit mode, while the pattern is running, press the Tempo encoder + Shift, all step data for the current selected instrument is cleared.
Note:
To make this possible the controls to change the pattern length had to be changed, instead of using shift+"01-16" button or shift+"16-32", you now use those buttons without shift. Which imho works a lot better anyway... So to change the length of the pattern after this change, hold either "01-16" or "16-32" button and select one of the 16 steps.
Implementation
As I had no TR-808 at my disposable, I investigated the TAP mode on the the TR-606.
If a tap is "late", it is registered on the next step (= quantise, more or less). The definition of "late" depends on the current scale, the specifics are documented in the code itself.