Howler.js: Call for Testing/Feedback: howler.js v2.0.0-beta

[goldfire]

The 2.0 branch is finally to a point where it is ready for public testing and feedback! This is still very much beta, so use at your own risk (especially the effects plugin). The library has been rewritten from the ground up, taking into account all of the lessons learned since the very first commit. Be sure to check the changelog for the quite large list of additions/updates/fixes.

Before this can be merged to master, I need help from the community testing and providing feedback on the API, features, etc. Please use this thread for general feedback and tag any issues or pull requests with 2.0. There's still a lot of work to be done, so check back with this thread often for updates.

There's also a new audible testing script in the tests directory. I'd love to expand this further, so if anyone has ideas, please add them here or open a pull request. Be sure to run the tests on a webserver so that the Web Audio section doesn't fall back to HTML5 Audio.

CHANGELOG

BRANCH: 2.0

TODO

• [x] Determine what else is missing from effects plugin.
• [x] Clear out rest of open 2.0 issues.
• [x] Improvements to tests.
• [x] Overhaul the documentation.
• [x] Add more examples to documentation.
• [x] New examples and demos.
• [x] Create a migration guide.
• [x] Should the logo get a refresh?

...am I forgetting anything?

[johnrayner]

Thank you for your hard work on this. Most appreciated!

I dropped this into my Melon.js / Cocoon code and found an issue. I don't use sound sprites and this line is giving me an error ("Cannot read property 0 of undefined"):

 var seek = sound._seek > 0 ? sound._seek : self._sprite[sprite][0] / 1000;

Looks like the default sprite is not being setup correctly.

[johnrayner]

Turns out that Melon.js was playing "_default" as the default sprite, instead of "__default". I'll pass on the tip to the Melon devs.

[goldfire]

Oh, I didn't realize anyone was calling the default sprite directly. I changed it to "__default" as I figured there would be less chance for collisions.

[obiot]

interesting, is there then a better/proper way to do it without using _default ?

[goldfire]

Calling sound.play() is equivalent to sound.play('__default').

[obiot]

in our case we also use a callback function, so we do have to pass a first argument (although based on the 1.1.x branch, we could just use undefined) :
https://github.com/melonjs/melonJS/blob/master/src/audio/audio.js#L225

[goldfire]

Ah, yes for 1.1.x that'll work fine, and undefined could be passed as well. 2.0 does away with the callback, so play now only takes the sprite/id argument.

[obiot]

got it ! thank you very much by the way for Howler, we switched from our own crappy implementation to Howler a few months ago now, and we love it ! I can't wait to try the new 2.0 branch :P

[goldfire]

Awesome, I've really enjoyed seeing so many people benefit from it!

[obiot]

https://github.com/melonjs/melonJS :)

[namuol]

Great news! I'll switch over ASAP. :thumbsup:

[johnrayner]

I had some trouble looping a sound. To get it to work, I had to change the loop detection code to be this:

  // Should this sound loop?
  var loop = !!(self._loop || sound._loop || self._sprite[sprite][2]);

[goldfire]

@johnrayner Thanks, just pushed a fix. self._loop actually just needed to be changed to sound._loop.

[ddennis]

I am still not sure if this is the right place, to post issues?

Regarding the 2.0 branch and getting the duration of the sound.

mySound._duration // works
mySound.duration // fails

[goldfire]

@ddennis Thanks, not actually a bug as there is no duration property, but I've now added a duration() method to make checking this clearer.

[filipmares]

I just ran into something that i believe was in also present in the previous version. (pos/seek)

I'd like to seek() a Howl before i play(). The unfortunate side-effect of this is that calling play() after seek() resets the sound's _seek. This happens because by default the sound is initialized with _ended = true.

Two possible solutions:

• Have seek() set _ended = false.
• When finding the first inactive node, check for _ended or _seek (line 1194)

Thoughts?

[goldfire]

Just a quick update on progress. I was hoping to have had this all ready to go by now, but we've had some things come up the last month or so that have kept me occupied. I am happy to say that we've been running this in production for a few weeks now without any issues, so a few more edge-case bugs and more work on the effects plugin are the major hurdles remaining.

[filipmares]

Thanks @goldfire! We're using this in production at Talko. Rock solid for our usecase of core.

[germs12]

@goldfire love what you're doing. I've switch over from my own implementation to howler.js and it's made cross browser functionality work really seamlessly (minus a couple issues). When can we expect to have this merged into master? Thanks!

[goldfire]

@germs12 Glad to hear you are finding it useful! To be honest I was hoping to have merged it by now, but things generally never go as planned. I'm out of town until early next week, but I hope to get back to working towards completion later next week and will have a better idea then.

[germs12]

Awesome. Really looking forward to using 2.0 in production. Will add PR for anything I find that's lacking. Thanks again!

[obiot]

@goldfire melonJS reporting here as well, a bit late but we just integrated the current 2.0.0 beta and we have no issue to report so far. On the contrary, all issues I initially spotted, and most specifically the previous pause/resume one (I created a ticket for) are now gone, and I finally could remove my ugly workaround code :)

[gre]

Thanks for this v2, it works quite smooth on my current game, 3D audio is a blast, very impressive result.

I have feedbacks in term of API, I don't find it very easy and straightforward to use audioId that you have to pass in to all functions:

var audioId = howl.play();
howl.pos(x, y, z, audioId);
howl.velocity(vx, vy, vz, audioId);

I don't know what are the reason behind but I I think it would be simpler to have an object returned like:

var soundInstance = howl.play();
soundInstance.pos(x, y, z);
soundInstance.velocity(vx, vy, vz);

Also, it would be great to be able to do this:

var soundInstance = howl.play({ pos: [x,y,z], velocity: [vx,vy,vz] });

That would make it more obvious (and maybe on your side have more guarantee) that the play() will start at a given pos and velocity (and no click / jump after starting the sound – if you happen to have this bug in the future, the current API make it impossible to fix that because you play before setting pos and velocity).

Also, in general, my proposal could be a way to unify the API of the listener, the group and a sound instance:

// 3 use-cases, same API
howl.pos(x, y, z);
soundInstance.pos(x, y, z);
Howler.pos(x, y, z); // like current, but ideally I think something like: `Howler.listener.pos(...)` would be more straightforward that you basically set the position of the microphone.

Thanks

[goldfire]

@gre Sorry about the slow response to this. I think the reason for going with the current API was to not significantly change it from the previous API. Considering it is a 2.0 release, that may not be as big of a concern, but it certainly would have been easier to make that switch before a lot of people started using the 2.0 branch.

I'll have to keep thinking on that one as I do agree it does help to unify the API. Does anyone else have any thoughts on this?

Edit: I do remember thinking about this exact API in the early planning of 2.0. Besides keeping the API as close as possible, another consideration was that the pooling would cause issues. The problem is that a sound node could get recycled for use with a different sound, and then you'll end up with unexpected results. By using an ID, if you try to play an ID that no longer exists, nothing will happen instead of playing a sound you didn't want.

[goldfire]

I've been revisiting my notes on the initial API choice from last summer (ouch, didn't realize it had been that long), and I may have come up with a way to use the cleaner API, while still allowing the current API to work, and adding in a few new benefits. I need to play around with the idea to see if it runs into any snags, but I'd still love to hear any thoughts on the API.

[gre]

Ok cool
Le 3 févr. 2015 18:39, "James Simpson" [email protected] a écrit :

I've been revisiting my notes on the initial API choice from last summer
(ouch, didn't realize it had been that long), and I may have come up with a
way to use the cleaner API, while still allowing the current API to work,
and adding in a few new benefits. I need to play around with the idea to
see if it runs into any snags, but I'd still love to hear any thoughts on
the API.

Reply to this email directly or view it on GitHub
https://github.com/goldfire/howler.js/issues/193#issuecomment-72696917.

[nyttimangus]

I just tried a basic sample of the beta in Windows 10's new Edge browser, and it seemed broken (as compared to performance in Chrome, Firefox, and IE). It sounded almost like the audio was being played on top of itself many many times.

[goldfire]

Just a quick update on where things are at. I've been in a fight for my startup's life since last fall, which is why the development on 2.0 slowly tapered out. However, we've finally hit our stride the last few months, and we've started hiring more developers. This is finally starting to give me a little more free time!

There's quite a few issues and pull requests I need to get caught up on. My plan is to get caught up on all of that over the next few weeks and then finally get on to finalizing and merging 2.0.

[nhoizey]

Any news for a stable 2.0?

[goldfire]

@nhoizey Getting very close on closing out the rest of the remaining issues. Other than that, before merging into master I'm going to create some more comprehensive examples, create a migration guide and possibly setup a standalone website rather than just a blog post. I'm finally getting some more free time now, so this should all start to come together much more quickly than the rest (I'll post more updates here over the next few weeks).

[nhoizey]

@goldfire good to read from you again, and know that it will come together more quickly now! ;-)

[goldfire]

Just a quick update. Virtually all of the issues marked for 2.0 have now been closed (woohoo!). The process has now mostly shifted towards setting up some example/demo projects (tracked in https://github.com/goldfire/howler.js/issues/444). I'm also in the process of setting up a proper website for howlerjs.com rather than just pointing to the blog post. I'm going to also try and get the migration guide posted soon as well as some other various bits of cleanup and polish to the 2.0 branch.

[goldfire]

We are getting really close now! The new website and logo are nearing completion, would appreciate any feedback on both:

https://dribbble.com/shots/2770228-Howler-js-2-0-Website

[nhoizey]

Great design!

[goldfire]

The migration guide is now available here: https://github.com/goldfire/howler.js/blob/2.0/CHANGELOG.md. We are in the final stages now, so I'm going to go ahead and close this.