A method to control chain and unit presets through CV or an internal mechanism is a critically needed feature.
If I have (X) Custom Unit presets that I’d like to work with, one at a time, it would be useful to be able to select which preset is loaded through CV or unit designed for this purpose.
I’m not sure how bypassing a unit interacts with the CPU load but I imagine interacting with loading (and eventually saving) functions through CV or specified Unit to be more elegant than managing a chain with bundles of bypassed units. Hands off is a goal. There are bound to be issues with this functionality, especially while under a rapid load, but I’d rather have access to this paradigm in a “not safe for performance, at users own risk” state than not at all.
I second this idea… CV controlled paradigm shift.
would this not get problematic with presets referencing audio files? What if there isn’t enough space in the pool or time to load the data… etc…and another trigger or CV is received. I don’t see how it could an instantaneous flip to a new set of processes.
I don’t expect for there to be instantaneous program changes. Depending on what programs are getting switched around I imagine some will take longer to load. Imagine loading a preset except instead of using our hands to recall it we use CV or an internal mechanism. I’d rather have this in some “use at our own risk state” than not at all. Stable and functional would of course be game changing. The patch architecture outside of the ER-301 could be devised to accommodate the extra load time. While sending 100 program changes within 5 seconds is probably not a stable approach sending 1 program change every 5 seconds probably is.
The addition of the recent Custom Unit is a good step in this direction. The control types can be consistently arranged in anticipation of changing presets. Example: User sets always uses A1 for the Custom Unit GATE control type and A2 for a CV control type. User designs 100 different Custom Units with this control scheme. Select Custom Unit preset via CV. I thought through this fast but that’s one simple example.
I could see this working with a pre-loaded chain and switching between chains, perhaps on an ‘ahead of time’ trigger, but the time it takes to load a saved chain is a good indicator of how practical what you are suggesting would be in application. If I understood correctly.
I would probably approach this with a sequential switch and for example route triggers to different paths in the ER-301- this is doable now with what we already have
Grouped bypass systems on a flip flop could be a nice way to go with this, then the system isn’t trying to load a whole bunch of stuff on the fly and the problem is reduced to which units are active and taking up CPU cycles.
I think this makes sense, but I just woke up
Yeah I agree, I think this needs to be handled from the point of view of already having x different chains/customs setup and then either stepping/flipflopping/cv-selecting through them… A bit like the chain selector in Ableton with an extra gate step input.
Don’t worry. I’m not ignoring this thread guys. It just requires a little thought and planning before I reply.
Yes I think that the units would have to be loaded BUT if there was a way to ‘disable’ them so that they are not using any CPU overhead (or maybe they already aren’t because they are not ‘in action’) and then some way to make them active - possible replacing the one that is there already - so a Unit slot maybe? Slot one has custom unit 1A in use and B,C,D are loaded but not selected and then on receiving a signal the slot switches to B?
When it comes to the ER-301 and this layer of interaction there are bound to be several paths we can take. Without knowing more about the development road map at the moment I anticipate a couple desired automation scenarios:
- loading chains and presets
- loading samples
- unit parameter randomization
- randomization of units
The first two scenarios have been brushed upon in this thread and I might have implied extra weight towards those scenarios in the original post.
We strongly need to consider the second two scenarios as well. A method to randomize a units parameter set through automation and the ability to randomly load units through CV or automation will bend the wheel of times patterns and enhance our sound computing capabilities. Randomly loading a mixer after a synth voice chain might not have any useful affect but if the pool of possible candidates can be curated within preferences than the probability of non-useful combinations can be reduced. Randomizing the parameters of an unit, perhaps an equalizer in this case, might produce an awfully abrasive sound but it could lend itself towards something beautiful. No risk, no reward.
Some of this sounds to be coming together between the mysterious “Hold” function, Custom Units, and Global Chains