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

    • 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