HSel

I am creating a program where the user interface is programmed in different programming language, which communicates with a Max patch for everything audio related.

The user interface can tell the max-patch to open a file in an sfplay~ object, and to play it back.

This works ok... the only problem is the time sfplay~ takes to buffer up the start of the file, and that it gives no indication of when it's finished.

A workaround I've used is to allow at least 1/3 second between "open" and "open" or "open" and "play/seek" messages to the object.

This is a very crude way of doing it however, and would change from system to system depending on rpm speeds on hd's, sleep mode ++.

So what Im looking for is an alternative to sfplay~. One that gives a return value when it's finished with a load. The only other messages I need to send it is "seek" and "0"(stop).

Using [buffer~] and [groove~] is no option as load times are too long...

Hi all,
I am creating a program where the user interface is programmed in different programming language, which communicates with a Max patch for everything audio related.
The user interface can tell the max-patch to open a file in an sfplay~ object, and to play it back.

This works ok... the only problem is the time sfplay~ takes to buffer up the start of the file, and that it gives no indication of when it's finished.
A workaround I've used is to allow at least 1/3 second between "open" and "open" or "open" and "play/seek" messages to the object.
This is a very crude way of doing it however, and would change from system to system depending on rpm speeds on hd's, sleep mode ++.

alternatives-to-sfplay

it's right output will tell you "read filename 1" when file is loaded.

and you can use spigot~ to route audio in msp if needed.

jit.qt.movie can read sound file.
it's right output will tell you "read filename 1" when file is loaded.
and you can use spigot~ to route audio in msp if needed.

________________
Mathieu Chamagne
mathieu.chamagne@free.fr

http://mathieuchamagne.com
http://www.maxobjects.com


have u tried using preload message to setup cues with sfplay~ ?

have u tried using preload message to setup cues with sfplay~ ?
this should fix the load time.

I don't own a license for it (yet) and I suspect it would consume more cpu than sfplay~ will (correct me if Im wrong).

Is that my only option? Perhaps there are externals that will do this? Have looked for suitable externals on maxobjects.com, with no luck...

Thanx for the suggestion.
I've heard of this solution before.
I would rather not use jitter though.
I don't own a license for it (yet) and I suspect it would consume more cpu than sfplay~ will (correct me if Im wrong).

I have looked into the preload message with sfplay~, yes.

This doesn't work in my case however, as there is no way of knowing what soundfile to load (changes from time to time), and the section of file needed also changes.

Which would mean I would have to preload the whole file, bringing the load time up significantly. Then I might as well use a [buffer~].

I have looked into the preload message with sfplay~, yes.
This doesn't work in my case however, as there is no way of knowing what soundfile to load (changes from time to time), and the section of file needed also changes.

Which would mean I would have to preload the whole file, bringing the load time up significantly. Then I might as well use a [buffer~].


i think you will get more concise answers if u explained a bit more about ur patch, or even better provided a part of the patch which illustrates the problem.

your answer below seems to say that there are several audio files, of which you need to play different sections of each file... then u go on to say you would have to preload the whole file???

so what is it one file or many files? are they big files, if so how big?

sorry, i'm a bit lost with your question...

> I have looked into the preload message with sfplay~, yes.

> This doesn't work in my case however, as there is no way of knowing 

> what soundfile to load (changes from time to time), and the section 

> Which would mean I would have to preload the whole file, bringing 

> the load time up significantly. Then I might as well use a [buffer~].

preload only load into memory the beginning of the part of the sound 

file that you want to play, not the entire file.

> I have looked into the preload message with sfplay~, yes.
> This doesn't work in my case however, as there is no way of knowing  
> what soundfile to load (changes from time to time), and the section  
> of file needed also changes.
>
> Which would mean I would have to preload the whole file, bringing  
> the load time up significantly. Then I might as well use a [buffer~].

preload only load into memory the beginning of the part of the sound  
file that you want to play, not the entire file.

Sorry for being about unclear about my program.

The max patch actually has 16 sfplay~'s. Each one of these can be controlled separately from the UI. The 16 players are abstracted away from the user, so he only needs to load files and tell them to play. The UI allows the user to load an infinite amount of samples, and only loading them into the max patch when they are needed.

Files are loaded into the max-patch as they are needed from the UI. So the file for each one of these 16 sfplay~'s may change at any time depending on the input.

The UI has functionality to load a new sample into a sfplay~ when the previous sample is finished/not needed any longer.

The problem then is for the UI to know when it is allowed to send the sfplay~ object(s) a new "open" or "play/seek". So if I had a return value from sfplay~ I could let the UI wait until it gets a message back before performing the next task.

Ah... I see about the preload... Though it still wouldn't help as there's no return value. I cannot load the sample before it is actually needed either, because the user input in the UI decides when a sample needs to loaded into one of the 16 sfplay~'s.

I hope that was a little bit clearer... If not, let me know and I'll try my best to explain.

Hi justin,
Sorry for being about unclear about my program.

Files are loaded into the max-patch as they are needed from the UI. So the file for each one of these 16 sfplay~'s may change at any time depending on the input.
The UI has functionality to load a new sample into a sfplay~ when the previous sample is finished/not needed any longer. 

no probs, kind of makes more sense now... but it's still difficult to see on how you might resolve this, do u have any pictures of the UI?

as u mention sfplay, doesnt provide feedback for when files are loaded - sfplay streams files from disk, so if u have a fast HD then it should be very fast, and even faster if u use preload...

the other part of the problem, is the UI... out of curiosity what is the UI made in, and why that over max?

also can u preload the next file just before the end of the current file, then seek/play it when u get the end of file bang from sfplay~?

the other part of the problem, is the UI... out of curiosity what is the UI made in, and why that over max? 

The UI is arranged into events, where each event may contain one or more sound files. The events are then stepped through one after another, or jumped between. 

So it's difficult to know what the next file to load is, therefore it's also difficult to preload the next because you don't know what it is until it's actually needed.

UI is written in Java, communication to Max over OSC. I didn't use Max for this, because the UI handles lots of stuff not just the Max communication, and Max isn't really suited for creating a full-on UI like I needed.

You are right about HD speeds coming into this, like I mentioned in my original post. Which is exactly why I would want a return value. If the speed was always the same, it would be a lot easier...

I found an older post about the needs for a return value from sfplay~, so was hoping there now might be a alternative offering this. If not, I'm sure I can make it work with what I have :)

The UI is arranged into events, where each event may contain one or more sound files. The events are then stepped through one after another, or jumped between. 
So it's difficult to know what the next file to load is, therefore it's also difficult to preload the next because you don't know what it is until it's actually needed.

I found an older post about the needs for a return value from sfplay~, so was hoping there now might be a alternative offering this. If not, I'm sure I can make it work with what I have :)


in that case, i would consider using jitter to play the audio files.

as previously stated, the advantage being that jit.qt.movie does notify when files are loaded. also, i'm not so sure about your concern over cpu usage when using jitter. i doubt there would be any difference between that method and sfplay...

in that case, i would consider using jitter to play the audio files. 

Will look into the jit.qt.movie->spigot~ solution.

Though from my first attempts here, it seems to crash Max5 with just a single instance....

Also read the Quicktime 7 change in spigot~ help saying it now cache's all the data. 

Will see if there's anything to gain by going in this direction though..

Thanx for all the help.
Will look into the jit.qt.movie->spigot~ solution.
Though from my first attempts here, it seems to crash Max5 with just a single instance....
Also read the Quicktime 7 change in spigot~ help saying it now cache's all the data. 
Will see if there's anything to gain by going in this direction though..

You should consider [sflist~] as a central hub to load/change sound files for all your [sfplay~] objects. It should be simpler to handle loading separate from playback. Your individual [sfplay~] objects can then just use different numbers to address the soundfile cues you want them to play. And it makes remapping the cues for each [sfplay~] a breeze (just change the number).

I have used this method before and the changes happen quite fast. But it also allows you to easily load new soundfiles *ahead* of the change in selection by your playback routine. In other words...

2) load cue M into [sflist~] now so it is ready

3) some time later change [sfplay~] to cue M

You should consider [sflist~] as a central hub to load/change sound files for all your [sfplay~] objects.  It should be simpler to handle loading separate from playback.  Your individual [sfplay~] objects can then just use different numbers to address the soundfile cues you want them to play.  And it makes remapping the cues for each [sfplay~] a breeze (just change the number).

I have used this method before and the changes happen quite fast.  But it also allows you to easily load new soundfiles *ahead* of the change in selection by your playback routine.  In other words...

1) [sfplay~] is using cue N
2) load cue M into [sflist~] now so it is ready
3) some time later change [sfplay~] to cue M
4) repeat

I doubly echo Nathan's suggestion for sflist~. I think it's just what you are looking for.

Will look into that. Requires a bit of redesigning on how the samples are loaded, but if it works, it'll be worth it.

Thanx for the tip about sflist~.
Will look into that. Requires a bit of redesigning on how the samples are loaded, but if it works, it'll be worth it.


Quote: justin wrote on Thu, 24 July 2008 04:55

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

> in that case, i would consider using jitter to play the audio files. 

I might be crazy, but I think this combination simply makes a secret sfplay~. It plays the soundfile off of the disk in time with the movie. If I'm right, I don't think this is that great of a solution.

Quote: justin wrote on Thu, 24 July 2008 04:55
----------------------------------------------------
> in that case, i would consider using jitter to play the audio files. 
>
> jit.qt.movie > spigot~
>
----------------------------------------------------

I might be crazy, but I think this combination simply makes a secret sfplay~.  It plays the soundfile off of the disk in time with the movie.  If I'm right, I don't think this is that great of a solution.

mzed wins a fish! spigot~/jit.qt.movie does use a secret sfplay~ object to do its work.

What's all that about crashing, though? Support is your friend. If it crashes, don't just mention it offhand, send a bug report! (I can't reproduce on OSX, btw).

i would suggest looking into sfinfo~. pull up the help file and consider the right side of the patch, which uses the 'name x' message to sfplay~ and the 'getnamed x' message to sfinfo~.

1) when sending a message to sfplay~ to load a new file, begin polling sfinfo~ with the 'getnamed x' message

2) wait for a changed filename to come out the rightmost outlet of sfinfo~

maybe this approach could be fleshed out to work for you.

i would suggest looking into sfinfo~.  pull up the help file and consider the right side of the patch, which uses the 'name x' message to sfplay~ and the 'getnamed x' message to sfinfo~.

1) when sending a message to sfplay~ to load a new file, begin polling sfinfo~ with the 'getnamed x' message
2) wait for a changed filename to come out the rightmost outlet of sfinfo~

Quote: mzed wrote on Fri, 25 July 2008 19:41

> I might be crazy, but I think this combination simply makes a secret sfplay~. It plays the soundfile off of the disk in time with the movie. If I'm right, I don't think this is that great of a solution.

so how come jit.qt.movie > spigot~ supports more audio formats than sfplay~ (mp3, mp4) -- a bit weird since it is just an sfplay~...

or does sfplay open mp3/mp4 via openraw message?

BTW, no crashing here with 504 and spigot~.

Quote: mzed wrote on Fri, 25 July 2008 19:41
----------------------------------------------------
> I might be crazy, but I think this combination simply makes a secret sfplay~.  It plays the soundfile off of the disk in time with the movie.  If I'm right, I don't think this is that great of a solution.
----------------------------------------------------

so how come jit.qt.movie > spigot~ supports more audio formats than sfplay~ (mp3, mp4) -- a bit weird since it is just an sfplay~... 

>> I might be crazy, but I think this combination simply makes a 

>> secret sfplay~. It plays the soundfile off of the disk in time 

>> with the movie. If I'm right, I don't think this is that great of 

> ----------------------------------------------------

> so how come jit.qt.movie > spigot~ supports more audio formats than 

> sfplay~ (mp3, mp4) -- a bit weird since it is just an sfplay~...

The mp3/mp4/orwhatever file is decompressed (using QuickTime), and 

saved to your hard disk as a 32bits floating point sound file, which 

> or does sfplay open mp3/mp4 via openraw message?

it does ;-) but probably not what you would expect, it just play bytes 

>> I might be crazy, but I think this combination simply makes a  
>> secret sfplay~.  It plays the soundfile off of the disk in time  
>> with the movie.  If I'm right, I don't think this is that great of  
>> a solution.
> ----------------------------------------------------
>
> so how come jit.qt.movie > spigot~ supports more audio formats than  
> sfplay~ (mp3, mp4) -- a bit weird since it is just an sfplay~...

The mp3/mp4/orwhatever file is decompressed (using QuickTime), and  
saved to your hard disk as a 32bits floating point sound file, which  
is read by the hidden sfplay~.

it does ;-) but probably not what you would expect, it just play bytes  
like if it were a PCM file.

ok that makes sense, but i still wonder why u cant open mp3 / mp4 with sfplay directly? i know u can do it with buffer~, but that's loading into ram...

would it not be useful to have an import message for sfplay to decompress mp3/mp4 and be able to stream them from disk?

i'm only asking because i was recently asked to build a sound file player that could play commom media types (including mp3 / mp4). i ended up having to use jitter to get round the problem, but it would be nice to have that functionality in MSP.

sorry for straying from topic a little bit.

> ok that makes sense, but i still wonder why u cant open mp3 / mp4 

> with sfplay directly? i know u can do it with buffer~, but that's 

> would it not be useful to have an import message for sfplay to 

> decompress mp3/mp4 and be able to stream them from disk?

basically using the import message is going to decompress the file and 

stores it in the buffer~ as 32 bits floating points values. Using 

[jit.qt.movie], does the same kind of decompression, but stores the 

files permanently on the hard disk (it's somewhere in your ~/Library/ 

Application Support/ folder). I would say that this use of 

[jit.qt.movie]+[spigot~] here is there for compatibility reasons, kind 

of nice hack to keep sound track playing since the dead of this 

> ok that makes sense, but i still wonder why u cant open mp3 / mp4  
> with sfplay directly? i know u can do it with buffer~, but that's  
> loading into ram...
>
> would it not be useful to have an import message for sfplay to  
> decompress mp3/mp4 and be able to stream them from disk?

basically using the import message is going to decompress the file and  
stores it in the buffer~ as 32 bits floating points values. Using  
[jit.qt.movie], does the same kind of decompression, but stores the  
files permanently on the hard disk (it's somewhere in your ~/Library/ 
Application Support/ folder). I would say that this use of  
[jit.qt.movie]+[spigot~] here is there for compatibility reasons, kind  
of nice hack to keep sound track playing since the dead of this  
feature with QuickTime 7.

sorry, i think my question was slightly misunderstood.

i guess i was asking for an additional feature to sfplay~. 

The idea being that if u didnt have jitter installed, u could stream mp3/mp4 files from disk via MSP's sfplay~.

i imagined something like "import audio.mp3" > sfplay~

but i guess it's not overly important as that functionality is covered by jitter, although (personally) i would put this feature in the MSP category, rather than Jitter.

i guess i was asking for an additional feature to sfplay~. 
The idea being that if u didnt have jitter installed, u could stream mp3/mp4 files from disk via MSP's sfplay~. 

Am actually using sfinfo~ to get other info about the samples as it is, just hadn't thought of using it like this.

For me, this will be an easier thing to implement than going the sflist~, less to redo.

Though for loading samples quicker, sflist~ definitely sounds like the way to go!

Wasn't sure about whether the crash had anything to do with me running an unauthorized version of jitter. Anyway, it seems to happen if you load a large sample (in my case about 250mb). All I did after that was to hit read and stop a few times. This is on 10.5.4 running Max 5.0.3 btw. Will update to 5.0.4 and see if the bug persist. If so, I will file a bug report.

dalinnen,
sounds exactly like what Im after!
Am actually using sfinfo~ to get other info about the samples as it is, just hadn't thought of using it like this.
For me, this will be an easier thing to implement than going the sflist~, less to redo.
Though for loading samples quicker, sflist~ definitely sounds like the way to go!

Wasn't sure about whether the crash had anything to do with me running an unauthorized version of jitter. Anyway, it seems to happen if you load a large sample (in my case about 250mb). All I did after that was to hit read and stop a few times. This is on 10.5.4 running Max 5.0.3 btw. Will update to 5.0.4 and see if the bug persist. If so, I will file a bug report.


> sorry, i think my question was slightly misunderstood.

> i guess i was asking for an additional feature to sfplay~.

> The idea being that if u didnt have jitter installed, u could stream 

> mp3/mp4 files from disk via MSP's sfplay~.

> i imagined something like "import audio.mp3" > sfplay~

> but i guess it's not overly important as that functionality is 

> covered by jitter, although (personally) i would put this feature in 

well, you have "import" for [buffer~] in the MSP world. I personally 

prefer this kind of solution, because I have more control over my 

> sorry, i think my question was slightly misunderstood.
>
> i guess i was asking for an additional feature to sfplay~.
> The idea being that if u didnt have jitter installed, u could stream  
> mp3/mp4 files from disk via MSP's sfplay~.
>
> i imagined something like "import audio.mp3" > sfplay~
>
> but i guess it's not overly important as that functionality is  
> covered by jitter, although (personally) i would put this feature in  
> the MSP category, rather than Jitter.

well, you have "import" for [buffer~] in the MSP world. I personally  
prefer this kind of solution, because I have more control over my  
sound file management.

Quote: Emmanuel Jourdan wrote on Wed, 30 July 2008 00:35

> well, you have "import" for [buffer~] in the MSP world. I personally 

> prefer this kind of solution, because I have more control over my 

i know i can do it with buffer, but isnt that decompressing the mp3 file into RAM? whereas the sfplay~ method is reading the file from disk...

for instance, if i was using the buffer method and i was working with long .mp3 files (== large decompressed file size). i might get to a point where there is very little RAM left... which would have a negative impact on the stability of the app / os.

Quote: Emmanuel Jourdan wrote on Wed, 30 July 2008 00:35
----------------------------------------------------
> well, you have "import" for [buffer~] in the MSP world. I personally  
> prefer this kind of solution, because I have more control over my  
> sound file management.
>
> ej
----------------------------------------------------

>> well, you have "import" for [buffer~] in the MSP world. I personally

>> prefer this kind of solution, because I have more control over my

> i know i can do it with buffer, but isnt that decompressing the mp3 file into

> RAM? whereas the sfplay~ method is reading the file from disk...

> for instance, if i was using the buffer method and i was working with long

> .mp3 files (== large decompressed file size). i might get to a point where

> there is very little RAM left... which would have a negative impact on the

I believe if there is no more "real" RAM, the OS will make some from the

hard disk. So, that shouldn't be too big a problem. Anybody knowing more

>> well, you have "import" for [buffer~] in the MSP world. I personally
>> prefer this kind of solution, because I have more control over my
>> sound file management.
>>
>> ej
> ----------------------------------------------------
>
> i know i can do it with buffer, but isnt that decompressing the mp3 file into
> RAM? whereas the sfplay~ method is reading the file from disk...
>
> for instance, if i was using the buffer method and i was working with long
> .mp3 files (== large decompressed file size). i might get to a point where
> there is very little RAM left... which would have a negative impact on the
> stability of the app / os.
>
> justin
>

I believe if there is no more "real" RAM, the OS will make some from the
hard disk. So, that shouldn't be too big a problem. Anybody knowing more
about that?
J-F.


Sorry to insist Emmanuel but I am with Justin here.

There are some needs where sfplay is the right choice because you really want a direct to disk (many large files to access).

If only some of these file are mp3, I don't want to give up on sfpay (use buffer) just to get compatibility with mp3.

Quote: justin wrote on Wed, 30 July 2008 10:41

> Quote: Emmanuel Jourdan wrote on Wed, 30 July 2008 00:35

> > well, you have "import" for [buffer~] in the MSP world. I personally 

> > prefer this kind of solution, because I have more control over my 

> i know i can do it with buffer, but isnt that decompressing the mp3 file into RAM? whereas the sfplay~ method is reading the file from disk...

> for instance, if i was using the buffer method and i was working with long .mp3 files (== large decompressed file size). i might get to a point where there is very little RAM left... which would have a negative impact on the stability of the app / os.

Sorry to insist Emmanuel but I am with Justin here.
There are some needs where sfplay is the right choice because you really want a direct to disk (many large files to access).
If only some of these file are mp3, I don't want to give up on sfpay (use buffer) just to get compatibility with mp3.
You see what I mean?

Quote: justin wrote on Wed, 30 July 2008 10:41
----------------------------------------------------
> Quote: Emmanuel Jourdan wrote on Wed, 30 July 2008 00:35
> ----------------------------------------------------
> > well, you have "import" for [buffer~] in the MSP world. I personally  
> > prefer this kind of solution, because I have more control over my  
> > sound file management.
> >
> > ej
> ----------------------------------------------------
>
> i know i can do it with buffer, but isnt that decompressing the mp3 file into RAM? whereas the sfplay~ method is reading the file from disk...
>
> for instance, if i was using the buffer method and i was working with long .mp3 files (== large decompressed file size). i might get to a point where there is very little RAM left... which would have a negative impact on the stability of the app / os.
>
> justin
>
>
----------------------------------------------------


i think you have limited options in this case. option 1, i guess is 3rd party externals. the ms pinky external is one that comes to mind (not free though).

option 2 is converting all mp3 files to aif or wav. this seems the best option to me, especially if performance is a concern. why add unnecessary decompression stage during performance when you can do that ahead of time?

i think you have limited options in this case. option 1, i guess is 3rd party externals.  the ms pinky external is one that comes to mind (not free though).

option 2 is converting all mp3 files to aif or wav.  this seems the best option to me, especially if performance is a concern.  why add unnecessary decompression stage during performance when you can do that ahead of time?


aren't any sound file found on CD already compressed?

yes, buffers fill up memory, and yes sfplay~ plays from disk, but what's the difference if you want your sound clean and clear - when compression already exists? can't sample from CD too many files at once, right? so buffers open, for speed, and more files played at once?

___________________________________________________________________________________Ron Alford                                                        

aren't mp3 files already compressed?
aren't any sound file found on CD already compressed?
how about flash memory stick?

justin  wrote: 
Quote: Emmanuel Jourdan wrote on Wed, 30 July 2008 00:35
----------------------------------------------------
> well, you have "import" for [buffer~] in the MSP world. I personally  
> prefer this kind of solution, because I have more control over my  
> sound file management.
>
> ej
----------------------------------------------------

___________________________________________________________________________________Ron Alford														

> why add unnecessary decompression stage during performance when you can do that ahead of time?

e.g. because you work on a project where people can bring/upload their 

e.g. because even with decompression you have enough cpu left - so why 

bother - and you prefer to spend you time with making music instead of 

Robert Ramirez wrote:
> why add unnecessary decompression stage during performance when you can do that ahead of time?
>

e.g. because you work on a project where people can bring/upload their 
own sounds
e.g. because even with decompression you have enough cpu left - so why 
bother - and you prefer to spend you time with making music instead of 
optimizing patchers

-- 
http://pure.test.at
http://www.myspace.com/pvre
http://www.heartchamberorchestra.org


Quote: pure wrote on Thu, 31 July 2008 08:46

> e.g. because you work on a project where people can bring/upload their 

Alternatives to sfplay~