sfplay~, preload and unibody macbook pro

Feb 3, 2009 at 7:24am

sfplay~, preload and unibody macbook pro

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.

- 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
IMac 3.06 GHz, 4G Ram: works fine

Many thanks to all.

matteo pennese

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

– Pasted Max Patch, click to expand. –
#42073
Feb 3, 2009 at 11:30am

try
http://www.arts.lu/roby/
rs.numbox

#150326
Feb 3, 2009 at 1:12pm

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)

Alistair

#150327
Feb 3, 2009 at 2:06pm

Hi Alistair,

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

thanks

matteo

#150328
Feb 3, 2009 at 4:55pm

+1

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.

#150329
Feb 3, 2009 at 11:47pm

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
—————————————————-

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.

A

#150330
Feb 4, 2009 at 11:45am

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

– N.

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

#150331
Feb 4, 2009 at 1:06pm

Hi Nick,

just playing preloaded cues causes this issue.

matteo

#150332
Feb 4, 2009 at 6:32pm

On 4 Feb 2009, at 13:06, matpe wrote:

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

$$%!#@!.

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

#150333
Jun 20, 2009 at 10:45am

Hi,

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!

Benjamin Thigpen

#150334
Jun 22, 2009 at 4:44pm

Hi,

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

stl

#150335
Jul 6, 2009 at 4:24pm

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…

#150336
Feb 8, 2012 at 7:52pm

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.

#150337
Feb 8, 2012 at 8:15pm

Hi Oli,

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.

Sorry to disappoint…

matteo

#150338
Feb 8, 2012 at 8:20pm

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…

#150339

You must be logged in to reply to this topic.