Alternatives to sfplay~
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 ++.
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...
What are my options, if any?
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
________________
Mathieu Chamagne
mathieu.chamagne@free.fr
have u tried using preload message to setup cues with sfplay~ ?
this should fix the load time.
j
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).
Is that my only option? Perhaps there are externals that will do this? Have looked for suitable externals on maxobjects.com, with no luck...
Any other suggestions?
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...
On 24 juil. 08, at 11:30, Hans wrote:
> 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.
ej
Hi justin,
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.
Thanx for the help so far!
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~?
j
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 :)
in that case, i would consider using jitter to play the audio files.
jit.qt.movie > spigot~
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...
j
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..
Thanx again!
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
Hope that is clear.
--NW
I doubly echo Nathan's suggestion for sflist~. I think it's just what you are looking for.
David
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.
>
> 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.
mz
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).
jb
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~.
you could try....
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.
--dave linnenbank
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~.
j
On 26 juil. 08, at 13:38, justin wrote:
>> 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~.
> or does sfplay open mp3/mp4 via openraw message?
it does ;-) but probably not what you would expect, it just play bytes
like if it were a PCM file.
ej
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.
thanks,
j
sorry for straying from topic a little bit.
On 27 juil. 08, at 12:14, justin wrote:
> 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.
ej
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.
just a thought...
justin
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.
On 27 juil. 08, at 14:18, justin wrote:
> 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.
ej
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
>> 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.
You see what I mean?
or did I missed something?
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?
hi,
aren't mp3 files already compressed?
aren't any sound file found on CD already compressed?
how about flash memory stick?
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
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
----------------------------------------------------
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
___________________________________________________________________________________Ron Alford
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
p
Quote: pure wrote on Thu, 31 July 2008 08:46
----------------------------------------------------
> e.g. because you work on a project where people can bring/upload their
> own sounds
----------------------------------------------------
that's sort of the situation i'm in - one of the projects i'm working on requires a music player which ppl can bring their own files to (including mp3 / mp4). personally, i dont really like mp3 as a format... but i dont really have a choice for this project!
it seems to me that mp3 / mp4 playback would be a useful addition to sfplay~ for 2 main reasons:
1. streaming from disk leaves ram for other things
2. the use of mp3 and mp4 formats has increased substantially in recent times (amongst other things, the rise of the mp3 player...)
At the end of the day, i've built my hack around jit.qt.movie and it works fine... But from my POV, i see this functionality as more of an MSP task rather than Jitter. If i were new to max and wanted to make a similar type of application, MSP would be the first place to look, not Jitter.
j
I totaly agree, this should be a MSP feature included in sfplay.
I don't like mp3 neither but we have ot deal with it for obvious compatiblity reasons.
Where do we post an enhancement request for Max 5?
You should send feature requests to support, I'm pretty sure. That's what I've done in the past. The last one I sent was for enabling a text wrap option in the Max window.
9 years later I can open mp3 files with sfplay~ but it's still decompressing the whole file into ram instead of streaming from disk. And that adds much delay before playback. same amount of time it would take to load(decompress) the mp3 into buffer~.
It's still not possible with MSP to build an mp3/flac/* player app where you can quickly step through a playlist of compressed files.
I noticed that sfplay seems to keep the decompressed versions in ram even after opening other files. Every file is opened and played immediately if it has been opened before. Is that sfplay or simply some prefetch system of Windows maybe?
My question: which way to go to stream compressed files directly from disk so playback starts immediately?
Side question: How to open m4a in MSP (Windows OS) ? It says "cannot open parser for this file"?