Extend waveform zoom range

[mixxxbot]

Reported by: wolfbiter
Date: 2012-11-01T06:11:20Z
Status: Confirmed
Importance: Wishlist
Launchpad Issue: lp1073813
Tags: waveform

---

I'm using the Mixxx 1.11 beta 2, and while the new waveform is a huge step up from the old, I'm still finding it inadequate for setting solid beatgrids. This is even a problem when using the precision offered by a visual nudge button in my script: other programs, such as audacity, fruityloops, and traktor, have the capability to zoom in until you can see individual points on the waveform. That makes beatgridding much simpler, and I feel it is something mixxx should have because as it stands it's not really possible to set a listenable beatgrid at this zoom level - I speak from the experience of djing a live dance floor.

[mixxxbot]

Commented by: esbrandt
Date: 2012-11-01T08:53:01Z

---

+1
We had this discussion before, since the first zoom implementation.
See this thread : https://bugs.launchpad.net/mixxx/+bug/367151

[mixxxbot]

Commented by: vrince
Date: 2012-11-01T17:52:57Z

---

The major drawback of the current implementation is that the waveform is based on a sub-sampled version of the audio to ease the cpu requierement to compute and display the visible part. For the moment the visual sampling is something like 441Hz so the smallest feature you can see repesent 1/441 sec of the real audio. It seems to not be precise enougth. You can easily change this value BUT you`ll pay this resolution with far zoom ratio !

[mixxxbot]

Commented by: daschuer
Date: 2012-11-01T21:46:07Z

---

We should distinguish two use cases:

1. Having a fast cpu saving waveform for life situations
2. Having a detailed Waveform for manual track analysis

The current solution focuses 1.

Is it possible to calculate the Missing Samples on the fly when having use case 2?
Is a three band waveform required in 2?
We may consider something like is done, when displaying a high resolution JPG on web. Showing a low res version during the load of the high res version.

[mixxxbot]

Commented by: wolfbiter
Date: 2012-11-01T23:21:42Z

---

I did see those threads, and i should clarify that i wanted to submit this as a bug specifically because I feel like the sync button really is bugged if we can't get a proper beatgrid working (syncing poorly beatgridded tracks turns into double kicks which sure sounds like a bug to the listeners!).

Thanks for the response, and glad to know you guys are fully aware of it. For now, I'll continue to outsource my beatgridding...

[mixxxbot]

Commented by: ywwg
Date: 2012-11-04T14:12:17Z

---

Have you tried any of the 1.11 betas? The new beat detector is near-flawless.

[mxmilkiib]

At maximum zoom out level, for a 140 BPM track I can only see 100 beats on the screen at a time, which is only 25 4-beat bars or 6.25 16-beat phrases, which makes things a bit scary when playing, as I can't see if the drops etc beyond what is visible actually line up.

[ronso0]

as I can't see if the drops etc beyond what is visible actually line up

What's the use case?
a) Verify beat markers for a single track while it's playing (live, can't seek to verify locally) or
b) beatmatch two or more tracks?

[mxmilkiib]

b) but more in the realm of phrase matching

[mxmilkiib]

For anyone wanting to achieve this, the value to tweak is

mixxx/src/waveform/renderers/waveformwidgetrenderer.cpp

Line 14 in b14c624

const double WaveformWidgetRenderer::s_waveformMaxZoom = 10.0;

This is what it looks like at 80.0;

[ronso0]

(the pre-/post-roll triangles should probably be drawn with device coordinates, not waveform/track coordinates to avoid them appearing as solid bars at low zoom levels)

[mxmilkiib]

The main UX issue is that the zoom is always orientated/focused on/toward the playhead, which makes precision mixing ahead of time fairly harder, though that can always be nudged closetr to the actual mix. Also, one always has to hit play to get the new track moving to keep in sync.

Otherwise, this is a godsend, I can see the big picture now and I don't get stressed, especially working with a library where most of the tracks haven't been beatgrid aligned and 16/32/64-bar-pre-drop hotcue(s) added. (How I can do that to my big local library but then get tracks onto my USB stick setup... Idk rhetorical shrug). This could give me so much time.. especially if performing live at the same time as DJing (I'm very interested in controllerism)

I'll have to make a sed for my PKGBUILD prepare() to apply the change every time I build main (the process of creating a package on Arch includes an automatic pull, I just run my makepkg alias "mP" in the same dir as the PKGBUILD).

[mxmilkiib]

How about the possibility of upping the value from 10.0 to 20.0?

Personally I've been using a max waveform zoom number of 60.0.

[ronso0]

We need to keep it mind that the waveform_zoom control is mapped to pots, and with a much bigger range it may be hard to adjust the zoom in the lower / mid range.

See also #12387

Maybe waveform_zoom would need to use ControlLogPotmeterBehavior when the range is extended further.

[mxmilkiib]

For anyone interested in having an extended range now;

echo 'add_custom_target(sed_fix ALL COMMAND sed -i "s/s_waveformMaxZoom = 10.0/s_waveformMaxZoom = 60.0/" ${CMAKE_SOURCE_DIR}/src/waveform/renderers/waveformwidgetrenderer.cpp)' >> CMakeLists.txt

in the root dir of the repo

[daschuer]

such as audacity, fruityloops, and traktor, have the capability to zoom in until you can see individual points on the waveform.

The root cause of the issue is that our waveform widgets are using cached waveform data.
With 1/100 of the original samples:
https://github.com/daschuer/mixxx/blob/adda147643d830ef3069121c634e799b6ca963ed/src/analyzer/analyzerwaveform.cpp#L61

This is a reasonable compromise during mixing and for the moving case. However it does not allow sample exact positioning of cue points and loops.

For this we need a non filtered and non colored mode to show the true samples.

One idea is to reuse the engine buffer which already has these samples cached around the play position.

This means for the highest wage from resolution we need to switch to a deiffent simple (sample exact) waveform renderer.

At 44100 a buffer of 20 ms has 882 samples. A reasonable number to render a waveform from.