Sequencer design for grid

I’ve got a grid and I’m thinking of building a 4-track sequencer with it, possibly ultimately as an alt firmware for Ansible.

The design is fairly simple:

  • Top 4 rows by default select the current pattern. So that’s 64 patterns. Long-press a pattern button to save your changes (might do auto-save instead). Hold one pattern and select another to duplicate.
  • The bottom 4 rows are trigs on each of the 4 tracks (16 stages)
  • When you hold down a trig, then the top 4 rows change their meaning to program the trig: pitch, octave, step length, probability
  • pitch is chromatic, using light and dark to indicate black and white keys.
  • step length is the number of clock pulses in the stage, allowing patterns of up to 256 (16x16) pulses in length, and polymeter between the tracks

I’m attracted to this design because it’s mostly non-modal. The only mode change is when you hold down a trig (or multiple trigs).

Just curious to get some feedback on this design :slight_smile:

cheers

9 Likes

Sounds great. Some similarities to http://www.markeats.com/sequencer/ but with a slightly different way of using the grid.

1 Like

If you have access to Max, I would encourage you to make a proof of concept before diving into Ansible code. Problem solving in Max is pretty straight forward compared to working with hardware in C (depending on your background), and in my experience is better suited to iteration.

1 Like

I have Max, but I do C++ software development as my main job, so I could probably code this up pretty quickly (on my laptop though, not as firmware).

2 Likes

I like this idea, it sounds like you could more easily see what’s going on with each sequence from a single view, as opposed to tabbing to different pages which can cause me to get a little lost.

I do think one of the more interesting features of Kria is being able to set the tempo of each sequence independently, and Im not sure how this would work with your interface (maybe you don’t want to implement this, which is fine too).

1 Like

You could effectively do a clock division by setting the step lengths. It’s a per-step parameter, so it would be slower to do than a single tempo per track.

ah I see. I overlooked your description of “step length” and assumed it would be more of a note length/gate parameter.

Yeah the more I think about it the more this interface sounds really nice. Per-step duration could allow you to get a little more granular anyway.

1 Like

Hey Taylor!

Seems cool!

Some questions:

Are you planning on any kind of visual feedback on the grid? For instance, displaying the current playhead position for each pattern.

Am I to assume that probability controls whether or not a trigger happens?

When a trig is held, do the current parameters of that trig get displayed above? You mentioned holding down multiple trigs, what is the behavior then?

1 Like

Hey Paul!

Yeah, I would indicate a playhead for each track using differing brightness levels. Perhaps a trig is half brightness and the playhead is full brightness.

Yes, probability controls whether the gate happens. I could also experiment with skipping the stage, though I worry that would be a bit uncontrollable.

Yes, the parameters are displayed. When multiple trigs are held, the behavior might be to indicate the range of values somehow. Pressing a parameter button would set the parameter for the multiple trigs. This is essentially an Elektron inspired UI (hence the trig terminology).

1 Like

One issue might be that with the dual meaning of the top four rows, it would be easy-ish to make a mistake and switch patterns when you meant to set a parameter (say you’re going quickly and didn’t hold the trig well enough). A solution might be to auto-save the changes to patterns so you can’t accidentally loose your work, but it’s also nice to be able to mess up a pattern live without worry.

It may end up being a non-issue. Hard to really say until you physically try using it to make music.

1 Like

not entirely sure of the current state of the project (cc @scanner_darkly) but it could be cool to utilize multipass in order to build alt-firmwares for the trilogy modules in addition to ansible. Note that I am asking this selfishly because I have a White Whale and not an Ansible and the sequencer sounds cool, and also I have no idea of the overhead or extra time it would take to utilize multipass.