@startchan not working in fluid.bufonsetslice~?

Bug Reports and Issues
1

I think I’ve found a bug, or I’m not understanding how the @chan messages work to fluid.bufonsetslice~. (I’m leaning towards the former, hence this thread)

I can’t seem to analyze a multichannel buffer and store the @indices in different buffers.

Here’s a simple example:


----------begin_max5_patcher----------
2782.3oc6bszjaaiD97L+JPoySTgGD.j6k0I4P1C10tU4spTa4jREkDjFNlh
TEeLdrSk7aea.PRQJQJQMFZFmD4Chj3AQ2e8Czna542t8lIySeRkOA8OPe.c
yM+1s2bioIcC2T87MS1D9zh3vbyvlrHcyFURwj6r8Undpvzd98okwKQyUnE2
qV7wnj0nGJyKfmBSRTwHR8LhiRTKRKSLSiV031LUN7VCKhRSl0+HBKVbO7Vm
koVTXIXYfbJ9NjmOSegP35KL3AzuVMojxMQIwpBCoS10XZYQcq3pViVZXiz4
O7cxI5l98auU+ycWXbgdbb4PtNfa4ZbfkqYNhqEtjqYSQ+26AQJZG6uLZ0JU
FL3+Y8nWklTjDtQYlw+RE+npHZQ3jgYceNQyrBFeJGP.pUfKNEqqWmUgKTmE
b30lJyi9hY1L7TrCQI5TzOpUJPpvE22nQrJMCkljqIsQacb1PISXAOtu0Dx6
BBkrW.njLE8tvOpPgHXDaSyiJTn4kZMtms1FiRLpYFkMVvkDgnNDg1nxyCWq
NzQjpvBH6Pniv7BqOUAVy7UNYnzgXdZuLJoGFUznLXGXwm2prq3jIne8YvtO
jWFcR9fhYFQI1xUX+yyaYirMJV0nBsJtLZ4T.ReLR8ooOzXr1gaI6HsLXhEp
rYvaXdrpshfiPhgD7DNn0hDDOuoHBXo6OEQkDcaLrjhgKd9D8S9dX3IOA1Gt
vIRB3ehyjfN.RfCnv7DvP0W31WojC9MPh.h9sHIB87jLodjRNU.8Ig1fF88B
BfWV.inmPf.ZFtDvzijfkXr9JgRLOS3T8bfWpOiNs2sG8FVfy4zoRPVK.sU3
B02rMovApt7fIWEXWNAF2Kv0BLeGKvRTeBdwGHu1h9kIqT.iUss8uL4HNjp1
p0CDt.2Z2UYXGqjwyrhiwrsoGXKQKKVwiV+ZOpxxgvKZ85uYR31ssZ9lVSQC
LOjZdQ920zTThsIbSSYpGipm+tAFlAnRA.IkYVeoOIpC2R+ZRWpxR.u5ZRw1
HHhpHIivP6CNea0lrFYVc2sTqrgGiM.rvCaCyAuCnAg853zEeTsrMIOIcqJI
JocDWc5doZUXYbwr1aTClc81ecX.81Yy9HeeVTXbCCrNKZYZhlH5HIzMWube
.YOoi92cLiYDIga6Yxf9A.KCzYNvjk4yCyzBppMln0cVjlF2sql4EqVUT081
HHt0tnXQ51g6LKZ88GYtySgN2br2som7YkI1dmA5DEyxCerKZWDFGWYw180+
TXRzlvBH9OqH.7dU2ocy46yWjkFG2ges87XO8rDzwWn9Tzxh6MKTakAX3Qaq
UhlzHkWFsVkWzsshv04caIu3yVPuUSkyqrgmUn1rMF3htCny44aav112Vm1O
lOtt94JPQnn18zm2brMtQqSNw9d2FzCWOd4ns5o8oI7aSBG3rKRe3.6EqO9a
p8yW4Hw83xWhQqyRK2hDm.bjlStyvFXIvDR5wAG54BNAGEaz.yKFpT9kHDFg
Gk9B05QaL5KCCIr9gDB8nXx7vj0Zbo95KohyVk5i+AJOFbejSGktC0ZX4SOM
PwFDnHC.TjiBTqhSCe4fl0JXeohLTd3ls4iymC1bwm803yY.cHwoMqdIMsrm
ierZNDe+V9j8uH9jGglSsMlSAICMOJ0CaDfrleGl6wmqgC0+zdX5rb0Iwp8N
2l2YxR0SsB60IPjkdF2NSB4XAogUQvC.Rc1Z5Yg.6B1Ue1xAhxwvb596GZxS
KyVTKYpEdntLJD1VQTRSr+enwGfdbiRxbtDgNlFDYDDgdyr8FXZ1R6I5HWNR
COVR6UGfBNXbahVtME1UuReA7+oC6pp5IBhM8fA6oq2.p3KB6HFIlVC9WDhH
XjDAM3BRDhQJWYWPZPG3ynPhKIPXLeniwNiLHUT0Xc1RlnOR7xY1i+OSGNUz
7xBqiy1o+4rNl553z4gwUGBsIIF8bJ1a2QbtIMa8G0Su63aygXUN1NLhmwji
MZe4XiLXN15KFmyjsAYSAHANRAoXD6tz1jF176WcpCwOqpT774zQIfOVNTYl
iKxoF4qLvUxWuKp7c.ttoNR1jGq48+.8Fq+gVEy7MPnQZXoBcPuAXGcEiyA2
muIuHLqP+DBeZ8GcEAzECSPcFtgmbTkj6bbB2edPFcHLiLhz0S7rXlyz0X9W
HLav5+Zgm4Yk42qxuCo2coEFbGxtrC+cmHMFalpgScWAgYxWnppUw+OjlrN9
y6y93Sx91BIyr0nxlpAmv9hWlZT0XxXMOz1KsBunsQy46Wo5aEfDz5CkvIlH
durtUp2+YLeeDd9Feoj.6GHA1cLM6UXOnZNux4P80ogQqFAFvMYxlvcGFPdE
w.qChpKiDArp9DF1YH.9U.ANq5XWELQULXtqN1Tx05XesN1Wqi805XesN1Wq
i805X+ms5XeNkwVxuVF6qkwdbJNcqh8g476ZUruVE6+9VE6uYpk2qdUM+KVk
h+SV42e4+9D9l3623ahpX6fBH+MQsz+FuJ1FdqquaaN21Gppx71gZrrNNJGx
SsN620HzA42a7qk7kasz0Q9zqkW2Q008vkdw65NcOm2O+E2aTKNk3DIp+XVK
tvEqEkLp0pZ2guRA3nrJ3AtXsDrwrVB2Hu7F0ZwNXsrNZ1K205kYubVuW9pO
LW0Cmm58yQswmqMec64baWZdKWFk9dSxVm8NURo0mYcJg6BFyWuJJNdQZb5A
opu9jESr81jV75w9ADdJMviP7AXYJivjTg4N3FNu8ts14PpmjG2K.S0C0SPk
dbyc9TFmouCu2zn6VKLIvtB3.erm8NnIBrVsmFbLnpjKKakgzsYoaSyZxx9T
VPy3KKRWmEtLp5fB3N6nbWktj9uKB6mlzIa..MpdNs08ZDFusr9+A6OeAPCw
MfLXj3RWofeC16Kwbee6c9drdmViTPvgEQOVg9eR6c12zEQHzyeZ..Cx+8VU
B585Rf+d0ln4owK2U4ovEKf2QGHhQAUNCt3US9ZkTcasHZPVzYVAXOhzLM+.
tmzvq9dz.oA03hl4ohUa1eIk9.5XgWLw22dGr5TZ20ryj7jbByLTZ.CVTycb
BVrGglCq3BMJ1cIov.MLGQHoViIeLl30cx5j6Xl2rnDseKUihDKfRD10r1Bk
1VivIFD+muuXlYZ3+JYVL5ocYsKrU36XlBiy98PSAKv02cCpMGv0aOXsU7jX
irPKJX6oMuHVAa+salliwCSGL43VREvTIajZwl4V+S6YztNpevTIUGoQ+w73
HXO5e99luGk90o2mE67iinkMgOIZpRc+jQOJEV00FyeYkAyfJD6Q9f.94HWb
FC2J4rmD4AmrPjFzf16Ancy4wItlr57Yt4Z2bsbXUaGe3cGwgkzWGw0c8d2g
S6UKFL2pU005XbRw1o0dDZWFZoUDts824DMKa0Z9g3R02QNSybFQBNhMdTaH
v.cSjK.Alk9ojylB2QW7FaS1EhB+wOGd9DHlBgBZcRJYLp0ZiRHDl6IveJSo
dFTnA8X5+YCETGZh6It2Ad1RJBOaxy2CKD1XSEXf3LPoHfDvcOM9+Twwoe57
IQHjao0eHw2D+BlCRc9oBmfGfw9thAJ2LWk8SvAaNaxW1DrEG1Pma3DRaezN
g.yrA8noviuA24Qa8EGovCzXBprzjUmCCjGAN0laG+3dDu2niwRB1Lz.lm.G
Tc5RIwoFBEgaOFyr2wGdaXQJ5s5uYtIOm02lNrA9tIu82u8+CqjnlPA
-----------end_max5_patcher-----------

Basically I have an audio file which I’ve fluid.bufnmf~'d into two streams, and I want to get the onsets for each individual channel separately.

Is the intended workflow to create a target buffer for each channel of the @source buffer?

Ideally I would just feed it a buffer~ with n amount of channels and it would spit out the indices into an individual channel in the @indices buffer.

2

We decided to keep the potential of very sexy complicated multichannel attack detection for the future, so at the moment we do the simplest of them all: we mono-sum

I’ll check if what you get is a bug later, but in the meantime, bufcompose is your friend for what you do (which is in effect multimono)

p

3

Just so you know, if you look at the helpfile’s didactic example, it has a stereo random buffer in and gives you the result of the sum of them…

4

and I can confirm it behaves right - @weefuzzy can sleep peacefully.

I suggest you study the helpfile, with the startchan changing and the numchans set to 1. I get each channel independently that way.

5

Did you check my example?

Regardless of what the @startchan is set to, it spits out the same results.

In the helpfile it appears that @startchan 0 returns all 6 onsets (mono summed) and @startchan 1 returns the second channel’s onsets (which are also present in the @startchan 0 version). I can’t get the helpfile to tell me only the onsets in the first channel. It always returns six, which is not how many onsets there are in the first channel.

6

Ok, so if I use the helpfile and send 6 random spikes I get 6 returns. If I then add an attrui and set @numchans 1 and @startchan 0 and bang only fluid.bufonsetslice~ I get only the onsets in channel one. BUT if I then set @startchan 1 and bang again, I get the same results.

Steps to reproduce:
-open helpfile and send 6 triggers
-(get 6 onsets)
-add attrui for numchans and startchan
-set numchans 1 and startchan 0
-bang fluid.bufonsetslice~ again
-(get however many samples ended up in channel one)
-set startchan 1
-bang fluid.bufonsetslice~ again
-(get however many samples ended up in channel one)

7

this is bizarre as I cannot reproduce this behaviour. I have an attrui and I look at the buffer and I get 2 and 4 (out of 6)…

edit It seems it is not consistent. I’ll fill an investigation report.

8

Here’s a video showing what I’m experiencing:
https://we.tl/t-FLFmF7tSnE
(link will evaporate in 2 weeks)

For me, it’s 100% consistent (as in, I never get individual channels).

Do you get the expected results from my pasted example?

9

ok confirmed on all slicers, on all CCE. Nice catch.

1 Like
10

BOOM!

I was banging my head against the wall for like 10-15min in Max trying to figure out what the fuck was wrong with my patch. Then decided to isolate things to see if something else was going on…turns out it was!

11

The moral of this story is that not all loops should count from zero. I will fix for the next release. Only workaround for the moment is to bufcompose away channels that you don’t want to be analysed.

2 Likes
12

Since I’m working on a blog post, I’m going back and filming bits which I didn’t film during the process leading up to the performance.

My direction of movement select between the two decomposed layers, and my position selects the position in the buffer to play back from.

Sadly this is a cool one that I wish I would have somehow included in the piece. Even though @weefuzzy suggested a suitable workaround, the friction of this was enough for me to backburner this at the time and the overall idea went on without it.

Posted here for posterity.

1 Like