# Fluid.list2buf using autosize instead of blocking?

**URL:** <https://discourse.flucoma.org/t/fluid-list2buf-using-autosize-instead-of-blocking/1441>\
**Category:** Usage Questions\
**Created:** [May 9, 2022, 9:09pm UTC](https://discourse.flucoma.org/t/fluid-list2buf-using-autosize-instead-of-blocking/1441 "2022-05-09T21:09:31Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![rodrigo.constanzo](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/rodrigo.constanzo/32/12_2.png) [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)\
**Post date:** [May 9, 2022, 9:09pm UTC](https://discourse.flucoma.org/t/fluid-list2buf-using-autosize-instead-of-blocking/1441/1 "2022-05-09T21:09:31Z")

</div>

So making a corpus-based sampler patch and as discussed [in the thread about being (un)able to concatenate `buffer~`s](https://discourse.flucoma.org/t/concatenation-in-the-select-based-future/1439/7), I’m presently going in/out of `zl` land with `fluid.buf2list` and `fluid.list2buf`.

I’d sooner not go into `zl`-land at all for this (by having a native/easy way to concatenate `buffer~`s), but in having to do so I’ve noticed that the way that threading is handed in `fluid.list2buf` is quite different from other `fluid.buf...` objects.

For now, at the top of my patch I have a `routepass` with a blocking path such that I can `onebang` a `blocking 2` back to the top to not have to deal with manually setting `buffer~` sizes anywhere. It will suck that my first hit will always be “slow”, but it beats the alternative.

 ![Screenshot 2022-05-09 at 10.01.21 pm](https://discourse.flucoma.org/uploads/default/original/2X/3/3f855a37f896b167a3217862a39e81b5acca8cbb.png)

Now because of my `zl` detour, I have some `join` action leading into `fluid.list2buf`, which does not take a `@blocking` attribute like other objects. It instead seems want an `@autoresize` attribute, which seems to function in the same way that `@blocking` does elsewhere.

It’s not the end of the word to code around this, but it seems like it would make for a cleaner overall interface if threading was handled the same here, which would also make it possible to change the threading behavior across the whole patch by sending a single message (`blocking 2` (actually it’s a shame that the `universal` object doesn’t seem to address externals, as that would make for an even sexier interface!)).

```

----------begin_max5_patcher----------
959.3ocyY00TiCBE841eEL7nS2N.4q18oceb+Mr53PaoUbSgNDhqtN5u8EtI
Qq1nRrIpuzLAuky8btGfawaGOBuPesn.i9N52nQitc7nQvP9AFU+9H7V90Ky
4EPX3k5saEJKdR0eyJt1BiuVaPqyKkqllKKrrEkqQ+BoDhUHqdBRpJrB9pIn
kWvUaDnSw7RqtP9Owo3loJWpDK0kJX9X0CtyHJbvwsRs57ViPUtUpxEVH8n0
CJWAIkdwkeiEieLRcosITRCBb6xKjpMmaDKsUJAiEMkLAEmx7OnIT+iH2Xny
7em6FO1+wjdSwbh0zoSQtr0kBEOpaMp0IKx0K+iKGOAwKPbEhasF4hRqnUsK
JTkIpyJSLqRRxhqTFBnSYuSkwA6BgAGZ5RvOjXF9VgUXNWn3KxE6mzOkJMlj
0Zk061fo1SgpgqhzdyNQE8bdQDdgSywny16apbnAowOMRdN9kkGJiLMcNKYN
kMKKy8V7rInjn4SSbO.sxqeuOsR7WmHbfIZiK8uv3VZErJRaunS6nRI8dsdT
jHfiJkdbhTmLTzzu9FJRBr2SJ73KhEhl7oagpkEFrx5HMMV8lM4hfIeb2MMz
fTfV3Y57CWoDkBrMt4y9zJ3niQihHjVUCVKpAC2MF+z0BAR4YPANM5nJytiK
sZUnk448XU9cw45MDGl57SaTKTMIsi0Z+72YdW2zUF6nJ1aEEE7MhCHdSiTH
VnN7nNR5Wkvwwv9VTVROXneSNRCkir9jiQwr9iiup+0YcYfGKPZlk7QXfYyR
FPCbgkarq8aI41EBA6rDJ6i6ypbaLutjSIoCQM2UsWKL2itTq1jeS8iobYva
ek8B1b1KI.qy0b6gMv0lmmk0xN3IYfbDQFzk.NGgs3dzOJD4t7AsUvUAaInc
TQ7hQ2WPTI.zAdqfbc4JkaUiWJzklkhZKRv1CxGgXz7KmmebaO3u.fR4qRMe
HUwVeSK3VZeaVO1lyqpEz34vUEvH6cwAGPeXFfKy3Y2IELi9weplTUnqwutE
ED4g7XknvJUvcGsWL9eA7dAoMqDfPQZsNDJxOaVeAnIUAcTH4OF6MQhlLDjj
FDzo8.I8Ny2DodAn3PnDqOPhE.RYw8.RgrJXd69C5vaMSGBjiBQaGjE9AgLY
H3L6SiyrOMNmE2AnONjHcPdONjB4nilkVGbZIe2tqDlh5nAPb8JboFD6YSfW
kppWg+y.Xi3JYS7vY7Xtwcds0cXcoo5B3tNs5WKf2pckMkqUipJmidNHg9P7
WVWwNdESf1UFe23+CDXfiDA
-----------end_max5_patcher-----------

```