#23

Thanks for explaining, will look into it tomorrow, loving already the latest updates!!!

#24

Something I have noticed about the Teletype clocking Kria.

When I turn TT clocking on, I noticed that if I do not set the Timing (button 1) to the fastest possible timing (both row 2 and 3 leftmost button lit), the timing is off, the way it gets clocked is not synced with the incoming TT clock. Donā€™t know if this is the normal behavior, but would it be possible when TT clocking is enabled, we can get clock divisions in the Time page like when Ansible is receiving an external clock?

1 Like
#25

The clock config page accessed via key 1 controls the primary clock timing for the module ā€“ for the most part app timing is derived from this setting, which determines how frequently clock handler functions get called. I think this might make it difficult to work around timing issues caused by running at lower internal clock rates, because Kria is only able to act on pending clock events from KR.CLK as often as this primary clock occurs. I also notice some odd behavior using KR.CLK at fast metro rates and I would guess that flooding the I2C bus might contribute to this.

1 Like
#26

This is awesome! Thanks a lot for the effort! :heart:
Iā€™ll give it a try this weekend. If I run into issues would you prefer a comment here or an issue on GitHub?

And I wanted to check if ā€œphase-synced clock division changesā€ means that the timing of parameters and modifiers for a track stay in sync this way? Or in other words that thereā€™s a single time division per track instead of per parameter/modifier per track?

Itā€™s the main thing that Iā€™m missing from Kria: a way to keep all parameters and modifiers for a track in sync when changing a trackā€™s time division, it most of the time messes up what Iā€™m working on so Iā€™ve effectively stopped using the time division option.

I think this has been mentioned in the past as well, though it could be under different descriptions/names. This was the most recent comment I could find about it Kria strategies.

1 Like
#27

It just waits to latch the time division change until that parameter reaches the end of its loop, allowing you to sort of cue a time div change the way you can cue a pattern change. So if loop sync is set to ā€œtrackā€, this ought to mean all ā€œcuedā€ time division changes for different parameters take effect at the same time, when the loop finishes. If loop sync is ā€œnoneā€, you might still have time divisions changing at different times if your parameters have different loop lengths or are out of phase. As such I think this does not do quite what you want but I think it should help make it a little more manageable and have some interesting possibilities to explore.

It also seems useful to share time divisions between all parameters in a track, so you would have ā€œallā€, ā€œtrackā€ or ā€œnoneā€ settings for changing divisions at the same time, similar to loop sync. Maybe put a similar UI on the clock config page to the loop sync UI. This also seems like it would be a more reasonable setting to call ā€œdivision syncā€, which is what Iā€™ve called the already implemented ā€œdivision cueingā€ feature in the docs. Iā€™ll see if I can prototype ā€œdivision syncā€ behavior some time this weekend.

3 Likes
#28

OK, thanks for the additional explanation, that clears it up for me :slight_smile:
It sounds like this feature could also be useful to be less reliant on exerting exact timing by the user for applying (in this case) a time division change at the start of the next loop, which is nice :slight_smile:
[edit] I now see this was the reason posted in Feature request, kria: phase sync on time div changes for requesting to add this functionality :stuck_out_tongue:

That would be really, really nice! If thereā€™s anything I can do to help (test it, look at how to do the UI, docs, etc) just let me know!
And ā€œdivision syncā€ sounds like a pretty good/descriptive name for it.
Naming things is hard :wink:

2 Likes
#29

First post is updated with a new build, PR. It seemed to make sense to have similar configuration for this as there is for loop/note sync ā€“ either all time div changes should happen together, all within a track should happen together, note + trig should happen together within each track, or all tracks and parameters have independent divisions. Therefore I added glyphs to the clock config page (key 1) to configure this the same way you configure loop endpoint behavior. The option to cue division changes seemed to fit in better here, so this is an additional glyph (4 keys in a square, bottom center) on the clock config page, rather than a single toggle key on the app config page.

2 Likes
#30

:open_mouth::open_mouth::open_mouth:

#31

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.

1 Like
#32

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. . .

#33

Yes, thatā€™s exactly right. Again Iā€™m not sure if this would be more confusing than itā€™s worth but Iā€™d be interested in giving it a shot!

#34

New build with this posted. This is totally fantastic. Long live Kria, long live counterpoint!

4 Likes
#35

This is really great, thanks a lot!

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?

#36

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) behavior
OFF NONE default behavior where all clock divisions are independent
ON NONE all tracks and parameters have independent divisions, but within a track, trigger & note divisions are always the same
OFF TRACK every parameter within a track is in sync, but tracks can have different divisions
ON TRACK within each track, trigger & note share one division, and the other parameters share a different division
OFF ALL every parameter on all tracks uses the same clock division
ON ALL all tracks share divisions, but trigger & note share a different division than the division shared by all other parameters
3 Likes
#38

Thanks for the clarification, I was quite lost when trying out the different modes today lol

1 Like
#39

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 :slight_smile:
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:

Time/clock page:

  • 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

Config page:

  • 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:

image
image.png1092Ɨ594 33.3 KB

(looking at this it might make sense to switch the Track an All rows, I kept them in the same order as the current glyphs).

P.S. Just played around with it and

  1. This is the best iteration of Kria for me so far, thanks a million!
  2. I noticed no issues so far. Didnā€™t use an external clock so didnā€™t run into the external clock related issue you found.
1 Like
#40

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 :slight_smile:

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.

#41

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.

1 Like
#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!