writing and reading in a buffer~ in the same block
We used to be able to do this in Max 4.6: indexing a buffer~ with count~ in read and write at the same time (i.e. putting the same address in poke~ and index~) and we were sure it was working.
Now in Max5 I get some nasty artefacts, as in the very simplifies patch included.
Is that normal?
----------begin_max5_patcher---------- 669.3ocyVtkbaBCEF9Y7pfgmcSkPfA2255HSlLBPlnVPhADicZl3oKkNcozk RWIUW.GkDahClZmWPvAIw+4iyE8vLGuD9FRim6Wbu10w4gYNNZSJCNcO63Uh 2jVfazSyqjzzfyIdyMuSP1Hz1aD7pdir1RJqfHzqvuy3JNSzP+AQYa4UfmlJ uUzOWXmUiIw8UDiz77buo6UUXQ5cTV9s0jTg4sA9p8yEs.nF7iTWggWA1sF0 mlgK0al2Wqo3hdkRyz13Ie6SHOkoGmMScY9ISCbsXMkkwWegfBJLxBJKBGGT BFCTXj0x09JljgS2dxv.LfGC0tJZoNZvDS.idudb3X73TdYIgIdkK+2e96+7 KcrvmU4Gt31LJeuL.NQLHLVyff.s2C.iCBKFCDpvLRwfN29ciDdcFoNkWvqM NA3JzReXXzb4cQ6tCBiVDHuCZ4LlkZGCsOlDzwDCL7Qpg.j01TyaYYjLaQYA indeJI2RjP8lYew8lQ.sbLkMbVwygl+gJFzPyYp+ktdTYf3PUFfwHCHLYHZ4 qpRraMV9NLtWa7ZpLBGKnblVGSWcgz6SKHacCB.++JU1QmAwRTrImQCjvfwk 43ilvJlox3RwVWfjMxT4KKcVZZtB7UCQnQRmIDNIsqVQp25VfushjgKHpxcf St35ASvVUvwBU9UBlkOLqL4Tn.SSWvHgEbBgk7jHjMVr5hFKgfwlCpoAS7Xy zlxylTw+N4svCZZZQCMsi7WnGhhFm2i.1dudsdET1KOKu96qr+bjzvaqS6+i YRLksX2ofLRifx1Uq+5c.2dR2QyxHLamsjlUwkce5zvA5GdrRBcDRJ7rpnfO bJR0d9MkjLT4bpI+iURvymj938m6nkzYjRGSF2Kh3deZR9viy9G0rzbR -----------end_max5_patcher-----------
|We used to be able to do this in Max 4.6: indexing a buffer~ with count~ in read and write at the same time (i.e. putting the same address in poke~ and index~) and we were sure it was working.
Now in Max5 I get some nasty artefacts,
you can still do this. start [count~] with a bang, and it should work. if you want to stop/pause recording, set the sample index (second inlet of poke~) to -1.
but i remember some funkiness with the order of creation of the signal obejects, so you might still run into problems…
this is a patch that makes sure it works, but it still pisses me off that it use to read than write, respecting the right-to-left rule, and now it seems to be random! with one Signal Vector delay, it works…
can this behavious be confirmed by any cycling coder?
----------begin_max5_patcher---------- 778.3ocyXtkbaBCEF9Y6UgFd10EcACtu00QlLYjAYG0hkX.4INMS7zkRmtT5 RoqjBGQvDWbLkfo7hEbDf+0mN2fmlNwYkduHyA8IzMnISdZ5jIfoBCSJOehy V99vXdFbYNJwC5UewYlcJiXuALGIh4Od.gcIrWlSFAyje0e.WYTuyDKLlGSD 1+TmL4FEO1Aca4ErVqLJ9VXZmOmJymqblDtI7doZycohPi8twT24tyPjE3hg EvIX+4tu5okI+F7zVlOq0pZ2VoJWFvJhbznUbfUbgwmmNs3mYuSzjkjY3Fwg l.C9rfQpLNyPNqi0b3fxyKF5FrHKn.eHKgAp+bu+cZgajVrdjVuoiTvUxOZI y5GQFC9QaEYY7Mh+BMYFcRCLgdVlzQZvrdHTKGH9.M7FezfmZdPphzOz.TX8 MTnd90fxBu+uP4bAO7vlxx34zoULFVpzkf2PYVidInvsCq3P81shhTfmrj+8 2+4u9A3K7wh3CDeWjT2.CVzMF3E.LfA4GvtcJy.t2fPBWIpj6JcZjHMTGqSs h0cNcIA64OK+H+pivX+Er7iv0DcMt3+VqdV4p2trIP8CFs1Cxpg56zq1TSQP Y4W8S0c1HgR06TQBPbt8Fz1vkpFq8dwhImVtsoJGLaQU1BXnpOjp6QmJyca4 FoVcR.wkhRH8WdgvGCiEGPLlaCbfPuVMmEXYBL3wFkMmEl6wYNfbyYSdzMB2 DetN3g3CMaPbgRIAiydWWsa8ZQ5ATL+tDQDOVTjCrImny2GaUCrq3pMc0UxF XQY1xttz9KMbOFkk2KhXeMV0juzU5Egn1fLhOPlfwYrVh9qh2FOT2NUkFyJa QABh786xpmdw5MvSyIVpN8ElAEUX+0HISuKM7kc2xDIniZJRjYjppBC2bzAo 1EcuLJRnpWObqLJQmWUpTCnaab+o0Rh1BMUTnbH0DqEZJukVDd7IogiRiOEQ GcJp3qqTyK4LQbCpmDHIxEjTvv5b2h8sgMCPPKTTQohw19Vwm4bH0DqsbZ.C 4ZydG98TjK+jmm9GbIqOZC -----------end_max5_patcher-----------
I don’t think, there’s anything wrong or random here…
The first patch posted didn’t work because [count~] doesn’t get started. So only _one_ sample (the first) was read/written.
As volker said, send [count~] a bang and everythings fine (without needing a [delay~]).
You can even feedback the [index~] back into the [poke~]. This of course introduces a delay of one vector block (like send~/receive~), as this patch demonstrates.
Quote:it still pisses me off that it use to read than write, respecting the right-to-left rule, and now it seems to be random
BTW, I don’t think, that the right-to-left rule applies to signals.
In the SDK there’s a Z_PUT_FIRST and Z_PUT_LAST flag for signal objects, which tells the audio scheduler to put it near the end or beginning of the signal chain. But the docs don’t go into detail…
----------begin_max5_patcher---------- 1222.3oc0Y0kjahCD9YOmBJdbKurp0O.ZeKmiToRgAMdHAibAhLytoxT6QYq 8nrGk8jr5GviyDaFjCCw4gYPHZi59q+TqOI97MqB2HePzFF76AuMX0pOeypU 1tLcrp+9Ug6xdHuJq0ZVX2NQcW3Z2S1moxuqrd66aD4J2agBnnXfwnqCvbHJ EALptcRZDR2CJBE7t9ebc2tx5Jgx9dg9NKKrihbyG9UZ5vvbqrV0V9mBqgPD iyfzjmdKxN0vqgz2q5O1ODVGFOmYlm3dPXYsJbcPn8uCVUpD65+kf9Aq0OE2 ek1eMs+JD22fLXQ7fI.dvHLavJFLXFfvCFhQzAKoH9foo.GeviLQec1NqWG9 llxrpPyC9xM2X925Il21zoTx5Il3H7HBmfhicoLeSb7vSlbfykH1jUuUmAtf npVbudDGFNk3AavDlUzpxTcsAska+T6DC5XllYkf4Z3mNdLiOQLi8mrhOGdX XjFx4LSAxk6zSdUeCZ0H1KaTFrpNqJ3SZvQ1DXBgf76jk4hQAPbZDF3oflEi onHJEvXhlhmP8m2P7GCQyJBcF5TYcg3gGCpxd+dQQVkXD7ffryWL7Jz.QBR7 gHAmBD3QH+lR4RlyMC56GefXtERRYWJ9fthwmaqj5wervmaCeLXCbl+0VImd QQ7Yh+yVhQ6oY1U+5q8tDzje4w.TDmyGkdjXgDpCeh8tNLI1K7Yom+zsainY j3GSIlPlfRtT9Aad3G8ZiVP1grVuLTk3QcTiPiQQRbPDwdgi7mhP9olhvsUN A9EWAAe0yPTxsaGcUD2rDfSFhdew.jmJTcpwlOx9NgpQp2GvnLcWThw1pfIf 2Dcb57PzWvh.4Uk4e7wwvDK6GyvNUVdm4wIW0S9OMprW9QwDkW4jcSQVXJIY b4UjSfOXejWsHpuKZ2a1Mm3wQW2zpqJ0RK.RRDar39D7BvKY2zWnn3A0U82+ JrYtch11rshuAsZUx8iM+worhF61dlifv7Y0yYQ98xgFYMp606OQd+XaZKAe DnDy7FTnWkfx4lOkkO5TIm.CFwsrJ26cnw9wUA4bmvw+8W+y+92VtvuYleDj 0UTJGkPXW5kRsmZI31SuW0Sh+wAB6ypEUCC+FYSgnIWVIabgFJhvw.KYstUx gV.jDS0sfiBwSgKw83hae6X2cDOvkCK+1H6pKDEGG9Ne8XV0ogoMaOJdrR.9 p+cQ5z1lUVO1rBlS2QpiIXGpXezhAogiKutoTSbyTkx5QUc2q6X87KIMWmPT 5cnqytZBe.LVIB2tzAvdIE4cIB7Oemw0ltauUzbjJrWR8N3zfwvNdIh3cMDu jjLumzi0rvpx5m+wgrApo+uFAakcM4Ci3vwXF7TnVHZUk0Gn2u8vJEAvAatq rnPTe7D8ckE6kZd9gujyISmytKgVLWxbTDunKYjjuj9T7D7om43u5oNzT7o3 k0mvSvmLeCykzm3SwmVV9zyff4wmnXilE62si.wQbVRL.517jHfQnluz545G GCQTDMlPVe7q4ot+Ni2IQKPKZJXRtDrrUYXSsJyxs.AIcpUYVPeZJ4NyA8sj 9DZp9zBRwmRtyb3eKoOkLAeBVVbBRu9TbfmpKsbTbywAFfeIeZYm0c0odk9J 6Q5a9xM+OyMD2IB -----------end_max5_patcher-----------
I think you are right about the new order, but it use to work right to left in max 4.6 or I am wrong but I have coded since MSP1 with that assumption and was never told wrong i.e. my code worked!
btw, I’ve added 1 as a second argument to count~ and it does not solve my problem, every other time!
it is very unpredictible, which is quite new to Max5, hence my questions…
Thanks for your help, the second patch I posted is working, but I want to know if the thread-safe buffer access is the responsible (which I think it is) but your idea of the audio chain order is a good hypothesis (again just in Max5… maybe to sort the problem induced by the increment/decrement of the b_inuse flag)
Ok, maybe my answer was a bit naive. I hadn’t thought about the new thread/multiprocessor-safe buffer access.
The audio chain order flag has been there there in max4, too.
Anyways, I haven’t noticed any artifacts opening the patch several times!
Maybe you should post this in the Dev-forum?
|The audio chain order flag has been there there in max4, too.|
I didn’t notice… I’ve been lucky then!
|Maybe you should post this in the Dev-forum?|
I’ll flag it, you are right. I sent it to the bek list as well, and some interesting answers came from there…
Forums > MaxMSP