Merge lp://staging/~oberling/mixxx/feature_first-beat-in-bar into lp://staging/~mixxxdevelopers/mixxx/trunk

Hi Stephan,

Thank you very much for your branch.
From the coding side it looks good.
Except expression in mixxx/src/waveform/renderers/waveformrenderbeat.cpp line 110 should be combined with the expressions above.

Form the visual point of view IMHO the first beat bar is too highlighted (too red and bold). I would prefer an additional icon on the normal bars. I hope Jus, our design maintainer can also help out here.

While this is a good step to the final goal, I would not merge this branch yet because of the missing detection support.

Kind regards,
Daniel

Hi Daniel,

thanks a lot for the review and kind advices.

I made the first beat bar a little less thick and integrated my if-clause with the existing ones. As i'm no designer i just chose the colors that fitted the most for me - may Jus feel free to change them all :-) .

I just don't get what you mean by "missing detection support". The missing phase-sync from the cited bug report was already implemented before my branch. At least one can click on sync and when not in vinyl control mode it should sync the bpm as well as the phase to the nearest detected beat. However it does not sync to the first beat of a bar - that's right. Was that what you meant?

Kind regards,
Stephan

Hi Stephan,

thank you again. IMHO it looks fine now.

Please don’t kill me if the following paragraphs are totally rubbish :-) ...

I am not an expert in music theory but for a lot of my tracks it feels to me that the new downbeat makers are simply placed at the wrong position.

I have just read:
http://en.wikipedia.org/wiki/Beat_%28music%29
http://en.wikipedia.org/wiki/Bar_%28music%29

As far as I understand (please correct me) a downbeat marker should be placed at least at theme changes or when a chorus starts. Maybe there is an unwritten law that the first beat in a track is always a downbeat like assumed in your patch, but for some of the tracks in my collection this is true but not for the rest.

I cannot evaluate how useful you patch is in the current state. Is the four beat assumption true in general? Do we need a facility to correct the first beat in a bar and the number of beats per bar?

I hope we can answer these questions soon.

Kind regards,

Daniel

Hi Daniel,

sorry for that taking so long - lots of other stuff to do first.
I thought for some time about your suggestions:
I totally agree with you, that it would be nice to have the "first beat in a bar" adjustable. At the moment it's just the first ever stroke in the grid corresponding to the audio file (which doesn't have to be the first beat of the track - however it (at least for my tracks) is in 90% ;-) ).
The first beat in a bar in my understanding (and if i understood correctly also in your understanding) describes the downbeat (thats also the definition of Downbeat in the wikipedia article "Beat_(music)").

There are a few steps i could try to implement from that point:
* add a "first_downbeat" to the stored track informations
* store the first beat really on a beat (and not the first ever grid-element in the audio file) - that would be quiet hard to distinguish i guess (silent intros and stuff)
* bloat the beat detection to be really highly sophisticated and also detect bars, intros outtros, repeated parts and stuff - that would involve detecting where bars start and end and also a the writing of a PhD thesis :-D

All those changes would however that would (as far as i see) result in the need of a recreateion of the database and i don't know if that would raise my chances of getting this branch merged ;-) .
That's the main reason why i didn't do it that way in the first place.

As of the four beat assumption: this is adjustable but defaults to 4 (see the Constructors of the BeatGridIterator and BeatMapIterator) in the current state of development to give an idea.
When extending this idea we would have to think about storing this information as well in the Trackinformation.
And... in general (although i can not remember having seen that in other DJ Software) all the beat detection is voulnerable to time changes.

Kind regards,
Stephan

> Hi Stephan,
>
> thank you again. IMHO it looks fine now.
>
> Please don’t kill me if the following paragraphs are totally rubbish :-) ...
>
> I am not an expert in music theory but for a lot of my tracks it feels to me
> that the new downbeat makers are simply placed at the wrong position.
>
> I have just read:
> http://en.wikipedia.org/wiki/Beat_%28music%29
> http://en.wikipedia.org/wiki/Bar_%28music%29
>
> As far as I understand (please correct me) a downbeat marker should be placed
> at least at theme changes or when a chorus starts. Maybe there is an unwritten
> law that the first beat in a track is always a downbeat like assumed in your
> patch, but for some of the tracks in my collection this is true but not for
> the rest.
>
> I cannot evaluate how useful you patch is in the current state. Is the four
> beat assumption true in general? Do we need a facility to correct the first
> beat in a bar and the number of beats per bar?
>
> I hope we can answer these questions soon.
>
> Kind regards,
>
> Daniel

Hi Stephan,

first of all: I am sure your branch will get merged.

I personaly not like informaton that "might" be right. So the bars schould not be displayed by default if they are not valid. But you might introduce a waveform preference to enable them.

An other option is to introduce a new Cue point type "first bar". The database schma already supports different cue point types. lp:~smstewart91/mixxx/advanced_autodj makes use of it. I think it is common for many DJs to place the normal cue point at this place so you might deal with it.
We could probably adjust it by rightclick to the "Adjust Beatgrid" button.

The third option is to activate the bar detection which already lives in the mixxx source. mixxx/vamp-plugins/plugins/BarBeatTrack.cpp I dont know the current state but maybe Vittorio or RJ might help here.

Kind regards

Daniel