gpvillamil

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.

patch-wont-load-audio-file

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.

Quote:Do I need to include a delay after sending "open" to sfplay?

gpvillamil wrote on Sat, 04 April 2009 19:48

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.

gpvillamil wrote on Sat, 04 April 2009 19:48
Do I need to include a delay after sending "open" to sfplay?

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.


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.

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?

jvkr wrote on Sat, 04 April 2009 12:53Quote:

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.

jvkr wrote on Sat, 04 April 2009 12:53Quote:Do I need to include a delay after sending "open" to sfplay?

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


Other option with Jitter: use [jit.qt.movie] and watch the dumpout output for the "read" confirmation.

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


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.

Patch won't load audio file