I’m curious if there is a standard way to take two buffers and combine them, consecutively, into a third buffer,
I was trying to use the following code, but it seems to stop reading after the first “copy” - and it would be great if there was a way to automatically trim/expand the buffer “d” to fit the new size. Thank you all.
(
b = Buffer.read(s, Platform.resourceDir +/+ "sounds/a11wlk01.wav");
c = Buffer.read(s, "/Users/wheeler/Desktop/render.flac");
d = Buffer.alloc(s, 200000);
b.copyData(d);
c.copyData(d);
)
Sorry, what I meant by “combine them, consecutively” is have them one-after-the-other in a new buffer.
It still seems this may be possible with FluidBufCompose, by adjusting the destination start frame of the second buffer with the numFrames of the first buffer - but I’m not entirely sure how to do that?
Something like this…
(
// fork to make a Routine so sync can be used
fork {
b = Buffer.read(s, Platform.resourceDir +/+ "sounds/a11wlk01.wav");
c = Buffer.read(s, "/Users/wheeler/Desktop/render.flac");
s.sync; // wait until buffers are updated
d = Buffer.alloc(s, b.numFrames + c.numFrames);
b.copyData(d);
c.copyData(d, dstStartAt: b.numFrames);
};
)
@TXMod - I used the same code - and I actually got it to work when using a11wlk01 twice - or trying a variety of smaller duration files. The problem seems to occur when using a longer file.
I’ve never use a flac file before in SC. I wonder if that might be an issue? (I’ve only used .wav and .aif).
If you run this code what does it post?
(
// fork to make a Routine so sync can be used
fork {
b = Buffer.read(s, Platform.resourceDir +/+ "sounds/a11wlk01.wav");
c = Buffer.read(s, "/Users/wheeler/Desktop/render.flac");
s.sync; // waits until buffers are filled
d = Buffer.alloc(s, b.numFrames + c.numFrames);
b.copyData(d);
c.copyData(d, dstStartAt: b.numFrames);
s.sync;
b.numFrames.debug("b.numFrames");
c.numFrames.debug("c.numFrames");
d.numFrames.debug("d.numFrames");
};
)
Thanks for your patience - I think the issue was actually caused by not specifying the numChannels when copying the secondary buffer (which had 2, as opposed to the mono a11wlk01…