sfplay won't go faster than 29?

May 18, 2007 at 9:22pm

sfplay won't go faster than 29?

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;

#31983
May 18, 2007 at 9:24pm

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

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

#104508
May 18, 2007 at 9:59pm

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

#104509
May 18, 2007 at 10:39pm

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
>

#104510
May 18, 2007 at 11:05pm

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

Cheers,
ej

#104511
May 18, 2007 at 11:12pm

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

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

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

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

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

-Joshua

#104512
May 19, 2007 at 1:20am

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.

#104513
May 19, 2007 at 1:21am

mega, not giga.

#104514
May 19, 2007 at 5:46pm

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

#104515

You must be logged in to reply to this topic.