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
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.
It’s actually much easier for us to track in a single thread . Much less will fall through cracks this way, but we try to keep an eye when stuff does pop up else where.
When we see feature request, we almost always add it to the “Wishlist”, this doesn’t necessarily mean it will be added or implemented, but it does mean we’ll consider it.
We really appreciative of all of your feedback, regardless of the thread it’s in
I understand what you mean. Small team does mean you do not have a lot of eyes and it’s easier to follow one thread and write ideas on a wishlist. (catch all the fishes with the same net)
Is there a way to access this list? In this way, users can know what is planned and what is not. This would avoid having to scan all the threads concerning Metropolix or worse to ask again for the 10th same time because we are too lazy to reread everything.
I strongly believe that separate thread for each feature request will be clearer for the forum users. But it’s more moderation work.
But I do not want to bore you with my boring heavy organization needs. It is certainly my Swiss side (everything has to be classified meticulously).
Keep going guys and girls you do an incredible job.
Our issues list is not public. We don’t want to lead people on with a list of features that we may have planned, but ultimately do not make it into the product, either because they are not good after we try them or we feel they do not work with the UI or spirit of the module.
We already have loose plans for the next 2 major versions, but I don’t want to communicate the direction, because they are not set in stone, we make take a different direction than planned for either of those versions!
The next one is close, we’re just adding the list couple things.
Here are some feature requests for adding some randomization in stages buttons to generate some happy accidents. This could be really fun.
Randomize a Stage button value
It will be nice to have a way to randomize a Stage button value. For exemple when editing Probability, long presse or combo button can generate a random value for this stage
Randomize all Stages buttons values
Randomizing all Stages by a button combo (or something else)
OK great. Sorry if I misunderstand, but are you saying the feature I’m requesting already exists just in another form?
Can you clarify? Are you saying I just saying I need to set LEN to AUTO?
It’s already defaulted to AUTO.
Also, would it be possible to be add the capability to assign gate type to a ctrl knob and to the x, y, z ins?
I can imagine flicking between different gate types on the fly would be absolutely wild.
If you Set LEN>Pulses to anything except “Auto” then that number will be used to calculate when the queued preset will load. So one preset can have 32, and one can have 64, and they will complete their play through before the next preset is loaded.
Any chance we can get the raw firmware files added to the update archive? I see the updater is just running dfu-util and saves those of us not on win/mac from running a virtual machine.
based on that description, yes. We can’t calculate the end point automatically because many of the Play Orders do not have a predictable end, and changing things like Skip or Stages or Offset also change your end point.
The purpose of the the LEN>Pulses value is so that your starting step always snaps to a selected grid, you can modulate and play with all of the other parameters without worrying about going out of bounds.
Set it to 64, and then go to town on pulse counts, Skips, and Stages, etc… When you stop playing with those items you’ll hear your sequence start to loop on your current settings every 64 pulses; and one step deeper, this is all tied to how the Queue Load works, as i described above.
Yeah randomizing parameters is on our wish list, we would probably come up with a system wide version of this so you could randomize any parameter. Thanks for the suggestions
Thank you, that makes total sense now.
I hadn’t even looked at the LEN setting until now.
IT’S SUCH A DEEP MODULE.
Congrats again on an incredible product.
I work as a UI / UX designer in my day job, and you guys could teach a course on UI / UX in the modular realm, I really appreciate it.
Everything is so well thought out, from the per button access, through to the menu layouts and navigation on the OLED. Well done!
Was thinking about this a bit more and wonder whether it might be better as a setting rather than simply powering on in whatever Run state Metropolix was last in, but I’m unsure…
There could be users (I’m thinking particularly those who clock the module externally) who might expect the module to always start up running, perhaps in the case that Metropolix’s A, B, and CLK outputs are feeding the beginning of a performance which does not contain Metropolix’s two voices (let’s say they are muted and brought in later).
In my case I’m clocking various things from Metropolix through a mult and don’t want them to just start running before I say so…
Feature request: A setting to enable a security combo to activate the run button
Context:
When playing live, sometimes I press the run button by accident instead of the loopy one … and everything stop.
It would be create to have in the settings a way to activate a « security run combo ». For exemple, you have to presse alt + run to activate the run button.
. Much less will fall through cracks this way, but we try to keep an eye when stuff does pop up else where.
(everything has to be classified meticulously). 
