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
Make a standalone 'ampSpectrum' extractor? #85
Comments
Yes, that's absolutely a glaring design flaw that I missed. We should totally do this, and modify the main meyda class to use it rather than calculate the ampSpec inside the SPN callback each time. If you want to take this on, that'd be great. ✨ |
Oh, and while you're doing this, it'd be really great if you could look into the possibility of doing exactly the same thing with the complex spectrum? |
Alright, self-assigned this. Will do the same with complex spec, too 🚀 Hopefully this will be done in the next couple of days as I kind of need it for research anyways |
@hughrawlinson versioning-wise, should this end up in the next versioned release or shall we just leave it as a hotfix on the master branch? |
@jakubfiala I switched us to using semantic versioning in meyda so that we'll be able to push small hotfixes/patches to production when we incremement the patch version. When a PR (or a group of simultaneous PRs) get merged to master, I will increment the appropriate version number, be that major, minor or patch, and push to bower and npm. |
This issue is probably going to be solved in #86 Closing this now. |
Alright so having attempted to use our MFCC extractor as a standalone function in node, I realised that actually I cannot use any spectral features unless the FFT is calculated internally by the Meyda object. We may say this is by design, but in order for the "standalone" extractors to work, we need the ability to calculate the amplitude spectrum without having to run an SPN/audioworker. Otherwise the simplicity of using Meyda in node is compromised by the fact that I first have to FFT my data with a non-meyda method, and then run the extractor on it.
This would be an easy thing to add, and I'll assign this issue to myself if approved. The only ugly part is that the proposed extractor is then basically a wrapper for Nick Jones' jsfft, but whatever.
The text was updated successfully, but these errors were encountered: