(In reply to comment #4) > Is this the imprecise/precies option ? If so, then I'm talking about different > algorithsm, such as the Rayshooter, Autcorellator, FFT measurer etc. This is > also related to bug 785 > ok, i'm unable to do this one.
Is this the imprecise/precies option ? If so, then I'm talking about different algorithsm, such as the Rayshooter, Autcorellator, FFT measurer etc. This is also related to bug 785
(In reply to comment #2) > Hello, > We should also add an option that allows the > user to choose which algorithm is used to perform the analysis. this is already in there. see libbpm-example. you specify to the init() method which algorithm to use.
Hello, Now that most things are finally in the bugtracker, I can start answering things. I believe that your suggestion is a good one. > float libbpm_getBpmFromBuffer(stereo_sample2 *userAudioBuffer, unsigned4 > userSampleRate, int userInputRate); > float libbpm_getBpmFromFile(char *fileLocation); > is that acceptable to you? Of course that is a good plan. We should also add an option that allows the user to choose which algorithm is used to perform the analysis. The userSampleRate is an option that might be nice in the future but converting the algorithm to work with any samplerate is not as easy as it appears. I will generate a new bug for the samplerate issue.
(In reply to comment #0) > > What I meant with fixed buffer size is that your demo program now shows > > how to measure the tempo of a .wav file, we are in general interested in > > measuring the tempo of pieces of information that are already in memory. > > So the question then is whether we work with fixed length buffers or > > not. This functionality is a critical part of the library it is not an > > option or something like that. The essence of a library is to provide a > > clear defined functionality that is as reusable as possible. Passing a > > .wav file into the library is nice, but not the goal of the library. > > there are two methods in the api, one for working with wav file, and one that > takes a buffer. both are important in my opinion. > > > float libbpm_getBpmFromBuffer(stereo_sample2 *userAudioBuffer, unsigned4 > userSampleRate, int userInputRate); > > float libbpm_getBpmFromFile(char *fileLocation); > > is that acceptable to you? > again, i don't get what the bug is. what do you want me to do?
> What I meant with fixed buffer size is that your demo program now shows > how to measure the tempo of a .wav file, we are in general interested in > measuring the tempo of pieces of information that are already in memory. > So the question then is whether we work with fixed length buffers or > not. This functionality is a critical part of the library it is not an > option or something like that. The essence of a library is to provide a > clear defined functionality that is as reusable as possible. Passing a > .wav file into the library is nice, but not the goal of the library. there are two methods in the api, one for working with wav file, and one that takes a buffer. both are important in my opinion. float libbpm_getBpmFromBuffer(stereo_sample2 *userAudioBuffer, unsigned4 userSampleRate, int userInputRate); float libbpm_getBpmFromFile(char *fileLocation); is that acceptable to you?