Non-realtime mode 1-sample delay?

The problem might well be in the chair here, but I’m seeing a 1-sample offset vs what I’m expecting when I use @rt 0 to write into a buffer.

Here’s a simple patch where what I think I’m doing is making a straight copy between a source buffer and a dst buffer. The source is read with fl.read~, and then I’m using fl.sink @buffer dst to write. What I see is that the contents of dst are offset by a point.

If that’s the way it’s meant to be, I’ll adjust accordingly, but if I’m doing something silly, I’d like to stop it.


----------begin_max5_patcher----------
1515.3oc0YssbZiDD8Y7WwT7LY7b+x9T9ORsUJALFqrBIsRBG6jJ4ae6Yjvr
15BBPxUEbETn0fl4b5tOSOM+7tEKWm8rqbI5uPeAsXwOuawhfIugEMedwx8Q
OuIIpLLrkax1u2kVsbU88pbOWErWVUDEu6wJzlr7WPYOfJK1fpxPaKqvX7wg
mDm51jcHM7cXMFi2FdBYq+1m37iiL8v93zDWUXVomLlcn5nURi07npMOFmt6
qEtMU0XwPzXxJDSFtPkD+ENGSP+s+67q6ty+1pQh47nTWxwE15rhsth9V+zA
W+0e2MYIYE0qSBVaYToxnXZgjXMq.SDKgZUDsQvobMuSSTOTtTVQZIXpkHYB
t0xLDo.lOAghUTKkQ3RqfQzZEXTgIBsjqrDqzPXbJLkLJ15sBVf+zbK80kP4
iQ4t+ORK.m7VWfXnVQiw8Yac++kXT5tjfAl16fZ3ncugeXqdyamPcdQVdVQU
bVZ3QhkWgisufYHnEU5b6K8QvOF8jCEgnepLZedhCs0kD8B562WbekOHeY6n
.ldZhhULK1RsbpPCNFigS6yewzRrlJ3DpgIjJql.rEibkw66OjTEWlD6iy6.
cxAQWdTQzdWkq3qtzn0IuwgWBis5kDW+rwwbpx3eTOJUig5wT8RcX1WPKWtB
92ong1rG2nwbNmYA5iRHBgwGXy3A1iHrFpfwDLADYC4EBshQYbFSSg.VYsnA
XDFqgZ.tEF8ov83coMA2WA8l59NvisB59QBZGj1j2Ek2srHaPJ7JXLOOHYbM
w3YFqRpAUSJyKdJoAAU1UFR0Clyct+428kEI5Dz7NAMsOP+PRVT0fnFBAvFP
lipTDvQKIdTyTDrx+RKYDK7h.odpaiCVenpBTq5.orqNiZjrvZPpcPRPRsXv
yazBC0xz.O.jfTfASTu7uxHUbCjq.jEo984PZg7mgzhhHvRul.UyLvlg1vFo
+QJsPseHRKBsESBASZgfYjRC+CQZA1IuKPa9fjVfsfZohLGRK8vAG9QLDliH
cQA5KvuyGTWY0oqwomgPZJHWMiN9Jz55+5B0pKnxLwXQ8atdwprVdX6GFUyg
BUfSA.gCR1MwL6ckkQ6bsnlGhSR5NZPdAQC8lPLH1gSLf8Y9vUBnOR4L.6TN
MnDZrLoWPU3IDNYV.egC1iXEBN2vFXDPczVUWLAY1YBITr9oj.JULGYAqO7v
Cthf.H5y9StzKhMWPJAaXsvwjCzcbPCW3O24zyEOjfKiSgcC9bMqzytB5ovy
62+NJYL9eNjj6OOMTbf.Jh.JNvSDT1Lw.EtnsgRsQ2eHMtpDUeb1Rz8fnsqH
uScA0GUxPSo.TqbtfOf1eitOwktq5wPp.5de+HPEt+8fqrBp4pM7keTvmorg
Kz4B9Ae7SQI+tF5etnpS+s3BzBtM.yp0.Yp4aitMYkH3f+c.S9r6W00Mfry8
2Tx4Tv2mgOrfO8iUv+HULrDe3ID5O76ZGc3I5s+VJoL6PwliKlik1g3utP1B
4zwoQG6O3WNUmC5TOD2GuMOCRMZlRoeI99xy7s8T40oE9lsYjv+cExnTXaqM
wZOxdbvWDlHmCS5AwDy1Al355sdHFklK0Lov2yWEV148tQT3auw4QQCTuc9h
dtYhLHeIHcvWBAV7d9RZDA9p88lBTvNCJ3CBB+IqZGHqp6tmUaYPvqxpVgzz
Zmd66cifXLQt5IvkKGw7LIgV5Q3T78UneuhvZ7bMCjILb+KHlQ.m+Oj7Y0XZ
qNEzdju9re8Wghb6v5rYL1AgkgEfkP6u.kxFNh6aZzS3dyxR+bdDeSjuROBW
f4sZK7X7Hz42iv3iwiPL0I0RqvHXVpOlhasX666weGibpg06Vw8.K4Djo9NW
9vD3s4priYlHSwLYFyVn1IXlFiahNEHZLB2loXhHiXhDSvDMlvt1w2008Fkm
+jqnrYvgo.J5+a0+L3lUgOFmV+wPg5KKbOEeb7xfknBnx6Jnr6CEgk0xmU0G
mK76tWjdHtIKF.GLkgCTjFAmfJOpFGgycb2ut6+Pm0DLb
-----------end_max5_patcher-----------

In context, what I’m actually using this for is batch analysis of a source buffer. The analyais is using an overlap through the source, so I use fl.read rather than fl.source in order to have tight control over what bits I’m reading when (if that makes sense).

I think your method is fine, but there does seem to be an offset issue here - I think this is because I should have compensated for the fact the time 0 is one sample before the first sample (this is necessary to make various other things work). However, I’m a bit unsure why that isn’t just missing the first sample, rather than shifting it as it is now - that’s probably just my lack of being able to reason it through fully. Feel free to put this as an issue on GitHub and I’ll aim to fix it soon.

1 Like

This should all be fixed up now if you build the latest from main.

Is it indeed, thanks! Have been able to remove some confusing fl.+~ 1 action from my patches…