Bug: length and active quantization dysfunctional in MusE 3.1pre

MusE is a DAW for Linux with both MIDI and Audio editing. https://muse-sequencer.github.io

Moderators: MattKingUSA, khz, spamatica

Post Reply
User avatar
electrocoder
Posts: 2
Joined: Tue Apr 30, 2019 9:14 pm
Location: Hamburg, Germany

Bug: length and active quantization dysfunctional in MusE 3.1pre

Post by electrocoder »

:shock: New in MusE 3.1pre, some aspects of event quantization seem to be broken. Especially there seems to be no way to achieve length quantization any more. The checkmarks in the respective Quantize dialogs are present still but have become no-ops. Also, though of lesser importance to me, active quantizing seems to have disappeared completely as well. Permanently?

To me this seems more like an intended operation rather than a regression bug appearing unnoticed. In the source of 3.1.0pre2 the variable "quant_len" is replaced by a fixed false value in all relevant places. As grep shows:

Code: Select all

muse/midiedit/pianoroll.cpp:775:    /*ret._quant_len*/ false,  // DELETETHIS
muse/midiedit/drumedit.cpp:1476:    /*ret._quant_len*/ false,  // DELETETHIS
muse/midiedit/scoreedit.cpp:840:    /*ret._quant_len*/ false,  // DELETETHIS
muse/arranger/arrangerview.cpp:671: /*ret._quant_len*/ false,  // DELETETHIS
I re-enabled the "quant_len" parameter again. Then length quantization was effective - sort of. Lengths seem to be quasi-arbitrarily screwed. So function quantize_notes() seems to be a bit buggy. I didn't examine this further. But since position quantization seems to be okay, it is hard to believe that length quantization in the same function couldn't be fixed rather easily by some of the code maintainers, no?

:!: I regard length quantization an important feature! I make heavy use of it. (Probably not me alone?) In MusE 3.1pre the only way to quantize lengths is to manually resize each single one with mouse. To me that seems a serious setback. For now I'm stuck with MusE 3.0.

:?: Can any of the maintainers explain the rationale behind this? Is it actually planned to remove length quantization instead of just fixing it?? If so, why? What are the plans or problems? I found no documentation or hints on that. Changelogs don't mention quantization issues.
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: Bug: length and active quantization dysfunctional in MusE 3.1pre

Post by Tim E. Real »

My fault. Sloppy copy and paste regression at 21.01.2019
Only the Drum Editor should have had that 'false' argument, as it did before my changes.

Fixed in git master now.
It should now behave exactly as before.
As for the actual behaviour, another coder did that.
Be sure to set the strength to 100% for full alignment with raster.
Hm, we should have a choice of quantizing position and/or length, ie. two check boxes, ie. what if user only wants to quantize length.

As for 'active' quantization, do you mean automatic quantization while recording and/or playing back?
The history of that is murky to me. I recall MusE long ago had a 'quantize' button in the transport or something like that.
But I do not think it really worked. I do not recall how or where the user would set the quantization values.
Possibly in the original 'quantize' dialog box. But the other coder removed all of that in favour of this 'retroactive' functions menu, if I recall.
I recall I think he informed us he wanted to remove it and after discussions I think I agreed.
The reason I (would have) agreed is that automatic quantization is one area that is notoriously unreliable, and my reasoning
(and gradual philosophy over time) was "never mess with an original recording", ie. it is better to allow the user to undo such changes
and experiment to see what works after the recording, with a functions menu.
Automatic quantization of playback notes also seems like a tempting idea... but do you really want to trust it to do the right thing?
You would never be sure it was correct unless recording it and examining it.
Unless... the purpose is to intentionally provide a little humanization to the playback and don't care - ie. the more random the better.
I could see that being useful. But that should instead be put in a 'humanization' dialog with randomization.

[Edit:] In keeping with that "never mess with an original recording" credo, I meant to also mention non-destructive
quantization, or any other 'function', where it is like an effect that you can just turn off and on. I'd go for that, eh :)
The original MusE-2 (Werner's, in our git attic) had midi tracks with a midi effects rack that you put midi plugins into. Cool, eh?
(Hm, but for this use case the effects would have to be able to mess with time, like a streaming system.)

Ironic, that quantization is supposed to align everything perfectly for sloppy performers, and yet humanization purposely
misaligns it for perfect players (the computer).

But if you are curious, the place to inject automatic recording quantization and humanization would likely be in
void buildMidiEventList() in midi.cpp
[Edit:] Careful, that's called by one other place: The midi importer code.

And the place to inject automatic playback quantization and humanization would likely be in
void Audio::collectEvents() in midi.cpp
Coincidentally, that is exactly what I am doing now in the latency correction branch - applying a frame offset
to force the notes to play sooner, to correct for playback latency.
Because of the way collectEvents() works I had to mess with the line that calls collectEvents(), adjusting the tick arguments:

Code: Select all

              if(playing)
                collectEvents(track, curTickPos, nextTickPos, frames);
in void Audio::processMidi() in midi.cpp

Apologies for the trouble and thank for catching this.
Tim.
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: Bug: length and active quantization dysfunctional in MusE 3.1pre

Post by Tim E. Real »

Rambling on... The Midi Transformator and Midi Input Transformator dialogs are also powerful tools.
I just tried the Midi Transformator dialog in the functions menu for the first time in a long time.
(Some functions there are similar to other more dedicated things found in the functions menu.)
I tested most options and virtually all of them still seem to work.
Even Its positional (time) randomization feature works.

But... tantalizingly I could not get its 'Quantize' drop-down to enable. :(
Unfinished business?
Post Reply