# Non-realtime mode 1-sample delay?

**URL:** <https://framelib.discourse.group/t/non-realtime-mode-1-sample-delay/85>\
**Category:** Usage Questions\
**Created:** [20 February 2021 15:33 UTC](https://framelib.discourse.group/t/non-realtime-mode-1-sample-delay/85 "2021-02-20T15:33:37Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![o.green](https://yyz2.discourse-cdn.com/free1/user_avatar/framelib.discourse.group/o.green/32/29_2.png) [@o.green](https://framelib.discourse.group/u/o.green)\
**Post date:** [20 February 2021 15:33 UTC](https://framelib.discourse.group/t/non-realtime-mode-1-sample-delay/85/1 "2021-02-20T15:33:38Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![a.harker](https://yyz2.discourse-cdn.com/free1/user_avatar/framelib.discourse.group/a.harker/32/21_2.png) [@a.harker](https://framelib.discourse.group/u/a.harker)\
**Post date:** [20 February 2021 17:37 UTC](https://framelib.discourse.group/t/non-realtime-mode-1-sample-delay/85/2 "2021-02-20T17:37:34Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![a.harker](https://yyz2.discourse-cdn.com/free1/user_avatar/framelib.discourse.group/a.harker/32/21_2.png) [@a.harker](https://framelib.discourse.group/u/a.harker)\
**Post date:** [21 February 2021 20:43 UTC](https://framelib.discourse.group/t/non-realtime-mode-1-sample-delay/85/3 "2021-02-21T20:43:20Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![o.green](https://yyz2.discourse-cdn.com/free1/user_avatar/framelib.discourse.group/o.green/32/29_2.png) [@o.green](https://framelib.discourse.group/u/o.green)\
**Post date:** [21 February 2021 21:30 UTC](https://framelib.discourse.group/t/non-realtime-mode-1-sample-delay/85/4 "2021-02-21T21:30:07Z")

</div>

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