FluidBufCompose.kr - why not?

New Ideas Pre-Release Toolbox2 New Ideas
7

Hi Ted,

Not SC’s finest error message. I think what’s happening is that FluidBufCompose is calling UGen.multiNew (for no particularly good reason) but also using a keyword to pass the blocking argument (also for no particularly good reason). Either of the following should fix it, but both is probably better

  1. Don’t call this.multiNew in kr, call this.new1 instead
  2. Don’t use a keyword for the blocking argument (we’re passing the whole set anyway, so it’s not needed), just pass the 1 rather than blocking:1. Alternatively, change new1's signature so that blocking defaults to 1

The whys:

  1. We don’t need to support multichannel expansion here (and I have no idea how it would make sense), so multiNew is overkill. Meanwhile, multiNew doesn’t have a keyword argument called blocking, so it makes SC sad (this not being python, where you can pass any old keyword arguments in)
  2. There’s no point launching a worker thread to run bufcompose, because this would always entail doing more work launching the thread than the plugin is doing anyway (because all the data gets copied).