Closed virtuald closed 6 years ago
virtuald
commented
6 years ago Also, I believe you can write gstreamer plugins in rust (https://github.com/sdroege/gst-plugin-rs)? That would make ellington easy to integrate with existing solutions that use gstreamer (and perhaps address some of your dependency issues?).
AdamBrouwersHarries
commented
6 years ago My main goal for Ellington is, realistically, is a testbed or laboratory for improving the algorithms that are available for BPMing swing music. That being said, I would also like to make it useful, so any work to integrate it into more applications would be more than welcome!
At present, the library format is only there to make it easier for Ellington to stream information between stages of the program and allowing the user to inspect the progress. My background (and day job) is in compiler engineering, so the architecture is somewhat similar to a compiler: There's a front-end (ellington init), passes (ellington bpm), and finally a backend, where data is written out (ellington write). With that in mind, the ellington library is something akin to llvm ASM, but describing an abstract library rather than abstract machine code instructions. Continuing the comparison to compilers, Ellington presently only allows the user to run each stage separately (i.e. compiler, then optimiser, then linker), rather than the whole compilation pipeline.
I think it would be possible to provide "one-shot" tools as part of Ellington, but at present I don't think it's wise to change the library format, or separation of stages. As I started off by saying, I view Ellington as a "testbed" primarily, and a high quality tool as a secondary goal. Having a greater separation of stages gives me (and others who wish to contribute) the ability to build more tools based on Ellington (e.g. bellson) as well as more experimental code, which a tooling-first approach would make more difficult.
On a final note, I really don't want Ellington to rely on a specific audio application, or a audio plugin framework (no matter how abstract the framework). One of the pain points that Ellington aims to solve is the wide variety of low quality BPM plugins for various audio software packages. None of the plugins work together, very few of them are extensible or open source, and almost none of them work for multiple applications. Many of them have died due to plugin interfaces changing (e.g. plugins for iTunes). I'm happy for plugins to be built on top of Ellington, but I am of the opinion that keeping it as an independent piece of software is critical to keeping it alive and useful to the maximum number of people.
AdamBrouwersHarries
commented
6 years ago That said, I'd love to see if it would be possible to integrate ellington as a plugin, and I'd be happy to do some refactoring if you need it!
virtuald
commented
6 years ago Thanks for the clarification. I'll open a separate issue tracking what I want then. :)
It seems to me that (unless you have other goals) the primary usefulness of this tool would be as something used by a plugin to another audio player. In that context, I imagine that ellington maintaining it's own library would just get in the way and make it more difficult to integrate with an external audio player.
From that perspective, it seems that it would make sense to separate the processing pieces from the library pieces (note: haven't actually looked through the code yet) and have a separate executable that takes in an audio file and spits out some JSON to stdout with BPM data. This would make it trivial to integrate with an external audio player.
Background: I'm the primary maintainer of the Exaile audio player, which I use to DJ swing music. Currently I have an autodetect bpm plugin which uses the SoundTouch library (as a gstreamer plugin). I'd be willing to integrate ellington as an option if it really works as well as you say.