Patch won't load audio file

Apr 4, 2009 at 5:48pm

Patch won't load audio file

I’ve attached a patch I’ve been working on.

It loads and plays 3 video files and a 5.1 channel audio file. It’s designed to start automatically once it loads, with everything running of a loadbang and a trigger.

Everything works fine, except that it does not seem to play the audio file (bang -> open filename -> sfplay~.) The Max console window shows no error message.

Manually pressing the “read audio” button and then restarting playback seems to work, so I suspect a timing problem. Do I need to include a delay after sending “open” to sfplay?

Is there a reliable way to get the patch to wait until sfplay has loaded its file? I tried having the start patch message wait until a bang from sfplay’s right outlet, but it doesn’t seem to be getting sent.

#43203
Apr 4, 2009 at 6:53pm
Quote:
Do I need to include a delay after sending “open” to sfplay?

That, or better use deferlow (in combination with delay). Startup sequences are quite critical and platform dependent. I was working on a patch that behaved differently on a G4, G5 and intel processor. But deferlow solved it for me.

_
johan

#154924
Apr 5, 2009 at 6:13am
gpvillamil wrote on Sat, 04 April 2009 19:48
Do I need to include a delay after sending “open” to sfplay?

no, normally not, “open, play” or [t start read] is completly legal with all externals coming with maxmsp.

it is only getting problematic when several files should be read at once, i had to give up loadbanging many of my vst-based patches for that reason, and i´ve also seen this little issue it with the [text] object.

check out if it works when you manually “loadbang” after the patch is already open, then you know if the load process is causing trouble or something else.

#154925
Apr 5, 2009 at 11:35am

Manually banging the “open” which goes to sfplay~ works fine. So it must be the load process.

Will look into deferlow, can’t quite get my head around it now.

Would I send the “open” message to sfplay via a “deferlow”? Or pass all the file read messages, like the ones to the qtmovie, through a deferlow?

On another note, I notice that if I move the windows to their playback context, start the qmetro, then send fullscreen, the patch crashes hard. If I move the windows, go fullscreen, and then start the qmetro, the patch runs fine, for hours.

#154926
Apr 5, 2009 at 2:40pm

Here’s what I’m going to try:

Everything triggered by loadbang *after* the open -> sfplay~ sequence will go through deferlow. I’m guessing that this will make the other actions execute after sfplay is done loading?

#154927
Apr 6, 2009 at 12:57am
jvkr wrote on Sat, 04 April 2009 12:53
Quote:
Do I need to include a delay after sending “open” to sfplay?

That, or better use deferlow (in combination with delay). Startup sequences are quite critical and platform dependent. I was working on a patch that behaved differently on a G4, G5 and intel processor. But deferlow solved it for me.

_
johan

Deferlow did the trick, thank you so much!

Basically all the patch loading operations after open -> sfplay~ are routed through a deferlow object, it now all works great.

#154928
Apr 7, 2009 at 1:16pm

Other option with Jitter: use [jit.qt.movie] and watch the dumpout output for the “read” confirmation.
J-F.

#154929
Apr 7, 2009 at 1:22pm

I thought of that, but the audio file is 6 channels (5.1) so I really need an sfplay~ in order to route properly to the dac.

#154930

You must be logged in to reply to this topic.