(Kria) durations relative to clock/division

Monome
1

I think it’d be nice if the gate durations from Kria were relative to the clock (internal or external) and division of the triggers of a track. With current functionality, if you use a slow clock or have a track with a long clock division, the gates are still relatively short. It’d be great if you could have voices that let long notes ring out.

I read through the source code a bit and found the line of code where durations get set (line 470, ansible_grid.c). If I’m just interested in getting longer gates in general (which I am), I think I could just increase the bitshift by a bit or two more.

dur[i1] = (k.p[k.pattern].t[i1].dur[pos[i1][mDur]]+1) * (k.p[k.pattern].t[i1].dur_mul<<2);

becomes

dur[i1] = (k.p[k.pattern].t[i1].dur[pos[i1][mDur]]+1) * (k.p[k.pattern].t[i1].dur_mul<<4);

I’m presuming that ultimately the duration is in ms. This would be the easiest solution.

Even better would be to incorporate the time interval between clock pulses into the calculation so a slower clock yields proportional gates. For the internal clock, the variable “clock_period” seems to store the time between clock pulses (again, I am assuming this is in ms), but based on my read, the “handler_KriaTr” function is called automatically when the clock input receives a trigger.

I’m very novice as far as C programming goes so I’m a little clueless as to where to read how much time has passed between the handler_KriaTr callbacks and how much precision I’d need to use to store it. If anyone can advise on how to accomplish this, maybe I could try it.

As for the clock division of the track’s triggers, I believe that would be as simple as multiplying the existing line by the track’s “tmul” variable:

dur[i1] = (k.p[k.pattern].t[i1].dur[pos[i1][mDur]]+1) * (k.p[k.pattern].t[i1].dur_mul<<2) * k.p[k.pattern].t[i1].tmul[mTr];

I think the bitshift + multiplying by the track division/multiplier (it is a division even though its referred to as a multiplier in the code, right?) would be fine, but feels like it’d be cool for it to all be linked to the clock speed so if anyone would like to shed any light on that, I’d love to get some tips!

3 Likes
2

get_ticks is probably what you want (it’s in ms). so technically you need u64 but u32 is probably good enough to store duration.

3

Ah thanks! Looks like what I want.

Why are some variables declared as u8 while others are uint8_t?

4

uh oh… the version of libavr32 that the Ansible source was using didn’t have get_ticks so I pulled the latest and now there are errors elsewhere:

../src/ansible_midi.c: In function 'arp_seq_switch_active':
../src/ansible_midi.c:1224: error: implicit declaration of function 'timers_pause'
../src/ansible_midi.c:1236: error: implicit declaration of function 'timers_resume'
make: *** [../src/ansible_midi.o] Error 1

In the current version of libavr32, those two functions have been removed from timers.h/timers.c :weary:

5

u8 is equivalent to uint8_t, that’s just for readability. these are defined in https://github.com/monome/libavr32/blob/master/src/types.h. some files might have a mix of both depending on who made the change, this is more of a question of personal preference.

timers_pause / timers_resume were replaced with irqs_pause / irqs_resume. just replace timers_pause() with u8 irq_flags = irqs_pause() and timers_resume() with irqs_resume(irq_flags) and it should fix it. you might also need to add an #include for interrupts.h.

1 Like
6

thanks! i will give this a shot when i am home later.

7

have to say I agree this seems like a great feature! It’d be great to get this idea into aleph kria, though the plumbing might work a bit differently, can’t remember…

8

I would also really love to see this feature. It would be great to be able to use longer gates to control slow envelopes. Though I do wonder if there was a good reason it was designed as it is.

9

i’ll probably tackle it tonight. i already added the part where the track’s trigger clock division is factored into gate length and for me it already went a long way towards what i was looking for. i can post a .hex file when i’m done if anyone wants to try.