MetaSequencer node

[treefrogman]

I'd love to be able to metasequence: automate switching between the eight sequencer patterns.

I propose a new node called MetaSeq or SeqSeq, very similar to MonoSeq, but with a fixed eight rows. It outputs a number between one and eight. It has a trigger input instead of a clock, which increments the pattern by one frame.
To complete the system, the two existing sequencers, as well as this new one, get an additional input and output:
The input is a pattern chooser, perhaps called patt, which takes a number between one and eight.
The output is a signal called bar, which triggers on the last note of each pattern, and is meant generally to be hooked up to the trigger input of a MetaSeq.

[maximecb]

Hello Mr Frogman. I think something like this could work.

I've thought about sequencing patterns before as well. The way I was thinking of doing it is that each sequencer could get an additional row where you could drag and drop the patterns into a metasequence. So essentially, each sequencer would have its own metasequence where you could drag and drop the squares numbered 1-8. The upside is that it's a bit visually cleaner IMO. The downside is that you can't programmatically control it.

In general I do want to take time to consider the options carefully. I like minimalism, and the issue with a change like that is that if we add extra inputs and outputs, people will start relying on them. Minimally, if we added a "pat" input to the sequencers which expects an integer value, that seems doable 🤔

[treefrogman]

I just fixed that too, but being inexperienced with GitHub I don't want to faux pas all over the place by opening up a bunch of pull requests when I'm not clear yet on the etiquette. Instead I'll just hand you the one-liner fix:
Find this line let node = treeCopy(nodeData); in model.js and add this line after it normalizeNode(node);

[maximecb]

Good catch. I just pushed a commit to both normalize and validate nodes when pasting.

[maximecb]

With respect to the pattern input. I don't really want to initialize all patterns immediately. Might sound silly but that increases the size of project files. I'm also working with the assumption that we might allow more than 8 patterns in the future.

I don't want to discourage you, but I'm very conservative when it comes to merging significant changes. I want to evolve this software slowly and carefully. One of the issues that we face is that because projects are shared, it's kind of like, once you add a feature, you can't really take it back.

[treefrogman]

I was wondering why they weren't initialized all from the beginning. 🤔 What do you think if instead of initializing empty patterns during playback, instead the sequencer update method gets a fallback for handling uninitialized patterns? Something like this.clockCnt = music.CLOCK_PPS * 16; and then skip the rest except the clock sign storage at the end. Maybe that moves to the beginning after storing the if statement's expression in a temp variable at the top...

As for the 8 patterns, I knew that modulo would bite back. What behavior should be presented in the meantime? Should inputs of 9 and up behave like 0: no automation? Or do they all switch to pattern 8? I imagine, for the sake of forward compatibility, at this point the goal is to discourage use of inputs >=9, as their behavior may change. So, for optimal unhelpful redundancy, I would suggest quirkily switching to pattern 4 for any input 9 and up.

Lack of discouragement appreciated! Maintaining forward and backward compatibility is tricky. I believe your conservative approach, given that goal, is warranted.

I was patently hasty implementing the pat input. What can I say, node programming puts me in a very giddy frame of mind. That was also my first pull request ever, and I hadn't read anything about how to do them properly.

I'd like to continue developing and refining this idea in discussion with you. I've closed the pull request but will continue developing that fork.

[treefrogman]

I consolidated my changes into one commit in a new fork and addressed both discussed concerns in mostly the ways I proposed.