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 record~ in @loop 1 and @append 1 modes).
The way 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.
OR
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
1 Like
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)
1 Like
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:
----------begin_max5_patcher----------
685.3ocyX10jaBBEF9ZyuBFldYZFEkDs+U5zYGhgjxNJ3.3tocmc+sW.wj8C
MgIwrauwOvi4kGdOb.ySyhfqE6oJH3GfeBhhdZVTjqIaCQ96if0j8kUDkKL3
5VsVvgy6dDusVzpqnZ2CS7sx13BUr99uiv8g1PjjZplJuixIqqn1Ph8Oq62P
+mFZWWAtlv2AA+5vqpK+Miu6NIsT2EQd7h34fLr8HJq+3g2vzuX7CcKaaOOa
l8v7.wjSezz8666Z5dmtv1+x.3ggOc.3QvSB37imYbc.7V3HMycMBMFunKf2
ZpRQ1Q+.vkUThLb2NYTfOIcnzbKRIEH6oT7zy2H9ojv2HpAIwwAyXxpQY7bl
XZmy4wbU5zi4ijGnaEx5WFFmk9VW2tcKUxMyGcu0FkFN.n3QAcakfnsosm3h
JlxcNjowHm8iKbiHIoEiMjfmvLakrD7JvOuuitrb67W64YY+u34F7GvyKt8V
teRPZbgan.uzdZY1mgkukUUATLN3aIAa64Wlq6oDk5Lb7mWEsNa9EfM8NAMR
YMzG4LfI6mcQ4dnW47z7hSCcxW2xTYWyT4Tbwm7pTaqZYaVXb1RQciPQeI3c
fjc1MfbvcCfbuwlDub5c1yjNapTCvwgmNmNAoyd6t.eqxlGgYuKu3QIoI7km
fW4do8kpxWENmtHLU84u+SHbhXa+svqDsxx9tU+FjAGEZCUoYbhlY9.iiAk7
1fDxMT43i3SqzqFV53qSZb.R22+tJkdW+eXkxm.gra7+7il2DeLDkSGVYzsW
Y7sHAJObguNByBer85xSCPmroPGT3ooenNGoo4ApT4C1ogob98BmglO2cKi2
cqq.MTRef0Gu6u5.RjlhuZSk2VY21v2uraIZXsvjZvaY9YDF5LR5VpvtkcUC
oCD2JJydd1+.K0kFcA
-----------end_max5_patcher-----------
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.
1 Like