Philippe Montemont

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. 

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

open-message-to-sflist-urgent

Quote: ph_m wrote on Fri, 23 June 2006 14:33

----------------------------------------------------

> 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 

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!!

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.

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 

if I send 1/0 to a sfplay~, the "opened" file is played/stopped (as 

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.

About Lqueue, the reason is this: I worry so much about crashes that I 

voluntary slow loading processes... Once cues are ready, they always 

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...

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...

Quote: ph_m wrote on Fri, 23 June 2006 16:10

> 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 

> if I send 1/0 to a sfplay~, the "opened" file is played/stopped (as 

> 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.

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)!

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~?

> 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?

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 

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 

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 

nick rothwell -- composition, systems, performance -- 

> 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.)

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


open message to sflist~ -URGENT-