it will also now be one of the grid modes on ansible.
initial changes to the ansible version:
four tracks
clock and reset input
per step probability (like normal ww) for each parameter
sync mode (tr and note linked for more traditional sequencing)
features removed from ansible version:
per step scale change parameter
per step transpose parameter
clock division (clock multiplication is still there)
to get clock in i chose to remove the pretty questionable clock multiplication routines-- they weren’t accurate. having both multiplication and division sounds good to me, so it’ll be added back in in a future revision. also we might want scale/transpose back-- perhaps with a new interface proposition.
there’s also a new higher-level pattern sequencer (like series mode on original WW) that i have mostly done but i’ll hold back until a near future update. ansible now comes with the usb A-A firmware update cable, as i anticipate it’ll be often-modified by various people-- so there will be options.
the question some people have is will any of these features be back-ported to the kria for ww. the answer is yes, but it in due time. the application on a whole is still breathing and changing a bit. my aim was to backport it once it settles.
if there’s an overwhelming demand for clock input, i could revise the ww version but the clock multiply would be likely inaccurate.
full tour and docs of kria on ansible forthcoming. in general it won’t feel too different, but there are some changes.
Clock input on the WW indeed would be overwhelming!
We, who already use Kria could stay on the white wale then and keep scale/transpose parameters. Besides the clock in I am very happy with all it is now…
I just did not fully understand the part with changed clock division / multiplication feature on the ansible above, though:
If I understand correctly, the division was kept and the multiplication was removed. I’ve seen in a few threads (on Muffs, mostly) that clock multiplication is inherently imperfect because it takes a few gates/triggers to determine the incoming clock rate so that it can be multiplied. I.e. Any changes to the base clock rate cause temporary desyncs for the multiplied clock.
Pretty much, yes. One of the challenges in doing a digital eurorack sequencer is that most people expect to send something like a 16th note clock. It makes it hard to work at a higher resolution internally because it needs to be multiplied. It’s less of a problem with syncing MIDI devices externally because a MIDI clock is 24 PPQ (or 6 beats per 16th note) so it’s a lot easier to sync it quickly without any noticeable glitching.
+1 to the requests for WW Kria clock in. I’m likely buying an Ansible and Arc anyway, but having the additional flexibility to choose where to run Kria would be very welcome.
I never noticed this before but while figuring out a way to clock everything from Kria via Ableton/Skinnerbox I found that my Kria does not follow its own clock and I wonder if anyone experiences the same. It drove me nuts trying to adjust the track delay/latency on ableton until I just noticed that there is simply no chance to get it right…
Here is clock out on one channel and trigger 1 without must/div on the other. Direct into the mixer and Logic (added some reverb and slight compression for a more pleasant listening experience):
For an e-learning side effect there are some nice twittering artifacts now, showcasing what soundcloud does to our music, they’re not on the original mp3.
I’ve really struggled clocking my Meadowphysics to an audio pulse from Ableton. I’m not sure if my problem is related to yours - could you expand on what you found?
Maybe I was overly complicated (I tend to be…) but what I found was simply that Kria is not running on the speed of its own clock. As you hear in the audio example with Krias clock on the left and the trigger of Krias Channel 1 on the right.
My goal was to clock Ableton from Kria over Skinnerbox which basically worked good just that Kria was running out of sync with itself as you can hear on the example.