sfplay~, preload and unibody macbook pro
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.
here a simple patcher to test (substitute with yours files, possibly of different length and type…)
----------begin_max5_patcher---------- 684.3ocyXtrbaBCEFdM9oPi5VWO5B2b6ttpqxltrSmLxFEr5fETiH0oYRd1K HIRLMNXbGaPKrLbPB8e9N5xQ73LO3p787RH3SfuC77dblmm1TiAO68dvsr8q yXk5pA2xKKYob3byyT78Js87BtDf+xtpRQN91eUwRlCvs0RVsUHy3J8qf7pw 7JUqUr05c4RUo3ObsMxBj0rolpGJ3FwBgfeXeTASsdiPld6N9Zk4o9n5FBhZ ZN.SCz+sbA5klHRLZd0O+Hg.Onmkrs5N.9Ud18bkXMCbCuhCapwSyl0TL+R. JhATD2.T9wCATzo.TzusoZEemxM.Ew2.pndAk+UBTqpTpb4QI.tWB7FWcESl 1q6RC0CIHgZGdIss7n9K9RF0QSUDlfzg3XcIkrH38iv3kWoHrJOMMieIhvBo pWuEiMKNRLwYTa4Qc2HG2WP5QoDb3.7kf+GeQx+ccieyX0D15mAX.4LFxh5e H6w7t.cjhP0+EXhW32w6F60n8mr0iisg43ALccr2hmNYTwlxST3.nBdjoBYx nhYWL6DoSPEzHSkhc7rbVBvuaxyfIaePpcmAjEZ8lTX7DQKZ2LnmbZYVM5Dv JZhfEoaVzSNrrG2Hn2rnCmfSaLUbwtxjcJGMtOtbs1g+cRwo7thL1COCNmM5 CNS1TJRkrL37Sc0IO0RKG80bLh1apRCgi1pTxtuUqe3FslLTo4x5e9M4QiVF V2aHiE3mq04AAAs.fYB4+9sVzNQi8tQlx7pcqa6RaZq0u7W7iDdoRHYJQ8wA OnRzNUZiHIgKOLoyshjh75roshniDme9ZZ4Pzz3JoH2SR08FcHAN7nJIhiMV pC.bFJ4Zy3Ht2var6IIjyIoXmSQt2BkgNmhnN4lI9mPQjwURMesaGiRD2KvQ t1qbWeySy964K7Vf -----------end_max5_patcher-----------
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
> Hi Alistair,
> 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.
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).
Nick Rothwell / Cassiel.com Limited
just playing preloaded cues causes this issue.
On 4 Feb 2009, at 13:06, matpe wrote:
> Hi Nick,
> just playing preloaded cues causes this issue.
Nick Rothwell / Cassiel.com Limited
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….
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.
Sorry to disappoint…
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…