PATCH: add kick-vs-snare visualisation

Bug #823354 reported by danstowell
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Mixxx
Won't Fix
Wishlist
danstowell
1.11
Won't Fix
Wishlist
danstowell

Bug Description

It's useful to show the different audio timbres as different colours in the waveform view, so you can tell the difference between kick and snare (etc) when you're cueing up.

I've added a feature to mixxx to visualise the different timbres by tweaking the brightness of the colour on the waveform - see screenshot here: http://flic.kr/p/absqfa

It uses a very efficient audio analysis (zero-crossing rate) so that it doesn't slow the system down, and takes the colours from the main colour scheme / skin.

Patch attached (diff against r2840) - if you like it, please do commit it.

Revision history for this message
danstowell (danstowell) wrote :
Revision history for this message
Eduardo Beattie (eduardobeattie) wrote :

Looks good! I hope to see this in the next release of Mixxx, or in 1.10.1!

How are the colours generated? Do you use a scale or is it done dynamically? Also, you could try to change the actual color instead of the brightness, but it might add a level of complication to it :/

Revision history for this message
William Good (bkgood) wrote :

This is cool.

No idea if this can go in 1.10.x as we're still technically way past 1.10 feature freeze. RJ?

Also, memory leak kinda sucks (pre-existing one too) -- it looks like the only (?) reason we can't allocated the qvectors on the stack is because TIO stores pointers to the vectors. Is there any reason we can't have TIO hold its own QVectors (on its stack space -- the data areas of these vectors are still heap-allocated, of course) and just have ::setVisualWaveform take a const QVector<float>& and then copy to its own vector?

Changed in mixxx:
importance: Undecided → Wishlist
status: New → In Progress
Revision history for this message
danstowell (danstowell) wrote :

Bill: thanks. I don't mind if it misses 1.10.x, as long as it goes in at some point ;)

Re the memory leak: I agree - I'm new to the codebase, but I would imagine the TIO could own the QVectors for waveform height & colour, even if they're not stored to disk - the downsampling factor is defined by (samplerate / tio->getVisualResampleRate()), so the array size should be known to the TIO in advance and usually unchanging, so we can create it in the ctor and free it in the dtor?

(Eduardo: actually, changing the colour as well as the brightness is not difficult, but this way we adhere to the colours chosen in the colour scheme. I use a palette of 7 variants on the colour scheme's chosen waveform colour.)

Revision history for this message
Orest (orestta) wrote :

I miss this feature a lot. Any chances for it to get included in one of the coming releases?

RJ Skerry-Ryan (rryan)
Changed in mixxx:
assignee: nobody → danstowell (danstowell)
Revision history for this message
Daniel Schürmann (daschuer) wrote :

Thank you Danstowell for working on this.
We have committed something similar from Bug #1074346. Based on the new waveforms 2.0.
I am sorry we must discard this patch.

I will now set this bug to "Won't Fix". But be free to reopen it again if there are aspects missing in the trunk solution.

Changed in mixxx:
status: In Progress → Won't Fix
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/5962

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.