#9

I do not have any lights going only on the “sliders”, I have the global octave control and the light showing the seq progress, same in the duration page.

On ratcheting All works fine except that I think it would be good if the seq light do not keep following the deleted steps.

https://llllllll.co/uploads/default/original/3X/d/6/d65d92dee1bf545e73d6035fc569aff38209e8fb.mov https://llllllll.co/uploads/default/original/3X/f/8/f8921d085bb36b1ac3be4e3e0747e17d868663b5.mov

1 Like
#10

Also forgot to add that I have not loaded any presets into ansible.

#11

What edition is your Grid? Does it have 16 brightness steps per LED or 4? I tried to adjust the brightness levels for a couple pages to match the brightness on the Trigger and Note pages, but maybe this makes the octave and duration positions invisible on older grids? I can revert those brightness changes if this causes problems on older grids.

The thing is that the playhead is visiting those steps, because they represent rests. So you can program something like note-rest-note-rest for a single ratchet step with 4 subdivisions, and the playhead is brighter to show you that it’s visiting the rests as well. If the playhead wasn’t lit for these I think it might make it harder to read the exact timing of some syncopations. If you don’t want rests at the end of a step, you can use the top row and the second from the bottom row to adjust the number of subdivisions up and down, or you can hold the top row to eliminate all rests that are at the end of a note, leaving the last active gate as the end of the step.

#12

As you spotted it is a 2011 grid with 4 steps variable brightness.
I am really fond of this version as I personally find the best looking one…personal opinion.

The standard ansible firmware works perfectly so it would be great if you can make it work with older grid as well…maybe you can also add an option to decide which brightness model the user would like to use?
Just an idea.

In any case I have seen that there is a post about upgrade the variable brightness on old monome I need to check it out

1 Like
#13

Awesome. I assume updating to this firmware will wipe old saved presets?

#14

Will do! I just noticed that the brightness levels on a couple pages were different with a 16-step grid, and wanted to make them visually consistent, but I bet making them work for 4-step grids is probably why they were brighter. I like the idea of having this be a setting. At this point the easiest way to provide customizable settings is probably to have them be loaded from the JSON file. So you could do something like: save settings, open the file from the USB disk, change a number at the beginning from “16” to “4”, put the disk back in and load it up. Could also potentially add it to the grid UI somewhere, though you need to be real sure that looks okay on all grids!

It will, but I wrote a Python program that should be able to convert a firmware backup to a JSON file that the new firmware can load, letting you carry over currently saved presets to new firmwares. You can either use this tool yourself (the extract tool here) or you can PM me your ansible.hex and I’ll convert it for you and send back an ansible-preset.json that can be loaded after you reflash Ansible with the new beta. This process is described in more detail in this post.

1 Like
#15

I’m a 4 step variable brightness user as well! Having the option stored on the JSON file seems good, but would be a pain if the wrong version was loaded and I couldn’t see all the parameters… Could this be an explicit option to choose when creating a preset with your python script? Or would that be getting too complicated?

1 Like
#16

@bassik @kbit I updated the Ansible build to support configuring the number of brightness steps Ansible should treat your grid as having. If you save a preset to disk, then open up ansible-preset.json off the USB disk in a text editor, you should see at the beginning of the file

{"meta": {"firmware": "ansible", "version": "1.6.1-45bbe5c", "grid_varibrightness": 16, "i2c_addr": ...

Change grid_varibrightness to 4, then load the file back up on Ansible. The octave and duration pages should look as expected, and hopefully it’s a little easier to tell what’s going on on the ratchet page because the rests will stay lit at brightness level 1 until you clear those subdivisions.

I tested this on my 16-step 128 by discarding the bottom 2 bits of brightness info before it’s sent to the grid, hopefully this looks as expected on 4-step grids. I haven’t added an argument to the Python script yet but that’s probably a good idea, otherwise you can just edit the file the script generates before putting it on the disk.

1 Like
#17

Wonderful, thank you! Have been light on time to beta test this week but will get to it asap; have been thinking of “boring” ways to test all the parameters when loading a new preset.

#18

I’m trying to find out how to do this, hints?

#19

Thank you very much.
Will try to find time this weekend to do more testing.

Really appreciate the effort.
:slight_smile:

#20

From the default settings, you should just need to go to the config page and turn loop sync off (press the lit row of four keys on the right side). Previously this would automatically turn note sync off, and turning note sync on would turn loop sync on, but now they’re decoupled.

1 Like
#21

@csboling: Note sync is the new feature that moves the note parameter when there is a trigger and/or ratchet?

#22

That new feature I’m referring to as “trigger clocking”, since it causes other parameters to only advance when a trigger fires. Note sync an existing Kria setting that causes enabling/disabling a note to enable/disable a trigger for that step. It’s on by default.

Config
Kria has two parameters, represented on the left and right quadrants of the grid when Key 2 is held down.

Note Sync can be toggled on or off on the left side by touching any key– the square icon will be lit bright when Note Sync is on.

Previously this only made sense if you had a loop sync mode engaged as well. In this update you can disable loop sync, so all parameters besides trigger and note are independent, but trigger and note are tied together and will always have the same loop selection.

2 Likes
#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