Metropolix and Gx

ohhhh thank you for clarifying that. i didn’t realize that shuffle retains the same order until it gets a reset. i had assumed that shuffle re-shuffles each time it plays through the generated order.

Shuffle works best when you repeat the phrase 3 or 4 times before the order is reset, makes the random seem a bit more intentional.

1 Like

Has anyone got the Gx expander yet- seems like it’s not available. I had mine on preorder and have my Metropolix but no Gx.

Also is the CVx 1U expander compatible? Would be nice to have a 1U expander option!

Gx should be shipping to dealers right now.

At the moment only the Gx is supported by Metropolix. Gx is actually the same hardware as Qx so they can be used interchangeably with both Metropolix and Quadrax. It’s just a different faceplate.

1 Like

I don’t think I’m totally understanding the way that the Queued Pulses setting works. Up until now, I’ve been setting it to 16 so that as long as I do a queued load in the bar before I want the change to happen, it changes on time.

However… I’m currently working on a live arrangement with more stuff going on where I’d like to be able to queue those loads a little further out. I set Queued Pulses to 64 and my hope was that this would mean that if I start a queued load anytime inside the 4 bars of my progression, the change will happen on time at the end. When I do this, it still just changes over at the end of the current bar.

So I’m wondering… is it possible to queue the changes further out like I’m trying to do? If this isn’t currently possible, I think it would be a really nice feature for performances to be able to queue things a little more ahead of time. Also, it would be super helpful to get a better understanding of when those queued pulse counts get reset/begin.

Here’s some background on how the internals work.

First, the sequencers (each track and lane) maintains an internal pulse_count of how many clock pulses its played since it was last reset, it doesn’t matter what other settings are going on, it’s always counting.

When LEN>Pulses is set to Auto (default), the sequencers (tracks and lanes) have no clear “last pulse” or end because many of the play modes do not provide this, add in modulation and skip steps, it becomes impossible to determine.

When you set LEN>Pulses to anything but Auto, then that number is compared to the pulse_count, when the pulse_count reached your configured LEN>Pulses then the sequencer resets, also reseting pulse_count

That brings us to Queued Pulses. Queued Pulses is a fallback for when your current Track 1’s LEN>Pulses value is set to Auto.

Now, this is how Queued Pulses works:
First, Queued Load only looks at Track 1. If your current Track 1 has LEN>Pulses set to a Number value (not Auto), then Queued Pulses is ignored, since your Track 1 will automatically trigger a reset when the pulse_count reaches it’s LEN>Pulses, in this case, it will also load your Queued Preset.

Here’s the info you’re looking for:
If your Track 1 has LEN>Pulses set to Auto, when you do a Queued Load, the Queued Pulses is used in place of a fixed LEN>Pulses. But since your pulse_count is through the roof, because you’ve been jamming with Track 1 LEN>Pulses set to Auto for like an hour, then when you do a queued load, we do the actual loading of the track when Track 1’s pulse_count is cleanly divided by your configured Queued Pulses. For example, if your Queued Pulses is set to 64, and you do do a “Queued load” when your sequencer is at pulse_count 4050, then the load will happen at ** pulse_count** 4096, because that is the next clean division of 64.

We added the Queued Pulses fallback so you can jam and load presets that don’t nessesarily have an end point, maybe they are completely generative, or random, but you want to mix them in a set of ridged 4 bar seqeunces. But remember, if your current playing Track 1 LEN>Pulses set to any number, Queued Pulses is ignored.

Hope that clears it up :upside_down_face:

PS— If all of your presets that you are Queue Loading have LEN>Pulses set, the LEN>Pulses will happen on the configured LEN>Pulses of each preset that you flip through, some could be 16, some 64, some 8, 3, 69, whatever. Each Queued Load respects the current sequence playing on Track 1.


Ok wow thank you so much for the extremely thorough explanation! That clears up why things are working how they are working.

So far, most of the time my track 1 has been set to a LEN>Pulses of 16, but I often am using a mod lane assigned to Pitch Pre to create chord progressions that are usually 2 to 4 bars long (32 or 64 pulses). One workaround to do what I want for now would be to not use Track 1 and have it work solely as the “length keeper” and then move my sequences over to Track 2, but I’d eventually like to be using both!

One thing I’d humbly suggest to remedy more flexible queued pattern changing would be to use the longest length of any track or mod lane not set to AUTO. That way you could keep your wild generative sequences, but also lock your changes in to longer running tracks/mod lanes.

This is similar to the way the OP-Z pattern queuing system works. You can set different divisions on different tracks and when you queue up a pattern to switch to, it won’t change until the longest track wraps around to the beginning. Sometimes even when I’m playing a 1 bar pattern on OP-Z, I’ll change an unused/muted track to a /4 division just so I’ll have that extra time to queued up my change. On Metropolix, it would be analogous to using a spare mod lane for something like this. I find it super helpful when performing to have that extra padding… frees my mind up to bring a fill on that last bar on the drum machine or something like that.

1 Like

I’d consider tweaking the formula here, but keeping track of 10 LEN>Pulses settings (2 tracks+8 Lanes) to determine the Loop point is a lot to keep track of. I think at most we would probably look at taking the longer of Track 1 or 2, or maybe just implementing a per-preset setting for something like “Queued Pulses”. I wouldn’t want some rogue previously used, now-unused mod lane interfering with other behaviours.

The 1.1 update is pretty locked in here ;). (Soon, but not before the weekend.)

Since 1.2 is already planned, I will put on the wishlist for 1.3+, but not sure on timing for that one.

Well, I don’t know the details of the implementation, but in my mind, it’s just a matter of looping through all the tracks and mod lanes to find the one w the longest LEN value, then only checking for that lane’s reset to load the queued pattern. Shorter length tracks/modlanes might reset multiple times within that span, but it’s only the longest one you are checking against.

Alternatively, maybe an even more flexible option would be to have a Queued Load modulation target for mod lanes and aux inputs. You could queue a pattern with the stage button and then of a Queued Load modulation target is present, it overrides any track length resets being used and the pattern only loads when a trigger is received on that mod lane/aux input?

1 Like

It’s not that the implementation is hard, most of the time that is trivial.

It’s that it it makes the UI more complex and harder for a user to diagnose unexpected behaviours, like i described above, scanning ten tracks to find the longest setting is a bit of a pain. We could highlight the longest track on a home screen or the preset screen, but that’s still a pain in the butt.

Keeping a single value per-preset and divorcing the Queued load from the tracks all together, seem to be the most straight forward solution. We have some other plans in regards to pattern/preset chaining, and we wouldn’t want to complicate with more settings in that area, before we work out the bigger parts.

1 Like

This sounds ideal to me! Looking forward to seeing what else is in store in those coming updates. :slight_smile:

Let’s just say that my Metropolix is just a bit more fun than yours right now

:speak_no_evil: :speak_no_evil: :speak_no_evil:


Heyho, i really love the metropolix but i have transport/run/reset however issues with my hardware. I own a Vermona qmi2 Midi Interface, which has a dedicated reset output but its logic is the exact opposite to the metropolix starting behaviour. So, if the qmi stops, the metropolix is running and if i start the qmi, the metropolix stops. Then i bought a din sync cable for the start signal, to sync it via my elektrons, but the metropolix is starting a 1/16th note later than the rest of my system. I helped me now with a gate signal at the 16/16th of the first bar, but its a little bit annoying.

So is it possible to implement an inverted starting behaviour in the metropolix reset options?

Loving my Metropolix. The basics are great fun and immediate like the original and then with a bit of learning the depth available becomes apparent.

Talking of basics - I often find a happy accidental groove but want to adjust the starting/reset point (say to stage 3 instead of stage 1). I see you can apply an offset at the start but that’s then changing the overall pattern (1234 to 3456). Is there a simple way to get 3412 that I missed in the manual? I started copy pasting 1 to 5 and 3 to 6 into pitch but seems a faff to do that. Is this a feature request?

if i’m understanding correctly, you could set SKIP on stages 5-8 and then your sequence would be 3412.

1 Like

Oh yeah?!
How much longer must we wait until the cst is out of the bag?!!

Nice idea - will give that a try

My Metropolix landed on Friday and first of all I have to say kudos to you Intellijel. This is absolutely wonderful. Within 5 mins of installing it, it was spitting out catchy little jams that would have been a nightmare to program on any other modular sequencer.

I also wanted to request a firmware feature that hopefully isn’t too tricky to add.

I was playing with the queued load preset feature, which is a brilliant touch! and I understand you can set the amount of pulses before the next pattern loads.

I was wondering if it would be possible to add a third option to this in the preset setup menu for the queued load, that simply plays the selected preset as soon as the previous pattern has finished playing regardless of how many pulses it has. This would be great for playing live, especially if you have some sequences with 32 pulses and some with 64 for example. It just plays the selected load slot as soon as the pattern has finished. Call it END OF PATTERN LOAD or similar for example.

EDIT: just read that freqout might have been talking about something similar above. Not sure if he means quite the same thing though.

Also it would be fantastic to be able to access save slots via CV. Either a gate that plays the next pattern in the row, or a wider voltage option split into 8 to address any of the 8 presets in that bank.

Sorry if this has already been requested.


I find hard to follow what has already been taken into account (and not) by intellijel for the future firmware updates. This thread is too big and there’s a lot of info in it.

It would be nice if each feature request has a separate thread.
It can be marked with the adequate category or tag and this it will be easier to track what is already in the pipe and we can discuss specifically for each feature request in his specific thread.

It’s a bit of moderation and discipline for people who ask for new features. But I think it can really help to keep up with the development of new versions. And keep this thread to say that Metropolix is awesome :level_slider: :level_slider: :level_slider: :level_slider: :level_slider: :level_slider: :level_slider: :level_slider: :star_struck:

You can see the explanation of how things currently work here:

TLDR— the current “pattern” is considered Infinite, unless Track 1 has a LEN>Pulses value, then that number is used as a marker to load the queued Preset, and yes, that is a per-preset value (can be different in each one); as a fallback the Queued Pulses values is used to mark the loading point off the next preset.

CV over preset has been requested, and we have some other things planned in regards to preset chaining, etc. We’ll—of course— take in all the user feedback when review this part of the module.

1 Like