Bug: Sample Rate issue with `fluid.bufcompose~`

[rconstanzo]

Please tell us what you were doing! You can include code and files by drag and dropping them into the text area.

As outlined in this thread on the discourse, 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.

As mentioned by @weefuzzy "we should probably check the behaviour for bufnmf~ because that also has its own witchy buffer writing code"

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

What operating system were you using?

Mac

Operating system version

macOS 14.4

FluCoMa Version

1.0.7

[weefuzzy]

After some prodding, I've decided this is just a core issue that comes down to a logic error in BufCompose

1. BufCompose always uses the destination sample rate when resizing the destination buffer. Surely it should be using the source sample rate, or is there some reason I've forgotten that we'd want to preserve the desination sr?
2. The weirdness with falling back onto the system sr the first time this is run is a side-effect of using the destination sr: when (in Max) a buffer is initialized without any samples it reports as not 'valid' in our code and (for better or worse, possibly worse) reports an sr of 0; this gets sent into resize() and when you send 0 to a max buffer's sr selector, this is interpreted as 'use the system sr', it seems
3. Meanwhile there's another logic error here, I think: surely (if we're propagating the source sr) an invariant of successfully calling BufCompose::process should be that – even if the destination buffer didn't need to resize – dest sr should equal source sr. This won't currently be the case. Indeed, we don't have a way at the moment to set the sr of a host buffer without going through resize().

So, not completely trivial to fix, it turns out. We should probably check the effects of this in supercollider as well, which will have its own buffer logic. In pure data, arrays don't have sample rates, so I'm guessing this isn't a problem in the same way.

Suggest two-stage fix, if we do want to propagate source sr:

1. Change BufCompose call to resize() with the source sr
2. Then think about how to deal with the no-resize case

[tremblap]

The idea was that if we composite sections we want to be able to not change the features of the output (sr and size) - for instance, what we currently do when loading folders of files in a single buffer.

So the solution is definitely not to systematically apply source SR. I'll get thinking of what a good interface would be, but maybe fixing a default SR if it is not assigned, and a support for a SR method is the most flexible approach.

[weefuzzy]

Hmm. Well, I think our current problem is that we're violating a principle of least surprise for the simplest case and meanwhile there's no useful thing we can do if someone decides to concatenate heterogeneous SR stuff into a single buffer: it would always require manual action from the user. So, I'm still sceptical about the usefulness of a flag vs people just setting the dest sr explicitly for these edge cases.

[tremblap]

as ever the wise one, @weefuzzy - we'll just need to check how it behaves in SC then - I don't think it would cause problem as one can assign the SR post creation without issue - if we go that route we'll flag as (edgecase) breaking change

[rconstanzo]

The idea was that if we composite sections we want to be able to not change the features of the output (sr and size) - for instance, what we currently do when loading folders of files in a single buffer.

I haven't tested this (thoroughly) but at the moment, when you concatenate stuff into a buffer~ isn't it just mushing whatever the original SRs are into a single buffer~ with whatever the current system SR is set to (sans any resampling) such that if you play back audio this way you'll potentially hear arbitrary playback rates based on the difference between the source SR and whatever your current system SR was at the time of bufcompose~-ing?

So, I'm still sceptical about the usefulness of a flag vs people just setting the dest sr explicitly for these edge cases.

I guess it's especially tricky since buffer~s are both audio and data here, so sometimes the SR matters (e.g. playback) and sometimes it doesn't (e.g. descriptor/stats).

I can see the usefulness of having a @destbuffersr (or whatever) attribute if someone is doing something especially fiddly, but I would think that a default behavior as you've suggested (source SR = destination SR) probably fits in with most expectations and use cases.

[tremblap]

as I am investigating the SC behaviour for this, I think I have found a bug in their code. So to take an informed decision (going for last source (or first source, not decided yet) and asking the user to deal with sr changes manually later via the CCE) let's check it is actually possible in SC.

[tremblap]

for reference: https://scsynth.org/t/how-to-change-a-buffers-samplerate-everywhere/10379

[tremblap]

ok there are no native ways in SC to do that. So 2 options:

1. we add an ugly @destSR attribute to FluBufComp;
2. we code a small SC object based on my https://github.com/tremblap/OfflineBufferProcesses/blob/master/OfflineBufferProcesses.cpp to change the SR

Of the 2 evils, I think I prefer the first one.

[rconstanzo]

Late bump/response here as I'm now tidying up the patch that led me down this rabbit hole.

A @destSR attribute isn't the end of the world, and at least offers the option of consistent behavior if you want it.

[tremblap]

I think a new method won't happen. Max can do it natively, Pd doesn't need it (arrays do not have SR in all cases) and SC is funny - the community asked me to correct their code as it should do it - it is on my todo list.

now we'll just need to decide if we do like @weefuzzy proposed in April in 2 steps...

[rconstanzo]

Ah nice, even better then!

[tremblap]

ok, PR done on SuperCollider itself to allow updatable sr on the server. It works perfectly so I hope they'll action quickly. In the meantime I'll work on our fix

[tremblap]

this is too easy, after fighting the whole SC codebase all day. Changing one word. @rconstanzo if I make binaries for you, can you help me roadtest the object?