I've been looking for one too, how about I match your bounty and make
it $200 to make it interesting ;)
--
Dav Glass
davg...@gmail.com
blog.davglass.com
+ Windows: n. - The most successful computer virus, ever. +
+ A computer without a Microsoft operating system is like a dog
without bricks tied to its head +
+ A Microsoft Certified Systems Engineer is to computing what a
McDonalds Certified Food Specialist is to fine cuisine +
> --
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en.
>
To post to this group, send email to nod...@googlegroups.com.
A million apologies.
Yeah, I'll chip in. My pledge...
- $50 for Marak's original request (total bounty at $300)
- $100 for a Web Audio API library (total bounty at $100)
I have the initial work done with portaudio, I will be getting an initial version meeting these requirements and working towards more library support.
I'll sweeten Derek's Web Audio API pot by another $200 for the hell of it.
Speaking of -- another $200 to the first person that can deliver a working IndexedDB API with an MIT or BSD license.
Though he wanted something native, not just a command line utility binding.
--
Audio playback with anything greater then 18ms latency is pretty much unacceptable, even that is high.Now imagine you are playing 16 tracks at once, still all need to be < 18ms. :-\
Similar to ChucK is SuperCollider, which also has an OSC interface
that node can communicate with. Did some bindings the other day
https://github.com/stagas/node-supercollider nothing much yet but it's
a start. Right now we have it playing a few notes on a Synthdef but
you still need to load them in SC yourself before using them.
The problem with audio/music programming in JS is the lack of strong
timing. If you miss the beat even by a few ms it would sound
shuffling. Also, even if you get .play() working with very low
latency, playing ie the same sample a lot of times would introduce
unwanted flanger/chorus effects as they will all be executed just a
bit one after another.
The only solution I can think of is having the timer/beats living
outside JS and just use JS to define when and how you want them to
play ie bpm = 127; steps = new StepSequencer(bpm); steps.set([1, 2, 3,
4], 'kick.mp3'); steps.set([2, 4], 'snare.mp3'); steps.run(); // not
exactly but you get the point
-stagas
process.nextTick() and Date.now() should work well as the basis for precise timers
--Elijah
process.nextTick() and Date.now() should work well as the basis for precise timers
--Elijah
--
In music you need a process.stopEverythingElseAndDo() otherwise if
something blocks the event loop nextTick will be seriously off beat. I
mean it's ok to play with and experiment and it would be great to have
a .play() in node, but for any serious music application, you need
_perfect_ accuracy, not a 5ms shuffle. Our ears are extremely
sensitive to timing.
-stagas
No, we can't detect latency <10ms _perceivably_, but there are
psychoacoustic effects that live in that low range of 0-30ms, and we
can certainly detect those. So in reality, we do hear a 5ms latency
shuffle pretty well as the effect flanger. Research comb filter,
flanger and chorus.
Even if you never play the same sample at the same time more than
once, which is something really common in sequencing, when enhancing
envelopes of samples like snares, the effect is still there which
makes it unacceptable for any serious application.
It works in js land like you would expect. My main issue right now is timing, reliability. Audio has to be fast.
It works in js land like you would expect. My main issue right now is timing, reliability. Audio has to be fast.
I will post the library tonight. The timing issue wasn't really an issue. I can't say my stuff will be perfect, but at least it is a foundation that can be built on and improved.
Would someone be so kind as to make a test for me that checks latency.
One of the big guns joining the fight. Can't wait to see...listen to it.
I've enjoyed reading this thread, but can someone explain to me the use-case of this?Matt.
--
I didn't see any problems with it, I was hoping someone would tie it all up in a nice package. That was kinda my original request, to just bundle it into an npm package without any external deps.
I wanted to create a one liner installer, it seems with sfml you need to download a few things outside of the npm process?
SFML is painful to install but once you get it working its fine and integrates well with node. I semi-automated install on it, but there are a lot of build edge cases I don't have covered.
--
mmm doesnt play sounds... odd. anywho cant work on it til later.
ill try in 5
Looks like it works! nice!
I've sent you a pull request that updates the README to include mac installation instructions.
-- Elijah
Sometimes yeah, but in trying it out there wasn't any perceptible latency. Though I switched to their blocking style code since node is backgounding the code already.
There is an issue with playback of different sizes, to use the callback method, it has to sleep the main thread. If you sleep to long small files repeat, too short of sleep and long files get cut off. That's why I moved to the blocking style.
I'm open for suggestions. My c/c++ fu is weak atm.
--
Linus G Thiel
Hansson & Larsson
http://hanssonlarsson.se/
+46 709 89 03 85
Indeed that would rule out libvlc from the list.
Maybe an alternative would be ffmpeg bindings? http://www.ffmpeg.org/
Best regards,
Jeroen Janssen