Interested in getting some buffer -> typedarray, typedarray -> buffer functions?

[sebpiq]

Hi!

I have a bunch of utilities that I have been using here and there for decoding PCM buffers to a Float32Array, and vice-versa. I was planning to release them as a lib, but you seem to have been doing some cool job here, so are you interested in getting them contributed to node-pcm-utils instead?

[xdissent]

Yes, in fact I've got to do a bit more work on this project this week. Pull request away or file issues if you have questions or suggestions. Thanks!

[sebpiq]

In fact I have are 4 functions / objects, with tests, if you want to get them in, I can can make a pull request

• BufferDecoder : Takes a PCM buffer, returns the corresponding array of channels as Float32Arrays, values in [-1, 1]
• BufferEncoder : the opposite operation
• StreamDecoder : Convenience object that wraps a stream, and provides a method nextBlock(done), which reads a block from the stream, and returns the data decoded with BufferDecoder
• StreamEncoder : the opposite operation

[sebpiq]

Just one thing though ... for me a library in coffee script is a no-no. So - and sorry of being an ass - but if it stays in coffeescript I don't really want to contribute.

But this being said, I really need a library for handling boilerplate stuff with PCM data, and I'm working on this those days, so it would be great to join efforts on this. I am useless with C and C++, but I can do JavaScript quite OK (you can check my projects on github).

Tell me what you think :)

[xdissent]

I think you're being an ass! =)

No but seriously, the coffee is compiled to JS before release and the vast majority of the actual code is native C++ anyway, so I don't consider CoffeeScript a trade-off at all. Can I ask why you think it's a no-no?

Either way, thanks for your interest in the first place. I'd love your contribution but I understand if you Just Plain Hate CoffeeScript too.

[sebpiq]

I think you're being an ass! =)

Haha ... yeah ... sorry about that :)

As TJ Holloway puts it, in the "manifesto" for components (http://tjholowaychuk.com/post/27984551477/components) talking about coffeescript, less, ... :

"These are all great tools and can increase productivity in your application, my opinion is that they do not belong in public components, they fragment the community and reduce contributions"

So that's exactly my thought. Every time I want to read the source code of a library and I stumble upon CoffeeScript I have shivers, and I just drop the thing, and google for another library. And I know for a fact many people do the same. Because CoffeeScript is reeaaally a matter of taste (I hate it, I think it is very hard to read).

On the other hand JavaScript is not a matter of taste, you just have to deal with it because eventually that's what node will run. So as a language, it is the "common denominator" for people wanting to contribute.

There's a bunch of -not really well maintained- audio libraries for Node, and I'd like to have better quality libs for audio on Node. So anyways, I'm not gonna roll off my own library, as I prefer collaborating and joining efforts with others. On the other hand ... I really don't want to rewrite my code in CoffeeScript, and I don't want to write CoffeeScript! So that's kind of a dilemma...

[xdissent]

The manifesto is IRT client-side components and I agree with him on that point, mostly. But that was a year ago and client side dependency/component managers have grown up a lot since then (sourcemaps, auto compile, etc) so it's probably even less relevant now. The problem he's trying to address is the difficulty of wedging compile tools between the source and the browser consistently. With node, there's no browser and the only compile/dep tool is npm, and it's gone to great lengths to give you consistent compilation steps and tools so you don't have to worry about that crap.

Maintenance-wise, I find coffee script MUCH more productive. Given that npm install should hand you a perfectly workable coffee environment with no special knowledge required, the fragmentation argument is reduced to a matter of taste. And good lord I'd have quit programming long ago if I wasn't willing to temporarily submit to the imho insane quirks of taste exhibited by other developers.

And there's nothing that would prevent JS and coffee coexisting in the same project of course. But also, if it is JS (or even coffeescript) then we'll probably be pulling the vast majority of the logic out to C++ to take advantage of the event loop anyway.

But it's up to you! No pressure.

[sebpiq]

I'm not worried about building/installing the lib. The quotation talks about the problem of making contribution out-of-reach (or making the threshold for contribution higher than with plain JS) for many people in the community. I interpret it as a more general comment than just in the context of components.

In the context of writing an open-source library, I think the "community" argument is more important than the "productivity" argument. I really think CoffeeScript sets-off a lot of people. So those people will be even less likely to contribute. JS on the other hand is neutral as it is a prerequisite to CoffeeScript.

Then again, I suppose it's not such a big deal since moving from CoffeeScript to JavaScript (if one day it is needed : ) is just one compilation step away...

So I'll make a pull request, and I'll be actively contributing ... on one condition!!! No code examples in CoffeeScript! Because that's really evil ... if there's some files in CoffeeScript alright, but it stays in the guts of the library.