Quantcast
Channel: Processing Forum
Viewing all articles
Browse latest Browse all 1768

Re : Minim and Real Memory / Memory

$
0
0
Yes, I expect amnon.owed is correct. I've just reviewed the code in Minim and when you create an AudioPlayer, even if you haven't told it to play, it starts an audio output that it gets from JavaSound. It could be the case that on the Mac if you open more than 32 of these it just stops working but does so in a way that does not generate an error message. I would recommend two possibilities:

1) do it like you were before where you close() your AudioPlayer variable before creating a new one with the next file to play. By calling close() it should close the underlying audio output and stop the thread of execution that it spawned. If you aren't seeing that happen then it's a bug and hopefully I can fix it some day.

2) Instead of using AudioPlayer you can use FilePlayer from the ddf.minim.ugens package (put import ddf.minim.uges.* at the top of your sketch). You would then create an array of FilePlayer objects and patch() them all to a single AudioOutput. Creating a FilePlayer and patching it to an AudioOutput looks like this:

  1. AudioOutput theOut = minim.getLineOut();
  2. FilePlayer theFile = new FilePlayer( minim.loadFileStream( folder + "/" + filenames[i], 512) );
  3. theFile.patch( theOut );
You then call play and pause and whatever else on the FilePlayer, it has all the same methods as AudioPlayer for that. And as amnon.owed already mentioned, you no longer have to explicitly close the stream opened for the FilePlayer or the AudioOutput, that will happen your sketch is closed. 

I think this second option is the one that is more likely to work how you'd like it to, though I am curious if you will run into a problem with having that many open file handles.

Viewing all articles
Browse latest Browse all 1768

Trending Articles