[SPLIT] Alternative Firmware(s) for Mutable Instruments Stages

[qiemem]

Amazing firmware I am having a lot of fun.

That's great to hear! Glad you're enjoying it!

One thing I noticed though.. Single looping gated yellow segments are not attenuating? When not gated, everything is fine and the pot is behaving like an attenuator, but when I put the gate in, pot is not responding. Can someone confirm this?

Thanks for catching this! Reproduced and made an issue: https://github.com/qiemem/eurorack/issues/15

edit: one more thing.. in the previous versions, when you hold the button and want to make it looping, while you are holding the button it starts flashing after two seconds...now you have to let it go to see it flash.. I think that the previous option was better because you could immidiately see that you switched the behavior, now its not that obvious until you let go of the button..

This behaviour actually goes back to joeSeggiola's firmware. Because the multimode trigger is also a long press, looping activates on release instead of press. I, too, miss this behavior. Maybe I could change the LEDs without actually changing state or something... would be a little hacky though. I'll look into it.

fuck..third thing ... before, when in green non looping mode, leds were turned off, now they are always on.. also think that is better if they are off because you can better see the beahaviour of the mode and the overall view of the moules state is more clear.

Ooo good point. That comes from single, non-gated ramps now being two-sided slews. The LED comes on during rise (or rather, turns off during fall), and just natural noise is making it rise and fall rapidly. https://github.com/qiemem/eurorack/issues/17

Thank you for catching these!

[Silentnotes]

Amazing firmware I am having a lot of fun.

That's great to hear! Glad you're enjoying it!

One thing I noticed though.. Single looping gated yellow segments are not attenuating? When not gated, everything is fine and the pot is behaving like an attenuator, but when I put the gate in, pot is not responding. Can someone confirm this?

Thanks for catching this! Reproduced and made an issue: https://github.com/qiemem/eurorack/issues/15

edit: one more thing.. in the previous versions, when you hold the button and want to make it looping, while you are holding the button it starts flashing after two seconds...now you have to let it go to see it flash.. I think that the previous option was better because you could immidiately see that you switched the behavior, now its not that obvious until you let go of the button..

This behaviour actually goes back to joeSeggiola's firmware. Because the multimode trigger is also a long press, looping activates on release instead of press. I, too, miss this behavior. Maybe I could change the LEDs without actually changing state or something... would be a little hacky though. I'll look into it.

fuck..third thing ... before, when in green non looping mode, leds were turned off, now they are always on.. also think that is better if they are off because you can better see the beahaviour of the mode and the overall view of the moules state is more clear.

Ooo good point. That comes from single, non-gated ramps now being two-sided slews. The LED comes on during rise (or rather, turns off during fall), and just natural noise is making it rise and fall rapidly. https://github.com/qiemem/eurorack/issues/17

Thank you for catching these!

No problem, very happy to help

[h1ghfiv3]

For some reason, updating my stages doesn't seem to work. I did everything as instructed on the stages website, trying to play the update file into the last segment's cv input, keeping the LED button pressed with slider at mid position. Also checked beforehand that my line out is indeed playing the update file as intended. However, LEDs don't turn into VU meters as stated, and the update didn't work. Anyone has an Idea why that is the case ? Do I have to make an intermediate firmware update (afaik, my stages runs on original firmware)

[boom blip]

For some reason, updating my stages doesn't seem to work. I did everything as instructed on the stages website, trying to play the update file into the last segment's cv input, keeping the LED button pressed with slider at mid position. Also checked beforehand that my line out is indeed playing the update file as intended. However, LEDs don't turn into VU meters as stated, and the update didn't work. Anyone has an Idea why that is the case ? Do I have to make an intermediate firmware update (afaik, my stages runs on original firmware)

Are you using your phone? My phone doesn't get loud enough and I have to play it out of my soundcard way way louder than I thought would be necessary.

[h1ghfiv3]

I am using my UAD will full gain. But after just another try, it is working miraculously Let's see what this harmonic oscillator can do...

[Silentnotes]

For some reason, updating my stages doesn't seem to work. I did everything as instructed on the stages website, trying to play the update file into the last segment's cv input, keeping the LED button pressed with slider at mid position. Also checked beforehand that my line out is indeed playing the update file as intended. However, LEDs don't turn into VU meters as stated, and the update didn't work. Anyone has an Idea why that is the case ? Do I have to make an intermediate firmware update (afaik, my stages runs on original firmware)

You dont need to keep the led button pressed, only when you power up the case.

[saiteron]

I've created an issue to track the attenuator suggestion: https://github.com/qiemem/eurorack/issues/16. As I mention there, the UI difficulties (as well as some technical) make me inclined to not add it, especially given the presence of attenuating segments. It would be nice to not eat a segment for this, but given that that is an option, and the popularity of utility modules for this kind of thing Sorry to disappoint. If anyone can think of a way of representing the attenuation level of a segment in a clear way, I'm might be open to it though.

haha no worries! i'm just trying to cram as much as i can into a single 7U case and thought i'd offer my two cents here. re: representing attenuation levels, brightness of LEDs is always an option but with them already strobing and cycling i see how it could easily get a bit too chaotic or too subtle to be worth the time. thanks again for your awesome work!

[joeSeggiola]

edit: one more thing.. in the previous versions, when you hold the button and want to make it looping, while you are holding the button it starts flashing after two seconds...now you have to let it go to see it flash.. I think that the previous option was better because you could immidiately see that you switched the behavior, now its not that obvious until you let go of the button..

This behaviour actually goes back to joeSeggiola's firmware. Because the multimode trigger is also a long press, looping activates on release instead of press. I, too, miss this behavior. Maybe I could change the LEDs without actually changing state or something... would be a little hacky though. I'll look into it.

Yep. And initially the LED changed while pressing, like the stock firmware. But that meant that when you wanted to switch mode, you will always cause an unwanted segment configuration change. I "fixed" that in commit 70a5e48, if you want to take a look at what I changed. The only way to get the old behavior is to "fake" the LED status, or to "undo" the segment configuration when switching mode, but I agree that these are both "hacky" solutions to an actual UI limitation.

@Silentnotes Note however that the duration of the long-press required to change the segment configuration has been reduced from 0.8s of the stock firmware to 0.5s, so you can be quite sure that you pressed long enough when doing it.

[qiemem]

I've created an issue to track the attenuator suggestion: https://github.com/qiemem/eurorack/issues/16. As I mention there, the UI difficulties (as well as some technical) make me inclined to not add it, especially given the presence of attenuating segments. It would be nice to not eat a segment for this, but given that that is an option, and the popularity of utility modules for this kind of thing Sorry to disappoint. If anyone can think of a way of representing the attenuation level of a segment in a clear way, I'm might be open to it though.

haha no worries! i'm just trying to cram as much as i can into a single 7U case and thought i'd offer my two cents here. re: representing attenuation levels, brightness of LEDs is always an option but with them already strobing and cycling i see how it could easily get a bit too chaotic or too subtle to be worth the time. thanks again for your awesome work!

Oh for sure, can definitely understand that desire... this whole firmware is basically me getting carried away with trying to pack as much functionality as possible in

I've tried using LED brightness for stuff in the past, but it's really hard to see in practice unfortunately, especially with the strobing.

[qiemem]

Hey, if anyone happens to have more than one Stages, I managed to borrow a second one this weekend, and have an early build of chaining support. I would be very grateful to those willing to try it out.

Here’s how it works:

• A Stages will only chain with other Stages that use the same firmware and are in compatible modes (mode 1 chains with itself, modes 2 & 3 chain together, and the other modes are correctly ignored).
• A module in an incompatible mode will split the chain. So, with mode 1 - mode 5 - mode 1, the two modules on either end will not be chained, but mode 1 - mode 1 - mode 5 will have the two mode 1 modules chain
• Changing the mode on one module triggers a rediscovery of neighbors in the other modules, so the chain will correct itself as modes change whether you’re adding or removing modules from the chain by changing mode

I’ve only been able to test it with two modules, but it should work with more It has also been updated with the latest version of the official firmware, so has the new sequencer orders Émilie added a couple days, and has a smattering of bug fixes.

[Squallaz]

Hey, if anyone happens to have more than one Stages, I managed to borrow a second one this weekend, and have an early build of chaining support. I would be very grateful to those willing to try it out.

Here’s how it works:

• A Stages will only chain with other Stages that use the same firmware and are in compatible modes (mode 1 chains with itself, modes 2 & 3 chain together, and the other modes are correctly ignored).
• A module in an incompatible mode will split the chain. So, with mode 1 - mode 5 - mode 1, the two modules on either end will not be chained, but mode 1 - mode 1 - mode 5 will have the two mode 1 modules chain
• Changing the mode on one module triggers a rediscovery of neighbors in the other modules, so the chain will correct itself as modes change whether you’re adding or removing modules from the chain by changing mode

I’ve only been able to test it with two modules, but it should work with more It has also been updated with the latest version of the official firmware, so has the new sequencer orders Émilie added a couple days, and has a smattering of bug fixes.

dope

[Squallaz]

----> another firmware update: https://forum.mutable-instruments.net/t ... e/17493/44

[qiemem]

----> another firmware update: https://forum.mutable-instruments.net/t ... e/17493/44

The chain test build above should be up to date with that thread. It has the new sequencer orders and tracking behavior.

[loreamon]

So which one is the latest unofficial ‘official’ firmware?

[qiemem]

So which one is the latest unofficial ‘official’ firmware?

Ah, sorry for the confusion. The latest released version will always be here: https://github.com/qiemem/eurorack/releases/latest

I was just hoping to get some other fingers twiddling the chain test build before I actually released it since it changes some pretty fundamental stuff in cross module communication (which can affect single module operation). I'll probably be releasing it officially in a day or two, unless something big comes up; seems pretty stable so far.

Besides the chaining fix, the test build was updated with the new sequencer orders added by Émilie (v1.0.2 has the new sequencer, but only has the first batch of playback orders she released) and a couple bug fixes.

[autopoiesis]

hey @qiemem, this looks incredible and has convinced me to bring a Stages back into my system.

I'm wondering if, with re-trigger *enabled* on a ramp segment that's functioning as an "attack" stage, will the segment reset to 0V when another rising edge is detected on the gate input before that segment has completed its rise? I can't remember if factory Stages does this, but it's pretty handy to use sometimes (bearing in mind that when used to open VCAs, it might produce clicks, but there are other uses for ramp-shaped modulators besides this).

I'd also like to suggest a use for the unmapped button + slider control for the green-gated-nonlooping segment type: frequency range! it would be very nice to have fast, medium, and slow ranges for ramp segments. if I understand correctly, the maximum time per ramp was increased (via joeSeggiola's code) to 58 seconds without applying external CV? this is sometimes not slow enough, and in other cases this might compromise the "feel" of the time range via Stages' short-throw sliders (as you mentioned sometime in this thread). I'm not sure what frequency ranges would be best to go with, but maybe one that is a bit faster than the current range, one that's the same frequency range but capped at a slightly faster maximum time (if 58s feels wrong on the sliders), and one that goes slooowwww.

last - it could be nice to have a polarity selection for the R&F slew (green-ungated-nonlooping), which would make sense to behave a little differently from the others: it could be either positive (0-8v I guess?) or inverted (-8v-0v). this would be handy when using it as an envelope follower, because an inverted envelope follower is the key to any kind of sidechain modulation. and if it's not already implemented, it might also be a good idea to add a full-wave rectification stage after the CV input on the R&F slew so that it works close to optimally as an envelope follower. that wouldn't detract from its performance as an ASR envelope (since in that case we're only slewing a unipolar positive gate signal). when using Maths or Function as an envelope follower, I always got better results when FWRing the audio signal before patching it into the slew input.

[qiemem]

Thanks for the interest and feedback, @autopoiesis! Glad I've re-ignited your interest in Stages

I'm wondering if, with re-trigger *enabled* on a ramp segment that's functioning as an "attack" stage, will the segment reset to 0V when another rising edge is detected on the gate input before that segment has completed its rise? I can't remember if factory Stages does this, but it's pretty handy to use sometimes (bearing in mind that when used to open VCAs, it might produce clicks, but there are other uses for ramp-shaped modulators besides this).

Factory Stages does not reset to 0 nor does this firmware. Émilie discusses it briefly here: https://forum.mutable-instruments.net/t ... r/13951/11. Basically, each solution is useful in different situations. That said, you can get reset to zero by putting a hold (red) segment with the slider and pot at 0 before the attack segment. Then it will use that initial hold as the starting value for the envelope.

I'd also like to suggest a use for the unmapped button + slider control for the green-gated-nonlooping segment type: frequency range! it would be very nice to have fast, medium, and slow ranges for ramp segments. if I understand correctly, the maximum time per ramp was increased (via joeSeggiola's code) to 58 seconds without applying external CV? this is sometimes not slow enough, and in other cases this might compromise the "feel" of the time range via Stages' short-throw sliders (as you mentioned sometime in this thread). I'm not sure what frequency ranges would be best to go with, but maybe one that is a bit faster than the current range, one that's the same frequency range but capped at a slightly faster maximum time (if 58s feels wrong on the sliders), and one that goes slooowwww.

I think an old version of my firmware extended the time to something like 58s, but I removed it because it really messed with the playability of the sliders. It currently has the original slider max of 16s. That said, it's something I've wanted as well. My hesitation though is that I'm not sure of a good way to represent which time range you're in. With looping segments, speed of the LED oscillations is a natural representation. But you don't have that on non-looping segments. I would prefer not to introduce more hidden state. Let me know if you have any ideas!

Also, FWIW, if you plug an offset into the CV, you can get up to like 18 minutes (with 8v of CV). Just using a yellow or red segment for this works well, though that eats a segment.

last - it could be nice to have a polarity selection for the R&F slew (green-ungated-nonlooping), which would make sense to behave a little differently from the others: it could be either positive (0-8v I guess?) or inverted (-8v-0v). this would be handy when using it as an envelope follower, because an inverted envelope follower is the key to any kind of sidechain modulation. and if it's not already implemented, it might also be a good idea to add a full-wave rectification stage after the CV input on the R&F slew so that it works close to optimally as an envelope follower. that wouldn't detract from its performance as an ASR envelope (since in that case we're only slewing a unipolar positive gate signal). when using Maths or Function as an envelope follower, I always got better results when FWRing the audio signal before patching it into the slew input.

In the firmware, you can use a single looping bipolar yellow to do attenuversion+offset, so combining that with rise & fall segment makes for easy sidechaining (you don't even need bias on your vca that way). Also, if you set the fall to be shorter than the rise, you'll get an inverted envelope follower (for bipolar signals). I'd prefer not to do full wave rectification by default since there are lots of other uses of a slew with independent rise and fall besides envelope following and slew. However, maybe setting bipolar should activate full wave rectification? I'd also been considering that for switch the slope to linear though.

[autopoiesis]

Thanks for the interest and feedback, @autopoiesis! Glad I've re-ignited your interest in Stages

I'm wondering if, with re-trigger *enabled* on a ramp segment that's functioning as an "attack" stage, will the segment reset to 0V when another rising edge is detected on the gate input before that segment has completed its rise? I can't remember if factory Stages does this, but it's pretty handy to use sometimes (bearing in mind that when used to open VCAs, it might produce clicks, but there are other uses for ramp-shaped modulators besides this).

Factory Stages does not reset to 0 nor does this firmware. Émilie discusses it briefly here: https://forum.mutable-instruments.net/t ... r/13951/11. Basically, each solution is useful in different situations. That said, you can get reset to zero by putting a hold (red) segment with the slider and pot at 0 before the attack segment. Then it will use that initial hold as the starting value for the envelope.

ah, okay. I'll have to poke around and see if I can get it working into VCV before I find another Stages. I'd really prefer not to sacrifice a segment to get that behavior when I want it.

I'd also like to suggest a use for the unmapped button + slider control for the green-gated-nonlooping segment type: frequency range! it would be very nice to have fast, medium, and slow ranges for ramp segments. if I understand correctly, the maximum time per ramp was increased (via joeSeggiola's code) to 58 seconds without applying external CV? this is sometimes not slow enough, and in other cases this might compromise the "feel" of the time range via Stages' short-throw sliders (as you mentioned sometime in this thread). I'm not sure what frequency ranges would be best to go with, but maybe one that is a bit faster than the current range, one that's the same frequency range but capped at a slightly faster maximum time (if 58s feels wrong on the sliders), and one that goes slooowwww.

I think an old version of my firmware extended the time to something like 58s, but I removed it because it really messed with the playability of the sliders. It currently has the original slider max of 16s. That said, it's something I've wanted as well. My hesitation though is that I'm not sure of a good way to represent which time range you're in. With looping segments, speed of the LED oscillations is a natural representation. But you don't have that on non-looping segments. I would prefer not to introduce more hidden state. Let me know if you have any ideas!

Also, FWIW, if you plug an offset into the CV, you can get up to like 18 minutes (with 8v of CV). Just using a yellow or red segment for this works well, though that eats a segment.

I don't think it would be problematic at all to use LED oscillation speed as an indicator while you're selecting the frequency ranges for ramp segments (since we should know our segment type anyway), but a flashing color sequence (as on the scale selection) could also be used to indicate that. I thought about consistency with Tides (where slowest = green, medium = orange, red = fastest), but that would be confusing because currently green is the default range.

in any case, I think frequency ranges for ramp segments would be super useful, even if the indication is a bit weird.

last - it could be nice to have a polarity selection for the R&F slew (green-ungated-nonlooping), which would make sense to behave a little differently from the others: it could be either positive (0-8v I guess?) or inverted (-8v-0v). this would be handy when using it as an envelope follower, because an inverted envelope follower is the key to any kind of sidechain modulation. and if it's not already implemented, it might also be a good idea to add a full-wave rectification stage after the CV input on the R&F slew so that it works close to optimally as an envelope follower. that wouldn't detract from its performance as an ASR envelope (since in that case we're only slewing a unipolar positive gate signal). when using Maths or Function as an envelope follower, I always got better results when FWRing the audio signal before patching it into the slew input.

In the firmware, you can use a single looping bipolar yellow to do attenuversion+offset, so combining that with rise & fall segment makes for easy sidechaining (you don't even need bias on your vca that way). Also, if you set the fall to be shorter than the rise, you'll get an inverted envelope follower (for bipolar signals). I'd prefer not to do full wave rectification by default since there are lots of other uses of a slew with independent rise and fall besides envelope following and slew. However, maybe setting bipolar should activate full wave rectification? I'd also been considering that for switch the slope to linear though.

ah, true, I wasn't thinking about other slew applications where you'd want to track negative voltages. I don't understand "if you set the fall to be shorter than the rise, you'll get an inverted envelope follower" - that's surely not the same thing as a bog-standard envelope follower signal that's had its polarity inverted, is it? I'll have to try it out with my Mini-Slew.

[SavageMessiah]

Wait, what? How does a green,ungated,nonlooping segment act as a slew? Do you put the signal in the CV input? How is it different from the yellow ungated,nonlooping? Has that always been a thing, or did I just not notice a new feature in this firmware?

[Jay]

Wait, what? How does a green,ungated,nonlooping segment act as a slew? Do you put the signal in the CV input? How is it different from the yellow ungated,nonlooping? Has that always been a thing, or did I just not notice a new feature in this firmware?

It is a thing of the alt firmware. The difference to yellow is that the pot controls the upward slew and the fader the downward slew giving you the ability for nice envelopes/ envelope follower, etc.. Plus it’s exponential slew and I think yellow is linear.

[qiemem]

I don't think it would be problematic at all to use LED oscillation speed as an indicator while you're selecting the frequency ranges for ramp segments (since we should know our segment type anyway), but a flashing color sequence (as on the scale selection) could also be used to indicate that. I thought about consistency with Tides (where slowest = green, medium = orange, red = fastest), but that would be confusing because currently green is the default range.

in any case, I think frequency ranges for ramp segments would be super useful, even if the indication is a bit weird.

Ah, to clarify, I'm more worried about something indicating that it's at such-and-such range when the module is just going, not when you're actively changing it. I have a pretty strong preference for being able to tell the state of everything in a module at a glance. That said, I already broke this for the quantization, and it's probably not as big of a deal as I think it is (especially because you can revert quickly to default state by cycling segment types). I'll play around with it when I have a chance.

ah, true, I wasn't thinking about other slew applications where you'd want to track negative voltages. I don't understand "if you set the fall to be shorter than the rise, you'll get an inverted envelope follower" - that's surely not the same thing as a bog-standard envelope follower signal that's had its polarity inverted, is it? I'll have to try it out with my Mini-Slew.

I believe it's the same as passing an inverted signal into an envelope follower, and then invert the envelope follower. So if your signal is symmetrically bipolar, it is the same. Now, of course, if you're using a rectified signal or something, obviously this won't work. Playing around, this worked quite well for pinged filters, standard waveform through a VCA, etc., but had some trouble with strumming rings. Still kinda worked though.

Anyway, I'll think about the bipolar => easier sidechaining thing.

Thanks again for the ideas!

[autopoiesis]

thanks for explaining and for considering the suggestions !

[h1ghfiv3]

I am uncertain whether or not this is answered in one of the previous 15 pages. But I wonder if the newest version of this firmware allows for two stages to be chained. I am aware that this was an issue at the beginning and wonder if it has been solved in the meantime.

[qiemem]

I am uncertain whether or not this is answered in one of the previous 15 pages. But I wonder if the newest version of this firmware allows for two stages to be chained. I am aware that this was an issue at the beginning and wonder if it has been solved in the meantime.

Hey, thanks for your interest! The official build does not support chaining, but you can find a test build that's been pretty stable for people here: https://forum.mutable-instruments.net/t ... 9?u=qiemem

I'm hoping to officially release support sometime this week. There's a few performance fixes I'm trying to get in there that are proving to be pretty tricky. Also... I live in the US, so

[h1ghfiv3]

Thanks!!

Can you possibly add this info to the original post ? I am certain that there are more people interested in precisely that question!