Let’s share our hopes and dreams for what could be accomplished by the hypothetical Command Bus architecture!
What we know:
Command and Event Bus
command messages broadcast or sent to specific units
example of command response: clear buffer to all loopers
example of event generation: End-of-Cycle
command generation unit that will emit a set of commands when a trigger is received
events are efficient (i.e. frame-rate) triggers?
Topics I’m pondering:
How to capture “mid-unit” signals more easily than sub-chain hacking + local access
How to efficiently distribute control signals (e.g. mod matrix), where the distribution itself is controllable
How to easily save and share big control frameworks / quicksaves
Running existing units at command rate instead of audio rate so control surfaces don’t explode the CPU usage
a question for @odevices: i cant find if it is already been asked but… do you think it will be possible to insert different instances of a unit type, set one of them and then give a command to copy the settings to all other units of that type?
i’m imagining a system where i use more instances of a scale quantizer and want a quick tonality change, i go to one of them, change scale and hit a button and BOOM all my other quantizers switch to the new scale. it might come really handy for live performances where the 301 is on heavy melodic\harmonic duties!
With the command bus, I’m not sure how you were thinking to implement it @odevices, but I’m wondering whether it makes sense to build it on top of the existing SC.CV and SC.TR system. These are effectively already buses that can send data throughout the ER-301. To turn it into a command bus, there would just need to be ‘effect units’ that do the opposite of SC.CV and SC.TR: rather than converting the ii data into signal, the units would convert signal inside the ER-301 into ii data which can subsequently be accessed anywhere in the system on that port.
(I’m not saying that these units would actually post data to the i2c bus: of course ER-301 is a follower and not a leader. But i’m guessing that once data is collected from the physical i2c interface, there is some kind of internal bus which could be posted to internally in this way?)
I imagine inputs to SC.TR would be fairly simple, it would work the same way as clock inputs to other units, just with a threshold. An input to SC.CV might use a clock input to determine when/how often to sample the CV input? Assuming that inputs to the command bus do need downsampling and that it is not meant to be used for high sample rate signals.
The command bus(es) will carry events not signals, although I’m sure there will be units that convert events into signals and vice versa. I have not decided yet whether a command bus will be named (e.g. gig_control, mute_group_A, mute_group_B) or enumerated (e.g. bus 1, bus 2, …) or something in between.
So something I was thinking about recently was how it would be really nice if we could assign the 6 buttons under the main screen to different functions. I was thinking about it in the context of muting multiple Loopers. Basically being able to create a performance environment with the buttons assigned to do different things. Probably a far-fetched idea, but would be cool, and your talking of sending event information made me think of that.
I also just thought of using custom gate controls. One of the best things about the er301 is that when I think of a feature I wish it had I can often come up with a way of implementing it. The only limitation there is the CPU used up in all the user level routing.
Along those lines it would be really cool if we could create custom units and then sort of “render” them to a middle layer unit. I don’t know if this would actually help the CPU usage, I just know that some bespoke units are more efficient than their custom unit counterparts. To be honest I can’t remember the last time I started running into the CPU limits though.
Although I understand the desire, it is a hard problem that would be better served by working on a nicer development environment for writing your own units in code.
It seems to me like there are two proposals, one is a flexible and efficient global data routing system (the bus aspect) and one is a system for attaching controls to particular events on some units which don’t have a top layer control for that event?
Sorry if this is all discussion that has been had previously, I did a search but couldn’t find it. I guess I’m just confused. I think the idea I had in my mind was that the command bus is essentially a low-res, low-CPU version of global chains. So that’s what made me think of the similarity to SC.CV and SC.TR.
I was getting a bit off topic about attaching controls to stuff. I think it is more to allow units to send event information to other units. Like a looper sending a trig to something when the buffer loops or something like that. I don’t actually know, just speculation.
