Hi, I love this project, it has become my main desktop music manager now.
But I miss the a BPM column reflecting the BPM tag of the audio files, it would be amazing to have it.
I will try to build the project from source and try to work it out, although I'm mainly java developer (my pet project is also an audio player http://github.com/octaviospain/musicott)
Any hints on where to start, coding guidelines will be appreciated.
Following up on this — the moodbar workaround is a fair suggestion, but I think it is worth distinguishing because moodbar and a real waveform actually solve different problems/features. The moodbar shows the spectral "mood" of a track as a colour gradient, which is fine for a vibe, but the colour bands do not reliably correspond to where the loud parts, drops, breaks, or quiet sections are. As a DJ I find myself wanting to see the actual amplitude shape of the track — the peaks and troughs over time — so I can spot a drop, a build-up or a breakdown by eye in a few hundred milliseconds. Mixxx and most DJ-oriented tools display this as a horizontal waveform strip with a playhead, and it is hard to go back to scrubbing without one.
What I would propose for Strawberry is a proper waveform visualization that lives in the analyzer area above the progress bar, alongside Block, Boom, Turbine and the others, as just another option in the right-click "Analyzer" menu. Selecting it would render the loudness contour of the entire current track as a horizontal waveform, with a playhead moving across it as the song plays. It would not replace the moodbar (moodbar can stay exactly where it is, painted into the slider groove), and it would not replace the live spectrum analyzers either.
It would just be one more option in that menu, for the users who want it.
I had a look at the code and the feature seems quite feasible without adding any new dependency. The moodbar pipeline already handles the hardest part: running a GStreamer pre-pass over a track on a worker thread and caching the result. A waveform pipeline would essentially be the same pattern, but storing peak/RMS values instead of FFT-derived colours. Other parts of the engine (Chromaprint, EBU R128 loudness analysis) already extract raw PCM from GStreamer in the exact way a waveform would need.
I am planning to open a GitHub issue to gauge the maintainers' interest. Would anyone else here find this useful? Especially curious whether other DJs, or people working with mixes and live recordings, would back this up.
Hi, I love this project, it has become my main desktop music manager now.
But I miss the a BPM column reflecting the BPM tag of the audio files, it would be amazing to have it.
I will try to build the project from source and try to work it out, although I'm mainly java developer (my pet project is also an audio player http://github.com/octaviospain/musicott)
Any hints on where to start, coding guidelines will be appreciated.