#143

Here’s a build:
ansible.hex (244.6 KB - cc8f5b2 - 2019/05/17) (buggy, see below)

Ansible PR
Docs PR

5 Likes
#144

wow! merged. thank you, this is fantastic.

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