Open rconstanzo opened 5 months ago
After some prodding, I've decided this is just a core issue that comes down to a logic error in BufCompose
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? resize()
and when you send 0 to a max buffer's sr
selector, this is interpreted as 'use the system sr', it seems 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:
BufCompose
call to resize()
with the source srThe 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.
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.
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
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.
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~
thatfluid.bufcompose~
is copying into has no size (as in, not declared, or after asizeinsamps 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 thebuffer~
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 usingsizeinsamps 0
to specifically empty/clear abuffer~
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"What operating system were you using?
Mac
Operating system version
macOS 14.4
FluCoMa Version
1.0.7