You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 9, 2019. It is now read-only.
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?
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?
The text was updated successfully, but these errors were encountered:
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 formodule.exports
.Checking for window should be a surefire way to determine if we're in a browser environment, right?
ex:
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?
The text was updated successfully, but these errors were encountered: