Forums > MaxMSP

sfplay~ is misbehaving?

July 28, 2007 | 6:24 pm

I’m having some odd problems with sfplay~ (latest version of Max/MSP, running in Windows XP).

My patch is set up so that when it receives a bang, it opens a specified existing wav file and, 20ms later, sends a 1 to the sfplay~ object to make it play. The next bang opens and plays a second wav file (once the first is done), and so forth.

The problem I’m having is that sometimes the file simply doesn’t play, even though the bang is clearly being received. If I manually send a second bang a few seconds later, it plays. If I add a delay object to automatically send the second bang, it still doesn’t work. I’m positive that sfplay~ is receiving filename and the 1, but it just doesn’t do anything.

The REALLY annoying part is that it’s not even predictable. Sometimes the file plays on the first bang, sometimes it doesn’t.

And, to make matters worse, from time to time the file begins to play, and then just stops a few seconds in.

No error messages are coming up in the Max window, and I’m completely at a loss to explain what’s going on. I’d be eternally grateful if anyone has any ideas!


July 28, 2007 | 7:02 pm

I’ve found that, when sending a load message followed by a play
message, you often need to delay the play message by a significant
amount after the associated load message in order to get it to run.
My sense is that this has to do with the disk access time, which
varies considerably depending on file length, other current read/
write activity, etc. Try lengthening your current 20 ms. delay until
it operates reliably. Also, make sure you have the internal buffer
time sufficiently long – you can set it with an argument to the
[sfplay~]. This will make sure you don’t get buffer under-runs, which
can stop the playback sporadically.

On Jul 28, 2007, at 12:24 PM, Peter C wrote:

>
> I’m having some odd problems with sfplay~ (latest version of Max/
> MSP, running in Windows XP).
>
> My patch is set up so that when it receives a bang, it opens a
> specified existing wav file and, 20ms later, sends a 1 to the
> sfplay~ object to make it play. The next bang opens and plays a
> second wav file (once the first is done), and so forth.
>
> The problem I’m having is that sometimes the file simply doesn’t
> play, even though the bang is clearly being received. If I
> manually send a second bang a few seconds later, it plays. If I
> add a delay object to automatically send the second bang, it still
> doesn’t work. I’m positive that sfplay~ is receiving filename and
> the 1, but it just doesn’t do anything.
>
> The REALLY annoying part is that it’s not even predictable.
> Sometimes the file plays on the first bang, sometimes it doesn’t.
>
> And, to make matters worse, from time to time the file begins to
> play, and then just stops a few seconds in.
>
> No error messages are coming up in the Max window, and I’m
> completely at a loss to explain what’s going on. I’d be eternally
> grateful if anyone has any ideas!

—-
Steven M. Miller
Professor, Contemporary Music Program
College of Santa Fe

Home < http://pubweb.csf.edu/~smill>
SFIFEM <
http://sfifem.csf.edu>
Atrium Sound Space <
http://atrium.csf.edu>
OVOS <
http://pubweb.csf.edu/~smill/ovos.html>
CMP <
http://www.csf.edu/csf/academics/cmp/index.html>


July 29, 2007 | 11:43 pm

That did it! Many thanks!


July 31, 2007 | 2:13 pm

On 28 juil. 07, at 21:02, Steven Miller wrote:

> I’ve found that, when sending a load message followed by a play
> message, you often need to delay the play message by a significant
> amount after the associated load message in order to get it to run.

The problem is to know how long "a significant amount delay" is.

Maybe using the preload feature of [sfplay~] could help you.

_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl

http://users.skynet.be/crfmw/max


July 31, 2007 | 2:41 pm

On Jul 31, 2007, at 8:13 AM, Patrick Delges wrote:

>
> On 28 juil. 07, at 21:02, Steven Miller wrote:
>
>> I’ve found that, when sending a load message followed by a play
>> message, you often need to delay the play message by a significant
>> amount after the associated load message in order to get it to run.
>
> The problem is to know how long "a significant amount delay" is.
>
> Maybe using the preload feature of [sfplay~] could help you.
>

Yes, when you know in advance what sound files you’ll be playing,
this can be a big advantage. However, when you don’t know in advance
- either because you are randomly selecting them or creating them on
the fly – this isn’t possible. I’ve found that somewhere on the order
of 20-50 ms. delay is usually sufficient. The longer delay times will
ensure less problems with disk access times, at the expense of timing
accuracy, of course. In the cases I’ve used this, however, that small
amount of delay has not been an issue.

—-
Steven M. Miller
Professor, Contemporary Music Program
College of Santa Fe

Home < http://pubweb.csf.edu/~smill>
SFIFEM <
http://sfifem.csf.edu>
Atrium Sound Space <
http://atrium.csf.edu>
OVOS <
http://pubweb.csf.edu/~smill/ovos.html>
CMP <
http://www.csf.edu/csf/academics/cmp/index.html>


July 31, 2007 | 3:28 pm

>
> Yes, when you know in advance what sound files you’ll be playing,
> this can be a big advantage. However, when you don’t know in
> advance – either because you are randomly selecting them or
> creating them on the fly – this isn’t possible. I’ve found that
> somewhere on the order of 20-50 ms. delay is usually sufficient.
> The longer delay times will ensure less problems with disk access
> times, at the expense of timing accuracy, of course. In the cases
> I’ve used this, however, that small amount of delay has not been an
> issue.

In the cases where you do know what your sound files are (i.e. are
not being created on the fly and being played immediately), loading
preloads into an sflist~ object, with your sfplay~(s) referring to
it, is a nice solution to the problem above. The latency using this
method is often around 1 ms.

Cheers,
David


August 2, 2007 | 10:09 pm

Quote: Patrick Delges wrote on Tue, 31 July 2007 16:13
—————————————————-
> The problem is to know how long "a significant amount delay" is.
—————————————————-

The right outlet is there specifically for this purpose, isn’t it?


August 3, 2007 | 12:59 pm


August 3, 2007 | 4:00 pm

Increasing the delay time (between the ‘open’ and ‘play messages) to about 400ms seemed to work, though the latency was obviously ridiculous. And though it worked beautifully in rehearsal, it messed up almost immediately in performance. Murphy’s law, I suppose.

Since the wav files are pre-determined and pre-existing, I’m now using an sflist~ object to preload them and cue the sfplay~. Thanks for the idea, David! The problem with files not playing is now gone, though they still sometimes stop abruptly partway through. I’m still playing around with the buffers, and hopeful that I can fix it. Again, this was something that wasn’t a problem in rehearsal, and only arose during a performance.

As far as I can tell, the right outlet of sfplay~ sends a bang when the file is finished playing…it doesn’t seem to have anything to do with the loadtime of the file.


August 3, 2007 | 5:09 pm

> Since the wav files are pre-determined and pre-existing, I’m now
> using an sflist~ object to preload them and cue the sfplay~.
> Thanks for the idea, David! The problem with files not playing is
> now gone, though they still sometimes stop abruptly partway
> through. I’m still playing around with the buffers, and hopeful
> that I can fix it. Again, this was something that wasn’t a problem
> in rehearsal, and only arose during a performance.

Yeah! Glad I could help.
Playing with the buffer size has been an obsession since most of my
work (theater sound design) requires these file to play. WIth using
sflist~, you can use pretty large buffers since all the files are
already read (up to the buffer size) prior to being played (so no
latency waiting for the file to load before playing)…like something
like 196560, or even higher (doing so does eat up more RAM, fyi).
That being said, tho, it doesn’t help if your hard drive is slow. I
recently tried running a show from my Macbook Pro using the built-in
drive which is 5400 rpm. Every once in a while a sound would stop
once it played thru the buffer. This was easily solved moving to an
external 7200 rpm external drive. Also using boot-up drives with at
least 25% of their total space free seems to be a factor, too (drives
filled to the brim tend to slow down dramatically). Anyway, perhaps
some of these observations can help.

Best,
David


August 5, 2007 | 7:38 pm

Quote: Patrick Delges wrote on Fri, 03 August 2007 14:59
—————————————————-

> AFAIK, [sfplay~]‘s right outlet doesn’t output anyhing once an open
> message (or a preload message) is finished.
—————————————————-

You’re right… my mistake. Sorry. At least I admit to mine (unlike certain Presidents I could name.-)

In which case sflist~ with preloads is definitely the way to go.


Viewing 11 posts - 1 through 11 (of 11 total)