Units and the potential for additional outputs

I’m thinking aloud again. Uhoh.

So far, units almost have unlimited input control potential, but have a single output signal.

What if a unit had its main output as we’re used to now, but additional utility output signals that would dynamically show up in the source list (if the unit catered to such a need). In the same idea with how the custom controls show up now as locals, instead these would be globally available like the audio outs.

With something like the above in place, I’m imagining being able to open up a unit, choose a controllable parameter and then be able to grab these utility signals from anywhere in the system such as ie:

-assign an EOD trigger from an ADSR envelope
-assign a trigger from a sample player when it cycles
-assign a trigger from a sample player when the Alice is changed
-assign a trigger from when a mixer channel is muted/unmuted

The possibilities could be really exciting!


yes! please

I think this is analogous to the idea I had for synthesizing the “master/slave” dichotomy. I really like the idea of off- chain accessible internal trigger events.

Yes, definitely, but the problem here I can see is the vast potential for feedback loops - squeal!!!

I’ve already managed it a few times with the current set up before I realised what I was doing!

How to manage this?


edit: how about an output unit, perhaps similar in configuration to the custom unit inputs?

This would necessitate thinking about how you wanted to route things before creating the additional output, with the convention of values zeroed out, feedback would be as rare as with any other system I think!

1 Like

I was thinking these additional outputs would not be the audio, but additional trigger information if the unit had a use to send such info. So I don’t see how that would cause an immediate feedback scenarious

No I guess not :slight_smile:

I was thinking more audio stuff as I have wanted to do this a few times now, mostly send/return loops!

I was also trying to imagine navigating what could end up being an awful lot of inputs and separating the internal output interface from the main unit and making it entirely optional makes sense to me. But hey, I am not writing the code or anything so this is all just speculation :smiley:

1 Like

Yeah, that was my thought re: master/slave, is that way to facilitate both the looping and one-shot playback is to have the end-of-slice make a trigger which would have variable functions (reverse playback, start playback over, stop). If it could be routed to other units, that’d give you some sweet mini-sequence potential. (e.g. I use the end of attack, decay, and release trigger outputs on the ADSR Jr. expander module to trigger additional envelopes often–sometimes triggering envelopes that themselves have EOC [i.e. Maths].)

Maybe these could show up in the ‘sources’ scope screen, off to the right beyond the outputs… in some sorta folder hierarchy that follows the units and subchains. I was dreaming of something such as below:


paroxysms of potential

this seems like the send/receive unit idea that we proposed Neil, and that Brian had on his “to do” list

                   | \
                   | |
                   | |

|\ | |
/, ~\ / /
X `-…-------./ /
~-. ~ ~ | definitely
\ / |
\ /_ _\ /
| /\ ~~~~~ \ |
| | \ || |
| |\ \ || )
/ (
/ ((_/

reported but not confirmed crashes

  • deleting slices while slice sidebar open

confirmed crashes

  • quicksave folder corruption
  • CPU overload
    – loading a 48kHz preset into 96kHz firmware can overload CPU
    – show projected CPU/mem usage for presets/quicksaves
  • out of memory causes crash instead of warning


  • sample pool silently fails when loading sample that doesn’t fit in memory
  • after 24-hours or more, playback glitches
  • VARIABLE DELAY slewing when modulated
  • bouncing cursor does not match selected spot sometimes
  • G inputs bleed into next channel

cosmetic bugs

  • gainbias control subdisplay label position needs to adapt to text length
  • scope traces draw outside of border


  • do not create/start a subchain until it is needed
  • use promise design pattern for async processing in lua

- bus units: SEND and RETURN

I see what Tom is saying: You could for example but a SEND unit at the end of a PLAYER’s trig chain.
I also see what Neil is saying: Some kind of event system that let’s you derive triggers from changes in a unit’s internal state.