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

Locals/Globals vs Anything Goes


#1

Partitioned vs Fully-connected?
Scoped vs Scope-free?
Differentiated vs Undifferentiated?

I’m not even sure what to call it at this point. :thinking:

Anyway, I’m creating this thread as the new home for a sub-discussion that is occurring over in the v0.4.xx thread.


V0.4.x Firmware Workout: Goofing off never felt this hard
#2

hmm i still think a universal (chain-wise) routing system might be better than locals\globals. example:

let’s say i have a complex chain with sound sources and various processors along the way.
then i go to chain 2 , insert a mixer channel that picks up the signal from point X in the chain, i add other units and then output it to an external filter or processor, or to a different physical channel on the mixer where i set up different aux sends…

another example:

i have a chain where i build compositional tools (like my analog shift register) with s&h’s , dividers, and stuff.
i’d like to be able to go to another chain and pick up part of that control signal from chain 1, further process it and use another sound source to play it…

at this point the need for a GLOBAL system might even disappear…tho i see the elegance of having a formally and practically separated environment for signals that are meant to be global…
but on the other hand i imagine an evolution of the 301 where the outputs arent locked to the chains either, so the system becomes totally polymorphic and free… maybe too chaotic?


V0.4.x Firmware Workout: Goofing off never felt this hard
#3

Both of your examples are really the same situation in my eyes. And in both of those examples, you would move the shared stuff into a global chain (or chains). This is beneficial for two reasons:

  1. By moving the shared sections into the globals you have made your patch easier to understand (and therefore easier to debug, alter, control and so on.) You were even forced to name those shared sections. That is analogous to language syntax that encourages good coding habits.
  2. You give the ER-301 the crucial information that it needs to properly order its computations so that there can be zero delay in all the feedforward paths. “Compute this stuff in the globals first, so that the rest of my patch can use it without any unnecessary delay.”

There is a third reason but it I think it is more personal to my taste: I prefer structures that are differentiated. I actively try to avoid symmetry and featureless landscapes. So not only will you have to overcome the 2 objective reasons that I gave initially but you will also have to overcome my natural aversion to homogeneity. :smiling_imp:


#4

First of all, let me also praise the time and effort @odevices had invested in his

the scope mode is changing a lot and at the same time: solving several problems concerning the overall development of this fantastic beast of a meta module!

I seriously hope that that peri-scope-thing will eventually find its way to global chains, too. Though we can use it whenever we configure inputs of a particular global chain, we still can’t have it on the flick of a switch. and we can’t switch between global chains the way we can do this with the soft buttons of the output chains in scope mode…

the main reason i am writing to you all is because @hyena 's and @odevices ’ conversation about the celebrity deathmatch ‘universal routing system’ vs ‘local/global paradigm’ made me think. and i’d like to share those thoughts. i am also curious about further opinions…

I’d like to respectfully disagree (in part) for the following objective and/or subjective reasons: :wink:

  1. While i certainly would place the compositional tools of @hyena’s second example on the global
    level of the current 301-semantics (and this is a part where i do agree with Brian) i would not necessarily do the same in case of the first example.
  2. I might have misunderstood @hyena’s first example

But even if i place all his stuff into one global chain:
for i can’t distribute them over several global chains since within different global chains i only can access the
output of another global chain but not any arbitrary point X of another global chain. thus the problem of hyena’s first example stays structurally the same and ‘just got transfered’ to a higher level (which is not quite true, but more on that later, see 3.) And again, i might be mistaken, but it even gets worse considering
the wish to being able to take any point X of any chain and to output it to external receivers via a regular output chain. i am sure this is not a good explanation but i believe what @hyena is trying to do there is to
transfer the most intriguing benefit of cv in modular systems to the er301: though it certainly does have its limits the overwhelming benefit of modular systems to me is the mere possibility of tapping into ANY output and feeding that information into ANY input.

  1. Finally i’d like to make a weak case for Brian’s first objective reason and a pretty strong case for his second objective reason:

I truly believe that semantic categorizations in complex systems are generally good if not necessary ‘mental tools’ for developers as well as the end users for a better understanding and thus: handling of the system.
I am not sure if Brian is only refering to computer languages but it seems obvious that the same goes for ‘everyday languages’, too.
Now, less obvious is possibly the fact that only the need of some kind of a syntax is obligatory. The choice of a particular one is not. Though the possibilities are probably not limitless the choice seems rather arbitrary.

This use-theory-friendly meditation applied to Brian’s first reason means:
I am really greatfull to @odevices for giving us such elaborate tools for understanding and for using the magic inside the code. And i am happy to say that the level-switching between output chains and global chains is quite an important part of my trying to keep my s together (i.e. to easier understand and remember my patches. And the periscope on the uotput chain level of things is just another great dream that just became true! Another part of my keeping order is proper naming.)
Though i can see a lot of objective reasons that we necessarily do need some elaborate tools of understanding the patching possibilities of the er301, i can’t see any objective reason why the current state of semantic affairs should necessarily be the best one we can come up with. beware: :smiling_imp: ‘s advocate speaking! For given some universal routing system i certainly just could name whole chains or just parts of it in a way that most of us could objectively understand the right way: e.g. for output channel 3: ‘shared verb to output 3’. But even if i’m right about the arbitrariness of semantics, that would never endanger the serious implications of @odevices’ second and i believe powerfully plausible reason, which i feel strong about:

I suspected this for a long time, i even made some tests by cutting out modules from a regular (output) chain and pasted them into global chains just to see whether cpu and ram loads would climb higher (which they did).
i am pretty sure that Brian had already explained that somewhere in the guts of this forum, but didn’t care to look the corresponding threads up.
But i made the effort to look into the wiki under ‘global chains’:
http://wiki.orthogonaldevices.com/index.php/ER-301/Global_Chains
and ‘signal flow’:
http://wiki.orthogonaldevices.com/index.php/ER-301/Signal_Flow
in both cases i didn’t find a mention of that fact.
And I strongly recommend to put that information in both of those chapters.
Just because the instruction

might be quite an important information for rookies in general and for the question whether the user should place something into global chains or not in particular. This is the case at least for me and not to mention the (current) fact that (at least) the outputs of global chains are currently the only ones that can be adressed by any element in any outputchain.

last question @odevices:
(Besides your subjective reasons, which i would find quite exciting to discuss. even if they were more important than the objective ones. :zipper_mouth_face: )
Should my affirmation of your second reason of computational differentiation categorically rule out
the possibility of a “best of both worlds” solution in the future?
Please, could you encourage me to subjectively dream of some limited version of a universal routing system paired with semantic and computational differentiations concerning routing possibilities (other than in the middle layer)? Is there still hope? :anguished:


#5

Forgive me if I’ve missed some of the complexity in your post, but isn’t there a point when:

A) you need to use a different tool (or make your own)

and / or

B) we allow the maker to fulfill their vision of their own creation?

This whole discussion strikes me as taking Brian’s unusually open stance to the community a little too far.

I for one want to see this unfold from Brian’s vantage point and that is why I bought the module. No module that is useful to a large community of users will ever be able to serve all purposes - the typical usability vs flexibility thing. Thoughts anyone?


#6

Agreed! Anyway I think it’s up to Brian to decide in which discussion he takes part and what ideas he adds in whatever way to HIS code. And as far as I can see he is really listening carefully what users of his module need, wish or suggest, but he seems to have a major vision (and of course a deeper understanding of the foundation) that none of us users can have - as we do not know the code he already wrote. We just see the surface and get explanations how things work under the surface if we ask for them.

Bottom line: argue as you like, but keep listening to Brians replies. If he looses interest he will drop the thread.

Bottom line 2: any deeper arguing about basic behaviours cost a lot of precious time that could maybe be much better be invested into heavy coding of Brians own vision of the 301. :wink:


#7

absolutely!

I respectfully disagree. Though, you made me aware of the importance to make something absolutely clear:
I personally do not expect anything from Brian other than he would expect from himself! (Which corresponds to your point B)) Furthermore I consider myself a very happy customer and a really big fan of the ER-301!
So please, don’t get me wrong in this respect and i apologize if anybody had the impression that my thinking
would have anything to do with ranting or such alike. Maybe i should point out that english is not my native language which might helped develop impressions that i did not intend.

I hope you understand now why i can absolutely agree to your last point, too!

(there are several threads where Brian had to point that out himself and i am absolutely aware of it and i did not meant to take anything too far other than my own thoughts.)


#8

I don’t see any harm in discussing these things. Sometimes great ideas are born of deep discussions.

My personal take on this one: it sounds like it was completely non-trivial to get the routing options to the point that they’re at now. For me, I think they’ll be fully sufficient. Allowing cross-channel locals would basically boil down to a semantic change from a patching perspective, right? (I.e. you can easily restructure your patch to include globals to get the same net routings with a cut/paste or save/load). I do tend to agree that globals increase clarity, and if there are performance benefits, all the more reason to use them.

Meanwhile there is this list of delicious things that might someday be. I’d love to see as many of them implemented as possible, and there is but one Brian. :wink:


#9

Categorically, no. Practically, yes.

There is of course a way to automatically order the computations for minimum delay even without the locals-vs-globals partitioning. It is called topological sorting and it is already used inside units where the ER-301 allows for fully-connected graphs. However, you need to lock the entire structure that is being (topologically) sorted which stops the audio. So, a fully-connectable network implies that ALL audio would briefly stop whenever creating or breaking a connection.

With the current design, only the current sub-chain where the connection is being created or broken needs to be locked and thus have its output interrupted. I believe this is a very desirable feature because it means you can have an uninterrupted performance running on OUT1 while you are patching your heart out on OUT2.

In fact, you can have a (mostly) uninterrupted output from OUT1 while you are patching your heart on one of its sub-chains!


#10
  • one further step back from my best of both worlds approach leads to a best-of-all-worlds-approach
  • it seems that i am pro-partitioning since i’d like to keep those computationally prioritized global chains
  • going further from globals-vs-something-else i am not only wondering what that something-else might be, but also whether that decision is prone to dualities.
  • while i am wondering about reiterations of locals and also triangles of differentiation (where e.g. globals are sitting in one of the corners and something else is sitting in one of the other corners that would only stop audio on those channels that are currently interconnected while leaving other channels peacefully working. e.g.: and speaking with hyena’s first example: a beast that would stop audio ONLY on let’s say channels 1+2-instereo and channel 3 without stopping audio on e.g. some sets of compositional tools goofing off on global chains) let me ask this:

i am neither assuming that the 301 would be capable of fullfilling the requirements nor that this should be desirable for the er301 (see above), just out of curiosity:
how brief and stable would the disconnection of all audio has to be in order to begin to be ‘usefull’ for you Brian (to the rest of the family, too!) and how were things if it should be absolutely not noticeable to anybody?


#11

I’m a programmer for a living, so naming and scoping are a daily part of my life and I have opinions :slight_smile:

I think of modular synth patches and ER-301 patches as computer programs. They have different semantics from programs written in textual or graphical programming languages, but they are programs nonetheless, and I think it’s valuable to look at the parallels with other programming paradigms to get ideas about what works, where things fail, and what’s possible.

I think of chain outputs as “variables”. They don’t have to have names, since sometimes you have an anonymous connection from an output to the input of the next element in a chain, but they can have names, as in the names of custom module parameter chains or global chains. The ability to route and connect chains, beyond the trivial routing of “gozouta this one” to “gozinta the next one”, is basically a problem of name binding in a programming language: for a given name, how do you find the associated value?

A “free-for-all” kind of routing makes no distinction between variables local to a module and those global to the system. Any part of the system can access any other part of the system. While this is convenient in a lot of ways, it’s the kind of “convenient” that leads to very bad design in computer programs, because it makes it virtually impossible to isolate parts of the system from each other, which is essential if you want to build and reuse functional components. This is the equivalent of “all globals”, the BASIC approach.

Adding a basic “local / global” distinction gives you the equivalent of a “C” (language) level of isolation: you only have to worry about names that appear (1) locally (in “this” function) or (2) globally (at the program level). You can write reusable, sharable components if you want to, since you can always add parameters that can be connected to globals rather than directly referencing them.

“Lexical scoping” takes it up to the next level: elements can see names that are local to themselves, global, OR local to any element that contains them (globals aren’t really special, they are just lexically at the “top level” that every other thing is a child of). This is basically what the v0.3 name resolution had (I haven’t installed v0.4 yet, I’m ashamed to say, but it looks like it’s like v0.3 but with better navigation from the screenshots I have seen). This is like many modern programming languages (and some older ones going back to Scheme, Pascal, etc)… it’s a bit different because inserting an ER-301 unit is more like cut-n-pasting code than it is like linking it in, so “lexical” scoping on the ER-301 can have surprising behavior if you refer to chains that are in a parent. But pretty close.

I like lexical scoping because it helps me write powerful but flexible elements that I can reuse. 75%+ of my use of the ER-301 is building custom units (aka “subroutines”, “functions”, “modules”) that implement some specific behavior. I would have thought this was a pretty common workflow but maybe not.

All IMO, YMMV, etc


#12

ok i’m focusing a bit more the whole thing…
i think that one of the actual limitations is access to the OUT jacks.
example: i want to “insert” an external module in a patch, let’s say i want that beautiful sounding spring reverb followed by an analog filter on a delay feedback path.
as of now i have no opportunities to do it because if i stay on the “delay” chain i have to include everything that’s in that chain if i pick the signal from that chain’s out.
if i go to another chain i cannot access the delay out from the former chain.

so, a solution that doesn’t break the actual paradigm of locals\globals might be a way to route signals TO and not only FROM.
in my dreams i see this paired with a beautiful 8 outs dc-coupled expander :smiley: :smiley: :smiley:

(hope my not-learned-in-school broken english is comprehensible enough :smiley: )


#13

You got me!
Except I loaded your gun with blanks when you weren’t looking. :rofl:
(Haha. I feel like one of those kids playing cops and robbers.)

I agree that you might not be able to set this up deep within a software patch but the hardware patch option is still there, and in fact, actively encouraged. So please patch the feedback externally using a good ole mult on the OUTx and bring it back into an INx.

I love the physicality of the modular. In that context, creating the ER-301 was (for me) a kind of walk on the proverbial tightrope to not accidentally kill it but instead enable it. (And yes the existence of the micro-systems thread is evidence of my failure in this aspect but I’m not giving in yet!) I’m OK with the ER-301 not being able to do everything :wink: In fact, at this point it could be considered a positive.

I don’t think the distinction between routing TO and routing FROM is useful? :thinking: It still requires you to break locality.

Power for the sake of power? Are you actually Dr. Evil? :rofl:


#14

heheheheh :smiley:
well, the thing is that if i simply use a mult i’d be forced to pick everything that comes out of that chain…imagine i put filter and a reverb after a delay line, but i want to insert an external analog filter IN the feedback loop of te delay. if i had the expander and routing options, i could just insert an OUT unit, route it to X1,take signal from X1 , filter it, take signal from filter and go back into IN4…then from there the signal will go into other units, filters, reverb, a limiter…

in the actual case i’d be forced to remove extra units OR to have them in my feedback loop


#15

Oh I understand there are limitations. :wink: Did you read my reply? :thinking:


#16

eheheh of course i read it and it totally makes sense. and i repeat: i don’t want or dream the 301 to become a “do it all”, even if development stopped at 0.3 i’d be mad happy with it!!! but a man is allowed to dream ehheheh :slight_smile:
i don’t think this totally breaks locality because the chain is still confined by her boundaries…you just have access to a common outs set that is different from the hardwired set of outs that still are tied to their respective chains. fact is this pairs with my dream of an expander allowing us to use the incredible power of the 301 to create and process control signals. i still hope there will sooner or later be a dc-coupled outs expander for using my 301 as a control room for my whole rig or for parts of it.


#17

For the record, I’m pretty much neutral on the cross channel chain signal tapping. I would love to see a DC coupled output expander someday. If nothing else, it would let me route multiple internally generated low frequency signals to an external oscilloscope, which would be very handy at times in understanding.

It’s always interesting to hear about your design philosophy, Brian! For what it’s worth, I think the tightrope is wider than you think.

I would say that my patches are ER-301-centric - it’s used in every single patch as my modular to line level interface if nothing else (but usually more, of course). But outside of the demo/tutorial videos where I try not to include some other specific hardware, I would say that I almost never use the ER-301 in isolation.

There are always some intrinsic limits such as CPU, a single encoder for every parameter, 100% digital, etc.
For me the fact that just about every parameter of every unit is modulatable by an external signal strongly encourages it being part of a larger ecosystem. And of course modules that are designed to do one or a few things very well will always have a place.

Anyway, just some food for thought. Reaktor wasn’t the last piece of musical software/gear that I added to my arsenal, though it can arguably do just about anything… :wink:


#18

i agree 100%
in particular with your last line. my use of the 301 is similar to yours Joe, i use it in almost every patch and it worked perfectly as a substitute for other gear i was using live, and this is very important for me because i finally was able to do everything in one context: eurorack.
but i almost always integrate the 301 with other gear: monome ansible for sequencing, analog filters, sometimes analog vca’s , or use it to process other modules via aux sends from my mixer or directly through (insert).
i see the dc coupled expander only as a way to interact MORE with the rest of the modular, not the opposite! it will open a lot more ways of interfacing different modules!


#19

Yep, just to further the discussion a little - I have not sold a single module since receiving my ER-301 more than a year ago, though I have added some modules, and am currently looking at a case expansion.

The ER-301 ties the Euro ecosystem together nicely. I think it does allow me to be more selective about new modules and perhaps prevents some impulse buys. And of course it adds its own unique capabilities, too.

Initially the concept of an ER-301 microsystem looked appealing to me, but after more thought, I really don’t see myself going that direction. I think it’s kind of a natural part of getting something as flexible as the 301 and asking “oooh, what can I eliminate?” A few may go the microsystem route, and a few might stick with it. I’m not convinced that’ll be the long term impact of owning a 301 for the majority, though.


#20

i’ll never have a microsystem either, but i’m thinking about a live performance skiff (one row,120 hp) so i can go lightweight when i don’t need the whole assault troop