Two fluid.bufcompose~ questions (Threads <> Time)

Usage Questions
1

Hello !!

---- It takes a very long time concatenating, and mixing (?), buffers together onto a one long buffers.
When should I use the “reset” and “destgain” commands ?
It is faster to provide the overall length of the target buffer beforewards. But it is still rather slow for some reason.

---- I do not fully understand how the thread, “blocking” attr, is working.:

  • “blocking 0” -> Why not “@queue 1” by default ? It is still blocking periodically.
  • I had the impression it was faster to use “blocking 1” and make a queue system within max ?
  • Is “reset” erasing the QUEUE stack ?
  • “blocking 1” -> “fluid.bufcompose~: already processing” even with “@queue 1”
  • “blocking 2” -> no error message even with “@queue 0”. Is there a stack, a “@queue 1” when blocking = 2 ?

I made here is a “clear” patch to try to describe my questions:


----------begin_max5_patcher----------
3775.3oc0cs0jiZiE94d9UnxUp7PR2dQBIAL0lq0N0topslY2jIadHyVcgMp
cSFLvB3dZmTI+1WIDXC1bQfELNtpwdZ.iz46bz24hjv+1KtYwpnmYoK.uD7y
fat42dwM2jeHwAto3uuYwV2mWG3lleYKVGscKKLawsxykwdNK+32A9Nvitdf
rGY.+swIrzT+nPfeF3CtofGbSyXIfrHvtTF3cKVEDs989ga.v2s.3F5A159d
FvE7+1w1w.o64W8VvG7ydzOjepmAeUY6E3GxVGsKLuQQEGTzZ79jaFuEuuwq
Hb21ncYArrbgvn3n9d4c8nU+xcPKyxl3gnvrP2sr7y8MI9tAfuMJvq7zwtYq
4cqM2mvVmIQNnoEcows.SSi7OfVhOP72A+2ic.+vx1GJN1u+hWHd61KD243c
3hdwAbm3f3lsNJHJQJN4Bww2fUDiZHFpJhk5+q4HFBuzX7.IzbI4V.NG+HNR
LcNPQ3hgAPNNTCKarIWyiHXmaU7PsBkFZGJo45NIRhr0ORtZWVVTXyvFrIQD
drylvkDNcv8rP2UArp.s7ljsOlIkhEqbC2r3PutA4Dkakffh2sIkuO8VLnOt
VLTGsawfLvGG7MElLc35Hk6SPPdkwcGvRbSEtFDdR92+3q9wWARybW+9i9.5
mLmh0.YNL2lh6XP9w7fDUbMh3XwceIHLhiHIQIfsbWptaX.1Srvbei7K9qkN
LMd2hkBPjCYIB2n4.1s7+ygqP3m8CbWEfC29u.flA2pTc3V01thBAM+ZBnTS
7tEODry2a4pcOv+ZwQor+3k.2fDlq2dPbRzZQLOgaDlvmqh32ioGrQZ.rKb6
NmwvTCrMjf8O83dtoeVcK3U6AdrGb2EjA9Jv2V9MhYI9Qd9qcCB1ur+XgLUF
OI1WNdhbPUvyYhF4t6.u8e78u5a9ae2q+6fOUxh9CfG3jHGscWpNcJw4RvAY
PwHK7RjMwBhKd2xlCGNz4CU3nvO71u6MuF71e5MubgNG1YbAvCxwQ30EQxcy
XiNCO1E5wRD8rpQVMoCEKcDuhwsXx82jrGH9BhD0RYrsohD4xyXimdmKHvOi
iOE43sjOxkS9k9Xzt.OdNgx78JukSuCGB8hFyJcwXHCprXD7rwA5wRy135Gx
AJuHVZN+25G4Q.y8oGtWjL7lgLpkb4HAzoH5G5LydwMt3VY9aYBSs0Qgqcy3
YKjw3lcg6ErXOvRDlgaXhXdVBd6iL+DP.KbC2oqeJHZ0S9Q6RC1KAPY7j9xa
4RPmVgJfr3KmODRomyGZhLlOKtC7gu40u5kCvrBc4rcPrLSM3Lw14lkkryur
i8jaxgtcdXGhSqdlr1Mk4EzdYq4vdL+07F5PyxwltvJC6kDiJufXNhYHilPl
dlH22o2N4ud+775K62mrkxVo3KvM.hjCxXbCQrPLczOSXH6C7N8Y.+mwIIT2
rDeHSqyL.8EnWG0PwxgHEXx4BLRNfsUKMj9j2fHWOQRt7XLx.3AH4nE8Ozqc
wlHJZBfJ0qyxHp27ed02+O+l+0OTwK0mB7R3wOIShovoed97.Apr7BcXggcX
tayU6bUrLOEHYB7.wuAqXsvvhZn6Z5nRsB4cJ+s61V0p3b8+sJTBwB6.I.Hk
e8ZGzh8dLXcBiGSy8EgyntOXSqE8UQTdbFmOXtnVVsKbUuqrjBQpPl3To9Ah
jADSrSkql6VKNtxguoxWQ.D+hrHn12d3P9gxCAObnD1S9mda422DtrkwErcI
R56mOTXOwsIhGpPH2sdoVIWkTzkxAeAseZr65BW8bcT4oOhVxxc.MxQFLs3C
iiHDW4tQ3sl4UQavM0hYg9gUcUU6zEko39pwH3rrwS+PQGrwSV2y0g9+lDeu
nPQenlhPb3xViGAAQNhtprjeEgtwM7k4VVbTokSlxkwcoqbSD5ohAhnxSlEE
ET+TGjk.1CYEmN1OL7DPLKJt8Sl3u4wN9tqh3mbaW267yjd+tP4YumaRjcep
6S06gYbF2hAn0u8O6x4W3COEoLT6TRpnGSWmDEDTCkjm4oFNiG2.eM6C9dYO
leupZJvub+3RKnEGzwd9bW.Y0OVl6lz5GIMauDxqbncqJF.eeFaab.WFpeA0
lz2piVqRjU63mPnUTJ5CiEqxpIbd+IvpmpQO3mxoYQq9UZ2QdqrdxI+A4z.s
m4YzdsDGyMkb6EjIiDdpw2eBmu66AF.igCOXs.OlbmCmCO1WMvyZ93Fvc2cm
fDKscPB2BHY1MHcak+0GfYRkS5fMOMcRYPhciQUUcBZFu6kTp2KR6ye0tL4f
taNCd3DG7.jjzWGN3AfdhgbdVF7jKGrAIwpSrtZJGslgqkLVShDoIWMVgeNX
37WlWNdTjTOO16lxB6ZAbRbC8h1xiSd3PDUSPDzA1Pl4n4Ehl.efljKij2w4
OCt.4g2xRBh9vvgmK1GXdQGa.cvJfNv4AcVALaGXLaAX51uWdBv2dxmJNRiz
PIgfT3UCbsNZ6J+PlXFAV1UXUnVPNT+QLn1ntF4jfEy56UAoDO68.Ppe3ZN0
zHbvgr0wnuFImHzqFxIYoX9Cf2tsa2OXyIT2d3dHHxMafi.aLhcpyUy.vLvJ
v5.laxvAKhRrVxatZfUwZWCae0.OetH55gOVCosfqaLX.30VzjiBjfZCjZJj
axUD0sabLKzisMNa+XhqD5bYT2EvTiTQVWOb269U+tMjZI7IHcPgOMf7TfM.
XP6qmxsDGEruziG+yASgCI8F9jZt5jC1JK1B09O0EaIuSN7AolJXFpncmzMn
Q46sihFUNQ4rUVsTw48QNyyys4x73LKHlZxVJpbdGsbQcbN3kFsKYcoXVlnG
nduVrzn7COLOK+7wQthKTIk2P6Eh3STpWT1cmjdgf6VMrfL0XAb.8hpVxIdx
oRDNMcMaEAHzTZrjaIhTwXAcFRNw.TdKpjc7TZAYRtFTShpzpVuvdJ6ETU0H
VSYuvT0dAcp6EPUG3LoCeUBKLmRVVUGo1fSgolDwTQ9MQVYe7cCYY1N.Y7w0
AfEct6ZVpZbaguFLty6EvYEfTMdSqobzOQYeSSISX432d6Ejoz2DTYWjn1CZ
o3fkKJr9RS72FyBxok020lfnUtAEqBmCqgqFVFOu3XeVOKpPQ8XWA7E+q40S
Hoo0SHYQma.6Sp9QKECowDRgEapX6llSRy4aM2BoeF9KnXvW.vfmAQOwRBbi
GvJtD2wJtzRlvMglOEzNVy1JDeaZVTp613z+P8EW6g4n3bccp+lPwhLrblJ5
Rw5juWyAXXCKRd5DrFZqWdziPP9JUT4kJNxXbKUbngAUXGaxEWJzw.aIem3f
l0kHeJKnRINUPaCg8NxtSAGKWOzk66D6tUrZTROtFbTPsBMF8devVp8rLwE6
nl4RUFmv6Zf+1ad8qTmExvYQ+pJIqJgLaqi8OCXhTWWYXOZcUgyDJlNy5pyl
kJUjSqKUNI14dRr5aqofzHcpHHqzL2jrGDa7Bvm.uETtqTAvk2BjjFMrYTLU
GXniiCtT6akCGVRBo4P6e2.T5ieSXI1ws4Kzz7Im87YebxDu+xvF9hFsD5Pk
ayrlhEbFGL6eL5vdEWmwOHtfN1hJiSxDsDRO9h.mKwcP6hPG73IsjaU7+TPN
aStT0JAZTDq+7oGopumHsQWr.J4gLo3YjHZ.Vp1vK085G6s6ZFOKcekij2xo
S4UgTwEOIqDovPZZAvBwyV3hiHoUKasjyZABLa4r1B.zzlbo4M3RMLncWQMt
wV5xDvF0v5cBq1dCUwpncxhrXTk3psfT48q7vSSOtXn5mvfZMtvNK3Covb+Z
T5UYFvzwy2WZSfpaSXZhu18hSgWpPirsNWnmwPuGiPabwQnIsjmwPWVAPJS0
SnpUJZUzt3hcys8rQsWpPUOgJx3i3lhLkabNSU1MTyPMCDO1JxKY.uoD++zA
vfQLGG8bAHTTU.HZFqURs5jntfNxRPWN5UJnzYT+l+vaSVGnh4eC7.iGCvVl
xBMdjNeIP6klUdgH1Gd7rAgjYinVNqZvZ6zg9CYCO3oUq9lcnCtMnUSaLKCN
U.143KKKy4ZdXjSgakABC8g4WSVM3QFxlb8pWLTAOeSZQ8ciF3q4AGuYi3AU
GTY+ec8vL5VEkaYIXDa9r4xC+I6oy9UslNibh3JL+MUZWbNY94quUCZdaFTS
qZLHl.UBtQRBhMzuw8.eztaZOMOY2KEzI6Q6dK51ydHOCJeBDqr5FZ1q59vd
ATohHKmcRHhNaV3GdXrYvaVvPl2qwMvtX8DTDyt07InY7X1SEOib.O93K2t8
kbQdap5kg7xjVq5g2XJdFOx4UlukOgnFTCI50Q5Q1wr3oJdCKehYbQETtWmJ
BeEbGr0T0ZZwTzpr27F6sKfnob1brzudO1MjELfe3DHc+zaURCYZIqedwNLk
rzptnzcADShDOjW8p8n7KxqlyBNJV7HFy5vSJqEq1z2OnFzJ+sAp4ifN16hS
hhiRN7naaIoB9leQ02SSR39zUxXAne9JXzp1BorsExc0U3+YpVkaKakZJczR
lJzRNZQlLnykPIxHedZIp0rISlyUKgmMYBimMybrJvmcwV45BGQ4nhTg0iXg
TBAczPaYqRSQ0ASgMQUc0wKp9FJX7MsZb7Dsv7phXlupyzTag6CRIZw7WbWL
UooziTg5EAM0VaA6y72PCMkiJrhDczRTU7S5f0PKIlu+dQOanVByPoXmLn5n
sx2ZqvdaKjNHEUQpPzlIEgWlaZUZZcDNfJLGZwFAYLShDQowxl5B7PpDHOTG
sTeF8Xc31RoHovDcgd81RFZgeRovqMr0RagTNDiK1uOToPmLzQnnNJAgmzgz
DYnhsccBls9dwQ9gYokEAVtEUjS.rMjtzpg+TVQQayhUGOdo1i18zt4DRZXq
Vvt0d1AnKU1gH.6O1sKULIpTiCpV7rnRnGDcD6FVEiDhNhmRrjX62yhNRR2R
EOKV5vGFUEJXKcvJZoByjkN7qPUgpmpindUp9FXcXkapR.1ZoPJJQ5ZOSoLf
6uJJxJmexOILh17jeJXN4mAly+Ifo8e9WN8m9k7c3ea+ju7he+E+eXLjjs.
-----------end_max5_patcher-----------
2

The queue could be on by default, but our preference was to preserve the historical behaviour as default, at least to start with. In any case, for big jobs, the copying to-and-from Max to worker thread still happens on the Max main thread, so it won’t completely aleviate any potential spinning wheels. For bufcompose , blocking 0 rarely (if ever) makes sense, because it’s doing the same amount of work (r more) launching the thread as the object would be doing anyway.

  • I had the impression it was faster to use “blocking 1” and make a queue system within max ?

I think this is due to the above

  • Is “reset” erasing the QUEUE stack ?

[cough] Good question. Possibly not

  • “blocking 1” → “fluid.bufcompose~: already processing” even with “@queue 1”

Queuing has no effect in anything except blocking 0, I’ll see if I can make this clearer in the threading help tab. This is because in the modes, you have de facto queuing courtesy of Max. With that said, I’m surprised you saw that message in blocking 1, except if the message was coming from the scheduler thread into the object.

  • “blocking 2” → no error message even with “@queue 0”. Is there a stack, a “@queue 1” when blocking = 2 ?

No: there’s the Max scheduler queue. I think that confirms what I just guessed: that the message you’re sending is coming from the scheduler thread. If you turn overdrive off (just to prove a point, not for real!), you’ll see different behaviour (no error message in either 1 or 2)

When should I use the
“reset”

If you want to return the object to the state it was in when created (i.e. all default parameter values, except what you entered into the box in Max)

“destgain” commands ?

When you want to mix incoming content into the destination, rather than overwriting

It is faster to provide the overall length of the target buffer beforewards. But it is still rather slow for some reason.

I’d meant to sit down with you at the plenary and go over this. In the patch you showed us with a speed problem, you’re pre-sizing the length with something like samps <n> but you’re actually writing to a multichannel buffer, yes? In that case, the buffer is still growing every time you bufcompose because the number of channels isn’t right.

So, what happens if you use the two argument version of that samps <frames> <channels>?

What should happen is that the buffer never needs to be resized on your successive calls because it is always big enough for the job at hand (i.e. it tests dest size >= needed size rather than dest size == needed size) . I would then expect it to be much faster, because the slow thing is the resize calls to Max, and the memory allocations that ensue.

1 Like