Sample rate bug in fluid.bufcompose~?

rodrigo.constanzo · April 29, 2024, 10:49am

As always, making a thread before a github repo since I want to make sure I’m not overlooking anything.

So after banging my head against the wall trying to figure why I was getting weird sample rates in my corpus I managed to narrow things down to something in fluid.bufcompose~. This is either a bug or an overlooked edge case, but either way, I don’t think it should be doing what it’s doing.

Here’s a patch showing the issue:


----------begin_max5_patcher----------
1666.3oc0ZszjiZCD9rmeEpnxosbbgdwibJImxgjKYOlJ0TXaYOrqMxEHlcl
r0t+1idAFx.iYLHSlspEvZDzp+Z0e8C3q2svaM+IVgG3m.+EXwhud2hE5gTC
rv96EdGSdZygjB8z71vOdjkI7VZ9aB1SB83Qq.oB.+QVdd5VVAP7.CHOKRyR
Do7LvG+ypa4PZFaCuLSeeH6fqKWu9.SMBr0HExGlZTe6n63YhcIaZMS0ZXC+
.O2nGvU9KA90Gj+D721YltUuV4q+zORIUqmrxioYGXhhlOSkbJR+GsbPpmS8
b4khpI2bQkkbTOYueic3QlHcSR0y+ThXyCoY6uOmsQXWhwnUzkf3X8ZEFGqN
EPUqT087s6tScX4HMIgq.ELQKq.eGXc4N4MbhWvdUCRW.cS3COivWDUgdQ9Z
XCFoOQBlXzKX8JvlGXa9rbqqB2XGOIdVgd6X4fj8IoYiB+PyH9E3GpfLJ1s.
3FEkPAHi+E.grB9YugAMjvYDZnXh1WLTiPvf.0Iz0BMqKEBd89jl5Xz40Ptb
8IX42yxRrTf9ul92VQqF0Lj34SLid3sNIauWMwWmaBvZMknOgHUGuJE8HqnH
YO6E6AHDnu+pt.f3NMxn2lR9pJHECMJnV0nQZEDM0VRp+raIog5.cTp+DXIy
XeQpVuvPllsi+cPRFWFWOuKX.58FTU+9z0cG3IRlDfjSsPetdfgbg5+oYlKG
BfEq2S.gXU3jqdqQu7eIp.HRiGSEAoEC30DwfDLizh33.SDCChghbRDCpLj6
V1tjxCxvFBNn34BA63kRc7R3FYVCmzJZBZTvVubP34OZBDgtAQSh76NZB9FD
Mw+FDLgL+ASLICNqwRHn2QwRr3kaCkPS5uVjwvMhmyTssTFUUg3LxQ5r6Sgk
EUnJ2mFNKjiANmbDEX5mggWbjri84DPVAjDJUUfmVbN8.IWxVvGj7Ie.7yE7
x7Mr9xY.OWsaBOmYgff5kF1TMqscSQSc6lvqZzaIvm3Y6O77nHmlyVLA8olM
wFd8.+QQN0mOayVyYiGtDnoSdIbfbeNN19pEnUcnMUNzzF7e2gxzsqNuQ460
tr5cLrhtXvdKIDf5U0WNH0OFhZ3kL843gBm+3QTMoEFili3QnH2GOJL1nfXW
lsNBO+s9IPqgPLYBrj8QriZ1GCYY4ZK6XX1QyYyuowlfgFfCE5jNY.amud6f
gWBcfyYpBHC0fg7yj2vz296fY2wAghmNGm9n.KxA5Ff2E2guyIAqX+n1tC6F
RP3+CJuxGZxagLe8r.F7NpmEV.qJSmQ1zhdPLScZuJlgmhz5p09ATFNtQuZL
gAtZstWedl.7CntzVhy83CIMx5g.ciC+72qYiZhrwnbh690TkxsoHEqxGENE
Eo7lesstuFTae.sAlo9tYS77WCFL13k579r2+FV56nPVV3JJ5FDwxhX1r1Wk
jtqqWRwMN1Esg5iCciWey55Z19Em6zSreHbFsbj0q2i0MYagHQTV.J5LWj2f
N9pj2pMyuppFAOaICFmlVJq8rrZg+PpoFbuZpsbtfqVc0E.96IBdbih+D4G4
aaWFpfcz94fhQxcCREZoTqzwCptN573AjyWGEgpuNN373PTia.FptkpeDqDQ
MX0UYwmxY6Re59pkIpC+P3USk2rRZHomJowcUIsBHA+J+v1JYWHd1HPueoba
J+i5cZ2+GMLOuXyREq2kX9raXLAJhLeOZzFujg06a7xH7WgV13.r071kd3fd
t2WsL7L2ZGyPeDV8PConXBT8PCUWne7Ap+E1uLzGQUOgH6rkWgk7WX8yh.k6
GtvS3MoWIJha8FkvycFo0DJE784IaSYFmktmkzy4DOW0UdybnSbL4tBmfeOU
+HLpYRn8DMV+Dz8G7+7AlqehpwaCelDrsJhsRCvY6bi2URi4fLyoSCzPkS3.
jCcBji5aj6hBR8gQBf0Shmuko8Af2.Q2FvqEs+3Ds+PfW3TfuCPPtAcGffCb
A1pXMtrKRjKz4gI5Pmn0nAHZrSrzCSzNwOhLDW3ovMhLDGVxTP7hGBZBmBpW
0KO+x1soPmPCA8f3oPRCQPjIPPvfg.dAtveaXhl5B+M3PX0qVeiSRjg3vMEa
YfsrQ8flNwNN.AivW1LZxoL4zoGY4E1aWKTYx2exTrP7R8OSyL+TmprWN6wz
p4aFIIWlUqPlRaYtoTnmBLszwSUrYdVYpUqkpqTj5D6U0+UbxVhpN++691c+
KbP7WxC
-----------end_max5_patcher-----------

In short, if the buffer~ that fluid.bufcompose~ is copying into has no size (as in, not declared, or after a sizeinsamps 0), when you copy something into it, the SR is set to the system SR, and not the @source SR or even the SR if the buffer~ if you manually declare it.

This means that any automatic buffer management-related things with fluid.bufcompose~ will end up getting the SRs changed for all the newly created buffers, which can be a huge problem on its own. And whenever using sizeinsamps 0 to specifically empty/clear a buffer~ for iterative/loop-based processes, the SRs also get changed.

Is this a bug or an overlooked edge case?

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

In either case, some thoughts. An ideal solution would be able to specify a @destsamplerate, but I think the plumbing required for that is probably too late. Another possible solution would be to always inherit the SR from @source when creating new buffers (probably simplest and most elegant). AND/OR respecting the SR of a buffer~ if it already exists. I can see this being problematic, however, as a sizeinsamps 0 buffer~ will always default to the system SR and I wouldn’t think there’s a way to tell the difference between a manually set or default SR for an empty buffer~.

weefuzzy · April 29, 2024, 9:48pm

Can confirm that it’s not doing what you think it should be doing. Patch below more concisely isolates the actual behaviour, which is that the ‘sample rate’ of the destination buffer~ is what gets used. Agree that this probably isn’t the desired behaviour but can’t for the life of me remember if it was deliberately designed that way or not. @tremblap might.

Anyway, please do file on gh, along with a note that we should probably check the behaviour for bufnmf~ because that also has its own witchy buffer writing code. The fix would be to use the source SR; can’t see any benefit to adding params to choose, tbh: the sr on buffers in Max and SC doesn’t actually do anything except tell playback objects something useful.

So, for now a (slightly tedious) workaround if needed would be to set the destination SR from the source in Max when you’re doing batches of bufcompose in cases where this will be an issue.


----------begin_max5_patcher----------
819.3ocyXtsbaBCDF9Z7SgFt10ijPbpWk2iNcxHvxNJEjX.QpyjI8YuBIvlz
fMXanShmvA407ueq1ckreakiah7.qxE7cvO.NNusxwwLTy.Ns263lSOjlQqL
l4lJyyYBk6Z66oXGTlwYGJXoJ.g.dhUx.Bo95nNqx3BVprVXLE2NXQIqR+jn
JtT73fVHpyk0pLlxHMr6yQUoOwE6erTKn00wgAafqA3.ulSQnlid5qA+rmal
JyjkV6MF.Od.0yR9VCNxjm+F128jivEc9ApYr2Wsp4v56LpkTuS+VExJl6Uy
LlX7cTzIlwvyPBYwII8IV5utZH7hwa7OBAAdQH7VbHpXJvVVkBnj8xdmLMjn
foOkfWbZdVJ1m8JfWoqJuZVBP8YIH9hrflMVRpUJoXXuEcghAjoxGaOR5Ndz
YsOE0qELq8tITwd2gXAE6dTlRZNSwJejInIYr9Ar6lSA62Z09zTlBjXeMbDf
LZDHxTB4EamuviFBVelyCFZBcWd7u4odHoC4IA9f.FLa.lyppn6YehPRDDB2
byPZWfyOZbHGDPbzf.hmuYvcY07saNsr1e.OTIqKSYf1tQOzzekKLq5a50N3
dD7FL.gGM.gHg85ZQhuXDZ8YhRH+kNOmK1I+yGn+ifFOgNcVdgdimJrKSRUM
zlwqLmONvTtn4edyrx.QJh2W0BFOu3MA8+KJPGsBM8H7g2X4CBtzkO2QhwvD
SPeARSPnEOMopDXxTt5DERfceN1.ku+MlZDuzYF5Vp6XkWJ2.ONj17+P7UjL
b1EKCW9ReB5VJ88i85A6MWrS9+TqaWV7pq16f7KQ8MdoWurK4ucOD1San7cW
ekP7oum.xCNGEBi2by7oLav4e9oVLNXy3eLjX2wTqCz8kR.mbxdagpuQgViF
LrOYkBmhR9ykRnwTBMWJ4MhR34RH7HBEOGB4OkYof4PofInTy1.uak5dHWdV
JxlzbeLglRzCNCJMkx14npEOkIoOwissDsn3EVYUqwFIz8je19SkFs1bKWXu
02baI6Edm8lVstzRceVktIacowsbODXW9zMWtkUJp4ssD0vokzzuWP0q6WPs
bXVVX06q9K.+t7C3
-----------end_max5_patcher-----------

rodrigo.constanzo · April 29, 2024, 10:16pm

Thinking on this further, and this is likely the best solution.

///////////////////////////////////////////////////////

Hmm, your ‘workaround’ patch seems extra weird and inconsistent (I’m left more confused than before!).

Your patch when I run it for the first time (with my system SR at 44.1k):

(I see 44.1k, not 48k)

When I run it again after changing my SR to 48k:

(the SR changes to follow the system/buffer SR)

When I change the SR back to 44.1k:

So the fluid.bufcompose~ SR is kind-of based on system SR, sometimes?

weefuzzy · April 30, 2024, 7:15am

Ah sorry, that wasn’t the workaround but the patch reproducing the issue. Workaround is trivial, so didn’t occur to me that a patch would be needed.

However, that changing the system SR has any bearing on that patch is weird, so now I need to look at the code again and figure out where that’s coming from.

rodrigo.constanzo · April 30, 2024, 7:21am

Gotcha. I did read/respond to this on very little sleep so didn’t process things fully.

I guess given the funky behavior from my last post explains why any workaround I was trying wasn’t working (consistently).

I’ve also now made a github issue (I put it in Max rather than Core as I don’t know if this is a wrapper-layer issue or more underlying (seems the latter, but I don’t know enough to say)).

weefuzzy · April 30, 2024, 7:35am

Cheers. I suspect it might be both Max and Core

The actual desired behaviour (that BufCompose uses the source buffer SR) is a core thing
The weirdness with 0-length buffers getting stuck with the system SR looks like a Max thing

(but we can sort that out whilst we fix)