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

Request: Make Bypass modulatable

request

#1

Not sure if anyone else has suggested this. If module Bypass reduces CPU utilization, being able to modulate it would come in quite handy to manage CPU hungry presets (like Yamaha style FM algs). Thoughts?


#2

As far as I have picked up from the forum, bypass does not actually reduce CPU utilization, just sort of mutes it in the chain. Or am I mistaken?


#3

I think there is a setting in the admin area to choose between bypass reducing CPU or not.
Even as a simple mute, a modulatable bypass could be useful indeed.


#4

O yeah, I actually read that topic :slight_smile: Thanks for jogging my memory


#5

i don’t see how this would be a practical thing to modulate if was in “bypass = disabled” mode. If it’s disabled, it’s fully dis-engaged and i’m sure they’d be a processing delay to kick it back into gear… would that not cause instability and erratic spikes in CPU usage? Especially if you were slamming it with really fast CV…


#6

:fearful: Sounds like a recipe for disaster indeed


#7

I think they OP may have meant modulatable in the sense of being able to be controlled with a signal, but not necessarily at audio rates. Then expensive sub-chains could be “resident” on the ER-301, and switched on or off as needed over the course of a piece.


#8

Agreed @miminashi Being able to to disable temporarily unneeded “resident” units and sub-chains is central to effective CPU mgmt. Without it, the ER won’t be able to scale up to any degree.

@NeilParfitt do you think that being able to handle high (i.e. audio) rate modulation a prerequisite for inclusion in the ER-301?


#9

That’s not up to me, but, up to now anything you can assign a subchain to systemwide can take whatever your throw at it… so there’s a consistency.


#10

Haha. That is a bit of an understatement considering it isn’t that hard to load quicksaves. :wink:

It does seem like there is pressure to introduce “program changes” into the modular context. I must admit I’m a bit wary of this direction but since there are plans to introduce a CV/gate controlled command bus anyways, I suppose it would be obstinate to not include bypass and quicksave load commands. I wouldn’t call that “modulatable” though.

Also, I would like to say that this kind of request makes me feel like I’m losing touch with my customer base a bit. :scream: Which means I need to do more research.


#11

I don’t really have a dog in this fight, I was just hoping to clarify what @scott.lepore was getting at (for my good deed of the day).


#12

Also not really interested in this - I am much more interested in the hold mode!


#13

I mostly try to keep my irritation about the growing demand for presets and digital-behind-the-panel-connectivity for myself for the sake of not sounding negative.

My feeling is that people should get themselves a nice midi controller and dive into computer music if they don’t like patching modular synthesizers - but maybe it’s just me, who is a but old fashioned and should get into Serge instead?:thinking:

Anyway, of course I can see what might be useful here, it just would make everything feel more complicated to me if I were to program a dedicated preset module with bypass and quicksave messages at the right time. So I probably would not use.

Just to word another individual customer opinion: I am quite happy with the way the ER-301 has made by now, its philosophy and how it evolved. The only thing I might wish for ist even more interesting ways to work with recorded or live audio and internal event routing.

:+1:


#14

I’ve loaded quicksaves live and can definitely see where these requests are coming from. But since it can’t be done in sync in any case, as presets take time to load, I don’t see the benefit of CV control. I’d rather see development efforts directed elsewhere. Not that anyone asked for my take! :slight_smile:


#15

Yeah, I agree with this - I’ve used the ER301 live multiple times for 35-50 minute sets and I really can’t see this being a benefit - not least you’d need another sequencer to control the program changes and I’ve already got two ER101/102s … seems a bit overkill to me. Plus I see the hold mode covering a lot of the potential use cases being described above.
I’m waiting patiently for the feedback & cross-fade units that will really open up audio processing/mangling without the need of ellaborate routing via global chains etc


#16

I find the resistance to this idea rather puzzling. Seems like a feature that could be implemented almost for free, and could help get more mileage out of the 301’s finite capacity by allowing the user to manage patch complexity dynamically.

I think people may be getting hung up on the term “modulation” and thinking that it is to achieve an audible effect, when it’s really more about resource management.


#17

Could you outline a specific use case you have in mind that would open up the ER301 even more with having either CV control of loading chains or bypassing units? It may make it easier for others to see the benefits that can’t be already achieved through some other method e.g. gated VCAs closing audio outs from one unit and another, or manual loading etc
We might be able to offer some suggestions to implement your idea with the existing broad set of tools in the ER301.

Do you also have any thoughts on what would be a good CV source to perform the desired modulation? I’d speculate you’d need something like a precision adder but with more finer increments that could be used as a unit/chain selector (what the user interface inside the ER301 would look like is not clear).

I think the comment made earlier about loading lag is a genuine concern - I certainly wouldn’t expect a tight seemless transition if the unit/chain was CPU heavy, some of my performance chains can easily take 5 seconds to load.

No doubt someone would try audio rate modulation, because they can, but I don’t think that is at the heart of the discussion here (at least not me).


#18

I agree. My request is entirely about resource management. I admit that I am just beginning to learn the 301 but I have unintentionally maxed out the CPU a bunch of times while experimenting with polyphonic FM patches. (Seems the magic number is 16+ simultaneous sine waves.)

Being able to bypass/enable units and, possibly, even chains would allow us to make even more complex and dynamic chains. I can’t imagine how presets would accomplish this if they disrupt audio during loading.


#19

The use case that I offer is controlling n op FM algorithms like you find in the Yamaha DX series synths. Bypassing/enabling FM modulation chains and units using an external control would allow for a wider range of performance options (and considerably less patch mgmt).

Obviously there are a large number of other applications for this. Picking a single use case is always the challenge when trying to justify adding potential to any system. I’ve learned that adding potential is generally the right way to go.


#20

It’s almost too absurdly simple a concept to make a diagram of, but here goes. Consider a patch with three chains, each of which consumes roughly 50% of the available clock time. Clearly all three cannot be active at any one time. If B and C do not need to be active at the same time, then one can be disabled while the other is active, and CPU utilization will remain below 100%.

bypass

It’s certainly possible that putting bypass under external control might not be practical for technical reasons, but I don’t see any reason to pooh-pooh the suggestion out of hand.

I think that is the exact problem that is being addressed. Bypassing a unit is demonstrably faster than loading a preset or quicksave, and doesn’t interrupt audio processing.

Given that bypass is a binary state, I don’t see how anything more complicated than a gate signal (be it sequenced or manually controlled) would be necessary.