#42

Thanks for the additional explanation. I’ve updated my post to reflect my current understanding, might be useful as a starting point for some docs.

If I understand it correctly you’re describing the possibility of being able to create arbitrary combinations of parameters to be synced to eachother. Is that correct?

If so that seems pretty powerful but probably also a bit difficult to comprehend/for people to wrap their head around. What do you think?

The mockup I posted assumed the current situation where there is a single per track sync “clock” (if that makes sense as a description) for which you can then enable the different parameters to sync to, no arbitrary combinations.
It feels like an improvement to me UX wise. I’ll create an updated image to correctly reflect the time/clock page, I was a bit lazy before so it was a bit of a combination of time/clock and the trigger page.

I used grid_KR_CUEDPattern.ai from https://github.com/monome/docs/tree/master/resources and imported/edited it in Inkscape.
(we should probably add a blank grid template SVG file there, I’ll give that a stab)

2 Likes
#43

I understand your UI suggestion better now! I do like the cleanliness off it but I also appreciate the consistency on how it currently is in relation to the note sync parameters. Curious what others think!

#44

I’m kind of asking that myself! Some examples might be:

  • you want to keep triggers, notes, repeats, and durations the same, but let alt notes and octaves have different loops and divisions, so the loop always plays the same phrasing, but does a lot of melodic variation as the pitch parameters phase with each other.
  • you want triggers and repeats to stay in sync so you can more easily visually program a rhythm, but other parameters can do what they want
  • you have div cueing on, and you want to experiment with toggling loop sync and div sync off and on for different parameters, so that you can sort of explore the space of possible overlapping phrases that are available in your sequence, but keep the rhythm tight. For this to work with loop syncing as well, you would also need to support loop cueing, which sort of begs probability cueing…
  • Speaking of probability, what would a probability sync matrix do? It seems to me that you likely want to be able to program “these parameter probabilities are linked, when the probability threshold is met, apply all linked parameters”. Or perhaps have the option to have “odd” probability linkage: flip the coin and one parameter calls heads while another calls tails.

These possibilities seem pretty interesting to me but I agree that it could be a substantial contributor to cognitive load. This is why I think it would make sense tucked away a bit: hold config, then press a mod key. Existing UI I think should remain as these seem like some of the most common settings, and there should be some shortcut for clearing sync matrices and returning to the default timing configurations.

Interestingly despite the complexity, the main appeal of these options for me is being able to selectively “tame down” complicated sequences – often when I have a couple parameters with different timings or phases, the sequences become so long that they’re hard to fit in my brain all at once, and I sometimes have wanted ways to bring pieces of the sequence I’ve programmed back in sync with each other so there are some more repetitive footholds. At the same time I want to be able to really exploit parameter and track phasing because I think this is one of the most unique and exciting things about Kria – it drifts away, it comes around again, the primes are singing, the rhythm is in a rhythm is in a in a rhythm is rhythm rhythm in a

2 Likes
#45

Updated image of what I was initially going for.

image
image.png2010×1126 142 KB

This shows the original time/clock page with my initial idea of enabling/disabling all or per track time division syncing for the triggers, notes, octave and duration.
In the picture triggers, notes and duration have per track time division sync enabled.

Whilst working on this I noticed I didn’t keep the extended parameters in mind, not really sure if/how to fit them in to be honest. It kind of breaks this idea/concept I think since they’d need to be fit in as well.

Btw @csboling you mentioned 7 parameters, just to be sure, these are:

  • trigger
  • note
  • octave
  • duration
  • ratcheting (extended)
  • alternate note (extended)
  • glide (extended)

That’s it, right?
Asking because I was wondering if probability should also be included in the sync, although it’s of course already a per parameter probability, so not sure if/how that would fit in and if it even makes sense.

1 Like
#46

Thanks, yeah this makes the idea clearer for me. I think this UI has some differences in possible settings from what’s currently implemented, like I’m not sure how you express the note div sync + div sync here, but that may be okay if it’s conceptually clearer. I think I still need to experiment a lot more to try and figure out what kinds of options I most want while playing – I too have been shying away from changing clock divisions since I found it hard to get the loop timing right.

Yes, the ones you listed are the 7 parameters, but the UI design should maybe also account for a future 8th parameter, since the duration page currently doesn’t have any associated extended parameter. Probability yeah is per parameter so it behaves kind of differently, I’ve also been thinking about some other probability settings that would be useful but I’m not sure how the UI would shake out.

#47

What do you mean with just “div sync” here?

That’s why I was so happy to see these changes :slight_smile: The combination of all or per track time division sync and time division queuing means I can finally use the time divisions again :tada: and be a lot more deliberate in my choices/action/influence on what’s happening.
Whilst I do sometimes like to be less in control and see where the phasing brings me, most of the time I do want the control, so this makes Kria a lot better for how I’d like to use it :slight_smile:
Anyway, long winded way to say thank you and to confirm that just playing with it and trying it out is a good idea to figure out what makes sense.

That’s probably a good idea :slight_smile:
I’ve been considering an option to trigger once every x loops similar in UI/UX to the probability page.
Let’s say a range of 1-7 (or maybe 1,2,3,4,5,6,8?), with 7 being the top row and 1 being the row before the bottom row.
When selecting this the step only triggers every x loops, where x is the selected number.
This would allow a combination of faster/frequent triggers and sparser triggers that are not random.

It might be that it’s expected behavior and the behavior described in the above quote, but I noticed the duration for triggers with deleted ratchet steps was shorter than for steps that didn’t have any deleted ratchet steps.
Is this to be expected? Should I have deleted the rests? I couldn’t figure out how to delete them from the UI/naturally. Found it a bit odd they stayed around/dimly lit and I wasn’t able to get back to the original state with them being off.
Maybe just pressing on the bottom row should delete them?

#48
  • Pressing the bottom row will reduce the number of total subdivisions
  • Long-pressing the bottom row will clear everything, bringing you back the default one-trigger behavior for that step
  • Pressing the top row will increase subdivisions
  • Long-pressing the top row will eliminate all rests at the end of a step

These are very dimly lit because I didn’t want them to be too obtrusive but they probably ought to jump out a bit more.

I’ll look into the duration issue, not sure what I expect to be happening here – the duration calculation I think is unchanged from previous ratcheting behavior.

I agree that this is a funky part of the UI, and I have gone back and forth a little bit trying to figure out what the most sensible behavior is – maybe it should just never give you rests at the end of a step unless you specifically opt in to this by increasing subdivisions. But I also wanted enabling/disabling notes to be very playable, to allow experimenting in real time with different rhythmic patterns, and it seemed like reducing subdivisions automatically could cause unwanted changes in the phrasing when you’re trying to toggle triggers off and on. Maybe this needs its own configuration toggle somewhere.

#49

Hello,
I have just had a run with the latest version and everything seems to work.
Unfortunately the led problem now is fixed only for the note section but not for the octave and duration where there is still the problem that my old grid do not show any light.

All other features seems to work but I have not done an extensive review as I am quite knocked and need some sleep.
Hope this helps for the moment.

1 Like
#50

Forgot to respond to this – in the current version, this is the NONE, TRACK or LOOP settings for which division settings are shared, whereas “note div sync” is the behavior where note + trig are tied together but other parameters may be independent. The language feels kind of overloaded I think but haven’t thought of another term yet. This is one thing I like about the sync matrix idea conceptually – all the different types of sync are the same, you’re just “patching” sync connections together with the matrix.

This is after changing the "grid_varibrightness" setting in the JSON file? I’m unfortunately without a 4-step grid to test with so this is all a bit of guesswork, but I did try to make sure that with "grid_varibrightness": 4 it would use the same brightness level as was used originally in the 1.6.1 firmware. I think there may be a couple other spots that could use brightness tweaks as well. @kbit could you comment on if you are also affected by this or any other UI elements that are hard to see?

#51

Noticed something about looping seemed to have changed as well with the new versions.

Originally when I set a loop, for example 3 notes, I’ll be able to hold the loop button and move this 3 note loop around by just pressing once on any button for that row and that button would be the start of the 3 note loop. Now when I press a button, it just becomes a 1 note loop.

1 Like
#52

(Please do move this if there’s a better place for general Ansible feature requests.)

I’ve been seeing quite a few videos where the scale interface is used as a performance tool, which is a really fantastic way to do things. However, I wonder if it could be made more playable. At the moment each row offsets the pitch and all higher pitches which means you can’t just shift one note in the scale - for example by just flattening the 2nd or whatever without simultaneously shifting all the other notes.

So, how about the option for a second, less bright, button on the scale row. This would indicate a “temporary” offset for only that note in the scale. The subsequent higher notes in the scale would still follow on from the offset of the brighter lit up button.

The interface would be that a single press would work as before (and remove the temporary offset) whereas holding down the bright button and making a second press would create the temporary offset.

Seems like this would be very playable and also have the advantage of not looking any different for current users. How hard would this be to implement? Are there any obvious issues with this? (I’m also happy for any pointers for where to look in the code for this, although I’ve never done any firmware programming myself!)

1 Like
#53

Loving the new firmware @csboling !!!

2 Likes
#54

Oops! This got broken on the trigger & note pages when I was implementing “note sync on + loop sync off”. Other parameters I think were fine. This is fixed in the latest posted build (PR).

Very neat idea! Went ahead and added this in the latest build. This is a “live” setting – it’s not saved at all and it’s not part of scale or pattern state, so when you switch scales or patterns any active scale adjustments are still active. This might be odd – possibly changing scales or patterns should also clear the adjustment, give it a whirl and let me know what you think. If you’re interested in the code changes for this you can review them here – pretty straightforward to hack around on stuff once you’ve got your compiler toolchain set up. For that I recommend this Docker image.

4 Likes
#55

Amazing! Thank you so much for this. I’ve given it a go and it works perfectly. I think it makes a lot of sense when building up a scale. Once nice trick is to set all the notes to unison, and then work up from the bottom, starting with temporary notes and then locking them in and allowing the notes above to jump as a result. Another pleasing effect is to have an arpeggio running and then use the temporary scale change to make the notes’ pitches to switch order.

I think it makes perfect sense to have this as a live setting and not saved with the scale or pattern state. I kind of think that changing the scale should reset the adjustments, but I can also see a use for keeping them in place when patterns change…

Thanks again for the incredible turnaround from vague idea to actually being able to use it. Awesome!

5 Likes
#56

As the Varigate was my go to sequencer for awhile, I can’t help but wonder if some of its tricks could be implemented while we’re in the process of development of Kria. There is a possibility on the Varigate 8+ to set a randomization range, for example I can set the range from 0-5 for Ratcheting per step/trigger, and when that step is triggered, I will get a random number of ratchets from 0-5. This random range can be set for all the parameters, from trigger, to trigger width, etc.

And stray lit LEDs, this has been there since I received my grid and ansible, where in certain screens, with certain notes on, there are some stray LEDs lit. I don’t really understand it or if this is a bug in the original firmware, anyone also experiencing this?

1 Like
#57

This was such a wonderful suggestion, it’s so much fun to play scale degrees with this new behavior! I agree with keeping this as a live setting and I’d support clearing adjustments once scales have been changed. I think that would keep the cognitive load low and encourage improv scale changes.

I haven’t tested the 4-step-brightness mode yet because I found a bug in loading preset files, which @csboling is working on :+1:

#58

Just posted a new build (9cee10a) with:

  • fix for Kria state not being saved/loaded to disk! oops! I think this may have affected builds from the past couple days.
  • changing a scale will reset scale adjustments for all steps, but changing a pattern will not
  • fixes for bugs identified by @kbit in PM – note division page was unresponsive, ratchet division page was changing the wrong thing when note div sync + div sync were on

Thanks again to everybody for all the beta testing!

5 Likes
#60

Hello,
to be honest, I completely forgot I had to modify the hex file…
I will do one of these evenings…
Unfortunately I am in the middle of a big life change event so I can only do just a few bits of beta testing but I am loving all the ideas everyone is proposing.

Thanks for doing all this work.

#61

I’ve been thinking about this off and on but don’t have a rock solid UI picture of it yet. I’m unsure of both how the input should work and how the randomization range should be displayed once it’s programmed. With notes, I think it would be great if you could program multiple note choices for a single note step, Parc-style, and as the loop visits that step it would select one. But as a further wrinkle I think it would be awesome if you could select a direction mode for how it should cycle through notes, i.e. select the next note via forward/reverse/triangle/drunk/random strategies. I find myself drawn to a lot of sequences where I want to change the selected note each time the loop comes around, but then I want to go play with other parameters, so I wind up copy-pasting the loop over to another couple pattern slots and make tiny alterations to each one. But adding this kind of complexity maybe has a lot of consequences for cognitive load, storage space, UI design, … I’m especially interested in what people think the UI for parameter range/randomization features ought to act like.

I have noticed this! I believe I also encountered this when first learning Kria before I had made any firmware changes, and originally thought it was some feature I had activated by mistake. I’m not sure how it happens and I haven’t been able to reproduce it consistently enough to properly debug these spooooky ghost keys. Though I do sometimes wish I could peek at a different parameter page from the one I’m working on, especially when trying to place a parameter change on just the right step.

1 Like
#62

these recent updates are phenomenal, thank you @csboling!

there has been mention of this previously, but i think all the extra kria-counterpoint is bringing the issue to greater attention: ansible CV output channel-to-channel accuracy isn’t perfect.

with the new JSON import/export plumbing (stunned at this accomplishment!) i’m wondering if the presence of a textfile with scale tunings would be a good solution?

  • bugfix: ch-to-ch accuracy
  • bonus feature: weird microtuned scales! (?)

i’m not sure what sort of tuning granularity we’re looking for? i’d almost suggest just correction for octaves, and then have a macro generate the 12 tones between? or it’d be not too much trouble (and perhaps more interesting generally) to have the full map exposed?

11 Likes