Merge lp:~mixxxcontributors/mixxx/features_vamp into lp:~mixxxdevelopers/mixxx/trunk

Proposed by RAFFI TEA
Status: Merged
Merged at revision: 3014
Proposed branch: lp:~mixxxcontributors/mixxx/features_vamp
Merge into: lp:~mixxxdevelopers/mixxx/trunk
Diff against target: 0 lines
To merge this branch: bzr merge lp:~mixxxcontributors/mixxx/features_vamp
Reviewer Review Type Date Requested Status
RJ Skerry-Ryan Approve
RAFFI TEA Needs Fixing
Phillip Whelan Needs Fixing
Review via email: mp+58803@code.launchpad.net

Description of the change

Notes from Tobias

A branch from Vittorio that brings the heavily requested beat detection. Although it might not be ready yet, I propose it for a potential merge. The branch is quite impressive. The beats markers align to the beats quite well, which is especially true for electronic tracks.

We probably won't have any licensing issue as stated on http://www.vamp-plugins.org/develop.html.

"The entire VAPM-SDK is published under a very permissive BSD-style license. You are encouraged to copy from it wholesale, whether developing open-source or proprietary plugin or host software. "

The plugins, however, are mostly pure GPLed. There exist two beat tracking plugins for vamp: (1) Paul Brossier's (aubio) beat tracking algorithm; (2) Queen Mary plugin set algortihms for beat tracking, key detection, etc.

I recommend to contact the Queen Mary, University of London. They seem to be quite open for relicesing stuff as stated in the README of the 'Queen Mary plugin set'. A relicesing allows us to ship beat detection through the Mac App Store.

"If you wish to use these plugins in a proprietary application or
product for which the terms of the GPL are not appropriate, please
contact the Centre for Digital Music at Queen Mary, University of
London for further licensing terms."

To post a comment you must log in.
Revision history for this message
Vittorio Colao (l0rdt) wrote :

Actually Queen Mary plugins had been relicensed under GPL. This will bring beat tracking as well as chord detection.
Moreover, I had been able to rewrite both Mixxx bpm and ReplayGain detection as vamp plugins. Such code has not yet been merged.

Revision history for this message
Phillip Whelan (pwhelan) wrote :

Just off the top of my head: needs to use BeatMatrix or BeatGrid. Plain and simple.

review: Needs Fixing
Revision history for this message
Phillip Whelan (pwhelan) wrote :

> Just off the top of my head: needs to use BeatMatrix or BeatGrid. Plain and
> simple.

It does use BeatMatrix, my bad.

Revision history for this message
RAFFI TEA (raffitea) wrote :

> Actually Queen Mary plugins had been relicensed under GPL. This will bring
> beat tracking as well as chord detection.
> Moreover, I had been able to rewrite both Mixxx bpm and ReplayGain detection
> as vamp plugins. Such code has not yet been merged.

Right. But we cannot ship GPLed plugins through the Mac App Store.
Users might download the *.dll, *.so or *.dylib files after the installation.

This is why vinyl control is not included in the Mac App Store as far as I know.

So why not asking the Queen Mary University of London, if we can distribute Mixxx including the plugin over the Mac App Store?

Revision history for this message
RAFFI TEA (raffitea) wrote :

If you compile the branch without 'Vamp=1' compiling fails.
Please Add some "__VAMP__" define statements in your code.

review: Needs Fixing
2698. By Vittorio Colao

* Now compiles when "Vamp=1" is not selected from scons;
* First attempt to create a minimal set of Vamp plugins (libmixxxminimal);
* libmixxxminimal is built when mixxx is compiled with "Vamp=1". Though such library is not automatically moved to the right directory.
* Both Mixxx legacy bpm detector and replaygain had been ported to vamp plugins (this will allow us to select analysers on-the-fly in the future);
* Allow BeatMatrix to be built from a well-ordered QVector (this should increase speed);
* Other minor fixes.

2699. By Vittorio Colao

* Fixed libmixxxminimal compilation so that libmixxxminimal:mixxxbeatdetection does not crash.

2700. By Vittorio Colao

forgot to delete a qDebug

2701. By Vittorio Colao

Merge from trunk

2702. By Vittorio Colao

* Renamed some classes and files.
* Added preliminary beat analyser configuration dialog.
* Removed key analyser.
* Allow selecting beat plugins on-the-fly.
* Fixed mixxbpmdetection and replaygain vamp plugin.

2703. By Vittorio Colao

Merge from trunk

Revision history for this message
Vittorio Colao (l0rdt) wrote :

> If you compile the branch without 'Vamp=1' compiling fails.
> Please Add some "__VAMP__" define statements in your code.

That had been fixed. Thanks!
With the last commit, I think this feature is near to be usable.
For me, it remains to:

* get/set plugin parameters (options),
* write a better preferences widget,
* do not rescan tracks when... (beat tracking plugin is the same? beatsVersion == "BeatMatrix-1.0"? user based?),
* install libmixxxminimal on scons install.

I am doing my best, but I am still learning. This means that probably I did some mistake elsewhere.
Please let me know if there is something to be changed/added.
Thanks again!

2704. By Vittorio Colao

* Added again accidentally deleted SConscript
* Changes in VampAnalyser class to grep plugin key from config
* configuration dialog mockup

Revision history for this message
RAFFI TEA (raffitea) wrote :

Hi Vittorio,

I did some work to get your branch compiled on Windows
Path: http://www-home.htwg-konstanz.de/~rafreide/windows.path

However, Mixxx crashes when loading a track onto a deck.

Debug: [Main]: Displaying mixxx
Debug: [Main]: Running Mixxx
Debug: [Main]: New BeatGrid
Debug: [Main]: Successfully deserialized BeatGrid
Fatal: [AnalyserQueue 1]: ASSERT failure in QList<T>::at: "index out of range",
file c:\qt\4.7.1\include\qtcore\../../src/corelib/tools/qlist.h, line 456
Warning: [AnalyserQueue 1]: QObject::killTimer: timers cannot be stopped from an
other thread
Warning: [AnalyserQueue 1]: QObject::killTimers: timers cannot be stopped from a
nother thread

review: Needs Fixing
2705. By Vittorio Colao

Added RAFFI TEA patch to fix compilation on Windows

2706. By Vittorio Colao

* Added an if statement to check for malformed pluginid
* Fixed tabs in SConscript

Revision history for this message
Vittorio Colao (l0rdt) wrote :

Hi Tobias,

Thanks for the patch!
As for the failure, I added an if statement where I think it happens.
Unfortunately, I have no Windows machine where to check it.
May you send me the two lines in [VAMP] section from your mixxx.cfg?
they should read as:

AnalyserBeatPluginID qm-tempotracker:0
AnalyserBeatLibrary /Path/to/libmixxxminimal

2707. By Vittorio Colao

Added some qDebug to see if/where AnalyserBeats may fail.

2708. By Vittorio Colao

*Removed unnecessary qDebug
*Allow custom step size for better precision

2709. By Vittorio Colao

*Removed unnecessary qDebug
*Allow custom step size for better precision

Revision history for this message
RAFFI TEA (raffitea) wrote :

Hi Vittorio,

the ASSERT failure in QList<T> has gone.

However, the beats do not show up aligned because of a malformed pluginid.

Debug: [AnalyserQueue 1]: VampAnalyser: got malformed pluginid: ""

I've manually modified the config file, but it still does not work. Mixxx looks for libmixxxminimal.dll, but there is only a vamp-aubio.dll within the Mixxx folder. The folder <MixxxDir>/plugins/Vamp is empty after Scons has finished. But I found a file called mixxxminimal.dll in #win32_build/vamp-plugins which I moved to <MixxxDir>/plugins/Vamp.

=== DEBUG INFO=================================================
AnalyserBeatLibrary D:/Tobias/MixxxBuilds/features_vamp/mixxx/dist32/plugins/Vamp/libmixxxminimal.dll

AnalyserBeatPluginID qm-tempotracker:0

Debug: [Main]: Successfully deserialized BeatGrid
Debug: [AnalyserQueue 1]: Beat calculation started
Vamp::HostExt::PluginLoader: No library found in Vamp path for plugin "libmixxxm
inimal:qm-tempotracker"
Debug: [AnalyserQueue 1]: VampAnalyser: Cannot load Vamp Plug-in.
Debug: [AnalyserQueue 1]: Please copy libmixxxminimal.so from build dir to one o
f the following:
Debug: [AnalyserQueue 1]: "C:\Program Files (x86)\Vamp Plugins"
Debug: [AnalyserQueue 1]: "D:/Tobias/MixxxBuilds/features_vamp/mixxx/dist32/plug
ins/Vamp"

Revision history for this message
Vittorio Colao (l0rdt) wrote :

Hi Tobias,

the fact that mixxxminimal.dll is not moved from #win32_build/vamp-plugins to the right folder is somehow expected. That is due to the fact that I did not write any scons rule to move it in the right place.

If you did copy it to D:/Tobias/MixxxBuilds/features_vamp/mixxx/dist32/plug
ins/Vamp ,it should be detected by Vamp.
Instead of manually changing AnalyserBeatLibrary, may you go through Preferences->Beats Detection and see if qm-tempotracker:0 is shown in the combobox?
There you should be able to select few plugins (qm-tempotracker, qm-barbeattracker or mixxxbpmdetection) or all plugins in vamp paths by clicking on Advanced. That will let vamp to detect the right path and name for the library.

Revision history for this message
RAFFI TEA (raffitea) wrote :

There are no combobox entries although I moved the file to D:/Tobias/MixxxBuilds/features_vamp/mixxx/dist32/plugins/Vamp. I also renamed the file to 'libmixxxminimal.dll' but still no effect.

Revision history for this message
RAFFI TEA (raffitea) wrote :

Problem solved...

Attached you find another patch for windows.

http://www-home.htwg-konstanz.de/~rafreide/windows2.path

Please not does libmixxxminimal.dll is still not moved to <MixxxDir>/plugins/Vamp

Revision history for this message
Vittorio Colao (l0rdt) wrote :

uhmmm... I think I do really need to find a windows machine :p
just one thing, I see that vamp is looking for two paths:
"C:\Program Files (x86)\Vamp Plugins"
"D:/Tobias/MixxxBuilds/features_vamp/mixxx/dist32/plugins/Vamp"
While the first one is a well-formed windows path, the second one is in unix style.
May you try to copy libmixxxminimal.dll into C:\Program Files (x86)\Vamp Plugins too?

Revision history for this message
RAFFI TEA (raffitea) wrote :

The main problem was in PluginHostAdapter.cpp where slash and backslash was mixed in DEFAULT_VAMP_PATH.

The seconds problem was that the function 'vampGetPluginDescriptor()' was not exported to the DLL.

This is all fixed now :-)

BTW: The comboboxes have content now :-)

Revision history for this message
Vittorio Colao (l0rdt) wrote :

My bad! I was sure I fixed the first one. Maybe I reverted it somehow.
I will apply your patch and push it to lp later! :-)
thanks again!

p.s. : are tracks properly analysed?

Revision history for this message
RAFFI TEA (raffitea) wrote :

The beatmarkers look very good. But have you ever tried to sync various tracks with different BPMs?
The computed BPM value from the beatgrid is not correct. Using "sync" button + some pitch bending let drift the beats away frequently.

Revision history for this message
Vittorio Colao (l0rdt) wrote :

Yes, I saw. I think that there is a wrong factor two in some place, since it syncs by aligning it at exactly half way between two beats.
I'll take a look at it.

Revision history for this message
Vittorio Colao (l0rdt) wrote :

Ok. here I got it.
I think that the behaviour consists on the fact that sync aligns by mean of bpm calculated on the full track, while beattracking has "local" bpm which varies many times.
In fact, if you try to use mixxxbpmdetection (that is exactly legacy bpm detector through soundtouch), tracks align perfectly.
For me, the point is that engine/bpmcontrol.cpp deals with bpm and file_bpm, while for aligning beats at least locally it needs to deal with getBpmRange method from Beats ( if I understood the code ).

2710. By Vittorio Colao

* Added RAFFI TEA second patch to fix vamp under Windows.
* Modified engine/bpmcontrol.cpp to deal with non-constant-through-track bpm.

Revision history for this message
Vittorio Colao (l0rdt) wrote :

Hey Tobias, now sync should behave better.
It is an ugly fix, but works.

Revision history for this message
RAFFI TEA (raffitea) wrote :

> Ok. here I got it.
> I think that the behaviour consists on the fact that sync aligns by mean of
> bpm calculated on the full track, while beattracking has "local" bpm which
> varies many times.

Assuming that most modern dance music has a 4/4 signature the distances between the beat markers are almost equal. Based on that I expect an accurate computation of the global BPM.

I'll test your patch with some electronic music soon. Just facing some compile errors on OS X :-)
Stay tuned for another patch file :-)

2711. By Vittorio Colao

* Added RAFFI TEA's third patch. Fixed on OS X
* Fixed rate change in bpmcontrol.cpp

Revision history for this message
RAFFI TEA (raffitea) wrote :

Hey Vittorio,

I really like playing with your branch :-)

I'm not the low-level audio expert and I don't know why the BPM is displayed wrong but I have found some interesting information:

The method BeatMatrix::getBpm() seems to be wrong, There's also a comment within the method stating that. Thanks to you I've played around with "Sonic Visualizer". You're right there are some local variations in the BPM values. For example in "D. Guetta - Sexy Bitch" the local BPM of a position is either 129.2 or 132.5. Building the average of all local BPMs seems to yield the "correct" BPM value as computed by Traktor under a perfect beat grid. Same is valid for all my electronic tracks.

* I used the "tempo and beat tracker: beats" plugin from QM University.

Revision history for this message
Vittorio Colao (l0rdt) wrote :

Hi Tobisas,

thanks for all the help!

About BeatMatrix::getBpm() :
Actually it is true that one should need the full lenght of the song to compute correct bpm. Anyway, this is not the case for tempo and beat tracker from QM. If you use them, the first beat coincides (more or less) with the first nonzero samples, while the last one is always at the end.
I did some test and found in any case that temptracker:0 calculated bpm (got from BeatMatrix->getBpm() ) is more or less the same from legacy mixxx bpm detection from soundtouch.
I know that this is not a proof, but at least it is a suggestion :)

About average of all local BPMs vs BeatMatrix::getBpm() :
In this case, I think their values coincides. "I have discovered a truly marvelous proof of this, which this margin is too narrow to contain" (cit. P. de Fermat) :p

About local/global BPM and sync:
I did some ugly change in bpmcontrol::slotControlBeatSync to let it work by mean of "local" BPM. That is by using BeatMatrix::getBpmRange. If "local" BPM varies too much, sync will be lost in few beats.

Revision history for this message
RAFFI TEA (raffitea) wrote :
Download full text (3.2 KiB)

> Hi Tobisas,
>
> thanks for all the help!
>
> About BeatMatrix::getBpm() :
> Actually it is true that one should need the full lenght of the song to
> compute correct bpm. Anyway, this is not the case for tempo and beat tracker
> from QM. If you use them, the first beat coincides (more or less) with the
> first nonzero samples, while the last one is always at the end.
> I did some test and found in any case that temptracker:0 calculated bpm (got
> from BeatMatrix->getBpm() ) is more or less the same from legacy mixxx bpm
> detection from soundtouch.

Your findings are more or less right. But this would not be an improvement to Mixxx's BPM detection.
Using the faulty BeatMatrix->getBpm() along with QM plugin, Mixxx's BPM detection is often wrong up to +-3 BPM in may case. I have counted the beats manually and all my values coincide with Traktor (+-0.2 BPM)
Although QM does not need the full length of a song, it's impressive to see that the average of all local BPMs seems to yield the correct BPM for 95% of my songs.

With a correct BPM, I would be able to burn "emergency CDs" for DJing with correct BPM values on it. This might be quite useful for persons who are lazy in beat matching but also for beginners. An incorrect BPM of +-3 is too large and error-prone when it comes to harmonic mixing (assuming key lock off).

> I know that this is not a proof, but at least it is a suggestion :)
>
> About average of all local BPMs vs BeatMatrix::getBpm() :
> In this case, I think their values coincides. "I have discovered a truly
> marvelous proof of this, which this margin is too narrow to contain" (cit. P.
> de Fermat) :p

I'm not sure what you mean by the citation. But I think, the average is good way to go for at least one reasons: If I count the beats manually, I measure the time to count one or two bars (4 or 8 beats). It is very likely that there are some very small local BPM variations during the measure. The manual computation of the BPM (240.0/<time in seconds for one bar>) takes into account the variations. So why not compute the average BPM?

> About local/global BPM and sync:
> I did some ugly change in bpmcontrol::slotControlBeatSync to let it work by
> mean of "local" BPM. That is by using BeatMatrix::getBpmRange. If "local" BPM
> varies too much, sync will be lost in few beats.

Technically, I can't verify your hack nor can I understand it. I hope that RJ or Madjester can have a look at your changes. But I'm not a fan of this hack. I'm sure the hack becomes redundant with the average BPMs.

Just for the moment and for testing. Could you create a separate branch based on this one and implement my proposal to use the average local BPMs. This is just for testing and to see if sync will really syncs (once the beat grids have been aligned initially).

One more thing: The BPM preferences look complex know, i.e., the advanced features. Unless RJ or some other dev overrules me, I think it is better to keep the dialogue simple.

I don't want to criticize your work. As I said previously, I like and appreciate your work very much. This is all just about to find out what's going on. :-) And I have much interest to see your work in 1.11. I h...

Read more...

Revision history for this message
Vittorio Colao (l0rdt) wrote :

Hi Tobias,

I really appreciate! Thanks a lot!
I am sure that with your help, this one will be a great feature for 1.11 :-)

> I'm not sure what you mean by the citation. But I think, the average is good
> way to go for at least one reasons: If I count the beats manually, I measure
> the time to count one or two bars (4 or 8 beats). It is very likely that there
> are some very small local BPM variations during the measure. The manual
> computation of the BPM (240.0/<time in seconds for one bar>) takes into
> account the variations. So why not compute the average BPM?

I thought a bit about the computation you did and I agree with you.
Basically, we can do two things in my opinion.
The first one is based on QM-tempotracker.
According to the documentation, such plugin can output local BPM each time it changes.
We may take each value, get the mean and pass as track BPM.

The second one is by following the manual computation you did.
If I understood, you are taking BPM=60/H as track bpm, where H is the harmonic mean of the distance between two beats in seconds.
That is BPM=60/(N*(1/s_1 + 1/s_2 + ... + 1/s_N)) , where s_k represents the distance of the k-th beat from the next one.
Then we get that s_k = (beatpos_{k+1} - beatpos_k) / samplerate , where beatpos_k is the position of the k-th beat in samples and hence:
BPM = (60 * samplerate)/(N*(1/(beatpos_2 - beatpos_1) + 1/(beatpos_3 - beatpos_2) +...+ (beatpos_N - beatpos_{N-1}) .
 This value can be calculated directly from m_beatList. So that it should work for any beat-tracking plugin.
Did I get it?
In case, I do prefer this second way.

> Technically, I can't verify your hack nor can I understand it. I hope that RJ
> or Madjester can have a look at your changes. But I'm not a fan of this hack.
> I'm sure the hack becomes redundant with the average BPMs.
>
> Just for the moment and for testing. Could you create a separate branch based
> on this one and implement my proposal to use the average local BPMs. This is
> just for testing and to see if sync will really syncs (once the beat grids
> have been aligned initially).

Mine was just an attempt to see if that works. I'll revert changes and see what happens if we try a better BPM estimation.

> One more thing: The BPM preferences look complex know, i.e., the advanced
> features. Unless RJ or some other dev overrules me, I think it is better to
> keep the dialogue simple.

I agree with you. The idea was to just give a rough way to switch plugins on-the-fly
and then to write a better configuration dialog, when all will be fixed.

Thanks again,

Vittorio

Revision history for this message
RAFFI TEA (raffitea) wrote :

> The second one is by following the manual computation you did.
> If I understood, you are taking BPM=60/H as track bpm, where H is the harmonic
> mean of the distance between two beats in seconds.
> That is BPM=60/(N*(1/s_1 + 1/s_2 + ... + 1/s_N)) , where s_k represents the
> distance of the k-th beat from the next one.
> Then we get that s_k = (beatpos_{k+1} - beatpos_k) / samplerate , where
> beatpos_k is the position of the k-th beat in samples and hence:
> BPM = (60 * samplerate)/(N*(1/(beatpos_2 - beatpos_1) + 1/(beatpos_3 -
> beatpos_2) +...+ (beatpos_N - beatpos_{N-1}) .
> This value can be calculated directly from m_beatList. So that it should work
> for any beat-tracking plugin.
> Did I get it?

You got it :-)
I did not know that we can reuse the information from the beat grid.

> In case, I do prefer this second way.

Your proposed solution is better. It lets people decide if they want to use QM or Aubio.

This brings me to another idea:

At the moment, Vamp analyses the complete track, right.
For slow computers it would be great to have an option such that only the first, lets say 20 seconds, are analysed. Is that possible? This method should work for most 4/4 dance music.

2712. By Vittorio Colao

Merge from trunk

2713. By Vittorio Colao

* Reverted changes in bpmcontrol.cpp
* Tried a different calculation for BeatMatrix::getBpm

Revision history for this message
Vittorio Colao (l0rdt) wrote :

> Your proposed solution is better. It lets people decide if they want to use QM
> or Aubio.

Did it and pushed to lp some minutes ago. Let me know if bpm calculation is more precise, now.
Anyway it seems it does not solve sync issues if "local" bpm varies too much.

> This brings me to another idea:
>
> At the moment, Vamp analyses the complete track, right.
> For slow computers it would be great to have an option such that only the
> first, lets say 20 seconds, are analysed. Is that possible? This method should
> work for most 4/4 dance music.

I agree with you as I was already thinking on say an "hybrid" Vamp plugin.
Such hybrid plugin should:

1) Calculate BPM via soundtouch, since it is faster than beat detection
2) Calculate beats only for N seconds around the center of the track (to avoid intros and outros)
3) translate beats position according to point 2

Writing it as a vamp plugin has the advantage of being totally independent from Mixxx code.
Plugins can be implemented at any time (even after release, though such "hybrid" thingy should go into this branch).
Moreover, track analysis can be performed differently without having to recompile Mixxx itself.

I do not know if such hybrid plugin would work as expected. I hope so and I will start building it once this branch is stable enough.
What is your opinion?
Do you think it is better to prioritize it?

P.S. Forgive me for that P. De Fermat quote. It is a silly joke about the fact that Fermat wrote these words in 1637, pretending to easily solve a problem. Such problem was solved only in 2009.
It became a common way between we mathematicians to say "I found an easy proof, which is probably broken".

Revision history for this message
RAFFI TEA (raffitea) wrote :

I am getting a crash on Windows for all my tracks.

=====================================================================
Debug: [Main]: Running Mixxx
Debug: [Main]: Successfully deserialized BeatMatrix
Debug: [AnalyserQueue 1]: Beat calculation started
Debug: [AnalyserQueue 1]: Vampanalyser BlockSize: 1024
Debug: [AnalyserQueue 1]: Vampanalyser StepSize: 512
Note: nonZeroCount was 31963, is now 31460
Warning: [AnalyserQueue 1]: Object::disconnect: No such signal TrackInfoObject::
updated() in src\trackinfoobject.cpp:356
Debug: [Main]: Deleting QObject instance.

Unfortunately I can't provide a backtrace on Windows

Revision history for this message
Vittorio Colao (l0rdt) wrote :

eheheh!
good job, Vittorio!

Just to be sure, may you comment tio->setBpm(pBeats->getBpm()) at line 67 in analyserbeat.cpp and see what happens?

Revision history for this message
RAFFI TEA (raffitea) wrote :

this will not crash but the BPM value does not update then.

Revision history for this message
RAFFI TEA (raffitea) wrote :

hmmm just reviewed your BPM computation a second time. There might be some errors:

> The second one is by following the manual computation you did.
> If I understood, you are taking BPM=60/H as track bpm, where H is the harmonic
> mean of the distance between two beats in seconds.

Correct, this is valid if you measure the time between two subsequent beats.

For a beat grid of size N the BPM will be computed as follows:

BPM = N * SUM(60/H)
BPM = 60 * N * SUM (1/H) //hence a 4 beat count yield 240/<second to count for 4 beats>

You will start at beat number 2 to compute the time difference between beat 1 and 2 and so in.

=========================
double sum = 0;
FOR i=2 TO N STEP 1
  sum += 1/H
END FOR
sum = sum *60 *N

Revision history for this message
Vittorio Colao (l0rdt) wrote :

Hi Tobias,
I am sorry, but I cannot get the point.

> For a beat grid of size N the BPM will be computed as follows:
>
> BPM = N * SUM(60/H)
> BPM = 60 * N * SUM (1/H) //hence a 4 beat count yield 240/<second to count
> for 4 beats>
>
> You will start at beat number 2 to compute the time difference between beat 1
> and 2 and so in.
>
> =========================
> double sum = 0;
> FOR i=2 TO N STEP 1
> sum += 1/H
> END FOR
> sum = sum *60 *N

starting from 1 and computing the difference between beat 2 and beat 1, means that in general
I am computing the difference between beat k and beat k-1.
You are right that this means:

======

double sum = 0;
FOR i=2 TO N STEP 1
  double H = beat[i] - beat[i-1]
  sum += 1/H
END FOR
sum = sum *60 *N

======

but it is exactly as computing:

=======
double sum = 0;
FOR i=1 TO N-1 STEP 1
  double H = beat[i+1] - beat[i]
  sum += 1/H
END FOR
sum = sum *60 *N
=======

Another thing is that to get out the mean,I think it should be divided by N-1 and not multiplied by N.

On the other hand, it is strange but I cannot reproduce that crash on linux, even by getting it from lp and recompiling it.
By confronting the two methods, I am getting differences in BPM between +-0.1 and +-3

2714. By Vittorio Colao

Added Tobias bpm calculation patch

2715. By Raffitea

Merging with trunk; Use BeatGrid rather than BeatMatrix for beat markers; Reverted BeatGrid and BeatMarix. Added 'calculateBpm()' to AnalyserBeats to 'correct' the Vamp results.

2716. By Raffitea

Improved BPM detection again: The values differ +-0.05 beats compared to Traktor, however, the deviation is enough to let the beatmarkers look slightly unaligned after 3 minuted or more of playing time.

2717. By Raffitea

No [Vamp] section in config on OS X. TODO: Tell scons to bundle Mixxx the right way.

2718. By Raffitea

scons bundle will now include the the Vamp plugin

2719. By Raffitea

Simplified #define statements in PluginHostAdapter.cpp

2720. By Raffitea

Added a huge comment about BPM detection from Vamp

2721. By Raffitea

some minor changes for debug puposes

2722. By raffitea

Fixed compilation issues on Ubuntu 1.10 which were not present before. Vamp works on Linux now

2723. By raffitea

scons install will install libmixxxminimal to /usr/local/lib/mixxx/vamp on Ubuntu 11.10

2724. By raffitea

Merging from trunk
- Renamed analysergain.* to analysergainvamp.* + class definition
  (This was necessary because analysergain.h and analyserrg.h have had
  same class definion, however, these definitions have been diverted due to
  bug fixes. To make Mixxx compile renaming was necessary.)

2725. By raffitea

- changed a debug statement to be more clear
- get rid off a #define block

2726. By RaffiTea <>

Modified scons script to copy libmixxxminimal.dll to the right place
Update plugin host adapter class for windows

2727. By RaffiTea <>

Made Vamp ready to go for Windows
- Removed SoundTouch Library in plugin
- Removed mathstuff.cpp as dependency from TempoTracker.cpp
- Scons will install libmixxxminimal.dll to dist32/plugins

Warning: You'll need to put the msvcr90.dll in dist32/plugins
Starting Mixxx will show an error. Simply ignore that error.

TODO: libmixxxminimal.dll depends on msvcr90.dll.
How can remove that dependency? Any help appreciated.
(Using /MT as compile option does not help)

2728. By Raffitea

Merging from trunk; Fixed some compile errors for Linux and OSX

2729. By Raffitea

Hopfully fixed VAMP plugin initialization on Windows again

2730. By RaffiTea <>

Fixed Vamp on Windows finally.
You must put MSVCRT.dll to Mixxx folder.

2731. By Raffitea

Beat tracking does now work if the total number of samples has been estimated incorrectly. Vittorio please review this code change as I am new to audio processing.

2732. By Raffitea

Fixed a typo

2733. By Raffitea

An experimential algorithm to get a perfect beat grid

2734. By Raffitea

Beat detection is now aware of BPM ranges as defined in settings.

2735. By Raffitea

Added some rounding which has improved the beat grid and BPM. Almost perfect now.

Revision history for this message
RAFFI TEA (raffitea) wrote :

Hey all,

I've worked quite hard on to ingegrate Vamp in Mixxx.
More precisely, I've studied and imporved the original Vamp beat grid. It was
found out that the beatgrid is not limited to 4/4 signatures, however, this
leads to error-prone beat grids in many cases. Almost 3/4 of my tracks
had an inaccurate beat grid after applying the unmodified Vamp algorithm.

Fortunately, beat tracking is quite promising now. My attempts to "correct" Vamp has been successfull. I've assumed a 4/4 signature and applied some statistical methods. Now for about 80% of my tracks, I get a perfect beatgrid. The remaining 20% have a beat grid that looks aligned over let's say 2 minutes. This is because, the the BPM has been detected wrongly, however, in most cases the deviation to the correct BPM is at most +-0.05 BPM units.

I've also added some rounding heuristics, e.g., a BPM of 127.97, 127.98 and 127.99 BPM will become 128.0 and so on. The rounding leads to better beat grids in general. Again recall that
a deviation of 0.02 and higher is too large to get an aligned beat grid for club mixes with 6 minutes or more of playing time.

The branch compiles on Linux, OS X and Windows. On OS X, you can also bundle Mixxx along with the plugin. Packaging for Windows and Linux will need some work.

Over the nex time, Vittorio and I plan some refactoring. But the branch is feature complete at the moment. Vittorio and I are curious about feedback from you.

Tobias

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Hey guys, excellent work here!

A couple of questions before I get down to reviewing this:

* Have any changes been made to lib/vamp or is the source code identical to the VAMP release you have included? For Linux, we will need to depend on the system-installed libvamp-sdk2 package instead of using what's in lib/

* I'm seeing some huge diffs against seemingly unrelated parts of mixxx, e.g. the res/midi and files like plugins/build/osx_m4a_installer.pmdoc/index.xml. It looks like the changes are mostly reformatting. Was this intentional?

* Is FFTW a new dependency? I see it in the configure step. Is that a dependency of VAMP or just a dependency of a VAMP plugin?

2736. By Raffitea

Fixed computation of statistical median. Wonder how I got those great results previously. Increased BPM detection quality.

2737. By RJ Skerry-Ryan

Fix build with vamp=0. Rename 'Vamp' parameter 'vamp' to match all other scons parameters.

2738. By RJ Skerry-Ryan

Revert all changes to res/ and plugins/ as I think these were made by mistake. Also delete now-unused lib/soundtouch-1.5.0 directory (probably a merge conflict)

2739. By RJ Skerry-Ryan

Fix all VAMP code to use an external VAMP hostsdk and plugin SDK instead of the one in lib/. Hopefully fix plugin loading so that it works without hacking up the host-sdk. Delete lib/vamp.

2740. By RJ Skerry-Ryan

Add vamp-plugin-sdk to all Debian control files as a build-depends requirement.

Revision history for this message
jus (jus) wrote :

Trying to compile the branch r2740 on MacOS 10.6.8 with "scons vamp=1" and hitting en error: "ERROR:root:Unmet dependency: Did not find libvamp-hostsdk.a or the libvamp-hostsdk development header files - exiting!"

I successfully compiled vamp-plugin-sdk-v2.2.1 from source (it is not in macports) but where do you guys put "libvamp-hostsdk.a, libvamp-hostsdk.dylib, libvamp-sdk.a, libvamp-sdk.dylib"? Cant find anything in the vamp docs.

Thanks.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Was there no "install" target for their build system?

On Linux those end up in /usr/lib/ and the necessary header files end up in
/usr/include.

On Mon, Nov 21, 2011 at 3:40 AM, jus <email address hidden> wrote:

> Trying to compile the branch r2740 on MacOS 10.6.8 with "scons vamp=1" and
> hitting en error: "ERROR:root:Unmet dependency: Did not find
> libvamp-hostsdk.a or the libvamp-hostsdk development header files -
> exiting!"
>
> I successfully compiled vamp-plugin-sdk-v2.2.1 from source (it is not in
> macports) but where do you guys put "libvamp-hostsdk.a,
> libvamp-hostsdk.dylib, libvamp-sdk.a, libvamp-sdk.dylib"? Cant find
> anything in the vamp docs.
>
> Thanks.
> --
>
> https://code.launchpad.net/~mixxxcontributors/mixxx/features_vamp/+merge/58803
> Your team Mixxx Development Team is subscribed to branch lp:mixxx.
>

2741. By Vittorio Colao

* libmain.cpp: replaygain plugin works again,
* analyserbeats.*: use BeatMatrix instead of BeatGrid and allow to bypass Tobias code,
* beatfactory.*, beatmatrix.* : quick fixes for vamp beattracking,
*vampanalyser.cpp: fixed BlockSize and StepSize

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Vittorio -- RE: r2741, BeatMatrix uses frames internally because in the future all of Mixxx will use frames internally after various parts get rewritten. To make this smoother, all new code should use frames internally. Could you change it back?

2742. By Vittorio Colao

* Using frame offsets instead of sample offsets elsewhere,
* beattools.* , analyserbeats.* : moved Tobias statistical bpm computation into a class to use it in beatmatrix too,
* beatmatrix.cpp : reverted to frame offsets, fixed and commented BeatMatrix::findBeats.

2743. By Vittorio Colao

* Merge from lp:mixxx

2744. By Vittorio Colao

instruct the linker to export only the required symbol (According to Vamp documentation). raffitea: May you check it on windows?

2745. By Vittorio Colao

* analyserbeat.cpp, beattools.* : Added a method to calculate the best offset

2746. By Vittorio Colao

* bpmcontrol.cpp: Disabling some lines Vamp beattracking does not produce false beats (I hope!). On the other hand, those lines produced a weird behaviour when syncing two tracks.

* analyserbeat.cpp : Typos fixed.

* beattools.*: Typos fixed. Reworked offset detection.

2747. By Vittorio Colao

beatmatrix.cpp: Fix a compilation error whith vamp=0

2748. By Vittorio Colao

* Reverting beatmatrix.*
* beatmap.* : Introducing a new beatspointer implementation

2749. By Vittorio Colao

* Merge from lp:mixxx

2750. By Vittorio Colao

* Reintroduced a preference entry for vamp

2751. By Vittorio Colao

merge from lp:mixxx

2752. By Vittorio Colao

beatmap.* : fixes
beatmap.*, beatfactory.*, analyserbeat.* : store and recall the algorithm we used to build beats

2753. By Vittorio Colao

beatmap.* : fixes
beatmap.*, beatfactory.*, analyserbeat.* : store and recall the algorithm we used to build beats

2754. By Vittorio Colao

Reverting again beatmatrix.

2755. By Vittorio Colao

Adding again beatmatrix.*

2756. By Raffitea

Merging from trunk

2757. By Vittorio Colao

beatmap.cpp : fixes
analyserbeat.* : calculate bpm only when necessary

2758. By Raffitea

Added code infrastrcture for bpm lock.

2759. By Raffitea

Implemeneted BPM lokcing as checkbox in library.

2760. By Raffitea

Hide BPM_plugin_key column from library

2761. By Raffitea

Added BPM lock column for all remaining native library features.

2762. By Raffitea

Added a debug statement in analyserbeats to see if TIO::hasBpmlock() works.

2763. By RaffiTea <>

Fixed compilation on Windows

2764. By RaffiTea <>

Fixed all Windows issues with Vamp.
- libmixxxminimal must be placed directly in dist32 folder
- config entry 'AnalyserBeatLibrary' must not contain the absolute path -->'libmixxxminimal' is enough
- TODO: Delete config and make sure QM is working from the beginning.

2765. By RaffiTea <>

Removed an redundant #ifdef block.

2766. By Vittorio Colao

* using beatlock and BpmPluginKey in analyserbeat.* and beatmap.*

2767. By Vittorio Colao

Fixed compile error with vamp=0

2768. By Vittorio Colao

*beattools.cpp: Fix for tracks with less than 8 beats

2769. By Vittorio Colao

*beattools.cpp: return a valid bpm value for tracks with less than 8 beats

2770. By Vittorio Colao

*analyserbeat.cpp: fix offset detection when track has only one beat detected

2771. By Vittorio Colao

Merge with lp:mixxx

2772. By Vittorio Colao

* trackcollection.cpp: forgot to update requiredSchemaVersion

2773. By Raffitea

Merging from trunk

2774. By Raffitea

do not use tio->getSamplerate() in Analyser

2775. By Raffitea

- Frequency of shifted beats are reduced especially if a track starts with silence
- Added findFirstCorrectBeat() to BeatTools
  (does not necessarily return the first raw beat)

2776. By Raffitea

Tweaked some parameters which have improved the BPM accurancy for 'problem songs'.

2777. By Raffitea

Added a thread-safe wrapper class for PluginLoader

2778. By Raffitea

Merging from trunk

Revision history for this message
RAFFI TEA (raffitea) wrote :

Hey developers,

please review this branch again, so Vittorio and I can address final problems.

Thanks,

2779. By Raffitea

- Vamp will only analyse the first 10min of a track by default
  (a track longer than 10min may be a recorded mix).
- Added "Enable Fast Analysis" to BPM option dialog.
  If enabled, Vamp will analyse the first minute of a track.
  This may affect the quality of the BPM analysis, but it
  helps on slow computers.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Hey Tobias -- I've been reviewing the branch again for the past few days. I'll have some comments to share soon.

2780. By RJ Skerry-Ryan

Add test suite for BeatMap (currently failing)

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :
Download full text (5.7 KiB)

Hi guys,

I'm going to split my comments into two pieces -- the first is a user experience review of the branch. The second will be a code review.

A user of Mixxx 1.11 may be in a variety of states:
1) New user with no BPM analysis at all.
2) New user, some files already analyzed by external programs like RapidEvolution.
3) User of Mixxx with many files annotated with SoundTouch or manually tapped/entered BPMs and/or manually-chosen offsets in the Mixxx Library. Some of their files may even have BPM analyzed by external programs like RapidEvolution.

Here is how I think we should handle users in these states:

* Any SoundTouch BPM should just be thrown out and re-calculated as if it weren't there.

* A BPM that originated from a music-metadata tag (i.e. from Rapid Evolution or maybe manually entered) should be respected by default -- but the first-beat offset should be automatically detected using QM.

* Any manually entered BPMs and offsets in Mixxx should be respected by default and not overwritten to prevent us from destroying a user's hard-work in hand-detecting the BPMs of their tracks. This means keeping the BPM implementation as a BeatGrid and not a BeatMap on all tracks with pre-existing beatgrids until the user manually requests the track be analyzed via the Analyze view.

The current implementation of the VAMP branch over-writes the current beat data for a track when it calculates a BeatMap/QM-analysis. Also, we can't tell the difference between a SoundTouch generated BPM and a manually entered BPM from Mixxx 1.10 and before. This means that to satisfy the requirements I set out above, we can't over-write any pre-existing BPM by default. If no offset exists or the offset is 0 then I would be fine with auto-detecting the offset.

This means that some users will not get the benefit of the new beat analyzer without manual action. This is too bad but necessary. We can't afford to anger a user by overwriting all of their data.

To facilitate this:

* Disable AnalyserBeats beat detection if a previous BeatGrid is present.

* A preference option that says something like "Overwrite existing track beat data with VAMP-plugin beat data." defaulting to unchecked/off.

* On upgrade to a 1.11 database we present a welcome screen either similar the new promo-tracks welcome message or maybe a popup box that asks the user if they want to over-write all BPMs with new, much more accurate beat data. This will make sure that new 1.11 users will be unlikely to miss the opportunity to get great new beats detected for their tracks.

============================

The following is a laundry list of various usability issues I ran into by just playing with the VAMP branch for a while:

* We need a preference option that says "re-detect beats in tracks if my settings change". Right now if I change my preferences, there is no way to force a track's beats to be re-calculated.

* BPM Lock -- doesn't affect anything other than AnalyserBeats. Needs to prevent Mixxx from ever editing that BPM -- such as track information dialog, editing in library view, and tapping via BPM tap widgets both near the deck and in the track information dialog.

* BPM lock being it...

Read more...

review: Needs Fixing
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Hey guys,

I've got some questions about the VAMP plugins side of the project:

* What should I name my plugin? From the code, it looks like only plugins named "qm-tempotracker:0", "beatroot:0", "marsyas_ibt:0", and "aubiotemp:0" will show up in the preferences.

* What input/output arguments does the plugin have to implement?

* How can the plugin expose its own configuration options to the rest of Mixxx via preferences?

* If I do end up getting my plugin loaded and select it in the preferences -- does Mixxx re-calculate the beats of tracks that have already been analyzed?

* What if I only put a beat tracking plugin in my VAMP plugin. Does this mean Mixxx will lose the ability to calculate replay-gain because there is no replaygain plugin in my plugin-library?

Thanks,
RJ

Revision history for this message
Vittorio Colao (l0rdt) wrote :

Hey RJ,
I can give you only partial answers, as I am travelling at the moment.
Please find them below.

> Hey guys,
>
> I've got some questions about the VAMP plugins side of the project:
>
> * What should I name my plugin? From the code, it looks like only plugins
> named "qm-tempotracker:0", "beatroot:0", "marsyas_ibt:0", and "aubiotemp:0"
> will show up in the preferences.

Actually, those names had been hardcoded as they are all the beat-tracking plugins for vamp.
Beside that, vamp analysis will work with any plugin which follows the lines I am describing below.

> * What input/output arguments does the plugin have to implement?

Mixx can work with any plugin which respects VAMP SDK (see [1]), provided that its InputDomain is TimeDomain ,since Vamp FFT algorithm appears not to be thread-safe.

Moreover,

for a beattracking plugin, a Feature f (see [2]) for each detected beat is expected, such that

f.hasTimestamp = true;
f.timestamp = time elapsed from the beginning of the track ( in RealTime )

Please have a look at /mixxx/vamp-plugins/plugins/MixxxBpmDetection.*
for a short example (it implements "legacy" mixxx bpm detection through soundtouch).

> * How can the plugin expose its own configuration options to the rest of Mixxx
> via preferences?

Not implemented. Do we need it?

> * If I do end up getting my plugin loaded and select it in the preferences --
> does Mixxx re-calculate the beats of tracks that have already been analyzed?

If the track is bpm locked, no. Otherwise it will recalculate the beats.

> * What if I only put a beat tracking plugin in my VAMP plugin. Does this mean
> Mixxx will lose the ability to calculate replay-gain because there is no
> replaygain plugin in my plugin-library?

If the default plugin is deleted, Mixxx will lose replaygain.
Please note that multiple plugins can be used at the same time.

Thanks,
Vittorio

[1] https://code.soundsoftware.ac.uk/embedded/vamp-plugin-sdk/classVamp_1_1Plugin.html
[2] https://code.soundsoftware.ac.uk/embedded/vamp-plugin-sdk/structVamp_1_1Plugin_1_1Feature.html

2781. By Raffitea

- Merging from trunk
- Show progress in waveform overview when anylyzers are in progress.

2782. By Raffitea

Disable BPM related controls when BPM lock is active (dlgTrackInfo.cpp)

2783. By Raffitea

Code clean up in BeatMatrix and other classes

2784. By Raffitea

Added tooltip descriptions in preferences

2785. By Raffitea

Compiling with vamp=1 will remove the former BPM preference pane.

2786. By Raffitea

Reworked Analyzer Dialog

2787. By Raffitea

- Added TRACKMODELCAPS_BPMLOCK
- Added bulk bpm lock and unlock possibilites to context menu
  (playlist, crates and mixxx library)

2788. By Raffitea

- Don't reanalyze BPM if the BPM has been computed by
  Mixxx < 1.11 or 3rd party products (default behavior)
  (There's no way to distinguish between 3rd party BPM
   values and Mixxx computed onces. If the id3 bpm
   tag of a track exists, TrackDao::getTrackFromDB()
   will create a BeatGrid object, but Mixxx beat grid
   are BeatGrids in version < 1.11)
- Changed bpm preferences again.

2789. By Raffitea

Changed reset button label

2790. By Raffitea

BPM lock checkbox is now part of the BPM column. Made former BPM lock column an internal column.

Revision history for this message
RAFFI TEA (raffitea) wrote :
Download full text (7.8 KiB)

Hey RJ,

thanks for you detailed review. Most issues have been addressed.
See my comments below for more details...

> Hi guys,
>
> I'm going to split my comments into two pieces -- the first is a user
> experience review of the branch. The second will be a code review.
>
> A user of Mixxx 1.11 may be in a variety of states:
> 1) New user with no BPM analysis at all.
> 2) New user, some files already analyzed by external programs like
> RapidEvolution.
> 3) User of Mixxx with many files annotated with SoundTouch or manually
> tapped/entered BPMs and/or manually-chosen offsets in the Mixxx Library. Some
> of their files may even have BPM analyzed by external programs like
> RapidEvolution.
>
> Here is how I think we should handle users in these states:
>
> * Any SoundTouch BPM should just be thrown out and re-calculated as if it
> weren't there.
>
> * A BPM that originated from a music-metadata tag (i.e. from Rapid Evolution
> or maybe manually entered) should be respected by default -- but the first-
> beat offset should be automatically detected using QM.
>
> * Any manually entered BPMs and offsets in Mixxx should be respected by
> default and not overwritten to prevent us from destroying a user's hard-work
> in hand-detecting the BPMs of their tracks. This means keeping the BPM
> implementation as a BeatGrid and not a BeatMap on all tracks with pre-existing
> beatgrids until the user manually requests the track be analyzed via the
> Analyze view.
>
> The current implementation of the VAMP branch over-writes the current beat
> data for a track when it calculates a BeatMap/QM-analysis. Also, we can't tell
> the difference between a SoundTouch generated BPM and a manually entered BPM
> from Mixxx 1.10 and before. This means that to satisfy the requirements I set
> out above, we can't over-write any pre-existing BPM by default. If no offset
> exists or the offset is 0 then I would be fine with auto-detecting the offset.
>
> This means that some users will not get the benefit of the new beat analyzer
> without manual action. This is too bad but necessary. We can't afford to anger
> a user by overwriting all of their data.
>
> To facilitate this:
>
> * Disable AnalyserBeats beat detection if a previous BeatGrid is present.

DONE. However, there's no reliable way to distinguish between a BPM value originating
from Mixxx < 1.11 or a 3rd party detector. In Mixxx < 1.11 beats are always represented
as BeatGrid objects. If you load a track with BPM meta data the first time, Mixxx won't recalculate the BPM via SoundTouch, however, it creates a BeatGrid object from the value.

For Mixxx 1.11 this means: Before the Analyser starts a TIO with a BeatGrid has already been
constructed. In other words any track with some 3rd party BPM will have a BeatGrid object, see
TrackDao::getTrackfromDB().

>
> * A preference option that says something like "Overwrite existing track beat
> data with VAMP-plugin beat data." defaulting to unchecked/off.

DONE.

> * On upgrade to a 1.11 database we present a welcome screen either similar the
> new promo-tracks welcome message or maybe a popup box that asks the user if
> they want to over-write all BPMs with new...

Read more...

2791. By RJ Skerry-Ryan

Merging from lp:mixxx

2792. By RJ Skerry-Ryan

Tweak preferences strings a little bit. Still needs more wordsmithing.

2793. By RJ Skerry-Ryan

Fix indentation and code style issues here and there.

2794. By RJ Skerry-Ryan

More cleanups.

2795. By RJ Skerry-Ryan

Cleanups to src/vamp. Change VampPluginLoader to use a big static mutex instead of a member-variable mutex.

2796. By RJ Skerry-Ryan

Re-analyze tracks with 0 average BPM even if they have a beatgrid from previous versions of Mixxx.

2797. By RJ Skerry-Ryan

Rename BeatTools BeatUtils and move to src/track. Remove VAMP ifdefs because this is unrelated to VAMP.

2798. By RJ Skerry-Ryan

Move fixed tempo correction out of AnalyserBeats into BeatUtils

2799. By RJ Skerry-Ryan

Move fixed-tempo and offset-correction handling from AnalyserBeats to BeatFactory. Save work on re-calculating BPM in calculateOffset()

2800. By RJ Skerry-Ryan

Cleanup analysergainvamp.

2801. By RJ Skerry-Ryan

Remove disabling of half-speed syncing for VAMP since I think this is a valid way to sync tracks even with VAMP.

2802. By RJ Skerry-Ryan

Clean up the BPM-lock / library interaction a little bit.

2803. By RJ Skerry-Ryan

More misc cleanups.

2804. By Raffitea

Improved scratching for Vestax VCI-400

2805. By RJ Skerry-Ryan

Minor cleanups.

2806. By RJ Skerry-Ryan

Fix issue with BeatMap::findNthBeat (don't floor() dPosition anymore). All BeatMapTest tests pass now.

2807. By RJ Skerry-Ryan

Actually, we do want to avoid fractional frames.

2808. By RJ Skerry-Ryan

Trying to factor logic in BeatUtils out into tiny, bite-sized methods.

2809. By RJ Skerry-Ryan

Remove bpm_plugin_key since it should be stored in the beat object itself.

2810. By RJ Skerry-Ryan

When fixed-tempo correction is enabled, create a BeatGrid instead of a BeatMap

2811. By RJ Skerry-Ryan

Factor all version string manipulation out of AnalyserBeats. Make the check for whether the settings have changed solely depend on the version/subVersion strings.

2812. By RJ Skerry-Ryan

Factor out preference strings in src/track/beat_preferences.h. Rename a bunch of stuff and keep BPM preferences under the [BPM] block instead of [Vamp].

2813. By RJ Skerry-Ryan

Add fast-analysis as extra version info.

2814. By RJ Skerry-Ryan

Pull fast-analysis check out of VampAnalyser and into the individual analysers. Disable fast analysis for replaygain.

2815. By RJ Skerry-Ryan

Accidentally disabled analysis.

2816. By RJ Skerry-Ryan

Rename DlgPrefAnalysers to DlgPrefBeats

2817. By RJ Skerry-Ryan

Prepend 'Queen Mary' to the name of the QM beattracker.

2818. By RJ Skerry-Ryan

Switch ST detector to say SoundTouch instead of Mixxx and change credit to Olli.

2819. By RJ Skerry-Ryan

Fix beat length epsilon bug I introduced when moving calculateOffset to BeatUtils.

2820. By RJ Skerry-Ryan

Don't call setBpm if bpmlock is enabled.

2821. By RJ Skerry-Ryan

Delete BeatMatrix. Remove m_fBpm from TrackInfoObject and rely solely on the Beats class for getting average BPMs. This fixes issues where the TIO BPM and the Beats bpm could get out of sync.

2822. By RJ Skerry-Ryan

If a grid has an offset of 0 then even if the user prefers to not re-analyze tracks then we will analyze it to detect the offset.

2823. By RJ Skerry-Ryan

More unification of beats/bpm

2824. By RJ Skerry-Ryan

When user sets a BPM to 0 via track-table or track dialog, assume they intend to clear the beatgrid as well. Prevent invalid scales within BeatMap.

2825. By RJ Skerry-Ryan

Remove check for beatscorrection in dlgtrackinfo. Check for BEATSCAP_SET capability on beats before setting.

2826. By RJ Skerry-Ryan

Wordsmithing in dlgprefbeatsdlg.ui

2827. By RJ Skerry-Ryan

Some minor fixes.

2828. By RJ Skerry-Ryan

In BeatUtils::calculateBpm, use the filter-weighted-average instead of median-bpm when finding a first-correct-beat window.

2829. By RJ Skerry-Ryan

Remove bpmConfirm property from TIO since it hasn't been used in a long time.

2830. By RJ Skerry-Ryan

Update variable naming in BeatUtils::calculateBpm to make it more clear which value is which.

2831. By RJ Skerry-Ryan

Fix syntax error.

2832. By RJ Skerry-Ryan

Minor fixes in BeatUtils. Disable using calculateOffset. IN calculateBpm slide the N-beat local-bpm windows in increments of 1 instead of N. This should lead to more accurate BPM estimates.

2833. By RJ Skerry-Ryan

Sweep offset calculation window by 1 instead of N.

2834. By RJ Skerry-Ryan

Fix bug in min/max bpm saving.

2835. By RJ Skerry-Ryan

Cleanups to BeatUtils and re-enable min/max BPM constraining for BeatGrids.

2836. By RJ Skerry-Ryan

Save sub-version in the database and restore it when loading beats.

2837. By RJ Skerry-Ryan

Add vamp-2.3 to lib/ and optionally build it if the sdk or hostsdk are not present.

2838. By RJ Skerry-Ryan

Sort version fragments when building the sub-version.

2839. By RJ Skerry-Ryan

Minor lint.

2840. By RJ Skerry-Ryan

Add clear-beatgrid option to right-click in the library.

2841. By RJ Skerry-Ryan

Rewrite BeatGrid and BeatMap to serialize/deserialize using Google's protocol buffers. Bump BeatGrid from version 1.0 to 2.0 and migrate 1.0 beatgrids to 2.0.

2842. By RJ Skerry-Ryan

add libprotobuf-dev to build-depends.

2843. By RJ Skerry-Ryan

More wordsmithing in the beats preferences dialog.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Vittorio / Tobias

Great job on this branch! I'm very excited to get this in the hands of our users. I've been working on the branch for the past few weeks and here's a brief summary of the changes I made:

* I changed serialization/deserialization to use protocol buffers so that we will have fewer headaches in the future when extending the beat data format.

* I added vamp back into lib (sorry Vittorio for asking you to remove it!) I agree it simplifies things for people if it's just included.

* I moved all beat related tools into src/track/beatutils.cpp and factored everything I could out of AnalyserBeats.

* I changed fixed-tempo-assumption to create a BeatGrid instead of BeatMap. There's no sense making a list of beats when the grid is defined by the BPM and first-beat.

* I scaled back the offset-correction code (BeatUtils::calculateOffset) due to performance and quality concerns. I'm open to looking at turning it back on but it would often choose bad offsets on about 50% of my tracks. Maybe there is a bug?

* I disabled the logic for setting the BPM on a BeatMap that tried to insert or disable beats. For 1.11 non-fixed-tempo-assumption beatgrids (BeatMap) will be experimental and so we can improve this support later. For now changing the BPM merely scales the beats relative to the first beat by the ratio of the old to new BPM.

Those are the main things I changed but feel free to browse my commits to see everything.

I'm merging this into trunk now. Congratulations and thanks again! This will be a killer feature in 1.11.

There is still more work to be done but I think it can be improved over the course of the beta period for 1.11. Here is my list of TODOs:

* SoundTouch legacy support (for App-Store users if QM licensing issues are not resolved)
* BPM-above-range preference is not available in the new preferences dialog
* Allow rounding-when-within-0.05 to be optionally turned off.
* Sync doesn't currently work for BeatMaps. Phase is synced fine but the tempo-sync uses the global-bpm when it should only use a local-window BPM (because the global BPM may not be the current tempo).
* Once SoundTouch support is present, we can delete the old BPM preferences dialog and make VAMP required (remove ifdefs and all).

review: Approve
2844. By RJ Skerry-Ryan

Fix BeatGrid test.

Preview Diff

Empty