Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use native bindings #1

Open
xdissent opened this issue May 4, 2013 · 4 comments
Open

Use native bindings #1

xdissent opened this issue May 4, 2013 · 4 comments

Comments

@xdissent
Copy link

xdissent commented May 4, 2013

This is crazy, but I built the same thing yesterday: https://github.com/xdissent/node-echoprint-codegen

The cli wasn't working for me because I need to operate on raw pcm data from within node, so I wrote a C++ addon to interface with the codegen library directly. Can we merge our projects maybe?

@psirenny
Copy link
Owner

psirenny commented May 4, 2013

It would be great if we could merge our projects. I'm not familiar with node bindings. Is it possible to make the echoprint library optional during npm install? I think that would be necessary in order to make our projects compatible. Other than that, both seem to operate pretty similarly except for the way in which we pass parameters. The cli interface also does not require an index/offset and takes values in seconds rather than in samples.

My thinking is that if we merge we can use the echoprint library if a buffer is passed in and the cli if it's a string/filepath. The numSamples/offset or songOffset/index can be interpreted accordingly. Is that a reasonable approach?

On May 4, 2013, at 6:44 PM, Greg Thornton notifications@github.com wrote:

This is crazy, but I built the same thing yesterday: https://github.com/xdissent/node-echoprint-codegen

The cli wasn't working for me because I need to operate on raw pcm data from within node, so I wrote a C++ addon to interface with the codegen library directly. Can we merge our projects maybe?


Reply to this email directly or view it on GitHub.

@xdissent
Copy link
Author

xdissent commented May 6, 2013

Well the echoprint-codgen package itself is MIT licensed, so we can just throw it in a deps folder and have npm build it for us upon install, then link to it directly for the library version or use the relative path to the binary. That way users won't have to even worry about downloading it at all and we know both options will work. The filename versus buffer approach sounds totally reasonable to me - and converting between samples and time is a cinch because we know the predefined PCM parameters required by the library version. Let me try to whip something up tonight and I'll send a PR to get started!

@xdissent
Copy link
Author

Almost there. https://github.com/xdissent/node-echoprint-codegen/tree/hybrid It took a while to get node-gyp to do what I needed, but now I'm building both the lib and the binary from npm install. Now to hook it all together.

@xdissent
Copy link
Author

There ya go: https://github.com/xdissent/node-echoprint-codegen/tree/hybrid
It includes the echoprint library as a submodule and builds upon install. The echoprint-codegen binary lives inside the module so it doesn't have to be on your path either (but ffmpeg does). I clarified some of the start/duration stuff too a little and simplified the actual calls using optional arguments. Let me know what you think!

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

No branches or pull requests

2 participants