Forums » Code » Howler.js plugin for Impact

This plugin let you simply use an howler.js library in Impact.
Howler.js is a modern web audio javascript library!
Example of usage:

var sound = new Howl({
  urls: ['sound.mp3', 'sound.ogg']
}).play();

var sound = new Howl({
  urls: ['sound.mp3', 'sound.ogg', 'sound.wav'],
  autoplay: true,
  loop: true,
  volume: 0.5,
  onend: function() {
    alert('Finished!');
  }
});

Thanks for your work, but with all due respect, your plugin should
1) require the Howl library as an external file and
2) inject ig.Sound so it works seamlessly with Impact, especially with its loader.
When injecting, you can add the new functions that Howl provides.

This Howl seems interesting, handling sound sprites is nice, but what advantages has it over current Impact sound, or over SoundManager 2 ? I'd be interested to know if you have a clue.

Quote from vincentpiel
your plugin should require the Howl library as an external file

I have noticed many people doing plugins this way. For example, the official Box2D plugin wraps the Box2DWeb library inside a module in exactly the same way. Why do you recommend doing it differently?

Editted for grammar and typos.

Quote from Joncom
I have noticed many people doing plugins this way. For example, the official Box2D plugin wraps the Box2DWeb library inside a module in exactly the same way. Why do you recommend doing it differently?

Editted for grammar and typos.

One reason is to keep the code separate between the Howler (Or anything else) API from the Impact stuff. The plugin should act as a bridge to the external library connecting Impact to an external lib, passing and receiving data as needed:
Impact <-> External LIB Plugin <-> External Lib

If the external library receives an update (Bug fixes, etc), you can just pop the new version into your project and it will work all the same, without any changes needed to your plugin. If the external library receives a major release, affecting core functionality, most likely your plugin won't be very large and you can quickly make the changes.

Whereas if you wrap an external library as an impact module, you have to manage a larger codebase and implement any changes to external libraries yourself.

Quote from lTyl
One reason is to keep the code separate between the Howler (Or anything else) API from the Impact stuff.

I suppose the biggest drawback is that if you don't wrap the library within a module, you cannot take advantage Impact's preloading. Your point is a good one though.