#145

Right after this was merged I immediately found a bug where when loop start/end were swapped, reverse and triangle mode would wander off and start corrupting nearby parts of state. Fun, but not ideal - it might be amusing to code up some Teletype ops that would directly let you trash Kria’s state memory and see what happens. New build: ansible.hex (244.8 KB - a1798e5) current build, new PR. I also had apparently not understood “drunk” and “random” as separate things when first reading the post, so this PR also adds random mode.

7 Likes
#146

This is wonderful, thank you so much! I patched up something melodic and have one track set for drunk movement with sparse triggers of varying probabilities, which adds a really nice cohesive yet unpredictable element to the whole thing. Definitely has different quality than I was able to achieve soley with phasing previously.

Can you tell us more about how the triangle mode is implemented? When I have a track with parameters of different lengths, it seems like all parameters change directions once one of them hits an end of a loop… But I was also able to get one of my parameters to “scan” through a track somehow (i.e. a sequence of position: 1,2,3,4,3,2,3,4,5,4,3,etc). I’ll have to experiment more to see if I can replicate that behavior again it was pretty cool!

EDIT: ahh I figured it out, the track that “scans” is set to a slower odd division while the other track that flips the direction isn’t divided. The inherent phasing nature is manifesting in new ways :smiley:

1 Like
#147

Yeah I bet you’re right about the triangle mode, the state for “are we moving left-to-right or right-to-left” is at the track level rather than accounting for different loop positions etc for different parameters. This would cause all parameters to suddenly change direction when one hits the end. I’ll look at this later today to keep separate state for each parameter. Edit: fixed @kbit ansible.hex (244.8 KB - 79d1c8a - PR) current build.

1 Like
#148

Wow, this is great! Thank you. One question I’ve been pondering is how to save the state of the TT clocking mode in a preset. I think it currently defaults to not synced to TT when loading a preset. Will this store the TT sync clocking mode when loading a preset where TT clocking is enabled?

Monome ecosystem firmware development backlog
#149

This alteration opens up so much! Here is one track with triangle motion, different length and divisions on trigger, note, and octave pages. There’s going to be a lot to explore with this.

7 Likes
#150

Not sure about this, I haven’t found it mentioned in the discussion but maybe it was thought that it would be confusing to save this setting as part of a preset since it could mean that tracks wouldn’t be running when the preset is loaded. @freqout is this intended behavior or should the kria_tt_clocked settings be added to the kria_track struct?

#151

Yea I think it ought to be saved w/ the preset… not sure why I didn’t do it that way.

#152

I am not sure about this - it would be a preset then, with an essential feature that is not modifiable from Ansible/Kria/Grid itself, wouln’t it?

I think this belongs into the teletype I scene as a preset.

#153

No you’d be able to still change it from Teletype, but I think the idea is that a Preset represents a piece/song/track with a specific performance configuration. If you wanted to have certain tracks configured to be clocked by TT for a piece/song/track, it would make sense to me to have that configuration automatically set up when you load a preset.

2 Likes
#154

No, that wouldn’t be the case. Changing the ability for a track to be clocked from Teletype is available in Kria itself, in the top left corner of the scale page.

If you have a command to clock one track in a Teletype scene and it’s not selected within Kria itself, the track still follows Kria’s internal clock. Having to include this in the I script would necessitate a new Teletype operator to specify which tracks should be clocked from Teletype, an effort that would also eat up valuable I script character limits.

The only downside to saving it within a Kria preset I could see is if a track is saved as being clocked from Teletype when it wasn’t meant to be / that scene isn’t running. This could be confusing to a user but would be easily remedied, and I don’t think it’s a mistake that could be made very easily.

Just my two cents. I would prefer it to be saved within a preset of Kria. .

#155

I did not know that. Just thought it would be formal not good to save something to preset in a device that needs another device to be changed. Of course I see how it would be useful too. When it’s changeable from Kria itself I would not mind saving it in a preset - it’s like a Maths then that saves its cycle state during power cycles…
:smile::+1:

1 Like
#156

My work around has been to switch to TT clocking in Kria manually, then use KR.POS to sync position, then enable the metronome. It works, but would love the ease of just saving the preset!

#157

Build that saves TT clock enables: ansible.hex (247.1 KB - 3c70c51 - PR)

6 Likes
#158

You’ve made my compositional life much easier!

#159

Took sort of a stab at this and made it possible to select on the ratchet page which triggers you want to fire. So the ratchet settings for each note are sort of 4 toggle buttons rather than a fader for number of repeats ansible.hex (245.2 KB - db687c6). So far one thing that’s nice about this is that it doesn’t wind up taking any extra grid real estate or state memory - I can pack the toggles and the repeat counts into a single byte per step. Currently the number of divisions to use for a single step is determined by the highest toggle you have set, so you can’t really have rests at the end of a step, but on the other hand you can subdivide each note differently as opposed to having a global subdivision setting for the track. Some nice syncopation can be achieved.

10 Likes
#160

Wow, coming back to this thread has blown my mind, cant wait to try out the new directions.
The alt ratchet mode sounds super interesting too!
One feature I’ve been really wanting to see is having the octave page set in the middle so you can go up or down in octaves instead of just up. To me this feels more useful then tuning all sound sources to your lowest desired octave. It would also be great to have the octave rage extended to 3 up and 3 down. Anyone think they would find this useful and possibly implement it?

#161

Part of the problem is that Ansible is (on a hardware level) set up to output CV from 0 to 10V, so doing this would involve the strong, kinda weird choice to make the default CV output 3V.

1 Like
#162

ah right, well then is it possible to have ansible save its state so i could make the octave page always start up at 3v?

#163

This is a neat idea, so since the hardware has unipolar CV outputs maybe you would be able to set the “base” output voltage to +2 octaves (volts) and then work with +/- 2 octaves from that center point rather than +3 octaves above the current base voltage.
I was also thinking about how to have rests at the end of a note step for the selectable ratchet feature, as well as some other posts earlier in the thread about having more probability options, and I had a possible UI idea for these kind of “range” settings.

So to select a loop for a Kria parameter you have a three-key gesture: loop mod key, loop start point, loop end point, and this selects a loop range horizontally. Similarly you could have a three-key gesture to select a range vertically, and the “vrange” (naming things is hard) could have a different meaning depending on the parameter page. So for instance

  • ratchet page: selecting a vrange selects number of subdivisions for the note, whereas individual keys are toggles for the individual gates within the ratcheted note. The start of this vrange would always be the first gate for the note (third row from the bottom).
  • note page: maybe range of notes within which to randomize? centered on the selected note
  • octave page: selectable octave range. This vrange would affect the whole track instead of being a range-per-note. It basically would just apply an N-volt offset to all outputs equivalent to the octave corresponding to the range midpoint (maybe need some way to round if you select a vrange with even length), and let you choose octaves relative to that offset rather than relative to 0V. I think this could accomplish the octave master shift per track feature, while also allowing you to have notes pitched a couple octaves lower than the rest of the sequence.

Currently doing a vertical gesture like this sets a loop to a length of 1, but you can also achieve the same thing with: hold loop mod, press loop start, release loop mod. However, you also need a way to set a vrange length of 1, which seems like it needs a similar gesture. So maybe the top row (except for on the trigger and duration pages, but I’m not sure yet what if any vranges make sense for those) would be reserved for this when the loop mod key is held – hold loop mod, hold vrange start, press top key to set a vrange length of 1.

This would be a pretty substantial UI addition that I am presenting without having really thought through its consequences, its feasibility to implement, its cognitive load, or other important considerations I have not thought through it enough to think of. I just had been puzzling for a few days over UI options for a couple of features and with the “octaves below the root” suggestion it felt like something clicked.

6 Likes
Ansible Development and Beta Firmware Discussion
#164

@csboling - just coming back to this thread and saw what you have done :slight_smile: thankyou so much for looking into some of these feature requests. I made some of these requests along time ago, and so happy they are being looked at! The per track tapehead direction changes, (and previous independent clocking/track), was so I could do more phasing and fugue machine style sequencing. The global octave shifting per sequence / track was also to help with that style and particularly for live performance instead of using an octave switch module.

2 Likes