Decide on quantize default behavior

[RJ Skerry-Ryan]

now that beatloops don't automatically quantize it makes sense to turn it on by default

[Mel Grubb (melgrubb)]

Perhaps a better choice would be to just remember the last setting? The same goes for the vinyl spinnys. If I wanted them last time, I probably want them this time, too.

[RJ Skerry-Ryan (rryan)]

Totally reasonable suggestion -- could you file a bug requesting that
settings for these modes (quantize, spinny, etc.) be remembered?

On Thu, Dec 1, 2011 at 7:27 AM, Mel Grubb <email address hidden> wrote:

> Perhaps a better choice would be to just remember the last setting? The
> same goes for the vinyl spinnys. If I wanted them last time, I probably
> want them this time, too.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/898213
>
> Title:
> turn quantization on by default
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/898213/+subscriptions
>

[Phillip Whelan (pwhelan)]

There is a conundrum here. At the moment our beatgrids are not accurate enough so cues will not work properly, but beatloops are mostly useless without it.

 At least in my case I have some songs where I have fixed the beatgrids and others where I have not. Those without are close but are off by at least a margin of .3%, more than enough to render the beatgrid useless at 150+ BPMs. 90% of my problems would go away with bpm rounding, but that patch has been rejected.

As I see it, to get the best user (and least confusing) experience we have to either merge in the forthcoming vamp branch or turn off quantize by default and make beat loops always quantized. I think this is actually why I had programmed it the way ai did in the first place. I know the way it is now is the 'correct' way to do it, but the 'correct' way is usually more suited to technical programs, internals etc... and not UIs for end-user programs where convenience should be more important.

[RJ Skerry-Ryan (rryan)]

So there are a few options:

1) Quantize all beatloops regardless of quantize setting and turn quantize off by default.
2) Quantize all beatloops regardless of quantize setting and leave quantize on by default.
3) Quantize beatloops according to quantize setting and turn quantize off by default.
4) Quantize beatloops according to quantize setting and leave quantize on by default.

Option 4 is what we have today.

I'm not in favor of 1 or 2 because it eliminates the ability to use beatloops when the beatgrid isn't perfect. If your beatgrid BPM was perfect but the offset was wrong, then you want to be able to lay a beatloop without having it snap to the grid. Doing 1 or 2 takes away options from the DJ which seems wrong.

Good UX comes from simplicity. I think the simpler the mental model you need to use Mixxx, the better. Having beatloops act differently from loops, hotcues differently from cues, etc. just complicates the mental model you need to keep in your head when using Mixxx. You shouldn't have to go through a flow-chart in your head to understand what's going to happen when you hit a button. (For example: Loop -> follows quantize setting. Beatloop -> always quantized regardless of quantize setting. Cue -> seeks to the quantized cue position on set. Hotcue -> Sets hotcue but doesn't seek to quantized position on set, etc).

Oops, that last paragraph was just a long-winded inelegant way of saying Keep It Simple. Mixxx is already far too complex and we should be working to make things more unified and simple.

Anyway.. between option 3 and 4, I think that these are the pros and cons:

OPTION 3 PRO
============
* Cues/hotcues/loops/beatloops are not badly placed if the beatgrid is inaccurate

OPTION 3 CON
============
* DJs might not ever discover the quantize mode.

OPTION 4 PRO
===========
* Beatlooping experience is much better when quantize is enabled.

OPTION 4 CON
============
* Cues/hotcues/loops/beatloops work badly when the beatgrid is wrong
* DJs might not realize that quantize is a toggle button (the magnet symbol) and might think that mixxx is stuck with this behavior when they would prefer it was disabled.

[Sean M. Pappalardo (pegasus-renegadetech)]

I'm in favor of leaving it the way it is now (option 4) for the reasons RJ mentioned, but mostly because it's the most approachable for new DJs and very convenient for experienced ones, when the grids are reasonably correct. (And not all of us DJ with such fast music as Phil. For my purposes and genres, the margin of error is acceptable for the added convenience.) So speaking to the cons, if the grids aren't correct, the first thing a user will do is seek information on how to disable snapping to the beat. Since the quantize button is lit up clearly in the default skin showing that something is enabled, and tool tips are also on by default, it's likely that users who are actively looking will quickly discover and disable it. (If not, they'll ask on the forums.) Those for whom the grids are already acceptable can just work in ignorant bliss. :)

This is also a matter of image: if other DJ applications snap to the closest beat by default, Mixxx not doing so would lessen its first impression. With quantize enabled by default, it's clear at first glance that Mixxx just needs better BPM detection, rather than that it's missing a key feature that everyone else has.

[Sean M. Pappalardo (pegasus-renegadetech)]

BPM rounding is an interesting idea as a temporary solution. Can someone link to the discussion that lead to it being rejected?

[Phillip Whelan (pwhelan)]

One of my points is that beatloops are useless when the beatgrid is off, no sense trying to let people use it still. You can argue, rationalize and even make stuff up but in the end it's unlikely you'll ever manually hit the right loop-in position on the fly (granted, you can do it when it's paused) but even then and even a track in the 120-125 range will train wreck with another in about 2-4 bars.

Choice #4 sounds to me like the consistency that programmers strive to achieve and understand.

I will admit that #1 is perhaps easier to model in your head than #4 but I see more as a concession, a compromise. Basically #1 is a way of leaving everything working as before but adding the feature of beatloops. We don't have to change all the other systems in place to fit a new model which will fall apart becuse the beatgrids, a central component to all these systems, is not good enough to "Just Work'. Most users who upgrade to 1.10 won't know they can adjust the first offset and new users even less so. We could solve that by (re)educating our users, but we'd have to take in mind the fact that people "don't read" (stackoverflow has a blog poat about it somewhere).

By the way, a large portion of our users do mix at speeds faster than 120 bpms. This includes all the people who mix drum and bass, jungle, hardcore, happy hardcore, hardstyle, etc... While perhaps not being as numerous as the top40 crowd they most definitely represent at least 25% of our regular users.

In conclusion I whole-heartedly disagree with choosing #4 over #1 since in my opinion it caters more to our desire to 'connect the dots' in our internals while making it harder to just plain uae the software. That being said if we can either merge in vamp or bpm rounding and it works 80% of the time I'd say go for #4.

I'll follow up this post with links to the bpm rounding discussions.

[Phillip Whelan (pwhelan)]

Bpm rounding was implemented in an external branch here:

https://code.launchpad.net/~raskolnikov/mixxx/round-bpm/+merge/42349

It was dismissed because it was not deemed useful enough. I'm sure if the code has diverged enough that it can be re-implemented quite quickly.

[Phillip Whelan (pwhelan)]

The madness caused by quantize-by-default continues in bug #905800. This is a literal pandora's box that will swamp mixxx in billions of little hacks.

[RJ Skerry-Ryan (rryan)]

RE: raskolnikov's branch, I believe when I reviewed it he had not yet made it a preference option. I think that's a useful feature to enable since he made it configurable.

RE: Bug #905800 I don't think that's related to this. The proposal was for tying sync behavior to the quantize flag and I don't think that's a good idea. It'd be better if we provided CO's that do both behaviors.

[Phillip Whelan (pwhelan)]

It would complicate things, but a way we could help people is try and detect a user who is being plagued by this problem and popup a hint to them. As I learned from my short onlie software development course; users are averse to change, they react badly. Users are more likely to go on a journey of discovery once they are comfortable with the software, not during their first 5 minutes of frustration.

[RJ Skerry-Ryan (rryan)]

You can use beatloops just fine when the BPM is accurate but the beatgrid offset is wrong. If you have two tracks in sync at the same BPM then it doesn't matter where you start a beatloop, they will stay in sync relative to their original offset.

Lets say you have two tracks with beats every 100 samples. Mixxx thinks the offset is 0 while the true audio offset is 50.

Let's say you're perfect and you set a 4-beat loop on track 1 at sample 50, then your loop will go from 50 to 450.

After 450 samples, track 1 is at position 50 and track 2 is at position 450.
After 850 samples, track 1 is at position 50 and track 2 is at position 850.
After 1250 samples, track 1 is at position 50 and track 2 is at position 1250.

Their beats are lined up exactly with each cycle of the loop.

Now lets say you were too slow setting the beatloop and set the 4-beat loop on sample 55. Let's say the samplerate is such that 5 samples is somewhere within 10ms of the actual beat, so nobody will actually hear the difference since its well within the thresholds of perception.

After 455 samples, track 1 is at position 55, track 2 is at position 455.
After 855 samples, track 1 is at position 55, track 2 is at position 855.
After 1255 samples, track 1 is at position 55, track 2 is at position 1255.

These are still in sync just fine -- the original difference of 5 samples that was introduced by pressing the button late persists and does not widen with every cycle of the loop. This means that the songs will not trainwreck within 2-4 bars.

[Phillip Whelan (pwhelan)]

That would be true if the BPM was corect, but if it's off by .25 or more it will take at most four bars to be off by a whole beat.

[RJ Skerry-Ryan (rryan)]

Mixxx has never had accurate BPM detection so by that reasoning using any beat related feature in Mixxx 1.10 will fall flat. This is a perfectly good argument for option #3 above, and I already listed this in the PRO section for 3.

You were arguing for option #1 by saying that it was useless to even allow beatloops to be placed without quantization. I believe the above example disproves this. Does it not?

[RJ Skerry-Ryan (rryan)]

Since 1.10 doesn't even attempt to adjust the beatgrid offset, I think it might be a bad idea to go with option 4 over 3.

Ideally we would have a little hint bar, hint popups, or a first-run welcome walkthrough (a la promo tracks in 1.8.0) where we could mention these sorts of things, but we don't.

[RJ Skerry-Ryan (rryan)]

OK, turned off by default. If we aren't even attempting to adjust the beatgrid offset then I agree that it'll just confuse people who don't know it's there and annoy people who do know it's there. In 1.11 we can do some of the ideas that have been mentioned here for making the experience better and more discoverable.

[Be (be.ing)]

Now that BPM and beat detection have been greatly improved and quantize is even more useful, should quantize be enabled by default in 1.12?

[Daniel Schürmann (daschuer)]

IMHO we should keep it off, since it is the traditional behaviour. But we may make it persistent.

[Owen Williams (ywwg)]

I think keeping it off is ok. I feel like auto-quantize is more appropriate for introductory ipad apps, whereas Mixxx allows for a little more freedom.

[Swiftb0y (swiftb0y)]

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