Fluid.buftransientslice~

pasquetje · May 17, 2019, 10:42am

Hello !

How do I change the channel I want to analyze from a specific buffer ?

Is the fluid.buftransientslice~ “startchan” attribute for the analyzed buffer or the destination “slicepoints” buffer ?

The following example also shows my little concern about the difference between messages and attributes discussed here: Fluid.buftransientslice~ features

Thanks !

O.


----------begin_max5_patcher----------
2677.3oc6as0aiaiE94jeEbEVrO4ZPRQRIM.K1oEKPw.rCZ2sOzGlYPfrMsi
lHKYnKYRlhN+12CIkjkbjkksYbS1sAHN1xTh76b46bgL+10W4LK8AYtC5MnO
ft5pe65qtReI0Etp5yW4rN7g4wg45g4LOc8ZYRgyDy2UHenPec48xDTwsokq
tE9iLWhVKyyCWIyQgYRTRZA5iNYxUQ4ExL4hO5fBy2NjH08Jg+juQNuHMaJ5
mRheTMjvhhrnYkEx7o0yYbThbdZYhdhcqt3lvh42Fkr5lL3AX.DgvcmhmfD9
pWIddp+3Buh9T0MkTtNJIVVngFY6ESKKpuJt5pQKzvLc1m+NN2Qcse+5qUuL
4LEbuCsRV.xGjLKKMC8kaA4X3hE.TPyuMLIQFmiJR0hm73n4xMoQIE4nYkKW
JA4zujBx07hvrB0nAwZtTtVeGyjnkvCbO2XuBSZsvLCTfIEgEQoI2z+Hdp3l
G3OkOA4wHS8f+JHDk7lYA4MsdwtLEPPzWk5aGzpVTMbyMNC.MtPgEtqAZtbs
kj64iLReHixrJxVFWFsXJn1KxBSxifgnMG9FZcYdA51v6kfEzaiRV.WLusoB
4iNSQuaox1r4qifQHKln7mUxH312rQljOE88vCodP+U3Nq8sQfInxGtLRcuJ
Z.Yhhj3TM.cGx.z0Xw4aL.4bKY.x7t.Ff+pxwedbzcJwZpgOLVtr.A7egIqh
AI4Rz9zkSZD2KRkFwbLvzpeHg2GFEGNKtEi7L47vRfhF95G0zysXYQuuMuca
R5d3veV3sqHR7ITidDq4uEVPOxegPj3E3YWhDl3BPj7t7cB0nT8UwnPvRblL
SYiptpIHC71vBzWhhiUAiBSBie7qxEn+gygChPvZADWnChPsft+kRPDg008W
hfHiAYLgkCOxvW.j8uKk4pvL4n2LBHBnRAQhK9IXrLYgLSwwsCFOAf65aQfW
we+DfuMZsyP4P6qANE6p7KYA5ToC1mpk1KBI8fPV8jZFWwiajlYzwA8oS.kJ
XAgaJRSpev.RL.cH3gE7skHPw0u1ftnUIovvgfr2cP0ZVpxDPiQg5IYt5rUy
SiSyplO0D.Ta99TWt5cLOL22eh5KZKQaI7b2UuQZqIa8rwScYAX5jddS6mdK
k.ksUzjEtVBQ0uQlnRUnscYrbU37G6LYj8p6lX9UK5+TKa3D3wqm2uGxlIF8
CowKrYQTPBHEgIykUggFTi6apCzXIynVJ9B0l4VLZTXra4Fq2ijvk1CHZRi.
t6n0kqae2CYi.q9lgi6SN313OzqMyLHC2SyuOQ9EXk+DCBn.BntjEphUFRLR
M0HTwtY332O6FYzra8F3JX.YfMwN3jLCBC0opeL5sP93qVIyxQigumHzRDBi
cJD98XZ4RNVQxjSUrru.dMotdfPdU9V0FE91JjG0xg71GY3O8eF.cAATsh0j
+B2VretVj8KN5d4TchTCojvrVz3TCZTIm0fjYoYPBYpgyarxNQzQctXYjTkC
MkXpR30QJITqkRB4UWJImlZl2t0z++VdmD5+qj24lrTnDp7ATzlDLIBMOkms
x1jPtDcjLp3VzNYVi9K+cD4iIlMsP0oGytVT28w27wj80hx2fdWxlxh5VCge
PfmiAiPuETe7aZ0Y3ls8X39Ft2NDyFfbESlp2ZBgk6rHA+Gk93YQcL8DE8AG
TzyYl3ZLWgkD8A1rtq9Sn1Hi9FBv8iIfNfHPaU38fUOy9PvzrtArSonhdxfl
ejIPuLNMr37Jt57K2l6weNp1lcIK1tBC1tV6WckZ2MKm8GqKvHnBz96vqmYw
zD9XxV3IX8zwoY6JGz+l0p.QhoEhG1CW8ba24UmQKAbctPMNHNFkljCqj+18
ovRbHYfg+FpfTQm64eJjbrdJRNv4P43U0XfpgoVy2rHrHrBtU3U8EUAkprPt
xodTe.YDZJAl4gjGdubwMv7Cv6ls6b4tORIPTnWpjpa+R2up.sys8aWk30Z6
pp7Dsd2pndWrtUcP1lpvO0rMb7Qx1zz1qQy2PwWF9FH6STDJ5fQTXAl70M8k
6XM3c6gPU3LXXipJIaJnzh94gyuCpOFgOL0J1b7GHBlkZ.Iw+xnVK+ZjJEY7
A0qbv6UuK+tmBB6QuRCNndss90pJVo7tu0lC6fJXtveTwNcGMM99SSvTKfMw
KTvohgAkGtdyg6+gKjGn1ClXIOXF6v4IXS3VWB3HUvlB.w7y.z8DUh467LVr
2dP9dO9fuMOsLCpArtp32BPR+UHFG064I7vlITiKgKwVEMKbOHiPWokd9z88
XmiEsdQWe7N1JBMBgpGY8d+g1trWnNcII5dkzZPJMYqA0oapbr9Gdf.yDLc2
Z0Muk2sepM6tAoWc8nWthWUKWkeOhLxk6YMSJKmCKXXVXlniwhYmkSGUPfuf
x.we.Cyfbf0p.rGgh878wAdt95dxiodLWFw222ix8DcUOqiVTwpYx4zmMU6G
RlRnpHzjVe7LgKw8EGbgQ9rAW0199BCtDLjP8yl5keD387jrrWdRVR.uVTJ5
JYEmukzX3IbGBuA.N4h.pKEfr2DC6MUDPHr.OBQPz3EhBK39TpKgSIh8PiiO
OnPFCT5pesTDD5XB3siS6d7eHU++fz8yVOB8njU39kU3KfrhzIj79jUjJYkK
Eu8yVeACE.hnizE47n4FinQubrxLQFyLQN2DQFCjvC4YTk2PsiQmO9GRlquN
nCGkf2aH2rZIckWluv+4yIi3OFAuML80X9PyzN4SZqvDiYp2wDzVAGGSBxDa
TiCaLYPUyz8jhjC2r4dYVd0n0Shy5vOabv7mbsYuMMeT23bmL48Q0imquRX1
7aiJjyKJyLmSmGDlN63rNEDlIkQUpR8d03jW7X7tElu8H9TtHJ8WJBKJyu48
xjRSk+.pVFVFWzUTLa0xn33F5f16xScKBpHKlzreRsnN.BCBwWeRmHtdTg9c
va37V9nU2Co9lX75iGES.4TZNGVpCjkqlmYmaitctvj.yLfC7wLy6fKQ5vEA
xR0+kf59f30bLvTmVizMoY05T3VCZFeYQ5prvEpd5zX01rqVSprjxTc7QI1a
cj1bVCBzn56oskWix3eZj5.Ej5LWg94TUyWhFRkzdmVTYROswlyRKk2y9WG6
72tgUlS5RGif8qXvS848dPz9Pmihl8Q3IHowuNQ52QNDFWFVy1Q5rB2iVdLb
BM9K86h65IXdZghqOyknETrcbSOQu6QqPNINgt6GdepQqqACevaLFq+oVwND
xed1rwyID7mtEWX2h6xiifDd9UU1PCom18Pc24EKsVVG9fPsWQC5Ut+EBt0Q
9p43aeSThJYQYspBOo0KsYgCmOGV0cTq5Ds7cCzkegm5UoasKf0atzHk7f0K
j1FMPaeAY8wzuSkSGw1KqN+yL0+B63kwVvk1W.+nqY9oua.+5s+GH7z2cA8q
OmTf65cLNsnYyGGs0kVm0pbA.yvZ1hVVl858GhKkCmEUONitDEYtZYIZVfAU
761dA9iYRYxQuBMTPtpeTuiH7gxsr5hSehg+QHs1idsoDTXskLGny3Z4Hosk
7wu.MEiq2Ge0JLeSUVu5s6+5e+5+KkJUnZC
-----------end_max5_patcher-----------

tremblap · May 17, 2019, 11:14am

startchan and numchan (attribute and message) are for the source buffer.

for instance, analysing a section of a 4 channel 10 second buffer, let’s say the 3nd second of channels 2 and 3, will take

startchan 1 (we count from 0) numchans 2 startframe 88200 numframes 44100

then you bang, and you have it. It is true for all objects.

weefuzzy · May 17, 2019, 11:37am

Hi Olivier,

From the patch questions

fluid.buftransientslice~ must have “@indices slicepoints1”. If no @indices is set, nothing happens. A “indices $1” message or attrui is not enough.

These both work, but something weird was indeed happening when it couldn’t find a source buffer.

With instance number = 1
I get the error message :
fluid.buftransientslice~: Input buffer 0x60c00587d280.

As above, but I need to fix that error message to (a) to add ‘not found’ and (b) substiute the buffer name rather than the pointer address, which isn’t helpful!

Is “startchan” the channel number of the buffer that will be analyzed ?

As @tremblap says, it’s for the source buffer (true for all our fluid.buf*~ objects). Part of the difficulty your patch is having is because you’ve coupled the index of your dynamically created index buffers to a start channel in a non-existent source buffer.

When cliking on the left triangle of fluid.buftransientslice~, message does not list the available messages because they are attributes. Messages are as messages not “registered” in the inspector. Only as attributes.

This is standard for attributes: you can always set them (if they’re settable) with <attribute name> value, and they never show up in the message list. This goes for built in objects too (e.g. delay~).
Also, in common with newer Max objects, all of ours have a dumpoutlet on the right for getting attribute values by get<attribute name, e.g. getsource, getstartchan etc.

You appear to have found a bug though: I get different behaviour when setting the output buffer via message vs setting via attrui, and in the former case it errorenously fails to find the source buffer (which is weird). I’ll have to chase this down.

In the meantime, this version of the patch seems to work:


----------begin_max5_patcher----------
1547.3oc6Z0rbihCD9rySAEG1Sdoz+HlSY2Wio1JE1VwCIXvEHxFOSM4Ye0O
fGrMBjisyjC6gXaDpUquutU2sjxOtaV3hxWE0gAeI3qAyl8i6lMyzjtgYsOO
KbS5qKySqMcKrP7ukKdJbt8URwqRSyKZd7QQ0aAUh5cExuE7TYw57cQoYO10
0soxkeKqX8CUhkRqFozH57.NT+Ij.h.yCPnHPv+zJRQylxFYtPZTMps0rUFM
plE+IravscStaqvNxgOlWlJCmqlXoEqC2Oh0xc4ltDF9KcjUzoBntsed2c5O
l6IgnofEMRYYQ2PpPo7.cL.zYvnXEpQvX62VvCbBdbaqKVurLurxNHPsPfnX
NGgo5eQhATNet9E6Gm9zEoaF8XYgrHcikJ9qprz7f+tLeU2qqJaJVILBxzyr
NXToDQJpdPTjtvxifdNB8lYfHLIAflOvO5O2NwrosX5+LLXWuxEqSWt6.M.6
.25hREolms749MOkY9XuWT3GlgmRMVMdbzGmYG8+l8AM6v2iYeY4lMB0773A
aaU4RgpOtM8Dj1vAYI5uhMOfh6QKZqSc12MH.x2y+G5Q.Fv9tOL3MH7lmw6g
r.HXDrGi0vkPL9tIDCQj3.6INf9.I.neBR.3xgHqnVlVrTDnzvBQ0XwDrrCk
aSDd87LH2RGCOQkMRGka.E1EnvSXyUpNaSyFSe65oB.6a6TriB8H90fQht4d
LGl0vcjhDCoQSLDn5SGIIF.7P2KLt4nKUJqZx5FN8SsKGVkoBPNFpIVmDfAv
PNdhBBGB2Xm39lhYGQIUItxCJKpUi7e7RoB9iEgjogKqsvPH.MA5ImhdbR3T
YXM+4MSz1nFFOrJUl1x.sTf9EM1JdPz4sM00suZ539tpdyyhc8V5oa4kz7l1
InBksMaI8AEENnnHJ.6iznAkljvY9HMdPooTFwGoICKMGQ8QZ5fRy.PjORyF
TZHEv7hzicHNlF6i3bGhSfPeDOYXw4zDtWdLC6sgP3DuraPGtbHN0OOVGNcL
L0KeVnC2NVRhWdNPGNdIj3Duj2kqGf50pFHyg7Xne1uXGxSA9g+gc+3Thm1e
G9ePRLwqEeHfiAfEG60L.MrGHDgn9E7.gbL.DDyqUvHrqAff8KvKw8.z2Kr8
mpQpM6T5KhUOnRroxQ9ftNhLUgS1SqpeRHgpNzU6SbaybekxeusRrUTrJPk.
eryxgY2FODEg04tor201aFnbFL6SV4LaVjUHBpUa7VrsTsa8ZUh66UFl0qEU
0AvoKtSu6WylbtZaADEOdQO9xSnqWotp88UoHfzwJwWk+0VfmcSeTv4WrKB7
ox6PFrHHKHaxs0PRXlRbUaLbbHiGn9d136qo8LjN9nj93HgsoKeVsl.Lcg9P
KKXCVbl6xge4Fdz0CyMeOSe9OfIs7TLwhY74a4QISZ466A7afF1JDO+V+Xin
wV9iMK3oLqW.D9NV+iwSb5W9RB3qGIrVH0gACpS2rc5yBESSrgBfmuCAgL8l
c+MD.n6fQ64Gz0mbUtyesi4IOqT.sG2fomy8hQ3eBNWTGDzi4MYqhTzjrJsn
NSnHHMU8Vv80kMUKE6OR46U527p.BM391iOpOuBm1+pMHKAxO+KWjgmLhy6h
+LxXbFN5hWMvP29gjpkVZ0b2DK3W.YknVlUjJyJK50I8xitSU4DCmuZB5ilN
Z5bv0AkvYHBSeMP.PLTsWF8uPwDL4vaDZS1p10JVqG0bnwXHLBhzILf8d7Rw
D8LvzEoIc8YePZRkbL.MglzUMza5TVsRT4dssupF6iKhQ0vK0vw8PS5i.8ho
S81tlVSi41m.HPiaOE.PrDiaOFwYrQc6Y1MGQUaUx31Cw8e9TKG316zbDJuR
p1KBlvcSvlq81bK3TeXTbBNhoYTNp2iW6kBlPtPOQ0ksTvG9CkbszDzGMcoK
uQ9.o3ClMGYroVqKr8+olCd7Rmbw9DkCeKBv5kpOZA0UZYZWMDiiZ1ItY1Jb
R2t8EQUcauMJQUf3S1Ewly0UeCt1GM02GVIdIqq+lyLLLsRUXmTUUWSks5pW
Y1x9C2TpfXQSVKAqz7Ou6+PjolYO
-----------end_max5_patcher-----------

tremblap · May 17, 2019, 11:49am

on most buf* helpfiles I compose a stereo buffer changing the source dynamically with a message. I’ll test them now and report back.

edit: I cannot reproduce with bufcompose nor bufHPSS nor buftransientslice…

pasquetje · May 17, 2019, 12:06pm

@weefuzzy, in your patch, I get :
fluid.buftransientslice~: Input buffer 0x604004a75480: not enough channels
When changing to “startchan 1”.

Sorry, I am a little confused. Since “buffer~ resynth” has 16 channels, shouldn’t I get results until “startchan 15” ?

weefuzzy · May 17, 2019, 12:08pm

Two bugs, but I’m not positve that one of them is ours.
(1) Reproduceable crash if I set indices to a non-existent buffer. Easy to fix
(2)Strange thing if using the trick @pasquetje was using of calling set on a [buffer~] with a name that didn’t previously exist. I’m not sure what the expected behaviour is there, but the side effect we get is weird, as the Max API claims it can no longer find the input buffer. As far as I can tell, we’re not doing anything wrong, buf_ref_exists starts returning false for the same reference.

See here


----------begin_max5_patcher----------
1057.3oc4YsrqahCFdcxSgEZVLphFgwbsaZm4QXlkippLfShOEriLldNQUsO
6iw1jR5AHANQsQsKBD6X9u78em740qbx3OQpc.uA7efUq975Uqza0twJ65UN
U3mxKw05i4jyqpHLoiq42jjmj58+mFF.uCSYt.bYIfVCdjTV1cLVSEkURjZZ
.sad.Ky2SY69ffjKMx.D4swyE36quACCzqTK.u29PzBM63YO7ZXZOxyajcz2
qi9BRsRTwRJmcFOf83Q2kSLnVdrjn4gS6FeY851KtWI7zhGYMRIm0IaJMzfP
yFK7R5Ime65PPguWG02xYRFtxnA+kfhKA+MurXXjBY2UvaXEDM4hZ4SmLITD
RRDefvvYFP4RXqW5TXaK5jyK4Byo81fBR87cG3KvdOUIYGN+3YOaGrksqG4f
F1Emj3iBa+VPrWXRx4Dqm40tiAOjGOPLjQ8ClOZC2IvdGiqzyRZ9G6K.m7+C
Wh2xXAS+KQBxv4eDH4fG2ik.pD7HtdtdPggg5vHOzlv1noIcgfwKJZxxiXz8
cvTnIwhEJlNXBlbeDLcRl82D96UvTvR7VpH003cjmELUqXCYP+E+I7WBzkdf
Aws2PglrZi3uDMrCAbFnD382vzG8pESDBt.XgF.NSwYvqnrCMxWAdyq+SP2y
VRYjbkiqrOtLyp1v3vdUsQnQPKzBqZ2mG28Ussx4ERzDbuT0NYJr8W3DMnaa
UaVAPtW05qMdaCfxJTIepA064MkEf78X1NhpCY0AyZ1tkHTMJ6pKw6BDjVOf
h2NbLYvL8CQPcTXhMjTaTiFyOzaQgjHXjl3JNEdOGR5mj1SNmNj7NozOxy.s
p1o+MqzuuyMtPnhcUpIROd1bofENXpsefKzJczzgS2c0pLJ0EpU4+CNx3WXe
b3sr81tRL+Abt83ZyK5mn8BhltGW3OodbGsqd0HxyWkQl4Tspb.ZJUN8dSia
miwegFYaLd.bJMN9mjFyHOpX+yTXSGReEL9.bvKZoQ9Z8NdRm6QlHw+506sk
brrMOPlpAukABmmS+pSgGpaTvOx7lROccH0L3EadWt1cISLuQjS.OvY6JOtA
S2NWbHUasiMCsihmxZ6eOXsGAO1V1PK1nPEo.ypopdZzN+eE7NKBYu8tSCVr
jXCqSCxLb.xaxjBvWLboQI2uO4flW5Yb9t++As.2t+4vmQysjr60t.9lHWPp
kTltQ5dGJ8ryTQKNvUkpq6d2k12FXT6MTh+oUmdBtnfnaYvaPi7MUVaqwdsB
qeZxDBK7kIrvqQXmRVsRGx1srp0htUiDrbshVv0KYuH9DOey0MB7SuBNi9Ao
goCqfdOKJFe3vmHhZ6Sq4oJc2Cllsic0KoLyR8DANBxmncmW+pMbvBUZJoJG
UivjO4oHSAKmJthwrFpEbUb9Kq+e.qIHpD.
-----------end_max5_patcher-----------

weefuzzy · May 17, 2019, 12:09pm

Sorry, I am a little confused. Since “buffer~ resynth” has 16 channels, shouldn’t I get results until “startchan 15” ?

There wasn’t a resynth buffer in the patch you posted, so I threw in jongly (which is mono). If you’ve loaded my patch after yours, it has presumably overwritten your 16 channel resynth with jongly. Sorry.

pasquetje · May 17, 2019, 12:19pm

Ohh This is because I was too quick with the explanation patch and did not close my main patch.
buffer~ resynth was initially having 16 channels. Then instantiating it again somewhere else with jongly.aif creates a 16 channels of jongly.
I love polybuffer~…


----------begin_max5_patcher----------
274.3ocqQEraDBBE7L7UP3r0Ht0cM8WoYSC59zEiBFD2pYy1u8BOzzdn25dA
xLLC7lg6TBuxr.Sb1ar2YDxcJgfTABxFlvGjK08xITFWCeZp53IwibvhCoql
aZ.6WLKLspcWYBl33tH0ETh21K46b54AktGb3kJ9gzL61Yy2XGkt5qJc6GVn
1EG0Ch7zhDl3TItIJRyRX44oYryalh2iacDhN3M8Foim3mTotkyNGj8fRCKI
O2n2Yzs8qoRUyeT.hmSAbJ624+P4+J+nItbb7FXmTFMVAgBvG+NiM.KSPnRG
gYHzB2T65KPFo0OnN+TNaw2kub7Udzp4BX0yJLszPo6eRrZ0xAXZTVGMD9An
OneCHbCoiB
-----------end_max5_patcher-----------

tremblap · May 17, 2019, 12:25pm

I like that.

#2 is bizarre. First, renaming a buffer with set is a strange idea but why not. It does not create a new buffer though, so I am puzzled as to why someone would need to do that. For sure, the native objects behave with that, but that might be with the dirty_flag we spoke about before?

weefuzzy · May 17, 2019, 12:28pm

No, because this is to do with responding to a change outwith our object (rather than propagating a change we made). One hunch is that something is wrong with our notify mechanism, so that it’s messing with with the source buffer ref when it shouldn’t. Will check after I’ve zapped the obvious bug with non-existant output buffers.

pasquetje · May 17, 2019, 12:40pm

There is no order issue with non existing buffers on other Max objects. It simply does nothing until it exists.
The external must probably not check the list of existing buffers and blindly connect to any buffer; even to non existing ones. Or it checks every time there is the notification of a new available buffer ?


----------begin_max5_patcher----------
799.3oc0XE0bhBCD9Y7WQFd15PBf.ctWt6uwM2zIfqHsPBSHX0qS6u8Kj.W0
VvpzZG0YDkk0r6298sax3SSrri4afJazsneirrdZhkk1TiAq16srKnaRxoUZ
2rkvFYbsTxY1SMOdUFSpeTmgkbljQK.sweJxn4newyWz8XVcQFKGj50C2Zrj
JSTKT5cBHQZxGLIXlyTDYtyLe0GN5aTWQ+40EhWK6VI2VqBdMaArnwz7leiw
pwQ41Rvr3pj07Vm7cqXC3R34bgwImYtdQNjo87E7N4QlNX1736uIx9+3Qnp.
RPbGvnw45n1kKwo6DCbCrblEDFRb8a9lWfieX3ahPJiqJL4YIOraQKGRoIa2
Kow6fDcV4a2X34ISZtL8hij8CL7Zv7qGRFGdwwxdW1rbWqrK9Jhk8t3XY2wv
x6yvGKi4o6GcizTkOt65.DFdHpIlxRs6s5N+fU2K6YVDrQ.SthTy3KN0LYLp
4DdQAnpLucw9wMMuPLNBDBt.AqAFRthWmtBkPUljnEbnR4fDAaxpjnZlLKGs
kWiJEPUEZEHfaO4AadQ6HEbCb+.sfSOLiy0wr6qI09k2Fz3wPxpJaLHFlOG2
PcbjeCXMG7x0ePljbHNa3A6jio12fkpr+psQ7lMl48L3QU7d2ffR.d3k1V9d
qOte3ldtQFkd3GTfFbWuk4bpr2pyb6yeAf+.74J.XWMxwXSuN4TllMpinL.R
djt9ShjnfiCHCxjUpVdUeVeTYvXPZgZmFZJ7NnVAxCATxANLhmmQspwH1IZr
h1dAo+Wnd8PXujKoRNbxfOhX9KBzntcmpuLv6c9aViqWtDDuzgeE+4bxmF0H
.5lZgCF6XcyTqCMamb9KHIaSxUM8dt9irevz36aFjcVZ72aqbsC14Yr29uno
SsF66WCp30hjtfzti.50raATIyXTYl5bcu5Ct0odKyGaf7Oh.Q9Bhi22Tbvj
iHPuuvYHLZY4ZPT05rNFJ448lCuENUeaFybqdWNaArNqyeesEpPo8jJgWsvb
lrMyMSLrK3K.AqNSqvlzfNUH0R+lyuUURM.Q2gL44I+Cer9AqC
-----------end_max5_patcher-----------

weefuzzy · May 17, 2019, 12:54pm

Yes, this is the first bug above, which I’ve just committed a fix for. It would catch if none of the output buffers had been assigned, but not whether they existed, and would then pass useless buffer references to the algorithm.

It is now cleverer:

If none of the output buffers has been assigned or exist, you’ll get an error message (I disagree with C74 on the usefulness of saying nothing at all, at least for these lengthier processes)
If (for a multiple output process like BufHPSS~) some of the output buffers don’t exist, it won’t try to write to them, but it will issue a warning, ex post, that you referenced non-existant buffer (presumably by mistake).

weefuzzy · May 17, 2019, 2:32pm

A fix for this is now committed.

Calling set on a [buffer~] box has different effects depending on whether there are other instances of a [buffer~] box with either the old name or the new name.

Two [buffers~] a and b with different content. set a on b will destroy b
Three [buffers~] , 1 a and 2 bs. set a on one of the bs just repoints that box to a, but b’s content remains
Three [buffers~], 1 a and 2 bs. set c on one of the bs will make a new buffer, c, with b’s content, but b remains (e.g. call clear on c, b is unaffected.

I’m sure there are more combinations.

For some reason–and differently to other notifications from Max–the notification message produced in scenario 1 will invalidate any buf_ref it is passed to, rather than just the buffer affected. So we now filter notifciations by buffer name!

Note that this still invalidates the reference for the buffer in question, so if you rename a [buffer~], then you need to update any objects that were using it. This is the same for other max objects (e.g. try with [groove~]): if you change the name back again, the buf_ref is revalidated. I don’t know why it would work this way.

FWIW, none of this is at all explicit from the Max API docs, but these forum posts provided a clue