Patch won't load audio file


    Apr 04 2009 | 5:48 pm
    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.

    • Apr 04 2009 | 6:53 pm
      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
    • Apr 05 2009 | 6:13 am
      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.
    • Apr 05 2009 | 11:35 am
      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.
    • Apr 05 2009 | 2:40 pm
      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?
    • Apr 06 2009 | 12:57 am
      jvkr wrote on Sat, 04 April 2009 12:53Quote: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.
    • Apr 07 2009 | 1:16 pm
      Other option with Jitter: use [jit.qt.movie] and watch the dumpout output for the "read" confirmation. J-F.
    • Apr 07 2009 | 1:22 pm
      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.