The case for a 'Pattern RUN' option

I am making this a post so I can direct Squarp to this URL when I submit this as a feature request - but I’d also like to hear if this is something other people would be interested in…

I’ve only owned the Pyramid for about a month but I’m already loving what it can do. The only place where I feel like the functionality is lacking is the SEQ mode. I think that by adding a Pattern ‘RUN’ option similar to what already exists in the Track mode, the usefulness of the SEQ mode could be greatly increased.

Two major shortcomings I see in the SEQ mode are:

There is no way to add ‘randomness’ to either a single sequence or to the ‘play/loop project’ mode (sequence of sequences). Yes, you can add ‘Chance’ effects to different tracks/steps, but there is no way for the sequencer to choose a random ‘phrase’ of notes (i.e. a Pattern). Having this option would open up a whole new level of generative music creation on the Pyramid.

The other shortcoming is that when a Track is active/unmuted on a Sequence, only one Pattern will be played on that Sequence. This means that if you have a single Track that contains five Patterns, to play those five Patterns, you would need to create five Sequences. If you always wanted to play the five Patterns in order, yes- you could combine them into a single Pattern or Track, but if you wanted to use those five Patterns as song ‘phrases’ which you switch between live or in ‘play project’ mode, you’ve just used up five Sequence slots. Now say you have a second Track containing five Patterns. This is somewhat of an extreme example but if you wanted the option to switch between any combination of Track 1 Pattern 1-5 and Track 2 Pattern 1-5, you’ve now used 25 of the 32 available Sequences in your Project and you’re only using 2 of the 64 available Tracks!

So, how to address this without changing too much about this product which has been around for years? My solution would be to create a ‘RUN’ option on the Pattern menu, similar to the ‘RUN’ option found when pressing 2ND+Track.

rand

This option would be Sequence specific in the same way that the currently-selected Pattern is Sequence specific. You would get to the option by using the data knob, which is currently not used at all on the Pattern selection screen.

For all existing projects, the Pattern RUN option would be set to blank/disabled. This is the current functionality: when the Sequence is running, the currently-selected Pattern loops.

When enabled, the Pattern RUN option could be set to ‘Random’ to play the Track’s Patterns in a random order! At the end of a Pattern, instead of looping, the Pyramid would choose from the used Patterns and play one at random. This would not negatively affect Pattern editing, because a single/static Pattern is still selected in the Pattern menu.

Or, the Pattern RUN option could be set to ‘Play’ (referred to in the manual as ‘free run’) to play through each Pattern on the Track in numeric order (Unused Patterns being skipped), beginning with the selected Pattern. (Since a single pattern is always selected per Sequence, this selection is the perfect way to tell the SEQ mode where to begin playing.)

Or the Pattern RUN option could be set to ‘Relatch’ - this would work the same as ‘Play / Free run’, but if the SEQ changes to another SEQ containing the same Track/Pattern option currently selected, it would restart at the selected Pattern again instead of continuing to play from the current position.

I feel like this solution 1) uses terminology already in place in other areas of the OS 2) would have zero negative effect on existing projects and, most importantly 3) adds significant functionality to the OS without almost any added complexity to the user.

Imagine having Track 1 with 5 Patterns, set to Play/Free Run, Track 2 with 3 Patterns also set to Play/Free Run, and Track 3 with 4 Patterns set to Random. You now have a very complex chain of patterns running using a single Sequence - and you didn’t have to think about how to set up your Sequence Chain to accommodate it… and you didn’t have to save different ‘consolidated Patterns’ as separate Tracks or Patterns which would need to be edited/updated separately if you choose to edit one part of the Pattern in the future.

As I said above, this would open up the Pyramid to the creation of more ‘generative’ / randomized music and really fun experimentation. This could be a late-life feature that gets a whole new audience interested in the Pyramid! I know I’ve bought-in to a device/platform that is six years old and no longer receives new features very often… but I can dream, right? :wink:

2 Likes

but with 64 Tracks (with 32 discrete Patterns within each Track) if you want more randomization between Sequences via Patterns, just use more Tracks and the 32 extra Patterns within them

yeah, it would probably be better if there were also 64 Sequences available but I don’t think the flaw in the Pyramid is lack of mathematical possiblities

Loopback + PyraMIDI can yield the results you want, I believe. Yes, the Pyramid can ‘play’ itself - even without an Event Processor.

Edit to Add: You can even change up phrases during the phrase.

Also note, this emulates basically putting multiple Tracks in Free Run Mode and using several SEQ to select between them.

My point is not really that there aren’t enough Sequences available, it’s that playing any series of notes (I refer to as song phrases, the Pyramid would refer to as Patterns) in a random order is completely unsupported. (Being able to play through patterns in sequential order would just be a bonus, and silly not to implement if playing in random order were to be implemented) Workarounds to this would be to create ‘consolidated Patterns’ (basically a bunch of song phrases in different orders, saved into multiple patterns or tracks), but you still would be manually selecting between these (not random), and the maintenance of these tracks/patterns is impossible (any change you would like to make to a single ‘phrase’ would have to be manually made in every location you’ve copied that phrase for the workaround.

Unfortunately I don’t think anything I’ve suggested is possible through PyraMIDI. First, changing Patterns is not implemented in PyraMIDI. Second, even if you could change Patterns via PyraMIDI, I don’t see how you could sequence a random Pattern or Sequence order since there is no event that occurs when the Pattern or Sequence has played through once. After a pattern (or sequence) has played once, what would trigger the selection of a new random or sequential pattern (or sequence)? There are a ton of other issues here too - how would it know which Patterns (or sequences) are valid to choose from (which are empty, which are not)? Without a trigger, playing through a pattern even in sequential order would be impossible if the length of each was not uniform - how would we know when to trigger the change?

Edit: I do see that the selection of ‘previous/next’ sequence is in PyraMIDI, so I guess the sequential playing of Sequences could be possible… buuuut that is also already possible using the ‘Play/Loop Project’ feature… not the same as doing this on a per-track basis within one Sequence, which is where the possibilities really open up.

Another possibility would be to make the seq mode hierarchical. Instead of a single chain of sequences one can create sub-chains of sequences, and then sequence those.

1 Like

Apologies.
You can’t do this specific thing that you suggested with Patterns but you can do it with Tracks or SEQ.

You can select the Patterns via SEQ and select SEQ via PyraMIDI.
I requested Patterns accessible via MIDI for the very reasons you are bringing up, which is why I did not implement Patterns for a long time.

Yes and no. I know you’re looking for a native solution, and there is not currently one. However, if you want to get closer to implementing your ideas right now, I was only offering suggestion. If you need a native solution, then contact Squarp for a feature request at Contact us | Squarp instruments

And you can actually tell Pyramid when a sequence has played through, or is on it’s final note or beat and to cue up the next one via PyraMIDI via a MIDI Event…which is what the Pyramid is outputting. Just loopback that value and assign it to what you want to do.

Not really, because I do this.
I actually had tested an earlier verson a few years ago by using Note #0 Events to create nodes to trigger an Event Processor to do “things” (what things are determined on a project by project basis)

Well, you know that when you program the song, no?
I’m speaking of creating a Control Track which sends data to loopback to turn other Tracks On/Off via PyraMIDI.

If they are not uniform, you can send out a MIDI message, which is what the Pyramid is designed to do. Granted I assumed uniformity.

You can also specify which Tracks to Mute/Unmute irrespective of SEQ Level Mutings.

Sorry, but I can and do what you’re looking to do, although with slightly different twists - several twists in fact. It is honestly one of the reasons I adore the Pyramid.

Perhaps I misunderstood.
Good day

2 Likes

Thanks for the detailed reply - I didn’t mean to sound like I’m brushing off suggestions of other ways to accomplish this outside of native methods (before buying the Pyramid I was doing a lot of Midi mapping/manipulation through software because of limitations of my old hardware). I may have also complicated things by even including the sequential/relatch options in my first post - I’m not so concerned with this - they just seemed like ‘easy’ ideas to implement IF Squarp was going to build on the existing (limited) functionality of Patterns.

What I am really, really trying to achieve here is the ability to play random ‘note phrases’ from some options that have been created ahead of time. No matter what form it takes (muting/unmuting of tracks vs triggering of patterns on a single track), doesn’t really matter to me. Although I don’t think it really makes sense to do this at the sequence level - this would be severely limiting to what you could do with the rest of your non-randomized tracks (mute states would get reset when switching between sequences, etc), plus you’d run out way too quickly if you were trying to randomize more than one instrument.

I’m still trying to wrap my head around exactly how you would accomplish this even using an Event processor. We’ll throw out the idea of using patterns since they are not currently addressable in PyraMIDI. Say I’ve created tracks 32-37 in a new project that will act as my ‘note phrases’ for a single instrument. They all have different lengths, but I’ve assigned a specific CC message to send on the last note of each phrase to let the processor know that we’ve reached the end (this is something that I’m used to - I used something similar all the time on the OP-Z). You’re saying that you’d have a project-specific setup in your processor that would evaluate something like: I’ve reached the end of this track, generate a random value between 32 and 37, and use that value to send CC messages via PyraMIDI… so if 34 was chosen, the processor would send: CC32 value 0, CC33 value 0, CC34 value 1, CC35 value 0, CC36 value 0, CC37 value 0. This would effectively mute them all except track 34. Then when track 34 finishes playing, this all occurs again and a new random value is selected.

I like the ingenuity but it seems like that would require so much setup per project. For each project, you’d be modifying rules on your processor to get it to handle different ranges of tracks. If the project involved randomization of more than one instrument you may also be changing rules so the processor is ‘listening’ on the correct CC value triggers. (I guess if I went through the trouble of setting this up, I could assign a specific set of tracks to always handle this kind of function and only use them when I’m interested in adding some randomization :D)

Do you have a recommendation for a processor that would make this kind of setup easy? I remember from your other posts that you were using a BomeBox - is what I’ve described similar to how you have that setup or have I misinterpreted your suggestion?

I still think that it would be a huuuuuuge feature for the Pyramid to be able to add some randomization beyond ‘does this individual note trigger or not’. And IMO, Patterns are just waiting for this kind of feature improvement. Their use is completely optional anyway, so building this kind of ‘advanced’ feature on them wouldn’t even complicate things for users not utilizing patterns.

it’s a nice idea… but we’ve have to wait to see if Squarp are able to/want to implement it.
lets remember the Pyramid now is a mature product, thats had many features added ,its a little unclear now how much ‘capacity’ there is for more.

I think the issue is mainly to do with patterns.
sequencers were designed as a song mode, so you can see why thats kind of linear.

the ‘issue’ is the only way to change patterns ‘automatically’ is by using sequences.
and thats also still true in pyramidi
this is all because patterns were added quite a bit of time after initial release.

perhaps there could be a track option for random, or cycling patterns… a bit like how rample plays with its layers.

but again, really we need feedback from Squarp on how they’d like would like (or not ;)) to do this.
after all… they are the only ones that can make this happen.

I think as others have said, you can achieve this with an external midi processor.
basically put different patterns on different sequences, then use CC79 to switch sequences.

pretty much any processor will do this, I use a blokes midi hub occasionally, there is also a smart cable by rokit

its useful to have a processor with multiple midi inputs, since you’ll probably not only want to have the loopback input into the pyramid, but also a live input (controller) … so you’d want to merge midi events.
(of course, you can do with with a separate midi merge box… but why complicate life :wink: )

If you’re amenable to an Event Processor, I’d strongly suggest this route - the flexibility is amazing. I use MTPro and a BomeBox in a convertible type of system (MTPro scripts need to be created on a computer and uploaded to the Box).

However, sans Event Processor, there are several approaches I can think of (few tested) and all comes down to how you want to wrap your head around your phrasing, what might the trigger be, do you want full phrases or to link options for motifs, passing tones, etc and have the system follow a sort of ‘map’, etc. I can think of at least 3 discrete ways to approach dividing up your musical phrasing and each would need to be looked at separately.

So, there are just too many variables that all come down to how deep down this rabbit hole do you want to go. A solution also needs to keep in mind your relationship with playing your music.

I would suggest flow-charting what you want to do with an eye on MIDI Events - and not necessarily just notes but also data, with an eye on Pyramid’s MIDI Fx. Also, check out the MIDI Fx in depth and try some things.

As a prelude to play around if you’re having difficulty with where to start:

  • Create a New Project with PyraMIDI turned on and a hardware loopback from DIN B to DIN IN
  • On Track01, send out on DIN B on the Channel you have set for PyraMIDI, & make it 1 bar long (You can make this longer later, this is just a demo)
  • Put a Note E3 on the first step
  • Add a MIDI Effect: RND, with Enable: ON, PARAM: Pitch, RANDOM-: 0; RANDOM+: 2%
  • Head to Bank B and create 4 Tracks of music and/or rhythm on 17-20. Set them to Muted.
  • Press [Play] and scroll to Bank B and watch the Tracks turn on and off.

Remember that these Tracks turning On and Off can also hold other data other than just Note Events, etc. They can even select other Tracks, so that Track 17 will Select one of several rhythm Tracks that might be Tracks 33-35, Track 18 will select a Bass Track on 36-42, etc. Then things get even stranger if you want to route Note Events back to the Pyramid that are not PyraMIDI but sending back to a Bank for further processing (MIDI In: Multitrack Bank D perhaps - I’ve never tested how that works with PyraMIDI tho…YMMV)

To add an Event Processor into this same config explands the capabilities because then you can flip between Tracks (so, turning on a new Track turns off others) or even expands the capabilities of the Pyramid to allow for SEQ’s that do not affect ALL Tracks - that is, you can have an alternate way to Mute/Unmute Tracks other than the native SEQ functions and this alternate way will allow you to Mute/Unmute Tracks irrespective of others (like, a SEQ mode that only affects 16 Tracks instead of all 64).

Your query pushed me onto a new path however, so I must thank you.
In trying to simplify my explanations, I figured out a new approach that I can incorporate into my own system and it’s exactly what I was looking for! Again: thank you!

Edit to Add: One thing I forgot to mention that could be useful to those who already have a suitable Event Processor is that you actually dont need the Pyramid to generate these messages with a Control Track for each set of layers or however you want to group/organise this data. I never really use Note#0 in music sequencers (or all of the 128 MIDI Notes), so I would use that as a Node to force a routine to randomise which Track of a group of parallel running Tracks would voice (using the FreeLatch Mode/Chance0% hack; also would work with Free Run Mode). That is: When my Event Processor would receive a Note#0 it would look at the Velocity Value which would indicate which routine to run and then send back data to the Pyramid to determine Track Run Status. Of course, the Even Processor swallows this Note Event which allows me to embed it in Tracks which are sending OUT MIDI Data to my synths.

4 Likes

I feel like I’m going to need to re-read your reply a few times to fully understand all of it, but I rushed to try out the instructions you provided and my mind is blown :exploding_head:. I understood the idea of the Pyramid controlling the Pyramid with a loopback, but had never actually tried it because I couldn’t figure out how I would implement a solution to the ‘limitations’ I was seeing (like what I described in my first post). I was going down the path of using multiple S+H LFOs to send CC 1/0 values to mute/unmute tracks. but it didn’t seem like it was going to work. Your solution is incredible, and simple to setup, and with the addition of sending a value of 0 on CC17-CC20 to mute the four tracks right as the RND MIDI Effect turns one of them back on, you gave me exactly what I was looking for. Thank you so much!!

One more quick question before I go spend the rest of the day messing around with these new powers :wink: You suggested that the tracks that are being unmuted by PyraMIDI could be used to select another track:

Remember that these Tracks turning On and Off can also hold other data other than just Note Events, etc. They can even select other Tracks, so that Track 17 will Select one of several rhythm Tracks that might be Tracks 33-35, Track 18 will select a Bass Track on 36-42, etc.

How would one accomplish this if the track can only send messages out on its assigned Midi channel? Using your example above, if my Tracks 17-20 are assigned to MIDI A Channel 1, being used for a kick drum, is there a way for that track to send additional data back to the Pyramid to select/enable another Track? In my case, I’ve assigned PyraMIDI to listen on channel 13, which is being from the Pyramid over MIDI B.

Thank you again for all of this help! This gives me a ton to experiment with, even before I invest in a Event Processor.

1 Like

As for the “one more quick question”, the idea is that a Track represents a “Destination” (excepting if you insert an Event Proc then you can embed control codes into the music clips of course).

There would be 3 levels:

  • Master Control turns on/off subcontrol
  • Subcontrol turns on/off the Tracks that actually send out music
  • The Tracks that send out actual Music

Such as:

  • Master controls if drums, bass, guitar, keys, etc are playing or not
  • Subcontrol is divided up by instrument and controls the actual melodic/rhythmic passages that output to your synths
  • Actual Music Tracks have the variations that are selected by the Subcontrol if they are active per the Master.

Keep in mind that I haven’t tested timing issues and it is dependent on what Trackmute Delays and stuff you’re using. I mean, they are ‘relatively’ in sync, but I didn’t see if the loopback keeps things on the same “1” and I didn’t really want to mess with my Settings.

I also haven’t tried the multi-layer thing…or I might have. I forget. I’ve tried so many tweaks because coming up with the tweaks is what I love to do (my music sucks).

Apologies, I’m trying to mete out information slowly so I dont’ overload and might have cross connected a few things/sent you conflicting data points. (Read: I type responses that are MUCH larger than what I end up posting) :wink: Apologies. For one Track to send out MIDI Data to synths and to the Pyramid requires two Tracks, which I’m not sure would work with this particular system unless you use an Event Processor.

Also remember you can use the MIDI In Multibank n Setting to process your MIDI Note Data through more than 4 FX

I look forward to hearing what you come up with, especially if you expand on these techniques, please please please be sure to share.

3 Likes

Thanks so much for this thread! I have always wanted to implement loopback with randomization. Every month I think I am going to buy a Bome box I find ways to push Pyramid a litle more first :slight_smile:

1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.