Non-standard output order of fluid.bufsinefeature~?

Not making a proper bug report on github as there may be a good reason for this, but after noticing I was getting weird order of operations going in a patch, I checked the output order of fluid.bufsinefeature~ and it outputs its buffer~s from left-to-right, as opposed to most other/native objects which always to right-to-left in terms of order.

Screenshot 2023-01-23 at 12.55.19 am

Knowing this, I can obviously code around it, but I figured I’d mention it in case it’s an oversight or something. I imagine this is also the case in other buf-based analysis things that output multiple buffers?

That seems to be a problem with all the buf* objects, as it happens. good catch

1 Like

LMAO, this has been wrong for ever and nobody caught it until now, including us. I’ll push a fix for the next release. Afflicted objects will be

  • all the fluid.buf*
  • fluid.stats
  • fluid.sinefeature~
3 Likes

Hot damn!

Is it in the next nightly already? I can just code around that and then specify that it needs to be 1.0.6+ (or whatever) for SP-Tools to work.

Would something like buddy combining the buffer outputs be version agnostic here (i.e. release 1.0 friendly) or is that problematic with threading/consistency?

Haven’t pushed yet, but will ping when I have, and triggered a nightly (I think this will need fixing in PD as well, FWIW).

[buddy] should work – the messages come out right after each other, just in the wrong order, and there’s no asynchronous mucking about at that point.

1 Like

Cool, I’ll code it around that to avoid version fragility. I’m only using this in one place thankfully.

That’s now fixed in the current Max nightly. PD forthcoming, once I’ve fixed something else (that broke the build)

1 Like