I’ve been waiting on this one also, but that’s kind of the beauty of open-source: if it’s important enough you can learn to fix it yourself, which I haven’t made the time to do either.

this looks like a promising function to tweak if duration / clock scaling is not to your liking (?)

i don’t have euro stuff so can’t easily verify, but seems to me if the dur is simply set long enough, then the next stage will cancel the gate-release timer before it fires, here:

[ https://github.com/monome/ansible/blob/master/src/ansible_grid.c#L579 ]

which i believe is what is meant by “note-tie”?

2 Likes

Sorry to anyone who has been waiting for a fix on this. Last year, my MacBook Pro that I was using to work on Ansible died and I was without a laptop for a while, which coincided with the timing for this issue that came up.

Since getting a new computer I still haven’t set up my toolchain for Ansible development, but @zebra’s exactly correct about that line of code in ansible_grid.c. Changing the number 384.0 to something a bit smaller should do it. Not too much smaller though, otherwise several of the last settings along the top row will act as tied notes.

5 Likes

i can make the change. will post a new build tonight or later in the week.

7 Likes
4 Likes

380 was the magic number. tested this with oscilloscope trigger detection. 381 still produced gaps. here is the new version:

edit: see updated build here: Kria: How to create "longer" sounds and faster gates

this includes everything from the latest 1.6.1 release plus @slowwild’s fix for config mode. this also includes an experimental fix for usb connect timing lag - that’s when connecting grid sometime introduces a lag. this might affect how grids/arcs are recognized, and i can’t test with all the different editions, so help with testing will be much appreciated.

version that includes earthsea posted here: Ansible Earthsea

17 Likes

FYI you can build firmware for any of the monome euro modules without any toolchain setup using the commands described here (just requires Docker.)

4 Likes

@scanner_darkly & @freqout : a huge shoutout to you and everyone else in this community who contributes so much of their time and their expertise to this endeavor, y’all are making something special, it’s a whole new world over here!

1 Like

Thanks for taking care of this. It is very much appreciated. :slight_smile:

What’s the significance of the magick number? Will it work regardless of the speed of the incoming clock?

good question - i don’t have the bandwidth to test but will be happy to provide another build if the number is still too high (it’s used in calculating step duration, and as @freqout said making it too low might cause tied notes even with lower duration values).

It’s just a scalar value that I adjusted until (i thought) i had it creating tied notes at the highest setting.

On the same line of code you’ll also see clock_deltas[trackNum] which is the amount of time (in ms) between clocks for that particular track so it does also factor in clock speed.

So it should work at any arbitrary clock speed. Tbh, it might be best to err on the safe side to ensure you can always get a tied note even if it eats into the 15th column, but let’s see how it tests out in the field.

1 Like

i’m not totally convinced this is right… hang on one sec…

… yeah ok. @freqout @scanner_darkly so again i don’t have euro stuff and this is just theorycrafting. so take w/ grain of salt. (*) but i don’t see how the arbitrary scaling factor can work consistently for all settings of clock mul and duration.

the scaled gate duration is the red surface. the clock duration is the blue plane. when the surface is above the plane, we got “note tie.” the scaling factor changes the steepness of the surface, but i don’t see how it can prevent them from crossing at some point.

(i’m assuming gate duration multiplier is ==1 btw.)

matlab:

n = 100;
c = linspace(50, 1000, n);  % clock duration un ticks
a = 380;                    % clock scaling factor
d = linspace(50, 1000, n);  % duration

g = zeros(n, n);             % scaled gate duration

for i=1:n
   for j=1:n
       g(i,j) = c(i) / a * d(j);
   end
end

surf(c, d, g, 'FaceColor','r', 'FaceAlpha',0.4, 'EdgeColor','r', 'EdgeAlpha', 0.7)
dplane = zeros(n, n);
for i=1:n
    dplane(i,:) = d;
end
hold on;
surf(c, d, dplane, 'FaceColor','b', 'FaceAlpha',0.4, 'EdgeColor','b', 'EdgeAlpha', 0.7)
hold off;

xlabel('clock duration')
ylabel('step duration')
zlabel('scaled gate duration')

i guess i would implement “note tie” feature differently, with brute force. when user sets gate duration to max, just don’t set the gate-off timer.


(*) i am also frankly kind of slow and hungover today, and could be easily be making some very stupid error or assumption. like about how stage durations even work.

1 Like

yeah, i think that the easiest solution is simply not adding a timer for kria_off if the setting for the note is at the maximum.

can’t tell though what’s the right condition to check (or how to calculate the delay properly) without getting deep into the code which is frankly what i’m trying to avoid - too many other projects on the go to get deep into another one… i’ll be happy to rebuild the firmware if @freqout could tell me what would be the right condition to check.

track->dur_mul == 16 && track->dur[pos[trackNum][mDur]] == 5?

this works, will post new version in a bit.

ehh, i’m dumb - kria doesn’t have arbitrary stage durations. (right?) so the scaler is probably fine? but it still will always send gate-off if there is a gap in the pattern.

and of course if the clock rate slows, you will get gate-offs from the firing of a timer that was set from a previous clock.

so yea - i think skipping the timer altogether is the ticket. assuming, of course, that this is a behavior everyone wants.

ok here is the new build that disables the off timer altogether if the duration settings are at the max. tested with internal clock (with one rate only) and external clock (at 30, 120 and 300 bpm), testing was done with oscilloscope trigger detection.

ansible.zip (79.7 KB)
ansible.hex (246.5 KB)

also posted the updated ansible earthsea version

1 Like

oh interesting so does that mean at max, a note will drone (gate high) until another note on the pattern plays?

20 characters of yes

1 Like

A post was merged into an existing topic: Ansible Earthsea

A post was merged into an existing topic: Ansible Earthsea

For what it’s worth, my interpretation of tie in step sequencer basically says “trigger the gate and keep it high for duration of this step and next”. Some examples(assuming each step is a 1/16th):

x - o - o = trigger on step 1. duration <= 1/16th
x(tie) - o - o = trigger on step 1 and hold through step 2 until step 3. duration = 1/8th

x(tie) - x - o = also trigger on step 1 and hold until step 3. duration = 1/8th. the trigger on step 2 is consumed and irrelevant.

x(tie) - x(tie) - 0 = trigger on step 1 hold until step 4. duration = 3/16th

Do these examples meet anyone else’s expectations?

1 Like