No more using 10 send tracks for seemingly trivial tasks.
Allows for more creative doofers.
EDIT: It should have amount for both the routed and the passed signal. That way you can use several audio splitters to split and “rejoin” anywhere you want.
One of the ideas of an audio splitter is that you won’t need a send track in many cases. Similar results could be achieved with an audio splitter AND in fully self contained doofers. It’s a very simple device (conceptually) that brings DSP chains a big step towards a “modular” feeling.
Yeah, I guess this is basically the same as the reciever device that has been proposed before. Perhaps a bit differently implemented. I think I prefer having a separate “audio splitter” and possibly an “audio reciever” instead of messing with the send device terminology.
No, I meant there that the send device / multi band send inside a doofer only could target doofers inside the doofer. So no send track needed, too. And the code of the send/multiband send could be reused.
But what you meant isn’t it more dry/wet? That could be achieved with a dry/wet amount knob feature in the doofer.
But I guess you also would like to really process in parallel? Since your solution cannot do this, or didn’t I get something?
No, I meant there that the send device / multi band send inside a doofer only could target doofers inside the doofer. So no send track needed, too. And the code of the send/multiband send could be reused.
So you would use a doofer as a “receiver”? That seems unnecessarily limited. It’s better being able to route the audio parallelly to any place in the chain.
But what you meant isn’t it more dry/wet? That could be achieved with a dry/wet amount knob feature in the doofer.
An audio splitter would make the dry/wet knob obsolete as you can place it first in a doofer and then change its pass/route (pass/“send”) amounts.
But I guess you also would like to really process in parallel? Since your solution cannot do this, or didn’t I get something?
Parallel processing is naturally covered by this device as well. There is a pass slider and a route/send slider.
(There are some details in the implementation to consider. You shouldn’t be able to insert a device and be startled by a doubled amount of volume, for example.)
The implementation should probably be as simple as the following, which will cover all cases and possibilities of routing:
Each splitter has a Dest 1 and Dest 2 with corresponding slider (0-100%) setting how much of the signal should be passed to each destination. By default these are set to Dest: none and Amount: 0%. Feedback should probably be forbidden (splitters can only route forwards in the chain).
An example of a flowchart and what order the devices would be put in a device chain (several solutions are possible, some less optimal). As seen, a splitter with one of its destinations muted would function as an “end bracket”.
Yes. But then you would have to use “blank” doofers just to function as ‘end brackets’, right? In case you want the output signal from each paralell to be routed to a different place in the chain. That’s a bit ugly design-wise. What you are suggesting is basically what I have drafted, but with a limitation (only route to doofers).
I see no reason for a splitter/send to be limited to the doofer scope. It would certainly make the chains more complicated. But it’s a good point that a splitter should be able to target a doofer as well.
But then you would have to use “blank” doofers just to function as ‘end brackets’, right? In case you want the output signal from each paralell to be routed to a different place in the chain.
Why should I want one doofer to be routed to another place than the other doofer? I don’t get this… Then I would simply include the jumped-over dsps in the other doofer.
If you look at my complicated scenario, the splitter 3 and splitter 4 signal paths would have to be achieved by blank doofers according to your suggestion, would they not? You couldn’t break out parallels from parallels and insert their outputs anywhere. Being limited to doofers is kind of semi-serial.
PS. Anyway, on a side note. I think some kind of parallel routing in DSP chains will “have” to be implemented at the same time that feedback/parallel routing is implemented for instruments. Or else users will be encouraged to do their processing/sound sculpting where it logically doesn’t belong. I don’t want to have to put a filtered feedback delay in an instrument, for example. And I don’t want to “synthesize” in a DSP chain, just because it is the only possibility.
