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
collectEvents(track, curTickPos, nextTickPos, frames);
in void Audio::processMidi() in midi.cpp
Apologies for the trouble and thank for catching this.