Something I found with the new division sync behavior: when using the the note + trig glyph in conjunction with the one track / all four track sync conditions, the note + trig divisions will follow the master division changes of all other parameters in their own track and not stay separate.
I think it would be more flexible to change the behavior so that trig + note have their own separate division setting in relation to all other parameters under those conditions, but this could be potentially confusing if you think all divisions are going to change together. This behavior could also be kept the way it is, but if so I think it would make sense to automatically deselect the note + trig glyph to accurately represent what’s going on.
So I’m clear – when note division sync is on (left side hollow box glyph) and division sync is “track” (right side top key), all tracks besides trigger + note should have one shared clock division, and trigger + note should share an independent clock division. Whereas the current behavior is instead that there is a single shared clock division, which is equivalent to just having division sync set to “track”. I think this makes a lot of sense and seems like a good behavior to have when both settings are on, and if I’m understanding right treating this as a special case doesn’t lose any behavior you can’t access otherwise. Please stand by. . .
One initital bit of feedback: The unselected config glyphs have a lower brightness than the unselected buttons on the bottom row in the normal view. Not sure if this is deliberate or not, but for me it’s a bit too low, I had a bit of hard time seeing them.
It’s easy to see when comparing the brightness of unselected tracks vs the unselected 4 by 4 square in the bottom left on the clock config page.
Does this mean it should now be possible to configure time division sync separately for triggers, notes and the remaining parameters? And it’s also still possible to keep all of them in sync?
Which setting or combination of settings does this?
I just found a bug where you can’t toggle the clock config glyphs when an external clock is patched. Must have something accidentally inside a conditional somewhere. Quick fix, will have a build + PR shortly (ed: build is posted).
I went with the same brightness settings that note sync and loop sync use on the config page, the drawing code is basically identical. This is the same brightness setting (3) as unselected triggers within the selected loop on the trigger page. This is on a 16 brightness step grid? I do have trouble seeing them under very bright lighting.
It should work like this, but I am pretty sure I have not tested all combinations thoroughly:
note div sync (left glyph)
div sync (right glyph)
default behavior where all clock divisions are independent
all tracks and parameters have independent divisions, but within a track, trigger & note divisions are always the same
every parameter within a track is in sync, but tracks can have different divisions
within each track, trigger & note share one division, and the other parameters share a different division
every parameter on all tracks uses the same clock division
all tracks share divisions, but trigger & note share a different division than the division shared by all other parameters
Sorry, forgot to mention it, but I’m indeed using a 16 brightness level grid (2013).
I just noticed it was barely visible whilst I didn’t have any issues seeing the dimly lit buttons on the bottom row. If that’s already an existing thing then it’s at least not introduced by these changes
Might still be a good idea to change it at a later point in time?
Thanks for the clarification on the combinations. Just to be sure:
4x4 square on the left: Trigger and note time division sync
2x2 square in the middle: Queue time division change on next loop
1/0/4 glyph on the right: Track/All time division sync
4x4 square on the left: Note sync (unchanged)
1/0/4 glyph: Loop sync (unchanged)
Is this correct?
I was wondering, would it be easier/better UX to simply enable/disable Track/All time division sync for the respective parameter with the buttons above that parameter? It would mean separate time division sync options for all parameters so I slight change from what it is now (although note and trigger can still be combined, both would just have to light up when enabling them) but it might be easier to use/remember?
Something like this:
The 4x4 hollow square on the left on the config page is unchanged from 1.6.1: it toggles note sync (triggers are placed when you place a note, and loop positions are synchronized). The change is that this used to be linked to loop sync, so you had to have loop sync engaged in order to use it – now you can have note sync on (triggers and notes share a loop and are toggled together) but loop sync off (all parameters besides trigger and note can have independent loop endpoints, but trigger and note share a loop). This is orthogonal to div sync, because note sync as of 1.6.1 does not link clock div changes, only loop points.
Division sync and note sync are settings for groups of parameters rather than individual parameters, so I think you would need a 7x7 matrix to represent all possibilities. But this would be super flexible! Consider the following hypothetical UI:
Config page, i.e. holding KEY 2: existing UI, to provide for normal note sync / loop sync configuration, but with three highlighted keys in the same position as the Kria mod keys: loop, time, and probability. Press one of these keys to go to the Sync Matrix page.
Sync Matrix page: The left half of the grid is the sync matrix for the modifier you selected. The mod keys are still highlighted, with the currently selected modifier brighter to show it’s selected. You can press one of the others to go to the sync matrix for that modifier instead. Above this on the right half of the grid is an additional 4x4 matrix controlling linkage between tracks. Press KEY 2 again to exit the Sync Matrix page and go back to the normal Kria sequencing UI.
The sync matrix is a 7x7 matrix of toggles in the bottom left corner, corresponding to the 7 Kria parameters. This allows you to toggle on and off which parameters should be linked, whereas the 4x4 matrix on the right lets you link linked parameters between different tracks.
These matrices have a couple properties that mean a full 7x7 or 4x4 square is not a very efficient use of grid space – the diagonal will always be on, for example, because a parameter or track always shares linkage with itself, and the matrix will always be symmetrical. So I think this means you only need the lower triangular part without diagonal to capture all the state, but this may not be as intuitive as using a matrix display. I think this approach generalizes all existing sync modes, (as well as adding the possibility for probability syncing between parameters?), with one exception – note sync causes placing notes to place corresponding triggers as well as loop endpoints. You can’t capture this with just the sync matrix for Loop, and I don’t think it really makes sense for other pairs of parameters. So maybe the note sync glyph would mean “I also want placing notes to place triggers” and it would be possible to toggle this separately from using the sync matrix to link these parameters.
I’m not sure I’m explaining this well and it might wind up being suuuper confusing, but I think it might not be too hard to implement
P.S. what did you use to make this UI mockup? I’ve seen a couple different ones now but my searches are not immediately forthcoming with what software people are using.
I haven’t fully explored all the division sync possibilities yet, but from a theoretical point of view the matrix concept seems complicated and potentially difficult to use (i.e. To read exactly what parameters are selected in a 7x7 grid).
Are there general use cases where selecting a only a few options on the sync matrix would be worth the complicated UI, aside from the note/trigger linkage that already exists? I’m asking this in earnest while being weary of feature creep.
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 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!
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
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:
alternate note (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.
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.
That’s why I was so happy to see these changes The combination of all or per track time division sync and time division queuing means I can finally use the time divisions again 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
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
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?
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.
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.
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?
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.