It seems that there is no event dispatching system for sound stop.
Is there any plan to add this kind of functionalities?
It will be perfect if this framework has these functionality.
Just to verify that I understood the question, you mean to say that the SoundSystem should send out a message any time a sound has finished playing, correct? I definitely agree that it would be nice, and it is something I have tried to add in a couple of times. However, as far as I can tell, it "can't" be done (or more likely I am not clever enough to figure out how). Let me explain. It could be "easily" done for streaming sources (what JavaSound calls a "SourceDataLine"), since I am feeding them the data chunks, so I know when the end is reached. The problem is for non-streaming sources (what JavaSound calls a "Clip"). As far as I can see, there is no way to know when these kinds of sources are finished playing, because there is no such event dispatching in the underlying JavaSound and OpenAL libraries (correct me if I'm wrong about that, but I am pretty familiar with both libraries). If it's possible in either of them, I would guess its OpenAL, but I would need to be able to do it in both libraries before it could be added to the SoundSystem. Currently, the only way it could be done would be to constantly check if each source is still playing, which would no doubt be a major resource hog.
:D ok I stay tuned, I'm waiting for the integration in JME. Will you really put your sound system into JME 2 or only in JME 3?
Currently I can't say. However, it will be a seperate library from JME itself (it'll just support JME-specific methods and concepts for easy use in JME projects), so I'll probably try to make it compatible with both (if that is possible). I'll research the issue further and let you know.
I hope this doesn't bother you too much, but would I be able to play a file that is located anywhere in my computer? I have tried using the .load on a URL, but it doen't seem to pick up the music file.
I wasn't able to reproduce this problem, however I changed the way URLs work, as I mentioned in a previous post, so that most likely resolved the issue. Also, I fixed a CodecJOrbis header compatibility issue with OGG files generated by Audacity, so if the file in question was an OGG, this might have been the problem (in which case it should be fixed now). When I release the next version, let me know if this bug and the MIDI issue have been resolved.
I believe the last thing I need to tackle is gracefully handling cases where AL_PITCH is not compatible. This is going to be a pretty simple fix I think, so I should be posting the next release of SoundSystem this weekend. Then I can get back to the extension of SoundSystem for JME (finally!)
Ok, I solved the problem. This logic error has actually been in the code for a very long time, but it never manafested itself until now. I had to change the CommanQueue/ManageSources infrastructure to correct it, so any legacy code that extends the SoundSystem class for customized source management models will most likely now be broken. If this causes problems for anyone, please refer to the JavaDoc for the proper new way to do custom source management, or post questions here for help. Sorry any inconvenience this causes.
I fixed one more minor bug - a looping MIDI source without any sequences its play queue wasn’t looping. I went ahead and uploaded the fixed JAR and sourcecode (only the SoundSystem core was affected by the change).
Also, I finished my new and improved Helicopter Balls applet (taking the silliness to a whole new level):
It is currently written in jPCT, but I am in the process of porting it to jME. I’ll repost the applet, as well as the source code when I finish the port. As mentioned previously, I am using this demo applet as a method of learning jME well enough to write a good extension of SoundSystem for it.
Nope! Well, I guess one goal might be to see how long you can fly around before you go completely bonkers (and then realize about how crazy I must be to have programed it). :D
I suppose if I was ambitious I could add a timer and hit-detection, and make the number of balls increase each level (the goal being to not collide with any balls).
I need to load sounds off the file system. I'm writing an editor where the user can add and remove files. Using a jar is out of the question.
I see that you've added url versions to some of the methods in SoundSystem. But not all, and not the ones I want to use like newSource.
I would not need to send in an url if I could change PREFIX_URL, but it is final. My plan was to set it to "*" and send in urls to the files like this:
String filename = new File("c:\temp\test.ogg").toURI().toURL().toString();
Any chance you could make PREFIX_URL not final, or add a setter and getter. I could compile myself but it would like to keep using the official version.
Other than that I think it is a great api :) keep up the good work.
The quickPlay or newSource methods don't need a URL - these methods don't actually load a file. It would be extremely inefficient if SoundSystem had to load a file every time you made a source. These methods access data that has previously be loaded and given an identifier (the identifier is the filename if you're not using URLs). They are somewhat forgiving, in that if you didn't previously load the sound before calling them, they will attempt to load if for you. Obviously, that safeguard doesn't work when loading sounds from URLs, since URLS do not necessarily have a unique string associated with them. Identifiers let quickPlay and newSource know which previously-loaded sound to use.
Use the "loadSound( URL url, String identifier )" method to load your sounds from URLs and give them identifiers. Then use those identifiers in the quickPlay and newSource methods.
-EDIT
I can see where the confusion may come from, since the parameter for identifer in both of those methods is called "String filename". The reason for that is because I originally used the filename as the identifier for each loaded sound. I still think it makes sense to call this parameter filename, because even if you load a sound from a URL, the identifier must end in the correct file extension (call it what you like, but it must look like a filename). That's how SoundSystem knows what codec to use for decoding it.
At any rate, I will explain the whole filename/identifier concept better in my tutorial - I'm sure you aren't the only one to be confused about it.
Perhaps when each sound is loaded, the codec needed to play it is also noted internally in the sounds system, to remove this reliance of needing the extension in the identifier. Just seems a little unnecessary to me.
Perhaps when each sound is loaded, the codec needed to play it is also noted internally in the sounds system, to remove this reliance of needing the extension in the identifier. Just seems a little unnecessary to me.
That makes sense, however it would change the way the codec interface is used, how the plug-ins are linked, and the loadSound methods. There are enough developers using the library at this point that I need to have a pretty good reason for changing anything that has an impact on legacy code. (I get about 30 complaints every time I make a change like that). Additions are fine or internal changes, but I try to keep the old interface methods exactly the same.
But getting back to the URL issue - I would like to point out that the SoundSystem library was not originally designed for use with URLs. I honestly don't see why this is such a critical capability. I have already spent several weeks on frankly a non-issue IMHO. I feel like I've accommodated the hard-liners who insist on using URLs - everything you can do with filenames I have provided a way to do with URLs. Yes, I could change the name of the parameter to "identifier" instead of "filename", but then the folks who don't use URLs will be just as confused as the URL folks are now. At this point I'd like to fix any bugs that may still exist, and move on to other features and improvements.
Speaking of bugs… I just found one while I was looking at the URL code.
It is related to the fact that clips in OpenAL can be much longer than they can be in JavaSound. If you hand JavaSound too much data, it gets very angry at you.
The bug happens if you load a clip via URL while OpenAL is the active library, then "switchLibrary" to JavaSound. In the past, to avoid getting screamed at by JavaSound, I would just dispose of the old buffers and load new properly-sized ones using the filenames. I would do the same when switching back to OpenAL, so the clips don't have to be restricted to the JavaSound size requirement. Unfortunately, I can't use this setup any more since a URL can not be conjured up via its identifier…
Hmm… I'll have to think about this one for a while.
The quickPlay or newSource methods don't need a URL - these methods don't actually load a file.
My mistake. I'm new to the api and was a bit confused. It's getting clearer though :)
Is there a way to get a list of all the sources and files that are loaded? I need to unload everything when I change level. I could track this information myself, but I'm very lazy.
Is there a way to get a list of all the sources and files that are loaded?
Not yet, but thats a great suggestion. I'll add a couple of methods to do this
For the files that are loaded, should the method return a list of identifiers/filenames? That seems like it would be the best choice since the unloadSound method takes the identifier as its parameter. The one for sources should probably return a list of sourcenames.
ok I stay tuned, I'm waiting for the integration in JME. Will you really put your sound system into JME 2 or only in JME 3?