5 ms·

I experimented with the MediaRecorder too but couldn't get anything to work. In the end, I used this: https://github.com/mattdiamond/Recorderjs https://github.c

I experimented with the MediaRecorder too but couldn't get anything to work. In the end, I used this: https://github.com/mattdiamond/Recorderjs https://github.com/mattdiamond/Recorderjs - It has been abandoned by the author and the forceDownload function does not work anymore so I had to replace that. I'll send you a copy of my version if you like?

vdnkh 10y ago
That would be great, here's my code: https://github.com/johnBartos/buffer-oscillator-node/blob/master/src/index.js https://github.com/johnBartos/buffer-oscillator-node/blob/ma... I wonder if instead of encoding as ogg/opus I could switch the string to WAV instead?
- errozero 10y ago
  Nice, I like the simplicity. Your download function is almost exactly the same as my modification to recorderJS, so you could just grab a copy of that and swap out the download function for your code.
catshirt 10y ago
slightly inefficient, but you can use a ScriptProcessorNode [1]. just copy the buffer right before it reaches your destination and encode it as WAV when you're done recording. (Audio Worker would be the ideal solution but i don't think they're implemented yet). something like this: http://pastebin.com/UP3F09Wn http://pastebin.com/UP3F09Wn [1] https://developer.mozilla.org/en-US/docs/Web/API/ScriptProcessorNode https://developer.mozilla.org/en-US/docs/Web/API/ScriptProce...
- vdnkh 10y ago
  I tried this but using ScriptProcessorNodes is a pain in practice because of how the events work: >An event, implementing the AudioProcessingEvent interface, is sent to the object each time the input buffer contains new data, and the event handler terminates when it has filled the output buffer with data. Events just fire like mad until you put stuff in the output buffer. Couldn't get it to work like I needed it to.
  - catshirt 10y ago
    i mean, of course events are going to fire like mad. welcome to the world of audio processing. :) MediaRecorder works the same way (but for MediaStreamSources, not BufferSources). the idea is that audio buffers are processed in chunks- an event fires for each chunk that is processed. the act of "recording" is just reassembling these chunks into a single ArrayBuffer. edit: seems like Recorderjs works exactly this way (but implements features more than just recording, like exporting as WAV). capturing the chunks: https://github.com/mattdiamond/Recorderjs/blob/master/src/recorder.js#L21-L30 https://github.com/mattdiamond/Recorderjs/blob/master/src/re... reassembling the chunks: https://github.com/mattdiamond/Recorderjs/blob/master/src/recorder.js#L97-L101 https://github.com/mattdiamond/Recorderjs/blob/master/src/re...
    - vdnkh 10y ago
      > if (!this.recording) return; This is the key I was missing in my implementation. Another challenge is wiring this up to multiple OscillatorNodes - the docs say a ScriptProcessorNode can only have one input. In my implementation I create a new OscillatorNode whenever you press a key.
      - errozero 10y ago
        In Acid Machine, I have created a kind of virtual 4 channel mixer, that is the only thing that connects directly to the main destination output. All osc nodes that are generated by an instrument get connected to the instruments master gain node, then that connects to one of the mixer channels. All mixer channels then connect to a master mixer gain, then the output. If you do it that way, you just need to attach the recorder to the master output of the mixer.
        catshirt 10y ago
        yep-- it's also decent practice to send your oscillators into a mixer anyway so that they can be rerouted at large. for instance, say you have 4 oscillators, 2 fx buses and an output. you route (4 oscillators) -> mixer -> fx bus 1 -> output. then if you want to switch the fx bus for your oscillators, you can just reroute the mixer instead of each oscillator individually. in the case of a recorder, you'd want the end of your entire graph to look like this: mixer -> recorder -> output. this way your recorder is capturing all audio (oscillators, effects, etc). (and, as noted above, you have the option to reroute the mixer directly to the output when it's not recording).

vdnkh 10y ago

That would be great, here's my code: https://github.com/johnBartos/buffer-oscillator-node/blob/master/src/index.js https://github.com/johnBartos/buffer-oscillator-node/blob/ma... I wonder if instead of encoding as ogg/opus I could switch the string to WAV instead?

errozero 10y ago
Nice, I like the simplicity. Your download function is almost exactly the same as my modification to recorderJS, so you could just grab a copy of that and swap out the download function for your code.

catshirt 10y ago

slightly inefficient, but you can use a ScriptProcessorNode [1]. just copy the buffer right before it reaches your destination and encode it as WAV when you're done recording. (Audio Worker would be the ideal solution but i don't think they're implemented yet). something like this: http://pastebin.com/UP3F09Wn http://pastebin.com/UP3F09Wn [1] https://developer.mozilla.org/en-US/docs/Web/API/ScriptProcessorNode https://developer.mozilla.org/en-US/docs/Web/API/ScriptProce...

vdnkh 10y ago
I tried this but using ScriptProcessorNodes is a pain in practice because of how the events work: >An event, implementing the AudioProcessingEvent interface, is sent to the object each time the input buffer contains new data, and the event handler terminates when it has filled the output buffer with data. Events just fire like mad until you put stuff in the output buffer. Couldn't get it to work like I needed it to.
- catshirt 10y ago
  i mean, of course events are going to fire like mad. welcome to the world of audio processing. :) MediaRecorder works the same way (but for MediaStreamSources, not BufferSources). the idea is that audio buffers are processed in chunks- an event fires for each chunk that is processed. the act of "recording" is just reassembling these chunks into a single ArrayBuffer. edit: seems like Recorderjs works exactly this way (but implements features more than just recording, like exporting as WAV). capturing the chunks: https://github.com/mattdiamond/Recorderjs/blob/master/src/recorder.js#L21-L30 https://github.com/mattdiamond/Recorderjs/blob/master/src/re... reassembling the chunks: https://github.com/mattdiamond/Recorderjs/blob/master/src/recorder.js#L97-L101 https://github.com/mattdiamond/Recorderjs/blob/master/src/re...
  - vdnkh 10y ago
    > if (!this.recording) return; This is the key I was missing in my implementation. Another challenge is wiring this up to multiple OscillatorNodes - the docs say a ScriptProcessorNode can only have one input. In my implementation I create a new OscillatorNode whenever you press a key.
    - errozero 10y ago
      In Acid Machine, I have created a kind of virtual 4 channel mixer, that is the only thing that connects directly to the main destination output. All osc nodes that are generated by an instrument get connected to the instruments master gain node, then that connects to one of the mixer channels. All mixer channels then connect to a master mixer gain, then the output. If you do it that way, you just need to attach the recorder to the master output of the mixer.
      - catshirt 10y ago
        yep-- it's also decent practice to send your oscillators into a mixer anyway so that they can be rerouted at large. for instance, say you have 4 oscillators, 2 fx buses and an output. you route (4 oscillators) -> mixer -> fx bus 1 -> output. then if you want to switch the fx bus for your oscillators, you can just reroute the mixer instead of each oscillator individually. in the case of a recorder, you'd want the end of your entire graph to look like this: mixer -> recorder -> output. this way your recorder is capturing all audio (oscillators, effects, etc). (and, as noted above, you have the option to reroute the mixer directly to the output when it's not recording).