# FluidBufCompose.kr - why not?

**URL:** https://discourse.flucoma.org/t/fluidbufcompose-kr-why-not/519
**Category:** Pre-Release Toolbox2 New Ideas
**Created:** [June 14, 2020, 6:24pm UTC](https://discourse.flucoma.org/t/fluidbufcompose-kr-why-not/519 "2020-06-14T18:24:33Z")
**Posts on this page:** 1
**Showing post:** 7

<div class="post-metadata">

### Author: ![weefuzzy](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/weefuzzy/32/362_2.png) [@weefuzzy](https://discourse.flucoma.org/u/weefuzzy)
#### Post date: [July 3, 2020, 6:23pm UTC](https://discourse.flucoma.org/t/fluidbufcompose-kr-why-not/519/7 "2020-07-03T18:23:44Z")

</div>

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).

---

_[View the full topic](https://discourse.flucoma.org/t/fluidbufcompose-kr-why-not/519)._