matteopennese

this 'trio' created me a lot of problems during a performance... with a really strange and erratic behavior driving me crazy:

- recalling a cue with 'preload' syntax sometime forces sfplay~ to play only a micro fraction of the file.

This happens erratically and after a 'period of inactivity', in other words after about a minute the last file has been played. And it seems to affect files with 2 minutes and more length (checked with mono, stereo and quad .aiff)

(Set-up preferencies prevents hd from sleeping, of course).

Impressions: it seems sfplay~ only plays the buffered/preloaded part of the file; it happens more frequently with large files.

- now the very peculiar aspect: I reported it with two new macbook pro unibody(late 2008) but not with an Imac. According to Ben (Cycling), it seems to be related to the specific hardware of the new apple laptops. He hasn't access to a unibody and other machines work fine.

I'm aware to be vague, but this behavior is really erratic!

If anyone, especially unibody owners (!), could check this behavior, I'd be very happy! However, you need a little bit of patience... in my experience it occours randomly.

setup: Mac OsX 10.5.6, Max 5.0.5/jitter 1.7 for all the tests

2 unibody macbook pro 4G Ram, hd 7200: affected

here a simple patcher to test (substitute with yours files, possibly of different length and type...)

Dear forum,
this 'trio' created me a lot of problems during a performance... with a really strange and erratic behavior driving me crazy:

- recalling a cue with 'preload' syntax sometime forces sfplay~ to play only a micro fraction of the file.
This happens erratically and after a 'period of inactivity', in other words after about a minute the last file has been played. And it seems to affect files with 2 minutes and more length (checked with mono, stereo and quad .aiff)
(Set-up preferencies prevents hd from sleeping, of course).
The 'open' syntax works fine.
Impressions: it seems sfplay~ only plays the buffered/preloaded part of the file; it happens more frequently with large files.

setup: Mac OsX 10.5.6, Max 5.0.5/jitter 1.7 for all the tests
2 unibody macbook pro 4G Ram, hd 7200: affected
IMac 3.06 GHz, 4G Ram: works fine

sfplay-preload-and-unibody-macbook-pro

Similar experience here at the weekend. New (November) MacBook Pro with sfplay~ object loading a file with the patch (loadbang) then only playing a short fragment before stopping. If I then hit play again immediately, it worked OK. After another few minutes of inactivity the same thing happens.

I didn't have time to do any testing, so solved it with something which effectively did play-stop-play in quick succession. Not ideal.

(MBP 2.53, os x 10.5.5, Max 5.0.5, sleep settings off etc)

Similar experience here at the weekend. New (November) MacBook Pro with sfplay~ object loading a file with the patch (loadbang) then only playing a short fragment before stopping. If I then hit play again immediately, it worked OK. After another few minutes of inactivity the same thing happens.
I didn't have time to do any testing, so solved it with something which effectively did play-stop-play in quick succession. Not ideal.
(MBP 2.53, os x 10.5.5, Max 5.0.5, sleep settings off etc)

Did you experience it with 'preload' or 'open' technique? The second one works for me.

I had similar experiences with intermittent file truncation in sfplay~ last week on my unibody Mac (early November vintage). I just chalked it up to n00b cluelessness at the time.

I will go back to that patch and see whether I've got a repeatable case.

Quote: matpe wrote on Tue, 03 February 2009 14:06

----------------------------------------------------

> Did you experience it with 'preload' or 'open' technique? The second one works for me.

The problem was with an "open mysound.aif" loadbanged. But as I say, even after playing the sound successfully, after inactivity the false start recurred.

Quote: matpe wrote on Tue, 03 February 2009 14:06
----------------------------------------------------
> Hi Alistair,
>
> Did you experience it with 'preload' or 'open' technique? The second one works for me.
>
> thanks
>
> matteo
----------------------------------------------------

On 3 Feb 2009, at 13:12, alistair macdonald wrote:

> Similar experience here at the weekend. New (November) MacBook Pro 

> with sfplay~ object loading a file with the patch (loadbang) then 

> only playing a short fragment before stopping. If I then hit play 

> again immediately, it worked OK. After another few minutes of 

This has been an issue with sfplay~ for several years. The general 

consensus is that it comes down to insufficient RAM buffering of the 

audio. There's information about buffer sizes in the help patcher, and 

as I recall it's more reliable if cues are preloaded (which seems like 

good form to me in any case, especially if you want immediate playback).

> Similar experience here at the weekend. New (November) MacBook Pro  
> with sfplay~ object loading a file with the patch (loadbang) then  
> only playing a short fragment before stopping. If I then hit play  
> again immediately, it worked OK. After another few minutes of  
> inactivity the same thing happens.

This has been an issue with sfplay~ for several years. The general  
consensus is that it comes down to insufficient RAM buffering of the  
audio. There's information about buffer sizes in the help patcher, and  
as I recall it's more reliable if cues are preloaded (which seems like  
good form to me in any case, especially if you want immediate playback).

Nick Rothwell / Cassiel.com Limited
www.cassiel.com
www.myspace.com/cassieldotcom
www.last.fm/music/cassiel
www.reverbnation.com/cassiel
www.linkedin.com/in/cassiel
www.loadbang.net


just playing preloaded cues causes this issue.

> just playing preloaded cues causes this issue.

> Hi Nick,
> just playing preloaded cues causes this issue.

Any solutions or workarounds or tips about this problem?

I have encountered the same behavior trying to play back 10-channel soundfiles with sfplay~. Am to the point of splitting them into 2 4-channel files and 1 2-channel file so that I can load them into buffer~s and play them with groove~. Unfortunately, this involves a serious revision of the patch...

Thanks for any information or suggestions anyone may have!

same problem here as described above (both with open and preload), but on an older macbook pro (2007). If i use upward transposition (+1 to +2 ocatves), the problem is getting worse and worse. So since years i'm waiting for a reliable audiostreaming object in msp now. For me these problems go back to 2005, where i first recognized them in an installation using a G5 desktop. So it's definitely not a hardware issue with the unibodies. 

In the moment i'm working on a patch for an 8channel installation running 24/7 and using tons of 8channel files. The only idea for me for a workaround is using Bidule (i use it as a AU wrapper as well) as a multichannel vst inside max5 for the streaming stuff. Rdiculous, isn't it??? Don't get it that a core object like sfplay~ seems to be of such a marginal importance for cycling74. Consequentaly i didn't get a reply from cycling support for over a week now....

same problem here as described above (both with open and preload), but on an older macbook pro (2007). If i use upward transposition (+1 to +2 ocatves), the problem is getting worse and worse. So since years i'm waiting for a reliable audiostreaming object in msp now. For me these problems go back to 2005, where i first recognized them in an installation using a G5 desktop. So it's definitely not a hardware issue with the unibodies. 
In the moment i'm working on a patch for an 8channel installation running 24/7 and using tons of 8channel files. The only idea for me for a workaround is using Bidule (i use it as a AU wrapper as well) as a multichannel vst inside max5 for the streaming stuff. Rdiculous, isn't it??? Don't get it that a core object like sfplay~ seems to be of such a marginal importance for cycling74. Consequentaly i didn't get a reply from cycling support for over a week now.... 

I usually up the buffersize to 262080 if I need reliable playback. With that I never had issues, but maybe I didn't test it hard enough...

This issue is really messing with our sanity on a current project. Both sfplay~ and sfrecord~ are seriously flaky with large multichannel files. We are using Max 5. Haven't tried with Max6 yet, but I really hope it's fixed.

I have the same issue with Max6 (last release) too.

And, of course, my macbook pro didn't change. Buffersize and others tricks don't solve it, at least in my case.

With Max6 the issue is exactly the same as I described in my first post of this discussion.

It seems that at Cycling nobody has never noticed this issue.

ouch... I find the help info on the buffersize quite hard to understand. If anyone can tell me what it should be set to in order to reliably play back / record 48000 / 24bit / 16-channel audio files I would really appreciate it!

It would be very helpful if rather than sfplay just stopping, it at least provided an error message to say it stopped due to...

sfplay~ crashes on every attempt to play files larger than 2GB, independently of format or quality. It doesn´t seem to be buffer related but simply the 2GB file size limit. I am using Max7 by the way.

https://cycling74.com/forums/multichannel-sfplay-problem-stops-playing-after-few-seconds/

sfplay~ crashes on every attempt  to play files larger than 2GB, independently of format or quality. It doesn´t seem to be buffer related but simply the 2GB file size limit. I am using Max7 by the way.

Also discussed here:   https://cycling74.com/forums/multichannel-sfplay-problem-stops-playing-after-few-seconds/


sfplay~, preload and unibody macbook pro