Stages


#1

Congratulations, looks like a great module!

Is there any reason that you settled on six segments? To make it more than an ADSR but not too wide (e.g. eight segments)?

Will a chaining cable be included with each module? Is there really a practical limit to the number of chained units (described as six)? What data is sent over the link?


#2

The first mockups have been done for 4 segments but the flexibility of the module would have been hard to appreciate with so few segments. It needed to be at least as good as Peaks.

8 segments would have been a better use of the hardware (there are 4-channel and 8-channel DACs, but no 6-channel DACs… so 2 channels are wasted in Stages!). But 8 segments require 18 or 20-HP and that was too big. For something unique like Marbles, maybe… but for something that is needed in any rack, that was too much. Plus I really like 14 (Tides, Rings…).

Yes.

Adding more units brought the total RAM use too close to the limit. Also the more modules you had, the less responsive to CVs it becomes (because the CV information has to be propagated throughout the chain) - for example if you create a 36 stage envelope and modulate the sustain time on the 35th segment on the last module… This information has to be propagated to the first module!

  struct LeftToRightPacket {
    uint8_t last_patched_channel;
    int8_t segment;
    float phase;
    Loop last_loop;
    ChannelBitmask switch_pressed[kMaxChainSize];
    ChannelBitmask input_patched[kMaxChainSize];
  };
  
  struct RightToLeftPacket {
    ChannelState channel[kNumChannels];
  };
  
  enum Request {
    REQUEST_NONE,
    REQUEST_SET_SEGMENT_TYPE = 0xfe,
    REQUEST_SET_LOOP = 0xff
  };
  
  struct RequestPacket {
    uint8_t request;
    uint8_t argument[4];
  };
  
  struct DiscoveryPacket {
    uint32_t key;
    uint8_t counter;
  };
  
  union Packet {
    RightToLeftPacket to_left;
    LeftToRightPacket to_right;
    DiscoveryPacket discovery;
    RequestPacket request;
    uint8_t bytes[kPacketSize];
  };

To sum up:

  • Information about which inputs have signals patched into them.
  • Current active segment and envelope phase (if an envelope spans two modules, the module on the left is in charge of generating it, but the module on the right must still generate the segment activity signals for its 6 outputs).
  • Loop points.
  • Information about which switches are pressed (to handle the creation of a loop spanning several modules).
  • Channel state (position of the pot, of the slider, value of the CV input).
  • Notifications that the user is trying to perform some action, so that it can be vetted by a module (eg: trying to create a loop between module 1 and 3 while there’s a jack patched in module 2).
  • Neighbor discovery messages (when the module is powered on, it searches for neighbors).

#3

Agreed that 12HP is a good size. For people to really push the envelope (pun intended), it means many racks will contain two or more. :slight_smile:

What you say makes perfect sense about chaining. I would have guessed that the CV processing tasks could have been handled by the host module though? I.e. if you have a 36-channel EG, does module #1 really care what segment 33 on module #6 is doing (notwithstanding creating loop points etc.)?


#4

Yeah, but creation of loop points is withstanding… and thus the head needs to know what the tail is doing, and v-v, all in real-time.


#5

If you build a 36-segment EG (only one jack in gate input #1 and nothing else), the signal is output by segment #1 on module #1. So if the active segment is 33 on module #6, the signal will still be output on segment #1 on module #1. Module #1 needs to get all the pot/slider/CV information from the rest of the chain.


#6

Of course! :sweat_smile:


#7

I’m trying to get my head around something.

Combined with Shades, this module takes up the same width as Maths. As a pair, Stages and Shades offer complex envelopes and LFO’s, as well as CV mixing, attenuating/inverting and offsetting. That covers a lot of Maths ground, at least for my purposes, but I can’t quite grasp to what extent their features overlap.

In other words, if you were to replace Maths with Stages and Shades, what would you lose? :thinking:

Cycle on/off CV control, I guess? There are probably lots of exotic Maths patchings I’m overlooking right now, but then again, I’m sure Stages can be patched in all kinds of crazy ways too.

What you would gain, of course, is the step sequencing functions, probably a lot of other stuff too, and above all an incredibly elegant and intuitive interface – reading the Stages manual is an absolute joy. I have to say it’s a tempting proposition…


#8

don’t forget about slewing


#9

Right! According to the Stages info page, a single segment set to “Step” can slew an incoming CV signal. But unlike with Maths, I don’t see a way to set different slew times for rise and fall.

Fascinating how differently Stages and Maths approach things, interface-wise.


#10

Oh yeah, I forgot about that. I guess it’s the different approaches that make the multitude of modules make sense and the racks grow big.


#11

Am I making things up, or did I read somewhere that the voltage delay per channel work as a lofi delay for processing audio? Can someone with a module post an example?


#12

I think it’s not delay like echo, but it’d be the same as the envelope if there’s a delay to it. Have you watched the DivKid video? Has a good example as to how audio processing sounds.


#13

It’s a delay without feedback, though you could patch it and/or mix it with the original.

As the delay time increases, it samples less frequently and then smooths the output to compensate. It will also clip as you turn up the slider and add a DC offset.

Here’s some playing with white noise -> Rings -> Stages delay with feedback patched using a stackable and 3xMIA.


#14

speaking of audio applications:

in looped green mode, each segment of stages can also be used as a simple vco. it does go into audio range, and the ‘time’ cv input (which in looped green mode, is really a frequency cv input) does track v/oct.

so 1x stages + 1x ripples can be used as a complete synth voice: one stages segment is the vco, the others can be configured as egs and lfos to modulate ripples’s filter and vca…


#15

Wow this is amazing, i wasnt aware of the audio tricks.
I guess it also features the predicitive pattern-locking clock sync like all other MI clock inputs?


#16

Yes.


#17

I’ve been familiarizing myself with Stages’ functionalities the last few days (via manual) and wanted to make sure I understand the individual segment output behaviors in a multi-stage segment.

When creating a multi-stage segment, the first output is always the envelope. Got it.

Then, the remaining outputs in that segment group only output a falling ramp (8v-0v) when that segment is reached? Is this the same regardless of the segment mode?

I.E. Even a hold stage only outputs a falling ramp on its respective segment output? Not a “held” voltage?

If so, does a looping segment then simply loop that falling ramp until it moves to the next segment (assuming there is one)?


#18

Yes

Yes

Basically, the falling ramp represents how much time is left in this segment before continuing.


#19

Got it! That’s great. Already conjuring up some juicy patch ideas.

Safe to assume these are already on their way to retailers? :star_struck:


#20

Shipping about 77 a day, so it’ll take 8 more working days to ship everything.