Skip to content
This repository has been archived by the owner on Jun 9, 2019. It is now read-only.

Timbre Environment Priority #19

Closed
jbielick opened this issue May 28, 2014 · 2 comments
Closed

Timbre Environment Priority #19

jbielick opened this issue May 28, 2014 · 2 comments

Comments

@jbielick
Copy link

Hi,

I've been using Timbre for a couple months now in an effort to develop an entirely javascript beetmachine / sequencer modeled after the Native Instruments: Maschine line. The app is here — it's mostly built out to support sequencing, multi-pattern and multi-group samples (effects like reverb, chorus, eq used to work through the UI, but I recently broke :[ ) and eventually I'd like to build a sampling feature to be able to cut the uploaded (drag and drop onto a pad) samples into pieces and save separately.

I've been loving timbre so far. It's phenomenal how much effort and consideration appears to have gone into it.

I had one recent issue, though. Which is extremely simple. I had been using timbre in a require.js environment, loading modules through the browser with require, but recently switched to browserify, which bundles all code into one nice minified file while using a node-like require() syntax to "load" module dependencies into a module's scope. (CommonJS pattern).

When using browserify, it defines module, exports and require so that they're used within the bundled application javascript. This tricks Timbre into believing it's in the Node environment and as such, T.envtype will equal "node".

I'm just monkey-patching it in my local file by reversing the ternary conditions to check for window before checking for module.exports.

Checking for window should be a surefire way to determine if we're in a browser environment, right?

ex:

var _envtype = (typeof window !== "undefined") ? "browser" :
        (typeof module !== "undefined" && module.exports) ? "node" : "unknown";

Doing so, however, causes a second issue here

Because browserify is expecting timbre to export itself through module.exports, but in the browser env it is only attaching to the window. I think a safer bet would be to attach to module exports if its defined at all. That way you cover all bases. Basically if module && module.exports, attach to it—regardless of attaching to the window global.

Does that make sense?

@mohayonao
Copy link
Owner

thanks!

@jbielick
Copy link
Author

jbielick commented Jun 1, 2014

Thank you thank you thank you. So fast, too!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants