I'd like to make a few comments over the next couple of weeks which might be useful to the developers of GDAM. I would also like to contribute some code eventually, but at the moment I am honing my coding skills (and in C++ too to boot!), so I'd like to stick with interface design if I may.
I won't make any big suggestions right now, as I want to put together a proper document for you all to view. I also want to spend some more time getting to know GDAM before I go opening my big mouth.
I'd like to know if this is acceptable to everyone - particularly the developers!
Just as an aside, some may find some example 'code' at http://freespeech.on.openproject.net/ quite interesting. There's an RAD development there for visual programming related to a speech recognition project. The application is called vFlow, and the example in question is the find_beats.n file contained within the examples.tar.gz file. It is just a demo, but it does (at least to my inexperienced eyes) seem to go a significant way to being able to detect the beat throughout an mp3.
There's no useable code there (that is, no C), but it may be a good demonstration of how to implement an automated system, yes?
If there is some work being done on automatic beat detection, I would like to request that it be logged throughout each track, rather than being represented by just one value. We should be able to see a nice graph for each song we select which shows the beat rate over the playing time. More on this later though, when I present my own ideas for a mixing interface.
Thanks for reading all! I look forward to some interesting discussions in the very near future.
Best regards,
Paul Dorman.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, the link you posted has been dead
these past days, so i haven't had a chance to see
what the folks at http://freespeech.on.openproject.net/ have been
up to.
The other code you sent us, Pitchtrack, is now
on the links page at gdam.org, alongside the
beat detection code by eric shierer. Thanks,
we hadn't come across that package yet.
I'm guessing that the first support for automatic
beat detection in gdam will be as follows:
through plugins, sound data can be passed through
one of several external programs, and their output
will be converted into a beat description of the
song. This will be a feature of beat calculator,
and users would be able to examine the output
via the existing visual display and clicktrack
features. Depending how accurate the output of
the beat detection program was, the data might not
need to be perfected by hand.
If we found a sufficiently accurate algorithm,
(which operated on a playing stream rather
than a static chunk of sound) we'd then add
support for on-the-fly beat detection of unknown
songs.
Another consideration is that we need to finish
support for complicated beat descriptions. Right
now, as you know, beats are described by a single
bpm / firstbeat pair. All access to the beatinfo
is done through functions designed to return the
beatinfo which describes a specific time within
the song, but there is no support within the
opaque beatinfo structure for complicated
descriptions.
One type of complicated description would be
sets of [firstbeat, bpm, time1, time2]
to signify that between time1 and time2
bpm and firstbeat accurately describe the
beat. Some have suggested a description which
is merely a list of times at which beats occur,
and such a description could be supported.
However it is my feeling that a beat description
which doesn't reduce the song to segments of
locally constant tempo won't be very useful in
practice, so i tend to believe the first method
will be sufficient.
Again, thanks for the leads. Assisted/automatic
beatmatching could be a powerful feature. It'll
be interesting to see what sort of results we
can get.
-geoff
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi guys,
I'd like to make a few comments over the next couple of weeks which might be useful to the developers of GDAM. I would also like to contribute some code eventually, but at the moment I am honing my coding skills (and in C++ too to boot!), so I'd like to stick with interface design if I may.
I won't make any big suggestions right now, as I want to put together a proper document for you all to view. I also want to spend some more time getting to know GDAM before I go opening my big mouth.
I'd like to know if this is acceptable to everyone - particularly the developers!
Just as an aside, some may find some example 'code' at http://freespeech.on.openproject.net/ quite interesting. There's an RAD development there for visual programming related to a speech recognition project. The application is called vFlow, and the example in question is the find_beats.n file contained within the examples.tar.gz file. It is just a demo, but it does (at least to my inexperienced eyes) seem to go a significant way to being able to detect the beat throughout an mp3.
There's no useable code there (that is, no C), but it may be a good demonstration of how to implement an automated system, yes?
If there is some work being done on automatic beat detection, I would like to request that it be logged throughout each track, rather than being represented by just one value. We should be able to see a nice graph for each song we select which shows the beat rate over the playing time. More on this later though, when I present my own ideas for a mixing interface.
Thanks for reading all! I look forward to some interesting discussions in the very near future.
Best regards,
Paul Dorman.
Unfortunately, the link you posted has been dead
these past days, so i haven't had a chance to see
what the folks at http://freespeech.on.openproject.net/ have been
up to.
The other code you sent us, Pitchtrack, is now
on the links page at gdam.org, alongside the
beat detection code by eric shierer. Thanks,
we hadn't come across that package yet.
I'm guessing that the first support for automatic
beat detection in gdam will be as follows:
through plugins, sound data can be passed through
one of several external programs, and their output
will be converted into a beat description of the
song. This will be a feature of beat calculator,
and users would be able to examine the output
via the existing visual display and clicktrack
features. Depending how accurate the output of
the beat detection program was, the data might not
need to be perfected by hand.
If we found a sufficiently accurate algorithm,
(which operated on a playing stream rather
than a static chunk of sound) we'd then add
support for on-the-fly beat detection of unknown
songs.
Another consideration is that we need to finish
support for complicated beat descriptions. Right
now, as you know, beats are described by a single
bpm / firstbeat pair. All access to the beatinfo
is done through functions designed to return the
beatinfo which describes a specific time within
the song, but there is no support within the
opaque beatinfo structure for complicated
descriptions.
One type of complicated description would be
sets of [firstbeat, bpm, time1, time2]
to signify that between time1 and time2
bpm and firstbeat accurately describe the
beat. Some have suggested a description which
is merely a list of times at which beats occur,
and such a description could be supported.
However it is my feeling that a beat description
which doesn't reduce the song to segments of
locally constant tempo won't be very useful in
practice, so i tend to believe the first method
will be sufficient.
Again, thanks for the leads. Assisted/automatic
beatmatching could be a powerful feature. It'll
be interesting to see what sort of results we
can get.
-geoff