Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Bug Reports

Reply
 
Thread Tools Display Modes
Old 05-15-2021, 07:27 PM   #1
Thonex
Human being with feelings
 
Join Date: May 2018
Location: Los Angeles
Posts: 1,719
Default 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.
Thonex is offline   Reply With Quote
Old 05-16-2021, 04:40 AM   #2
mpl
Human being with feelings
 
mpl's Avatar
 
Join Date: Oct 2013
Location: Moscow, Russia
Posts: 3,960
Default

Not a bug, it is MIDI precision.
mpl is offline   Reply With Quote
Old 05-16-2021, 08:37 AM   #3
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Quote:
Originally Posted by mpl View Post
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.
Klangfarben is offline   Reply With Quote
Old 05-16-2021, 10:14 AM   #4
Thonex
Human being with feelings
 
Join Date: May 2018
Location: Los Angeles
Posts: 1,719
Default

Quote:
Originally Posted by mpl View Post
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.
Thonex is offline   Reply With Quote
Old 05-17-2021, 04:40 AM   #5
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
Default

@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.

__________________
My Reascripts forum thread | My Reascripts on GitHub
If you like or use my scripts, please support the Ukraine: Ukraine Crisis Relief Fund | DirectRelief | Save The Children | Razom
_Stevie_ is offline   Reply With Quote
Old 05-17-2021, 11:49 AM   #6
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,714
Default

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.
juliansader is offline   Reply With Quote
Old 05-17-2021, 12:01 PM   #7
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
Default

OMG, I double checked the item properties dialog but somehow expected that one being accurate. Thanks for that important info Julian!
__________________
My Reascripts forum thread | My Reascripts on GitHub
If you like or use my scripts, please support the Ukraine: Ukraine Crisis Relief Fund | DirectRelief | Save The Children | Razom
_Stevie_ is offline   Reply With Quote
Old 05-17-2021, 12:03 PM   #8
Thonex
Human being with feelings
 
Join Date: May 2018
Location: Los Angeles
Posts: 1,719
Default

Quote:
Originally Posted by juliansader View Post
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.
Thonex is offline   Reply With Quote
Old 05-17-2021, 12:20 PM   #9
Thonex
Human being with feelings
 
Join Date: May 2018
Location: Los Angeles
Posts: 1,719
Default

Quote:
Originally Posted by juliansader View Post
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.
Thonex is offline   Reply With Quote
Old 05-17-2021, 02:03 PM   #10
Klangfarben
Human being with feelings
 
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
Default

Quote:
Originally Posted by juliansader View Post
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.
Klangfarben is offline   Reply With Quote
Old 05-19-2021, 11:45 AM   #11
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
Default

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:

__________________
My Reascripts forum thread | My Reascripts on GitHub
If you like or use my scripts, please support the Ukraine: Ukraine Crisis Relief Fund | DirectRelief | Save The Children | Razom
_Stevie_ is offline   Reply With Quote
Old 05-25-2021, 11:01 AM   #12
Thonex
Human being with feelings
 
Join Date: May 2018
Location: Los Angeles
Posts: 1,719
Default

Quote:
Originally Posted by _Stevie_ View Post
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.
Thonex is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 05:45 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.