Home | ER-101 | ER-102 | ER-301 | Wiki | Contact

Units that block their inputs


Pretty clever idea! Doesn’t take any UI real estate. But the thicker line is more intuitive. Even new users could figure that one out without reading the manual (wiki).


I am afraid as a new user I would wonder why the graphics are not consistent and some lines are too thick.

I have not thought about all possible units now but I also wonder if there really is some kind of inconsistency that needs to be fixed. From a logical point of view at least the examples seem clear to me. You normally would not feed a signal into an oscillator because it is a signal generator. You rather would modulate its modifiers/controls, even with audio rate signals. You would also do this with a filter or an effect unit but in most cases it only makes sense if you insert a signal first. I think the only thing where I always have to think against my intuition are envelope units when I tend to try to open the gate sub chain, which is not. I like the mixer channel paradigm as it seems to be logical consistent to me and makes it easy to understand a patch from a glance at it, even more now that we have scope view. I am afraid of inconsistencies here when you have the opportunity to switch e.g. an oscillators input behavior but can not see to which control parameter the input is going to at a glance. Signals should get mixed with mixer, just chaining them feels like mixing with stackables to me…


How about on units that don’t pass through the outline of the unit on the left side has square corners instead of rounded corners?



Quick and dirty mockup. It’s subtle, but could be applied in both regular view and scope.


The thick line idea seems best of what’s posted, but even that doesn’t seem intuitive. Better would be a help system where pressing a shortcut would popup a brief description of a highlighted unit, that explicitly says if the unit passes signal or not.




Thanks for the recipe joe I will definitely use it for now. Maybe what I’m really requesting is a sin function (and perhaps more math functions) similar to the sample scanner or bump scanner which requires an upstream phasor input (signal processors?). That would keep the consistency between generators vs processors?

Perhaps an explicit unit that could tap the signal in a chain (upstream) to be fed forward to any control? I know you can do this on occasion within a custom unit (made easy with scope view), but before units after INx?


I agree that the thick line is the most intuitive for me, but that is because I know the extant signal flow. It may not be so intuitive for new users as @leverkusen says.


It’s true in an absolute sense, but let’s benefit from some context - i don’t think that the 301 will hold the attention of those that don’t have some synthesis theory knowledge, so we don’t necessarily need to cater for all use cases here.

I think something that is a subtle visual reminder that remains either an (irrelevant?) mystery or goes unnoticed is doing it’s job. I don’t see someone halting their patching because of an asymmetrical line thickness - or if it does, I’d expect they’d be able to learn and appreciate why it’s there with nominal effort.

I know that design often has to cater for a novice audience but don’t feel that’s the case here.


well, i thought about the whole topic the last two days and i think it is not necessary.
first: it’s always interesting to figure out things by yourself.
second: it is pretty intuitive if you know your way around basic synthesis to guess which unit will pass and which will not.
also, this leads the user to think laterally (example: i discover that the sine osc , or any other osc, cannot be used to process incoming audio as processors do, well i go into the phase modulation control and assign the local output from a sampler, or one of the physical inputs, set the gain and see what happens!)
i’m really afraid that any of the suggested solutions would break the wonderful consistency and coherence of the 301 UI.

please , let it as it is!


That about sums it up for me!


I think that visual representation of state continually reinforced is a good design heuristic. After thinking about it further, I think the addition of a single line to the left, top and right would be a great way to signal flow potential without eating too much screen real estate/attention, while still signaling the reject, passthrough, or mix-to states. A further refinement would be an addition of a bottom line indicating that there are modulation inputs located underneath the unit. Good wayfinding/indicating.

This is all from my passionate user advocate hat. As you were, friends.


totally respect your vision, even if i don’t share it :smiley:


What about… instead of lines and such…

Right now the header BG colour is a (guessing 30%) transparent yellow. What if all generator style units had a solid header such as yellow will black text.

Then again, I honestly don’t feel like any of this needs to be made a deal of as we’ve made it this far without anything! :slight_smile:

  • “better is good”
  • i am wondering whether this whole

issue and its corresponding user-sexperience should deserve
its own thread

  • Brian`s idea of all units mixing their outputs with their inputs strikes me as being worth
    to be investigated further

some notes:

  • would each unit need a wet/dry parameter?
  • if so: global settings: wet/dry default settings for
    generators (LFO, VCO, Envelopes and such): 100:0
    fully wet processors (filter, VCA, etc.): 0:100
    comb processors (reverb, chorus, mixer): 42:58
  • i’m not a big fan of too-many-shortcuts. but:
    when focusing any unit header, how do we cramp all the following
    functions into/onto to unit header?
  • the s-button functions, i.e. bypass/delete/replace
    (could be reached via shift+s-button?)
  • mixer functions, i.e. dry/wet, input and pan
  • input functions, i.e. assignment, solo and mute


i like the idea of visual representation of states via rounded/ straight corners.

  • how about indented roundings on the left side of an input accepting state? (puzzle)
  • round corners for chain headers, too?


Hard corners was one of the first things I tried (see my first post). However, it was too subtle and cryptic, not to mention confusing because hard corners are already used on the inner side of chain headers and footers to denote encapsulation.


I am not sure if I get the point of this - what would be the benefit of not using a mixer channel but building a long queue of units?

Also an oscillator with a wet/dry control might provoke additional confusion. Sure, you could just chain three oscillators then to get your moog sound going, but I would vote for staying within the modular patch paradigm and use a mixer for this as you would do on a modular synthesizer. It is what makes the ER-301 so intuitive to use. Plus, I don’t find mixing several sound sources with all their own wet/dry controls very practical. Let alone the additional control fader each module would need then.


I’m pretty ambivalent about the idea myself. I put it out there mainly to widen the focus a bit just in case an interesting solution is nearby in “idea space”.


main reason would be what Brian had pointed out:

i might have misunderstood something, but i am having the impression that using mixer units
do not actually prevent us from building “long queues” in the ui

you might be right, but i certainly hope you’re not :wink: let me give you some
i am a suxxer for selfoscillating filters. its pretty rare that i (mis)use them
as mere generators (i.e. without any audio input) the main reason i love them so much
is that i can mix an audio input with those selfoscillations of the filter.

  • now, in the case of the great sounding SARA filter from dinsync i have to add a
    module that attenuates the incoming audio signal. since SARA does not have
    a knob for input level.
  • on the first version of the corgasmatron on the other hand there is this awesome
    input gain knob. granted, that gain stage is special but i am pretty happy to have it,
    so i can mix filter tones with filtered tones.
  • my first audio (exp) vca was a doepfer standard, which has 2 audio inputs with
    corresponding level controls. and that mixer in a vca is the very reason i never sold that
  • most of the oscillators i know do have inputs. no matter how those input jacks are labeled,
    you can and should try to feed audio signals into them. (be aware of the accepted voltage range, though)

a rather general observation:

  • there seem to be several and different ‘modular patch paradigms’ out there.
  • some of them seem to be strickter than others, each of them results in certain
    restrictions as well as possibilities presented to the artist.
  • i AM a big fan of restrictions in artistic processes. i’d even say that
    restrictions/selections are necessary conditions for artworks.
  • though i’d rather prefer selfimposed restrictions

in modular space you can choose to (mainly) build a system
where signals flow from left to right
for instance @rdevine1 explained such a choice for one
of his live setups:

you can make this kind of choices pragmatically, arbitrary
or even almost religiously (east coast /west coast anybody?)

in case of the er301 the seemingly left-to-right signal flow in the ui seems to be unavoidable
due to the given size of the machine. but since custom controls
on every unit (!) and the

we’ve gotten pretty close to the infinite possibilities of a rather minimalistic modular patching approach: it’s all about voltage and its control.
(in my case it evolved into loosely nested star patterns
that i can easily break up when i want a certain many-to-many connection…)

more to the point (er301):
lining up mixer units in long queues is what we are doing so far ui-wise.
and it does actually help, in my opinion. but it does not remind me of a modular synth.
it reminds me of mixing consoles, though. and giving up mixer units wouldn’t and
shouldn’t confuse me at all:
i could certainly live with directly inserting VCAs that have Input assignment.
or any other unit, as long as it incorporates the functions of the current
mixer unit.

main points being:

  1. rather than having to insert mixer channels first: we could go straight ahead
    and insert the unit we would have placed in a given mixer unit in the first place.
    it seems to me that we could save time and button presses. it might even flatten
    the ui structure…
  2. i am just trying to underscore what Joe had already pointed out:

now, that i am getting used to the new custom controls, x-band containers
and the new source selection ui: i don’t even think that incorporating mixer-unit functions
in every unit would be such a drastic change in what and how we are doing so far.

@Brian (and others, too): any idea how mixer-unit functions in all units
would change scripting and overall performance?