mr.l

I set up an installation of a one-hour loop. All the cues are timed by the file position of an sf-play object.

After 3 hours it suddenly stopped, while the file kept playing. I had to reconnect it, and it worked again.

Please help, because I have to leave the patch in a museum and it should be stable!

I set up an installation of a one-hour loop. All the cues are timed by the file position of an sf-play object.
After 3 hours it suddenly stopped, while the file kept playing. I had to reconnect it, and it worked again.

sfplay-file-out-position-stopped-working

It is difficult to predict what goes wrong.

You have to post the patch or more infos, including

It is difficult to predict what goes wrong.
You have to post the patch or more infos, including
max version, operating system etc


It is running on a MacPro. Can't tell which one, because I already left the venue. Max Version 7.3.3.

attached I stripped down the patch to only the audiopart.

I thought about using another timing system, but since all the triggered events are already precisly cued with in this way, I don't really want to change it.

attached I stripped down the patch to only the audiopart. 

I thought about using another timing system, but since all the triggered events are already precisly cued with in this way, I don't really want to change it.


the error occuiered again and the solution was again to disconnect and reconnect the cord from the "time position" of the sfplay, while it still was running.

Therefore I made a workaround disconnecting and reconnecting this cord automatically each time the the sfplay is done playing.

Therefore I made a workaround disconnecting and reconnecting this cord automatically each time the the sfplay is done playing.
Hope that does the trick....


Hi, I had a look at the patch, there is nothing terribly wrong with it,

1 - You are sending play, pause resume to 3 sfplay objects, only one has

open message, does that mean that 2 others have no file opened, and throw errors ?

2- put sfplay in loop mode instead of banging start message at end of play

3- play position can be done much simpler, you are dividing, than multiplying, dividing again etc

4- newer use for installation software version that has been updated recently, before testing it.

there are allways possible bugs, changes in behaviour etc

It could be also somthing that gets triggered by play position that causes problems

Hi, I had a look at the patch, there is nothing terribly wrong with it,
but few things need a change.
1 - You are sending play, pause resume to 3 sfplay objects, only one has
open message, does that mean that 2 others have no file opened, and throw errors ?
2- put sfplay in loop mode instead of banging start message at end of play
3- play position can be done much simpler, you are dividing, than multiplying, dividing again etc
4- newer use for installation software version  that has been updated recently, before testing it.
there are allways possible bugs, changes in behaviour etc
--------
It could be also somthing that gets triggered by play position that causes problems

1 – You are sending play, pause resume to 3 sfplay objects, only one has

Thats just an error. While I simplified the patch to only post the relevant part, I accidently erased the open messages.

You are surely right. However I chose this method so all sfplay stay in synch after playing for a couples of hours. Don't know if it is necessary, but wanted to be sure... There are also other things beeing triggered at the looppoint. (By the way: does sfplay send out a loop-report message?)

That's a good one. Thank you very much! :)

ok. Anyway 7.3.3 is not such an old version.

I found an older post describing the same problem:

https://cycling74.com/forums/sfplay-out-fil-position-not-reliable-EI

I tried my full-version patch on another machine, and ran into the same problem. After around 3 loops (3 hours) fileposition stopped.

With my workaround of disconnecting and reconnecting the patch-cord, it works fine on both machines.

Since the exhibition is running already, I think I will leave it that way.

 1 – You are sending play, pause resume to 3 sfplay objects, only one has
open message, does that mean that 2 others have no file opened, and throw errors ?

4- newer use for installation software version that has been updated recently, before testing it.
there are allways possible bugs, changes in behaviour etc

I found an older post describing the same problem:
https://cycling74.com/forums/sfplay-out-fil-position-not-reliable-EI
So maybe it is a deeper bugg?

I tried my full-version patch on another machine, and ran into the same problem. After around 3 loops (3 hours)  fileposition stopped.
With my workaround of disconnecting and reconnecting the patch-cord, it works fine on both machines.

Since the exhibition is running already, I think I will leave it that way.
best, luke_s


It is difficult to debug over such a long time, maybe turning overdrive on/off

which helps with midi drifts, or Audio Interupt would help, but as You say

if reconnecting the patchcord via scripting does the trick one can leave it so.

It is difficult to debug over such a long time, maybe turning overdrive on/off
which helps with midi drifts, or Audio Interupt would help, but as You say
if reconnecting the patchcord via scripting does the trick one can leave it so.


sfplay file out position stopped working