flies

I'm making a file player based on sfplay that will include a waveform

display. So the patch i'm posting plays the soundfile back at 29 times the

speed and records it into a buffer connected to a waveform~ object.

why 29? Because if i go higher than that it doesn't work! i get a little

blip of sound and then silence, and the sfplay never indicates that it's

done playing the cue! It seems as though occasionally it will play the

whole file but in general not; it have this halting problem intermittently

I'm making a file player based on sfplay that will include a waveform
display.  So the patch i'm posting plays the soundfile back at 29 times the
speed and records it into a buffer connected to a waveform~ object.

why 29?  Because if i go higher than that it doesn't work!  i get a little
blip of sound and then silence, and the sfplay never indicates that it's
done playing the cue!  It seems as though occasionally it will play the
whole file but in general not; it have this halting problem intermittently
for speeds above 20.

sfplay-wont-go-faster-than-29

I'm using max 4.5.7 on a PC running xp sp2.

> I'm making a file player based on sfplay that will include a waveform

> display. So the patch i'm posting plays the soundfile back at 29 times the

> speed and records it into a buffer connected to a waveform~ object.

> why 29? Because if i go higher than that it doesn't work! i get a little

> blip of sound and then silence, and the sfplay never indicates that it's

> done playing the cue! It seems as though occasionally it will play the

> whole file but in general not; it have this halting problem intermittently

> #P flonum 511 441 51 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

> #P flonum 462 183 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

> #P user spectroscope~ 209 467 300 100 20 0 0 0 1 1 0 0 0 0 0 0;

On 5/18/07, George Locke  wrote:
>
> Hey,
>
> I'm making a file player based on sfplay that will include a waveform
> display.  So the patch i'm posting plays the soundfile back at 29 times the
> speed and records it into a buffer connected to a waveform~ object.
>
> why 29?  Because if i go higher than that it doesn't work!  i get a little
> blip of sound and then silence, and the sfplay never indicates that it's
> done playing the cue!  It seems as though occasionally it will play the
> whole file but in general not; it have this halting problem intermittently
> for speeds above 20.
>
> I'm at a loss.  here's the patch:
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 33 183 45 9109513 loadbang;
> #P button 482 389 15 0;
> #P newex 39 153 26 9109513 print;
> #P flonum 511 441 51 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 486 417 29 9109513 timer;
> #P flonum 462 183 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P message 522 301 34 9109513 set $1;
> #P message 423 355 39 9109513 31.84;
> #P button 505 382 15 0;
> #P button 171 132 15 0;
> #P message 31 220 36 9109513 set wv;
> #P user ezdac~ 284 75 328 108 0;
> #P user waveform~ 36 272 200 74 139 9;
> #W mode select;
> #W mouseoutput continuous;
> #W unit ms;
> #W grid 1000.;
> #W ticks 0;
> #W labels 1;
> #W vlabels 0;
> #W vticks 1;
> #W bpm 120. 4.;
> #W frgb 33 0 0;
> #W brgb 60 178 173;
> #W rgb2 0 95 255;
> #W rgb3 0 0 0;
> #W rgb4 0 0 0;
> #W rgb5 190 137 255;
> #W rgb6 100 100 100;
> #W rgb7 100 100 100;
> #P user spectroscope~ 209 467 300 100 20 0 0 0 1 1 0 0 0 0 0 0;
> #X frgb 224 224 224;
> #X brgb 255 255 255;
> #X rgb2 0 0 0;
> #X rgb3 243 204 204;
> #X rgb4 255 0 0;
> #X rgb5 184 184 184;
> #X rgb6 0 0 0;
> #X rgb7 0 0 0;
> #X rgb8 255 255 255;
> #X rgb9 255 0 0;
> #X rgb10 255 191 0;
> #X rgb11 0 191 127;
> #X rgb12 127 0 127;
> #X rgb13 0 0 0;
> #X range 0. 1.2;
> #X domain 0. 24000.;
> #X done;
> #P button 319 294 15 0;
> #P newex 383 410 54 9109513 record~ wv;
> #P user meter~ 289 416 369 429 50 0 168 0 103 103 103 255 153 0 255 0 0
> 217 217 0 153 186 0 12 3 3 3 3;
> #P flonum 457 229 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P message 426 388 14 9109513 0;
> #P message 367 357 14 9109513 1;
> #N sfplay~ sf 1 120960 0 ;
> #P newobj 383 376 52 9109513 sfplay~ sf;
> #P message 383 356 14 9109513 2;
> #P newex 383 321 30 9109513 t b b;
> #P newex 383 298 38 9109513 del 100;
> #P newex 383 252 31 9109513 t b l;
> #P newex 383 230 60 9109513 prepend size;
> #P newex 383 209 27 9109513 / 29.;
> #P newex 404 274 54 9109513 buffer~ wv;
> #P message 161 92 54 9109513 preload 2 1;
> #P newex 83 60 19 9109513 t b;
> #P number 122 163 45 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
> #P message 83 92 61 9109513 getnamed sf;
> #P message 205 38 28 9109513 open;
> #N sflist~ sf 0;
> #P newobj 205 127 46 9109513 sflist~ sf;
> #P newex 83 123 79 9109513 sfinfo~;
> #P connect 12 0 15 0;
> #P connect 12 0 13 0;
> #P connect 12 1 27 0;
> #P connect 13 0 14 0;
> #P connect 13 0 33 0;
> #P connect 34 0 24 0;
> #P connect 29 0 8 1;
> #P connect 29 0 28 0;
> #P connect 30 0 31 0;
> #P connect 26 0 30 1;
> #P connect 14 1 16 0;
> #P connect 14 1 26 0;
> #P connect 33 0 30 0;
> #P connect 8 0 9 0;
> #P connect 8 0 17 0;
> #P connect 27 0 14 1;
> #P connect 28 0 27 0;
> #P connect 10 1 7 0;
> #P connect 16 0 19 0;
> #P fasten 15 0 19 0 372 398 388 398;
> #P connect 14 0 21 0;
> #P connect 14 0 18 0;
> #P connect 14 0 19 0;
> #P connect 11 0 20 0;
> #P connect 11 0 12 0;
> #P connect 10 0 11 0;
> #P connect 9 0 10 0;
> #P fasten 4 0 8 0 127 181 388 181;
> #P fasten 6 0 1 0 166 114 210 114;
> #P fasten 2 0 5 0 210 58 88 58;
> #P connect 2 0 1 0;
> #P connect 5 0 3 0;
> #P fasten 5 0 6 0 88 82 166 82;
> #P connect 0 3 4 0;
> #P connect 25 0 4 0;
> #P connect 3 0 0 0;
> #P connect 0 5 32 0;
> #P connect 24 0 22 0;
> #P window clipboard copycount 35;
>
>

I will offer a few fairly obvious things to check without claiming I have the solution!

This could be to do with disk read speeds. It would be the equivalent of reading 29 files at once. Maybe your disc just can't hack it... Maybe increasing the buffer size will help (in the sfplay~ help patch, double click new features, then double click buffer size and see if that makes sense). Maybe loading the file into RAM with buffer~ then playing it with play~ would work better.

This could be to do with disk read speeds.  It would be the equivalent of reading 29 files at once.  Maybe your disc just can't hack it...  Maybe increasing the buffer size will help (in the sfplay~ help patch, double click new features, then double click buffer size and see if that makes sense).  Maybe loading the file into RAM with buffer~ then playing it with play~ would work better.

it's really like reading 29 files at once? is there no way for sfplay to do

that more efficiently? if what you say is true then i would expect my 5400

> I will offer a few fairly obvious things to check without claiming I have

> This could be to do with disk read speeds. It would be the equivalent of

> reading 29 files at once. Maybe your disc just can't hack it... Maybe

> increasing the buffer size will help (in the sfplay~ help patch, double

> click new features, then double click buffer size and see if that makes

> sense). Maybe loading the file into RAM with buffer~ then playing it with

it's really like reading 29 files at once?  is there no way for sfplay to do
that more efficiently?  if what you say is true then i would expect my 5400
hard disk may not be up to the task...

On 5/18/07, Peter Reid  wrote:
>
>
> I will offer a few fairly obvious things to check without claiming I have
> the solution!
>
> This could be to do with disk read speeds.  It would be the equivalent of
> reading 29 files at once.  Maybe your disc just can't hack it...  Maybe
> increasing the buffer size will help (in the sfplay~ help patch, double
> click new features, then double click buffer size and see if that makes
> sense).  Maybe loading the file into RAM with buffer~ then playing it with
> play~ would work better.
>
> Good luck, hope that helps,
> Peter
>

On 19 mai 07, at 00:39, George Locke wrote:

> it's really like reading 29 files at once?

No it's not. But keep in mind that no matter what the speed of your 

hard disk is, it will always be a lot more slower than RAM. If you 

encounter such kind of problem, try increasing the buffer size, or 

better put the sound into a buffer~ and play it with whatever you 

want (groove~, play~ , index~, wave~...).

No it's not. But keep in mind that no matter what the speed of your  
hard disk is, it will always be a lot more slower than RAM. If you  
encounter such kind of problem, try increasing the buffer size, or  
better put the sound into a buffer~ and play it with whatever you  
want (groove~, play~ , index~, wave~...).

On May 18, 2007, at 3:39 PM, George Locke wrote:

Yes. The entire file is read in the requested period of time without 

> is there no way for sfplay to do that more efficiently?

Not if you want to support arbitrary speed changes in real time 

> if what you say is true then i would expect my 5400 hard disk may 

Well, just keep upping the disk buffer size to something really big 

like Peter suggested, and you may be able to do better. Otherwise, 

Yes. The entire file is read in the requested period of time without  
skipping any bytes.

Not if you want to support arbitrary speed changes in real time  
(which we do).

> if what you say is true then i would expect my 5400 hard disk may  
> not be up to the task...

Well, just keep upping the disk buffer size to something really big  
like Peter suggested, and you may be able to do better. Otherwise,  
you'll need to use buffer~.

you are playing this file at 1,2 Ghz sampling rate - so yes,

if a bigger buffer size does not help, it is a performance 

you are playing this file at 1,2 Ghz sampling rate - so yes,
if a bigger buffer size does not help, it is a performance 
problem.


glad to konw the answer, even if it's not what i would have preferred. tnx.

glad to konw the answer, even if it's not what i would have preferred.  tnx.

On 5/18/07, Roman Thilenius  wrote:
>
>
> mega, not giga.
> --
> http://vst-mac.info/
>

sfplay won't go faster than 29?