|
|
|
05-15-2021, 07:27 PM
|
#1
|
Human being with feelings
Join Date: May 2018
Location: Los Angeles
Posts: 1,719
|
Quantize Bug with repro steps and pics
Hi awesome Devs,
This is an annoying bug. I've saved out a Reaper file so anyone can test. Download 1 track project here.
Issue: In some cases when you quantize 100% (doesn't matter if quantized in the MIDI Editor or using a native arrange quantize notes) some notes are not quantized to the grid so when you split an item, you lose the MIDI note to the previous item.
The key here is you may not notice the bug until you split an item at the downbeat and then try to duplicate... then you'll notice your MIDI note is missing.
So, here are the repro steps with the project I included (really zoom in!!):
1) Quantize the Item notes to 100%
2) Notice the MIDI note is still preceding the downbeat of Measure 2 -- I.E. Not Quantized correctly
and in MIDI Editor -- Still not quantized:
NOW... here's where things get REALLY crazy:
If I Split using a native Split action (non-native actions won't split correctly, by the way, and result in a lost MIDI note in bar 2) then the MIDI note WILL be displayed correctly on the Item and in the MIDI Editor:
Lost MIDI Note when using all 3rd party split scripts I have tried:
Arrange when using Native Split (now displays and behaves as it should be after a simple Quantize) -- however notice the end of the item before bar 2, it is now notched at the end meaning something fishy happened:MIDI Editor (now displays and behaves as it should be after a simple Quantize):Let me know if I can be of more help.
Cheers,
Andrew K
__________________
Cheers... Andrew K
Reaper v6.80+dev0621 - June 21 2023 Catalina Mac Mini 2020 6 core i7 64GB RAM OS: Catalina 4K monitor RME RayDAT card with Sync Card and extended Light Pipe.
Last edited by Thonex; 05-16-2021 at 10:01 AM.
|
|
|
05-16-2021, 04:40 AM
|
#2
|
Human being with feelings
Join Date: Oct 2013
Location: Moscow, Russia
Posts: 3,960
|
Not a bug, it is MIDI precision.
|
|
|
05-16-2021, 08:37 AM
|
#3
|
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
Quote:
Originally Posted by mpl
Not a bug, it is MIDI precision.
|
You need to look more carefully. This is indeed a bug.
If the user quantizes and the note is not put exactly on the grid, that is not user expectation. You could argue "midi precision" - even though this is quantized data, not original unquantized data - but again not expected behavior when quantizing.
However, what makes this a bug is that after quantizing and *then* splitting it DOES put the note exactly on the grid as expected.
If native split can place the item exactly on the grid with no issues regarding midi "precision" then so can native quantize - and again would be the expected behavior. Thus, a bug.
More so, the unintended consequence of not placing natively quantized items exactly on the grid can result in lost data. Which the user would not see until completely zoomed in btw. Again, a bug. We are talking about quantized data here, where the action itself is explicitly moving notes to the grid (expected behavior), not unquantized data. Thus, if native split has no problem with midi precision, neither should native quantize.
|
|
|
05-16-2021, 10:14 AM
|
#4
|
Human being with feelings
Join Date: May 2018
Location: Los Angeles
Posts: 1,719
|
Quote:
Originally Posted by mpl
Not a bug, it is MIDI precision.
|
Hi mpl,
Actually, this really is a bug like Klangfarben explained. If you don’t believe me, download the test project and try the repro steps. After that you will see.
So in the meantime if you could change your post… Because the last thing I need is the first response in the thread to be a contradiction of what I just put a lot of time and effort into proving.
Thanks.
Cheers,
Andrew K
__________________
Cheers... Andrew K
Reaper v6.80+dev0621 - June 21 2023 Catalina Mac Mini 2020 6 core i7 64GB RAM OS: Catalina 4K monitor RME RayDAT card with Sync Card and extended Light Pipe.
|
|
|
05-17-2021, 04:40 AM
|
#5
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
|
@Andrew, I've just checked your project and I can confirm this bug/behavior.
To sum it up: when the item is split, the note aligns perfectly to the item, as seen in the GIF. At the end I'm extending the split item to the left, in order to make sure it is not a visual glitch caused by the item boundaries.
|
|
|
05-17-2021, 11:49 AM
|
#6
|
Human being with feelings
Join Date: Jul 2009
Posts: 3,714
|
Your item has a teeny tiny start offset of 0.0000052s, so the MIDI ticks don't fall exactly on the grid.
This is yet another example of REAPER's misleading display of rounded values. The Item Properties window displays the start offset as 0:00.000, and the only way to figure this out, is to use a script. To correct the value, you have to re-type "0" in the Properties window. (NB: simply typing "0:00.000" if the displayed value is already 0:00.000 somehow doesn't work.)
Last edited by juliansader; 05-17-2021 at 11:55 AM.
|
|
|
05-17-2021, 12:01 PM
|
#7
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
|
OMG, I double checked the item properties dialog but somehow expected that one being accurate. Thanks for that important info Julian!
|
|
|
05-17-2021, 12:03 PM
|
#8
|
Human being with feelings
Join Date: May 2018
Location: Los Angeles
Posts: 1,719
|
Quote:
Originally Posted by juliansader
Your item has a teeny tiny start offset of 0.0000052s, so the MIDI ticks don't fall exactly on the grid.
This is yet another example of REAPER's misleading display of rounded values. The Item Properties window displays the start offset as 0:00.000, and the only way to figure this out, is to use a script. To correct the value, you have to re-type "0" in the Properties window. (NB: simply typing "0:00.000" if the displayed value is already 0:00.000 somehow doesn't work.)
|
Wait... so I would never know this natively unless I run a script to verify to the Nth decimal place?
That is rather massive... and would explaining when duplicating Items, sometimes they would get out of sync with the grid... whereas the Properties showed a quantized Item Start & End.
Wow!
Thanks for reporting this JS!!
__________________
Cheers... Andrew K
Reaper v6.80+dev0621 - June 21 2023 Catalina Mac Mini 2020 6 core i7 64GB RAM OS: Catalina 4K monitor RME RayDAT card with Sync Card and extended Light Pipe.
|
|
|
05-17-2021, 12:20 PM
|
#9
|
Human being with feelings
Join Date: May 2018
Location: Los Angeles
Posts: 1,719
|
Quote:
Originally Posted by juliansader
Your item has a teeny tiny start offset of 0.0000052s, so the MIDI ticks don't fall exactly on the grid.
This is yet another example of REAPER's misleading display of rounded values. The Item Properties window displays the start offset as 0:00.000, and the only way to figure this out, is to use a script. To correct the value, you have to re-type "0" in the Properties window. (NB: simply typing "0:00.000" if the displayed value is already 0:00.000 somehow doesn't work.)
|
OK... so I tested, and you are correct. Something fishy is going on with the properties Start in Source. I wonder how that ever got shifted by so little. I never mess with that field or shifting MIDI like that. And the fact that it shows 0:0:0:0 yet still has an impact on quantization and splitting items can be very frustrating.
__________________
Cheers... Andrew K
Reaper v6.80+dev0621 - June 21 2023 Catalina Mac Mini 2020 6 core i7 64GB RAM OS: Catalina 4K monitor RME RayDAT card with Sync Card and extended Light Pipe.
|
|
|
05-17-2021, 02:03 PM
|
#10
|
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
Quote:
Originally Posted by juliansader
This is yet another example of REAPER's misleading display of rounded values. The Item Properties window displays the start offset as 0:00.000, and the only way to figure this out, is to use a script. To correct the value, you have to re-type "0" in the Properties window. (NB: simply typing "0:00.000" if the displayed value is already 0:00.000 somehow doesn't work.)
|
" Misleading" ??? Wholly giant s*&# snacks. This is on a completely different level.
So let me get this straight. The offset displays 0:00.000, when it is not actually 0:00.000. And there is literally no way for a user to be aware of this unless they write a script and send the value to a console message. And even if the user for some reason types in 0:00.000, that STILL won't reset it until they just type '0'. Do I have that right??
Furthermore, we don't even know how the offset actually occurred as nothing was done explicitly to change it, especially an offset that tiny. Which is equally disturbing (0.0000052 seconds Devs, really??)
I've been running at a PPQ of 15360 for the last couple years to try and keep things like the above from happening, since the midi grid resolves to the audio grid in Reaper (and thus technically isn't a grid at all). Which is a severe pain in the ass when importing/exporting midi (and just in general).
Devs, if you are going to allow an extremely high level of precision in an offset value, you HAVE to indicate that in the value. If an offset is 0:00.0000052 and you choose to display 0:00.000 only to the third decimal place you need to display it as 0:00.000 * or 0:00.000 * in red text. OR just display the full value. That isn't just " misleading". That is straight up evil (and a bug). The user HAS to know this information. Because 0:00.000 is NOT 0:00.0000052, has MAJOR unintended consequences and has really screwed life up for those of us working with midi, not even knowing what the cause of it was. Through zero fault of our own.
Furthermore, it would be extremely beneficial to end users and scripters alike to know what things will change an offset value that an action or script has not explicitly changed. Changing project start offset? Deleting/adding time? Editing tempo/meter map or playrate? Or maybe some reascript bugs/gotchas lurking that we don't know about?? An offset should never get changed unless a user or script explicitly changes it. An offset getting randomly changed by .0000052 seconds just should not happen. Ever.
Julian, thank you so much for your knowledge and insight. Devs, this one is a showstopper. No normal user (or user not named Julian) would even be able to find the issue, let alone figure out how to sort it.
|
|
|
05-19-2021, 11:45 AM
|
#11
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
|
One reason this is happening is the fact that record will start the item/take at the first note/CC input.
This is directly after recording MIDI.
MIDI take offset, retrieved via the API (click to enlarge):
MIDI take offset, zoomed in MIDI editor:
|
|
|
05-25-2021, 11:01 AM
|
#12
|
Human being with feelings
Join Date: May 2018
Location: Los Angeles
Posts: 1,719
|
Quote:
Originally Posted by _Stevie_
One reason this is happening is the fact that record will start the item/take at the first note/CC input.
.
.
.
|
It gets worse. Recording with a Count In (1 measure for example) will result in an Item starting a TEENY bit before the downbeat. You can actually split at the downbeat and end up with 2 items (although the first item will be invisible unless you REALLY zoom in). This is all using Native Actions.
This happens even with Audio (Note the script console at the bottom showing 2 items after being split at the downbeat):
__________________
Cheers... Andrew K
Reaper v6.80+dev0621 - June 21 2023 Catalina Mac Mini 2020 6 core i7 64GB RAM OS: Catalina 4K monitor RME RayDAT card with Sync Card and extended Light Pipe.
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 05:45 AM.
|