First time here? Check out the FAQ!

Comparing different strategies of combining Sounds

+1 vote

Sound constructs often consist of roughly two parts: one synthesizing part (let it call source) feeding into an transformational part (let it call transform). For combining sources with transforms there are two different design strategies (maybe more, but these are the ones I use):

  • the source is used as input to transforms (Variant A) or
  • utilizing MemoryWriters/Samples or FeedBack loops (Variant B).

The principle of Variant A looks like:

The principle of Variant B looks like:

If we compare these two approaches, there is an interesting difference in their properties, mostly related to complexity:

  • Variant A has a complexity of 281.191% - 311.186% (approximate)
  • Variant B has a complexity of 17.28% - 19.938% (approximate)

This results in the phenomenom that with more and more complex sources and/or transforms Variant A comes very early to an Out-of-Realtime situation (i.e. stopping to work), wheras Variant B fits for bigger sound constructs into Kyma without refusing to work.

I would be very interested to get a bit more background knowledge about the reasons behind; and how to deal with this observation. I guess that the reasons for Variant A are caused by the functional implementation, where nesting means recursion, i.e. a sound part f1(g1(x)) as input of f2(g2(x)) is computed as f2(g2(f1(g1(x)))). In contrast Variant B takes the result of f1(g1(x)) as input stream to f2(g2(x)). But maybe there are other explanations.

Would it be an idea to provide a structural sound within Kyma resulting in a different evaluation strategy without functional recursion, e.g. the input of that sound would be computed separately (on an independent processor) and then feeded as bitstream to the sounds, where it is used as input?

For completeness I attach here the example sounds (simple sounds without artistic relevance, just to show the point):


asked May 5 in Sound Design by explodingtickets (Adept) (1,230 points)

1 Answer

0 votes

The approximate complexity measure was not taking shared nodes in the signal flow graph into account, so it was counting the shared node FormantBank KBD 4 times in Variant A. This has been fixed for the next update to Kyma. The updated complexity measure will still be approximate; the best way to get an accurate measure is to play the Sound and use the DSP menu on the front of the Paca(rana) to get the true percentage of the processing used.

In this example, the second variation is slightly more expensive. Using the updated approximate complexity, you will get:

Variant A: 11.908% - 13.372% (approximate)

Variant B: 12.249% - 13.789% (approximate)

so the recommended strategy is to use the direct signal flow rather than routing the signal through MemoryWriters and Samples.

Thanks for pointing out the descrepancy in the approximate complexity measure!

answered May 5 by ssc (Savant) (108,900 points)