open message to sflist~ -URGENT-
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
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
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
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
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