Open jpcima opened 4 years ago
So your suggesting the final example could be written using new opcodes:
<effect>
bus=out2
Yes, that would be the idea. This wouldn't have an equivalent simplified form for input though. Implementation-wise, this would not make it a big difference. This still sticks reasonably to the Cakewalk effect specification + the book addition.
Yeah I had something similar in mind in order to transparently handle both the multiple output cases and the effect inserts.
Some notes on implementing a future effect graph
See the pages 351-352. It has an example of using it for routing. This need the effects
buffer
,mixer
and the busesauxN
.a
buffer
serves to send its input to a designated destination busbuffer_source
names the input. It is set to 0 to indicate the buffer effect's input signalbuffer_destination
names a bus (eg.auxN
) where to add the source signala
mixer
serves to add signals from a pair of busessource_1
typically 0, it indicates the mixer effect's input signalsource_2
a secondary bus to add in the signal (eg.auxN
)To implement this, we need to compute an order over all effects. It's a dependency graph, and needs computation once after the sfz load. The purpose is to compute the chains which produce
auxN
(buffer) prior to computing another effect that requires it (mixer).Idea: introduce some additional I/O ports to the Sfizz plugin. If we extend this model to designate
inN
/outN
as buses mapped to extra plugin ports, we can have some abilitiesinN
, writesoutN
)One could imagine an example like the following, which routes signal unchanged into the 2nd stereo output.
Maybe
bus=out2
as a simplified way of writing?