(I completely disagree with your point but adore that you’re being so detailed in revealing your thought process.)
I personally prefer the way it works now. If I want to pass audio through, or along with, an osc I already can with a mixer unit. This seems aimed at “fixing” a non-existent problem.
perfectly expressed,i feel the same
There are two problems I see being discussed:
- Does signal mix/process/rejection on a unit need a visual indication?
- Should units behave differently than now?
Algorithms are a funny business. They are descriptions of problem spaces designed to be inflated with observations of a particular instance of this problem. Provide too many assumption about the problem space, and you wind up with a tool that is narrowly designed to a particular problem instance; go in with less assumptions, and make the user spend more time specifying the parameters, you risk winding up a with a floppy tool that is the right shape for none of the problems it is applied to.
I think that is the crux of this discussion–modular is deigned for the latter philosophy but in actual practice most of the tools end up looking like the former (e.g. Brian has specified that ER-301 should be considered a bring-your-own-controller module).
I think the oscillator as a mixer or processor idea errs a little towards the overly extensible tool category. Moreover, I think as you point out, Brian has already solved that particular problem with the scope/routing mode.
I still think that better indication would be a nice conceptual affordance for newbs.
Idea space analog:
I’d add an invisible dot, so those who want an indication will simply know there’s a dot somewhere, and those who don’t care won’t see it.
(i am merely trying not to be a unit that blocks its inputs)
i am absolutely with all of you trying to improve visual representation
of current units, including especially the mixer channels. i am not trying to disrupt
though i am absolutely not trying to think about an overly extensive tool here at all
i am pretty much aware of the possibility, that going down that foxhole you might
end up with more problems than before.
but before i would and could make an informed choice i’ll have to try to understand
all available possibilities. (i want to see the fox into his eyes before i will delve into
a priori condemnations of his stench (do foxes stink?)) think about it: where
would we and our beloved er301s be if Brian and others would have fully embraced the
back inside the foxhole again.
My curiousity at this point actually stems from a practical (i.e. a posteriori) perspective
on several real world problems, here’s one of them:
- working with the 301 i always found the concept of ‘mixer channels’ confusing.
due to my education mixer channels only make sense to me inside
a mixing console where several channels are summed together into master
and aux and other busses. (not complaining about the unit here. just about
the choice of term. and alternative terms had been discussed several times)
visually, an output chain containing only mixer channels makes totaly sense
to me. i consider the chain as a summing mixer. and even if i put some processors
into it it seems fairly obvious to me that the processor would process the output
of the unit left to it but not the output of the unit right to it. the left to right ‘flow’
at least of the visual representation still makes sense, with processors put inbetween
mixer channels being insert FXs for the units to the left and processors at the
end of the chain being master FX for the chain.
but this one still strikes me as an inconsistency, rather than a possibility
and it does not make sense to me until the generator is not killing the input left
i never had any use for such a setup and i’m obviously blocking my personal inputs
here.(help me out!) let’s see. now we can route the output of that mixer channel to parameters of the osc e.g.,
so i could set up a modulation source at the level of the generator and i won’t have to dive into
the osc to tweak the mod source. i could then move the osc to a mixer at anytime, but then the mod source
isn’t blocked anymore… if anybody knows an interesting use case, where a unit is fruitfully blocking
the flow from the left, please let me/us know.
until then Brians other idea to solve the graphics seems rather elegant to me:
i feel the ambivalence in the idea space. and i don’t want to waste your precious time.
but i am really trying hard to avoid mixer channels for quite some time. fortunately, beginning with one of the
awesome x-band units in an output chain is more than just a fresh breeze to me.
as @leverkusen had pointed out i will still need mixer channels on units that don’t have their own input
assignments and as @Joe pointed out: when i’d like to use solo functions on the mixerchain,
maybe i could emulate those in the x-band containers.
does anybody has an idea (a priori) or even better some experience (a posteriori) with
solo functions in x-band containers?
i just can’t get behind those mixer channels!
now i can…
Rather than play with the interface at build-time or run-time, how about a “debug” step that shows your patch and highlights any blocks? That way the only time you need to look at weird UI artifacts is when you explicitly ask the 301 to show them to you. Think of it as a QA step on your configuration.
I offer this as someone with a still-rudimentary understanding of the 301 but a 30+ years of experience building commercial software.
This “debug” step could also highlight places where you’re CPU intensive, something that might be helpful.
I can only speak for myself but on the ER-301 I’m always in programming/debug mode!
Performance mode is when I plug in external vc/controllers.