open message to sflist~ -URGENT-


    Jun 23 2006 | 12:33 pm
    Hello friends,
    I have a problem with the "open" message to the sflist~ object. I get
    an error message (no open file) when recalling first sound file of my
    list. Should I "open" it on every sfplay~ I use? Please have a look at
    the patch below... I'm sure I went wrong somewhere...
    Please note Lrun & Lqueue (from Peter Elsea) objects are required.
    Thank you very much for help,
    Cheers.
    Philippe
    max v2;

    • Jun 23 2006 | 1:27 pm
      Hello Philippe,
      The problem is that sfplay cues should start from index 2, 1 being
      reserved for playing not preloaded files. It should be solved if you
      simply replace the two "+ 1" (at the top of sfplay~ and below the Lqueue)
      by "+ 2".
      Alexis
    • Jun 23 2006 | 1:43 pm
      Quote: ph_m wrote on Fri, 23 June 2006 14:33
      ----------------------------------------------------
      > Hello friends,
      >
      > I have a problem with the "open" message to the sflist~ object. I get
      > an error message (no open file) when recalling first sound file of my
      > list.
      Your cues are defines from 2 (which is a rather good policy) but you try to play cue 1. There is no cue for your first file.
      BTW, you should have a look at [uzi] and try to remove these sloooow [Lqueue] and [del] boxes! Note also that [sflist~] accepts the message | preload cueNum soundfile | which may also simplify your patch!!
      p
    • Jun 23 2006 | 2:10 pm
      Alexis, Patrick and friends.
      First thanks a lot for your answers.
      Do your answers mean sflist~ accepts the "open" message but does NOT
      report the sfplay~objects that a sound file IS "opened" in the sflist~?
      Please note, in my patch, that when I send "print" to sflist~, there is
      no trace of an any "opened" file...
      In my idea, this should happen:
      if I send 1/0 to a sfplay~, the "opened" file is played/stopped (as
      usual),
      if I send 2/0 to a sfplay~, cue 2 is played/stopped,
      if I send 3/0 to a sfplay~, cue 3 is played/stopped, a.s.o.
      Correct?
      About Lqueue, the reason is this: I worry so much about crashes that I
      voluntary slow loading processes... Once cues are ready, they always
      remain available, and very fast...
      Again, thank you!
      Philippe
    • Jun 23 2006 | 2:42 pm
      Quote: ph_m wrote on Fri, 23 June 2006 16:10
      ----------------------------------------------------
      > Alexis, Patrick and friends.
      > First thanks a lot for your answers.
      >
      > Do your answers mean sflist~ accepts the "open" message but does NOT
      > report the sfplay~objects that a sound file IS "opened" in the sflist~?
      Indeed. The open message to [sflist~] defines [sflist~] 's current file, the one that will be used to define the cues until the next |open].
      > Please note, in my patch, that when I send "print" to sflist~, there is
      > no trace of an any "opened" file...
      >
      > In my idea, this should happen:
      >
      > if I send 1/0 to a sfplay~, the "opened" file is played/stopped (as
      > usual),
      > if I send 2/0 to a sfplay~, cue 2 is played/stopped,
      > if I send 3/0 to a sfplay~, cue 3 is played/stopped, a.s.o.
      > Correct?
      I think so. But for cue 1, you have to open the file in the [sfplay~ ] object.
      Now I understand better what you want to do! You may try to connect your [pack open blob] to [sfplay~]. But I don't see why you want to start from cue 1, it adds unnecessary complexity to your patch (having to deal with this "open" special case)!
      p
    • Jun 23 2006 | 3:18 pm
      On 23 Jun 2006, at 13:33, Philippe Montemont wrote:
      > I have a problem with the "open" message to the sflist~ object. I
      > get an error message (no open file) when recalling first sound file
      > of my list.
      It's fairly accepted wisdom that sfplay~ has problems with opening
      and then playing files on demand, unless you're very careful with
      disk buffer sizes (and even then I'm not convinced it helps). Twice
      this month I've been approached by people with this problem looking
      for a fix, and I've run into the problem myself with a CPU-intensive
      installation work (and I've had this problem off and on for several
      years). But to be fair to sfplay~, it doesn't really make sense to do
      "[open foo.wav, 1]" to sfplay~ in overdrive and expect it to make
      sense: the disk access has to be moved out of interrupt, so the whole
      operation (including the "1") is deferred in a way that's
      conceptually a bit smelly.
      It seems to me that the only way to use sfplay~ reliably is to
      preload cues for everything you're going to want to play; if the
      filenames are generated dynamically, then your best bet is to preload
      a cue as early as possible before you want to play it. (I rewrote my
      installation's file handling to do this, after a pile of "no open
      file" messages, and it now works reliably without complaint for hours
      on end.)
      -- N.
      nick rothwell -- composition, systems, performance -- http://
      www.cassiel.com