Routing of effects as a graph

[jpcima]

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 buses auxN.

• a buffer serves to send its input to a designated destination bus

  • buffer_source names the input. It is set to 0 to indicate the buffer effect's input signal
  • buffer_destination names a bus (eg. auxN) where to add the source signal

• a mixer serves to add signals from a pair of buses

  • source_1 typically 0, it indicates the mixer effect's input signal
  • source_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 abilities

• to use Sfizz as an effect processor only (effect bus receives inN, writes outN)
• to route distinct effect chains into distinct audio ports

One could imagine an example like the following, which routes signal unchanged into the 2nd stereo output.

<effect>
bus=fx2
fx2tomain=0
type=buffer
buffer_source=0
buffer_destination=out2

Maybe bus=out2 as a simplified way of writing?

[AlexMitchellMus]

So your suggesting the final example could be written using new opcodes:

<effect>
bus=out2

[jpcima]

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.

[paulfd]

Yeah I had something similar in mind in order to transparently handle both the multiple output cases and the effect inserts.