swampflux / tri-plus-ger Goto Github PK

• retrigger
• play/pause
• roll
• clock division
• tempo
• roll rate

The idea here is that the user effectively presses on-off-on. only counting three beats initially feels awkward but it's more intuitive the longer I think about it. In live TV, a verbal countdown stops before reaching zero. skipping a beat will let the user have a moment to move their hands in to place and perhaps even record a bit into the pre-roll. That could be really innovative and genuinely awesome.

Created from #5
I think that the clock class's reset function will handle this, but actually outputting the clock signal should come from main loop. it hasn't been wired up yet

• catch the retrigger cv/button
• reset the clock
• be careful to not repredict tempo from the incomplete period

Retrigger, play/pause, and roll have just one analog pin each yet the original firmware seems to know the difference between a button press and CV input. Figure out what's going on. Write a new function or class if necessary.

• Measure transport buttons
• Measure Rec and Alt to see if they're the same — consolidate!

Anyone wanting to program with this big boy, can't right now.

Created from #5 This might be resolved with #9 or even with #11.

The idea was that the clock input might be coming from one module and that the user might want the behavior of the retrigger to be one of two modes

• time is always kept with the incoming clock
• time is kept with the retrigger

but if the incoming clock is not perfectly in sync, then the clock cannot reliably tell us when to trigger high. The retrigger offset would need to be added to that timestamp.

• research if anyone would even want this

The beat weight feature should be an enhancement not something you have to think about if you're just coming from the stock firmware. I think it would be intuitive to..

• hide beat weight under ALT + Roll
• set the default tolerance to 1 by default
• record new pulses with a weight of 3

This way all beats to be recorded and played back as if the feature wasn't there at all.

Tri-ger seems to be using a shift register to read from knobs and potentially other things on the board like slave/master pins. This issue will track all the nonsense that's going on with that effort.

Created from #5. Maintain the clock rate regardless of the sync. Keep track of how many beats need to have pulsed. Something.

Synchronize to Clock Input and allow clock multiply/divide via clock division knob

• figure out which jack to use
• decide how to mult/divide input clock rate
• #9 maintain mult/divide output clock rate
• #10 maintain internal clock when no external clock is used
• #11 maintain retrigger behavior (beats start immediately instead of waiting for internal beat)
• #12 keep time with external guidance but match retrigger start point
• try to make the code efficient
• clock input should hold up against non-trigger signal inputs

I've been a little too forceful in optimizing my inputs to the point that things stopped working. Arduino inputs are 10-bit. B1111111111 is the same as 1023 That's cool but it's time to diex everywhere I used a uint8_t variable and lost the 2 most significant bits.

Created from #5
Not everyone has a Pam's. I think the most obvious solution would be to detect if there are changes happening on the Tempo input.

• research the tempo of the factory firmware

If beats in memory have not changed for 4 bars, write to EEPROM automatically

Muting has problems! Firstly, the arcade buttons are always going to fire an output. I thought it would be nice to simply press "Alt" + the arcade button of that channel. Viola, a mute. But it'd also trigger a beat at the same time. The beat weight feature may be enough but even with a fourth setting with zero tolerance, everything would mute not just one channel. Alt+ the three left buttons might still be the best bet. But some investigation is needed. I was under the impression that the button and CV were multed together. Perhaps all input CV is passed through at a lower voltage? Because the factory firmware still distinguishes between the CV and the button press yet they do share the same digital channel. I don't see how that's possible unless they're actually being read as analog inputs.

• find out what value is read in by a hot CV versus a button press
• ???
• mute!

Use some sort of LED flashing of the ALT light as well as perhaps a visualization on the orange grid about the value. Also don't write any value unless the knob was turned. Similarly, the original function should not change once Alt is released unless the knob is turned again. There's some quickly written code in develop right now to do this for clock divide input, but formalize it as a function or class to save memory.

• create new class for detecting if knob changed
• replace current prev/next variables with new objects

Instead of storing 3 channels on 1 byte of memory, which only uses 3/4 of the byte, it makes more sense to use a byte per channel which can hold up to 4 steps.

• bring back the grid class
• store 4 time steps (2-bit weight) in 1 memory byte
• write function for extracting a weight from a byte
• write function for writing a weight to a byte

A quantized beat is also a less lengthy one. Perhaps Quantize and loop length can live on the same knob as opposites by somehow organizing the selection of beats in the grid creatively. Something like a bayer dithering pattern comes to mind..

Instead of throwing out the slop completely, I'd like to meet qu-bit somewhere in-between completely sloppy beats and perfectly quantized beats. I think that the clock division input will be a good way of doing this. Internally, my plan is to create many beat grids with ever finer divisions. As you record, beats will be added to every layer which will result in finer detailed layers keeping slop and less detailed layers sounding time-quantized. This method will likely also greatly increase the quality of recorded slop since the memory grid can be scaled to match the incoming clock signals.

• decide how fine of a grid can be used - 24ppqn since it's standard
• decide how to structure the data so it makes sense with typical clock divisions
• decide how to snap beats to their "home beat"
• should slightly early beats be snapped? how?

Storing a large multidimensional array of booleans for the grids was quick and easy but

• 3 channels
• 3 layers
• 16 quarter notes
• 24 pulses per quarter note

multiplied out to 3,456 bits which is more than the 2048 (2KiB) of RAM available on the ATMega328.

Thankfully there are 1024 8-bit bytes of EEPROM and the grids needs to be stored anyway, but that will also slow things down. Fix all these at once.

The grid and the clock code are becoming very complex. It would be good to write some unit tests so I know that it's actually doing what it's supposed to do instead of manipulating the main.cpp program or taking over the blinking LEDs all the time

• Research the PlatformIO Unit Testing Solution
• rewrite the platformio.ini file so that building all environments pass
• make some new issues to address tests that need to be made

Reading weights from the LEDs is hard to do. There might not be multi-color or anything like that, but at least distinguishing them a little nicer with the least amount of flicker.

• Try real pwm (did not work)
• Try faster light blinks
• Show these lights to another human being and ask them if they can tell the difference

I now am more confident that it will be possible to use the tempo cv and knob as the clock input.

• use the highest value for incoming clock pulses
• make use of lower range to slip the beat's offset (can be used for swing) 1 quarter note's worth?
• make use of the lowest value for disposing of the current tempo and switching to internal clock mode #10 until an incoming pulse is detected again
• make use of lower range values for setting tempo manually in internal tempo mode

bonus points:

• detect double-tap for catching retrigger from a host tri-ger

write an automated test to make sure that beats are quantized as expected

a Tri-ger must be able to host a Tri+ger and vice versa. Tri+ger must understand the configuration jumpers on the back of the board as well. This issue will track efforts to do that.

• reset (1 LOW pulse), play (2 LOW pulses)
• ground
• record button
• ground
• tempo dial

not yet identified

• tempo cv ?

While not in record mode or holding ALT, play/pause should simply toggle isPlaying. Be mindful that the state cannot be visualized on the play/pause button itself and that the button and CV jack have OR-like logic. That is, holding the button will stop incoming CV gates.