Alias Units / Chains


i have a feature request.
let me start by saying what i´m missing.
I´m missing a bigger freedom in the internal signal flow. allthough a lot is possible, some things are not, and some are a bit complicated how to do it.
i´m not sure if something like this is already in the work, but here is what i was thinking of:
Alias Units/chains.

It would be great if you could do an alias of any chain or unit.

the alias would be the same as the original (of course), and if you change it, the riginal and all the other aliases are changed, too.
thus, you could create a sine osc in a chain for instance, and use it to modulate a lot of other parameters within a chain or a custom unit for examples, but have the parameters linked ontop the custom unit.

in the end this is the same as having multiples or stackables in the modular world.
Of course i heard of the global chains and used them.
but to make an alias on the fly of a unit or a chain and use it elsewhere in the chain would be much more intuitiv.
PLUS with the global chains its not possible to use the parameters of a global chain in the custom unit.

You would create an alias, and after that this alias can be found in the unit list where you insert the units. But of course under a alias tab.

this seems to me the easiest way to have a real freedom in the signal flow in the er 301…

something like this in the works already? @odevices

and by the way, as this is one of my first posts, let me say that the er301 is really great! i like it very much. i just would like to have even more freedom:-)


There has been talk of this before but I can’t find the thread at the moment.

I think the consensus was that it’s generally better to have the restriction in place because it makes it much easier to follow the signal flow and with a little thought there really are no restrictions at all with the current methodology. It does take a little thinking about, but I am struggling to think of some routing problem that could not be solved already.

There is a discussion on replacing global chains with global parameters, so this may be more along the lines of the kind of thinking you are looking for, but again, my search foo is obviously off tonight… I am tired… it’s been a busy weekend :slight_smile:

I highly recommend checking out @NeilParfitt’s mixer sends patch as it shows the kind of thing that can be done with a little imagination:

Without trying to down-vote your feature request in any way, for right now, if you want to do this you can.

  1. Select your whole chain using the shift key and encoder
  2. “Cut” the chain
  3. Create a new global chain and “paste” that chain into it
  4. Then use that global chain in multiple destinations, as your “alias”
  5. Modify the global chain going forward, and every place you are using it will update too

Since you mentioned it was one of your first posts, just wanted to make sure you knew you can do this. Might not be exactly what you’re after, but copy/cut/paste to a global chain allows you to very quickly make a signal that you can route to multiple destinations.

I think the penny has just dropped for me on what Global Parameters will be - Global Chain outputs exposed in Custom Units in the same way as Local Parameters - that would be immensely useful if that’s the case!

If that’s not the case can I make that a feature request please :smiley:

edit: I’ve just realised this is already possible, route the output of your Global Chain to the input of the Local Parameter :blush:

No idea why I didn’t think of that before - but definitely going to be using that technique!


Yep! The black hole!


This reads to me that it could be like a mixer bus send. If you could insert a unit to send signal to a global chain and return it? Or maybe you could send some signal, without worrying about returning it to the same chain? You can sort of rig this up with global chains, but only at the beginning or end it sounds like.

What would be pretty awesome, is if you could send the output of a chain to a global chain input!

thanks for all the answers! maybe i should have started a thread first by asking how i could achieve what i want…:slight_smile: but i was pretty sure its not doable. or maybe its too complicated and it could be done much easier! but i´m here to learn:-)

so, what i don´t see how i could manage: to have parameters from a global chain in a custom unit.

So for example, lets say i have two sine osc in a chain. i´ll call them “osc a” and “osc b”. i want to listen to both of them (i would put them in a mixer channel.) but also i would like to be able to fm “osc a” with “osc b”. and third, i want to have them both in a custom unit as i would like to have several paramteres of these osc linked on the custom unit front. (hope you know what i mean:-))

i could make osc b a global chain, but i would not be able to have the parameters of this osc linked to the custom unit. (like “feedback” for example…)

and there was my thinking, that if i had an “alias” from osc b, i could put it in the fm mod from osc b and leave it in the mixer as well.
of course i could take a thitd osc that is the same as “osc b”, but i want to hear my treatening of osc b on the output but as well as in the fm input of osc a…

so, i think this is pretty basic… and most likely i just oversaw something here…
but to have there an easy solution would be great!

Something like this was brought up earlier this year. I think it was Neil and his Send/Return units. I’m still evaluating their impact (which is quite substantial) as well as a parallel idea which I’m calling topological units. Some examples are:

For example, under the topological unit paradigm feedback would be implemented like this:


alright, so this would be a way to implement feedback? or would it have other possibilitys, too?

in my question i´m not really looking for making feedbacks, but to use units outs more than one time, but in a custom unit… so no global chain… but see above where i try to describe it with better words:-)

A feedback unit is just one example of “re-using a unit’s output”. I’m mentioning it again here because this was how the overall subject was brought up first.

Here is a puzzle question: I make an alias from osc B (referring to @Evs’s example). Should it be visible everywhere (i.e. global) or should its scope me limited? If limited scope then what is the scope?

@odevices you mean if it should be visible just on one track or globally?
i would suggest global. like a global chain. and you access it from the unit screen where all units are. (but in a different tab…)
don´t know if this is possible…

also, i just realised i just been thinking of oscillators. there its easy. but when you have a unit that needs an input, theres the other question if an alias of such a chain or unit should carry its input.
and i would say no. there it should be different to a multiple. everything (also the mod inputs) in the alias is the same as the master, except for the input.
in this case you would end up that all the aliases from one alias chain could process different inputs independly, but all the mod inputs and parameters would be exactly the same.
there we clearly left the borders of a modular synth and extend it…

1 Like

ok, i now get what you mean with the question if we see it on a scope…

i would say, no, you don´t see an alias on a scope.
even if you would say that an alias carries its input, it just is in the alias list… and with a command you could go to the master maybe?

Once something is globally available, you have a potential name clashing problem (i.e. how do I indicate to the user which alias of a unit he is utilizing?) And there is ambiguity around what to include when saving unit or chain presets. So not impossible but lots of hurdles to consider.

These are great ideas, @Evs. I’ll have to think long and hard before I would embark in this direction because I can tell there would be a substantial GUI re-design involved. Perhaps if you show-cased some prototypical use case(s) then it would be easier to reason about?

One other thing: I can’t shake the feeling that at some point this “paradigm-breaking” routing is done better in a text editor as opposed to on the ER-301’s tiny GUI. This is something that hasn’t been talked about much yet but each unit is actually an arbitrary network of objects. It is only the unit layer where signal flow has restrictions (mainly due to GUI complexities). A unit is an arbitrary network of signal processing ‘objects’ with key parts of this network mapped to parameters that are exposed in the unit’s GUI (similar to Pd or MSP). Units are described in the Lua scripting language, with the idea that a user can also create his own units with almost no restriction on (internal) routing but without having to code and compile C++.

1 Like

Sorry. I don’t mean scope as oscilloscope but rather name resolution scope (i.e. what parts of the patch have access to the alias that you created). You had it right the first time I believe.

@odevices i´m not sure how this is achieved “behind the doors”, but for the user one alias would be enough. you could use this one alias as many times as you like. if i have a unit/chain that is called “osc” than the alias would be called “osc alias”.
if the alias is not carying its inputs that could be possible maybe?
(if an alias does not carry its input, it would also mean that an alias is just the information what is happening to its parameters, and which parameters get modulated by what and what is the chain. so its like a “shell”.)

but i would guess that this is not possible,
so the other thing would be that you make an alias. say from the named “osc.” than in the unit list under the tab “aliases” you would have, after creating it, a unit called “osc_001 allias”.
the moment you put it in a chain its called “osc_001 alias_001”, the next “osc_001 alias_002” and so on.
automatically of course.
the _001 behind the osc would be to guarantee that if you have two chains or units that are called “osc”, that you can be sure that you have unique names for the aliases.
to know which alias fits to which master you would have to go the the menu by tapping on the alias (the place where you normaly save a chain or load it), and there you could have the option to “go to master”…

keep in mind, the normal units/chains do not have to have unique names. just the aliases needed to have those.

good point, have to come up with more uses.
i think one of the main advantage would be that it would be more intuitive if you decide, while “patching” in the er301, to have one unit or chain in multiple occasions. of course you could put it in a global chain, but than again, you loose the abbility to put the parameters from that stuff in the global chain into a custom unit.
and its more intuitive to not go away into the admin area and just have it all there…

the other use, as an example, why i came to this, is that i wanted to build a harmonic oscillator, where the different harmonic outputs would be internally normalised to fm each other.
which harmonic fms which would need to be decided, but the patch points on the er301 would be linked to vcas to open the fming.
of course you can build this right now, too. but than just the base and three harmonics are doable, as you need single outputs. (to patch than from one track to the other…)

with aliases i would put up, lets say 8 oscillators. all the socillators would be also an alias. the master files would stay in a mixer. and the 8 aliases of these would stay in the mod fm input of each other master oscs.
now, this is possible right now so far with global chains.
one step further, i would like to put all these 8 oscillators into a custom unit, to have several control options linked to the front. and thats where we are, you can not have global chain parameters linked to a custom unit on a track.
and also, i think using aliases this way could be more intuitiv. maybe:-)

i get what you mean, but i think that in the end this would enable the user for far more complex stuff, but achieved in a much easier way…

Just wanted to bump this, and if a solution is not in sight, how would you people approach the described problem?

I use custom units all the time, and put any process i’ll need duplicates of in custom fader controls. Then that data can be accessed via locals anywhere in the unit. And, you can assign the input of a custom control to a local or even another custom control, so there’s tons of potential for eliminating redundancy in a complex patch.

I just want to re-iterate that in my mind this discussion is still open and no decision has been made yet about the future of internal routing. I understand @Evs suggestions and they will be considered as I flesh out the next round of changes to the routing architecture. However, I can say that any substantial changes in the routing architecture will probably have to wait until v0.4.x. :smile_cat: