So I was trying to dig up that thread that had a bunch of suggestions/abstractions (that @tremblap and @weefuzzy ended up making abstractions for) but it turns out it was just an uber-tangent off the thread talking about long strings of arguments. There was another smaller thread, but it didn’t go as far as the other one.
Basically, I’m trying to concatenate a bunch of smaller buffers into a single bigger one for later processing/granulation.
fluid.bufcompose~ is perfect for this…except… in this case I want my buffer to remain a constant size.
Because of how I want my patch set up, I want a fixed target buffer to work from, but I have an arbitrary amount of smaller buffers I want to concatenate into it. I also want the smaller buffers to “wrap” around the buffer (ala
@loop 1 and
@append 1 modes).
fluid.bufcompose~ works now, it will always ‘grow’ the buffer being written to. This is generally great, but in this case it makes for a bit of a nightmare because each time I get to the edge of the buffer I would have to work out some maths to only write a portion of the file, going up to the end of the buffer, and then continue copying the “rest” of it to the start of the buffer.
So the request would be for some behavior options for the boundary conditions when
fluid.bufcompose~ reaches the end of an existing buffer. The default could be as it is now, where it just creates new buffer-space to write to. Another option would be something like
crop where it stops writing when it reaches the end of the buffer and the rest of the original file goes nowhere, and then perhaps
wrap where it continues writing the contents of the source buffer to the start of the target buffer.
If anyone has any thoughts/suggestions on how to best do this kind of thing.
I’ll see if I can rustle you up an abstraction for this. I’m a bit dubious about whether it really needs to be built into the object
That would be super sweet.
Speaking of, it feels like those other abstractions should live in the help file, or somewhere more accessible.
See how you get on with this. It’s a pretty minimal interface: you give it (at least) a source and destination buffer and it will track write positions / multiple writes and generate messages for
fluid.bufcompose~. You can also give it a source start and source length to read a subsection of your source instead.
Not Rod-standard patching I’m afraid.
compose.wrap.zip (10.3 KB)
Oh man, that is peeeerfect!
It’s a nice touch being able to specify the source start/end as well.
I’ll be aiming to do something like this:
All of these nuggets should really be more accessible. Perhaps something from the top-level “Extras/FluCoMa” launch patch, where you can either have a tab for abstractions, or launch a patch that has a bunch of them in there.