Mixxx

Code review comment for lp://staging/~oberling/mixxx/feature_first-beat-in-bar

feature_first-beat-in-bar
Merge into trunk

Revision history for this message

Stephan Bergemann (oberling) wrote on 2013-04-18:

#

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 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

Reply

« Back to merge proposal