Forums > MaxMSP

open message to sflist~ -URGENT-

June 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;
#N vpatcher 0 44 969 759;
#P origin 33 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 405 71 33 196617 clear;
#P newex 180 218 38 196617 t i 0;
#P newex 875 496 32 196617 del 5;
#P message 691 533 32 196617 print;
#P message 449 618 159 196617 preload 2 p01_m0.aif 0. 0. 0 1.;
#P newex 449 588 62 196617 prepend set;
#P message 334 249 58 196617 set sound2;
#P newex 719 422 27 196617 + 1;
#P newex 742 327 27 196617 – 1;
#P newex 180 242 27 196617 + 1;
#P toggle 120 307 15 0;
#P message 366 316 33 196617 set 0;
#P newex 163 366 158 196617 dac~ 1 2 3 4 5 6;
#P newex 16 195 157 196617 if $i1 == 0 then 0 else out2 bang;
#P toggle 16 172 15 0;
#P newex 163 265 27 196617 1;
#P user ubumenu 180 196 142 196617 0 1 1 0;
#X prefix_set 0 1 0;
#N sfplay~ sound2 6 0 1 ;
#P newobj 163 291 213 196617 sfplay~ sound2 6 0 1;
#P newex 653 279 49 196617 tosymbol;
#P newex 875 467 31 196617 t b 0;
#P newex 556 528 74 196617 pack open blob;
#P newex 719 467 45 196617 t b i;
#P newex 449 528 96 196617 pack preload 2 blob;
#P button 776 404 15 0;
#P newex 719 400 39 196617 t i i;
#N sflist~ sound2 120960;
#P newobj 449 562 113 196617 sflist~ sound2 120960;
#P newex 719 443 166 196617 if $i1 == 1 then out2 bang else $i1;
#P newex 719 377 67 196617 Lqueue 1000;
#P message 653 95 75 196617 autopopulate 1;
#P newex 587 70 76 196617 t s b;
#P button 587 26 15 0;
#P newex 719 352 57 196617 Lrun;
#P newex 719 303 56 196617 t 0 i reset;
#P newex 719 279 74 196617 route populate;
#P newex 587 187 64 196617 t l 1 clear 0;
#P newex 587 135 76 196617 prepend prefix;
#P newex 587 47 76 196617 opendialog fold;
#P user ubumenu 587 254 142 196617 0 1 1 0;
#X prefix_set 0 1
0;
#P comment 156 530 271 196617 "open" does not appear to be functionnal
on sflist~ , right?;
#P comment 441 72 35 196617 Menus;
#P comment 408 251 140 196617 < - Connect sfplay~ to sflist~;
#P fasten 39 1 26 0 213 241 334 241 334 167 21 167;
#P fasten 29 0 26 0 371 338 404 338 404 164 21 164;
#P connect 26 0 27 0;
#P connect 27 1 25 0;
#P connect 25 0 23 0;
#P fasten 27 0 23 0 21 286 168 286;
#P connect 34 0 23 0;
#P connect 23 0 28 0;
#P fasten 30 0 28 0 125 344 168 344;
#P fasten 6 1 28 0 610 344 168 344;
#P fasten 6 3 28 0 646 344 168 344;
#P fasten 40 0 24 0 410 141 185 141;
#P fasten 5 0 24 0 592 161 185 161;
#P connect 24 0 39 0;
#P connect 39 0 31 0;
#P connect 31 0 25 1;
#P connect 23 1 28 1;
#P connect 23 2 28 2;
#P connect 23 3 28 3;
#P connect 23 4 28 4;
#P connect 23 5 28 5;
#P connect 17 0 34 0;
#P connect 23 7 29 0;
#P fasten 19 0 18 0 724 489 454 489;
#P fasten 6 2 15 0 628 242 913 242 913 557 454 557;
#P fasten 37 0 15 0 696 555 454 555;
#P connect 18 0 15 0;
#P fasten 20 0 15 0 561 553 454 553;
#P connect 15 0 35 0;
#P connect 35 0 36 0;
#P fasten 19 1 18 1 759 491 497 491;
#P fasten 22 0 18 2 658 509 540 509;
#P fasten 38 0 20 0 880 519 561 519;
#P connect 10 0 4 0;
#P connect 4 0 11 0;
#P connect 11 0 5 0;
#P fasten 12 0 5 0 658 124 592 124;
#P connect 5 0 6 0;
#P fasten 40 0 3 0 410 235 592 235;
#P fasten 21 1 3 0 901 492 911 492 911 247 592 247;
#P fasten 16 1 3 0 753 427 804 427 804 250 592 250;
#P connect 6 0 3 0;
#P fasten 22 0 20 1 658 511 625 511;
#P connect 11 1 12 0;
#P connect 3 1 22 0;
#P connect 17 0 37 0;
#P connect 3 2 7 0;
#P connect 7 0 8 0;
#P connect 8 0 9 0;
#P connect 9 0 13 0;
#P connect 13 0 16 0;
#P connect 16 0 33 0;
#P connect 33 0 14 0;
#P connect 14 0 19 0;
#P connect 8 1 32 0;
#P connect 32 0 9 1;
#P connect 8 2 9 2;
#P connect 13 1 17 0;
#P connect 14 1 21 0;
#P connect 21 0 38 0;
#P pop;


June 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


June 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


June 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


June 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


June 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://
http://www.cassiel.com


Viewing 6 posts - 1 through 6 (of 6 total)