How to transition from one part of a song to another without setting all tracks to relatch


My song has a 4 bar intro followed by a verse, chorus and bridge. Each with several, overlapping tracks of various lengths.

At each transition I mute several tracks and un-mute several others. Problem is, the tracks I un-mute have been running muted and many are part way through. Setting the tracks to RELATCH run mode fixes this but then I’m stuck with those tracks restarting when I don’t want them to.

Feels like I need a one-time RELATCH-ALL command or the ability to make a SEQ relatch everything while keeping my tracks in FREE RUN mode.

I can’t be the first person to see this. I must be missing something. Any help would be much appreciated.

Yeah the freerun mode can catch you by surprise - your song works fine as individual sequences, and as a whole, until you add that little intro sequence after which ethe song is entirely messed up. Been there, cursed and scratched head quite a bit before realizing it’s the freerun mode behaving as expected. For my purposes I figured I almost never actually want the freerun behavior, switched the default to relatch and been much happier after that.

Anyway, I think you should be able to handle it by using a dummy 4 bar pattern for each of your tracks during the intro.


Thanks Paul.

Yes, a dummy 4 bar pattern set to relatch works for the intro. Kind of a pain to have to create the dummy pattern for every track but it does work.

A relatch all setting on a SEQ would certainly be better.

Thanks again for replying.

I got right into sequence chaining as a means of finishing full songs that play through from beginning to end. Gave up in the end due to bugs in the SEQ functionality (sequence chain getting stuck / play button not restarting play at the next sequence in the chain as expected etc.)

But I did receive confirmation from Squarp that these bugs and other SEQ related issues would be fixed in the next release (this was back in September - maybe it’s coming in 3.0?)

Also during this testing and feedback period I came across a gap like the one you describe. And I flagged it with Squarp:

I had a modulation track set up to apply a long slow cutoff rise on an instrument that was playing in another (shorter) track.

As tracks in Run mode play concurrently, my modulation track starts along with all the other tracks (muted or not) whenever I press play. So when I’m starting the arrangement from bar one, even though the modulation is not required until, say bar 52 in my song, when the part that instrument that needs the cutoff comes in - it starts doing it’s thing in bar 1 - albeit muted.

By the time we get to bar 52 when the modulation track becomes unmuted, it has already looped twice and is half way through its third loop. This means my modulation curve starts half way through and then loops back to the top of the curve which is not what I want.

So in this scenario it would be super useful to have a 4th track run mode:

“Play from the start when the track is unmuted/launched, keep playing even if the sequence changes and don’t loop back at the end”

Happily, Squarp responded with this:

“You’re right, this mode is missing. I searched for a workaround using patterns and different playmodes but I can’t find anything that solves this scenario. Will add this to the to do list, but I can’t say when it is going to be implemented, as we have already lots to do!”

So that’s positive, right?

Maybe OS 3???




Possible solution for your modulation track; give it an empty, dummy pattern 52 bars in length with run mode RELATCH. Then, at 52 bars, switch to the non-dummy pattern with runmode FREE or TRIG. This assumes you have a convenient SEQ boundary at 52 bars.

This is similar to the solution Paul above suggested for my intro scenario. Using a dummy pattern to fake a missing runmode.


Right. I get it now. Good shout. Will give it a go, thank you.


Just got my Pyramid, and I realize I am resurrecting an old thread, but this seems to confirm my issues with replicating an example from the manual.

Track 1 is 12 bars, track 3 is 6 bars. There are 3 sequences, each 4 bars in length. All sequences have track 1 unmuted. Seq 1 has track 3 muted, while it is unmuted in seq 2. The manual shows track 3 running from its bar 1 in seq 2, playing into seq 3 and restarting at bar 3 of seq 3. But in the default free mode, track 3 is proceeding muted already in seq 1, and will start on bar 5 when it is unmuted in seq 2.

I was scared that the pyramid would be hard to use, but I’ve had it for two days and I think most things are falling into place. I would just like to confirm that my understanding is correct, as it seems strange that the manual isn’t correct in explaining this.

This is the section of the manual I’m referring to:

As I’ve understood it, if these are the only sequences, track 3 will not play as indicated, but start from its 5th bar in sequence 2.

Hmm, yeah. If freerun behaved as it’s explained in the manual it’d actually make sense a whole lot of times, but that’s not the behavior I remember from v2.30. Hence this thread and a whole lot of confusion. BTW it’s also worth noting track 2 in the example here: doesn’t it simply continue from bar 9 at seq 3, instead of restarting? If not, then it all seems even more inconsistent. Guess it’s time to grab a beer and go test it some.

1 Like

I think you are correct. I understand why it’s implemented like this, as it is less information to keep track of, but it’s not what you expect. Having trigger options on the sequences would give you all options, but “retrigger on first time”, as the manual describes would at least be less confusing. At any rate, the manual should contain clear and correct examples.

1 Like

Okay, easily tested (now on v3.2) with three freerun-tracks playing twelve-bar boogie. Arrange like tracks 1-3 in the manual example, split into three four-bar sequences. Track 1 is active in all sequences, track 2 is muted in sequence 2 and track 3 starts in sequence 2. All three tracks arrive at the wrap-around at the same time, aka boogie together. So freerun tracks really are always playing, whether muted or not.

So whatever the intended behavior, the manual and implementation quite clearly disagree. Beaming up bat-signal to @squarpadmin :slight_smile:

There are uses for the implemented behavior too of course, but in many cases the documented behavior would be more useful and far less weird.


FWIW, I reported this through the official channel and Squarp confirmed that it’s indeed a documentation bug that they’ll fix shortly.