Midi Snap Issues - phantom notes

[Joe90]

I'm talking about this -



Yes, I know it's been discussed before, and here was Schwa's official response (edited slightly for brevity) -

Originally Posted by schwa

What happened is it got accurate Starting with 5.28 the piano roll displays MIDI events at their exact MIDI tick location. Depending on the exact placement of MIDI media items, start offset, time signature, and grid settings, the project grid divisions may not fall exactly on MIDI tick divisions. This is only noticeable when zoomed very far in, as in your screencaps. But what you are seeing is exactly what is being played back.

Given a project with no partial measures, MIDI media items that are snapped to the beat, no start offset in the media items, and grid settings that divide evenly into the MIDI ppq setting, then MIDI ticks should align with the grid. If you are not able to snap MIDI events to a specific grid position that you want to, then one of those things must not be the case in your project.

Makes sense. You have to be zoomed in really far to see it, and I understand it's still essentially playing back in time, but here is the issue, when I go to split this midi item on the grid I get this -



It's not a phantom note, it's real, and it triggers a drum hit as you can see from the meters. This is a problem, because you literally can't see these notes unless you're zoomed in as far as you can go, and you can't see them in the midi editor AT ALL -



In this gif you can see the note is still there, it's still triggering (you can see the meter). I open the midi editor, no note to be seen (I could have zoomed in further but it still wouldn't have appeared) - I select some thin air and click delete, the note goes away.

There are a few scripts for deleting short notes. None of them have any effect on these notes.

I understand that it got accurate. I accept that. But this is a real issue - and Reaper is the only DAW in which I experience this issue. Can't we have an option to make the notes just snap to the grid lines, even if that's not EXACTLY where they're actually playing back? The visual inaccuracy from using this method would be a matter of samples (even less I believe) correct? So, yes it would be technically inaccurate, but it would solve these issues and make no difference for real world use. I'm willing to bet that's what all other DAW's are doing, and I for one would prefer that behaviour to this.

Also, regarding the last paragraph of qualifiers from Schwa - these gifs were made using all those conditions, except for the grid/PPQ divide, so I set the PPQ to 1100 (I'm at 110bpm) and repeated the test. Still get the same inaccuracies (although they decrease as PPQ gets larger, this just means that the phantom notes get tinier, they don't go away).

I'm aware there's a setting for 'force project tempo... to occur on whole samples' which seems to fix this, but then I'm limited to ridiculous BPM's like 116.002. Not only is this embarrassing to explain when sending over files for collaboration, it's also useless for any dancefloor oriented music that's intended to be mixed by a DJ, and relies on standard tempos.

Please can we get this looked at?

Edit: I should clarify - the midi parts in these gifs were recorded with a midi keyboard, using 'time selection auto punch' to make sure the item start record time is bang on the grid. If I draw the notes in by hand this issue doesn't seem to occur (as far as I can tell, that doesn't tend to be my preferred way of working).

[Joe90]

Here is another side effect of this issue which others may have noticed too -

Midi item lengths can end up slightly misaligned from the grid at either end (again only noticeable when very zoomed in) and once this midi item is duplicated across the timeline 50-100 times, the differences add up and suddenly your midi items aren't quite where they're meant to be (by literally a few samples, but that is enough to cause phase problems). It's particularly troublesome when combined with the action 'SWS/BR: Trim MIDI item to active content', or if you enable the snap/grid option 'snap to project sample rate'.

If your workflow involves recording/arranging midi to the grid (and I know for many of you it does) and this is not a major concern for you then I'm assuming you either -

a) just haven't noticed it happening yet, or
b) you've figured out a fix, in which case please feel free to share.

I think this is strongly related to the midi item's perceived start time. If I draw a midi item on the grid with snap on and then draw the notes in by hand, still with snap on, then they're bang on the grid. If I do the same thing but start by drawing the midi item with snap off so the start time is slightly off grid (but then still drawing the actual notes on the grid with snap on) then the notes are slightly off. I'm guessing it's related to the fact that Reaper isn't locked to a specific sample rate, so it's possible for a midi item to start 'in between' samples, and then each midi item seems to have it's own timebase/grid based off of that start time.

Would a project 'lock sample rate' option work? Wherein it works more like a traditional, boring () DAW - items imported that are not at the project sample rate would have to be converted on import, but hopefully with the effect of sidestepping these midi handling issues? You'd think that maybe 'snap to project sample rate' would fix this, but it actually makes it worse - everything is a tiny bit off because it's snapping to the sample rate instead of the grid, causing all the same issues I've already described.

Or maybe we could have a preferences option 'midi is only editable to the grid', wherein all midi notes/items snap properly to the project grid without these slightly late/early notes? Even the if true playback position might be half a sample out from where it's shown, at least then we'll be able to split that midi item on the grid, or trim the part to it's contents, without the risk of phantom notes or slightly too early/late notes.

I don't care if this makes the visual to auditory response microscopically inaccurate (I don't think it even would, because the amount of time discrepancy between display and playback that we're discussing here is literally 2 or 3 samples, if that), the issues caused by the current alternative are much greater in my opinion.

While I'm having a midi moan - there are a whole bunch of actions that relate to item manipulation around the grid from the arrange page that seem to be broken when swing grid is activated, and have been this way since I started with Reaper 5, 6 months or so ago. Anyone know what's going on there?

[Joe90]

No one is bothered about this, or has any workarounds?

Really?

[juliansader]

Originally Posted by Joe90

No one is bothered about this, or has any workarounds?

Really?

To the contrary -- this is perhaps the most commonly reported MIDI problem, and there are many threads.

The solution is to ensure that your MIDI items start on the grid, even a very tiny grid like 1/256, as you noted:

If I draw a midi item on the grid with snap on and then draw the notes in by hand, still with snap on, then they're bang on the grid.

If the MIDI item doesn't start on the grid, MIDI item ticks and project ticks will inevitably misalign, like two rulers placed alongside each other.

[dimitris]

Hi Joe. This is something that causes me headaches too.

It's been discussed before (https://forum.cockos.com/showthread.php?t=181729&page=2). According to Julian, it is not a bug but a side-effect of Midi specification. If I understand it correctly, Midi events in Midi items are quantized in ticks (ppq) that are relevant to the item - NOT the project. I wish there would be a single reference (the project one), not two.

Personally the only workaround that I have found when I encounter this issue, is to "fix" the starting point of the Midi item. I do this by extending the starting point to the left and cutting on a grid division. This refreshes the Midi item start and aligns the ppq ticks to the project ones. A simple drag the start of a Midi item to a grid division is not enough, there must be a new split.

[Joe90]

Thank you both for your suggestions.

Julian - I did search the forum but only found that one thread from a few years ago with the statement I quoted from Schwa. I did check the midi bestiary but didn't spot it, so thanks for the link. I see two bug reports that seem to be relating to this, both marked as fixed, as well as Schwa confirming that if the midi part does not start on the grid then this misalignment can happen, but it makes no real world difference... But it DOES, for the exact reasons I've posted above, not to mention keyswitching - I'm sure there are more. Point is, it matters.

Also, the second gif where the tiny midi notes don't even APPEAR in the midi editor, but are still selectable and deletable from the midi editor - surely you'd call that a bug? I checked that on the default theme too and you still can't see them.

I understand the inherent issue, but the question is - how is every other DAW handling this with apparent ease? I understand that midi is inherently not sample accurate, due to the reasons discussed here regarding PPQ, and I understand that technically Reaper is showing a MORE accurate representation of true midi position, but is it worth that accuracy when you get all these issues as a result of it? Have there been feature requests made for a preferences option to handle this in a more 'traditional' way, perhaps having ONE project wide 'midi tick' grid that ALL midi adheres to at all times?

I'm assuming that's how other DAW's are doing it? I'm directing that at you Julian as you seem to be the midi master on this forum (LOVE your multi-tool script!) and if anyone is equipped to answer that question I expect it's you. Is it worth me preparing a feature request for this do you think? Some kind of global project midi tick option, or an option for 'always align midi item ticks with project ticks' would surely fix all this straight away? So that the start time of all midi items is always forced to the closest possible grid. From my testing this never seems more than a few samples away anyway, so it would never be moving anything far enough to sound 'out of time' when using this option, and it would solve all of these issues caused by slightly off grid items and notes.

Regarding the workarounds - the tiny grid setting can help with editing, thank you. Although it would mean all my 'ignore snap' modifiers and commands are now no good for midi. However, it doesn't help with the issue of the actual recording start of the item being off grid. I'll have to get into the habit of placing the cursor on the grid after making sure snap is on, then hitting record, rather then just hitting record while the track is playing and I suddenly get inspired. Not a biggie, just need to get used to that. It doesn't help that probably half of my midi recording is done using retrospective record, and there's no way to tie the start time of that to the grid until after the fact.

The trim solution wasn't working for me, but I realised I had a preferences option 'allow trim of midi events' unchecked, so that's why, but when I check that option it means I can't re-extend my midi events after they've been split, which is a function I often use in my workflow, however I've just realised that this actually often seems to stop the tiny notes appearing too. Perhaps I'll need to get used to destructive midi splitting, as this seems the best workaround for the tiny notes issue so far, although it still won't protect against the splitting that's done when using 'trim content behind media when editing' - you still get the tiny notes.

I can trim then glue. That works, but it's not great when I've got 7 takes of a midi part that I've just laid down and I want to keep them in their separate takes - do I explode them all, split and glue them all separately, then implode them back together? Yes I can figure out a custom action I know, but you can see how it gets convoluted fast.

It's just an AWFUL lot of working around, all of which hampers creativity, for a problem that the devs seem to think either doesn't exist, or is fixed! All the posts discussing it are a good 2 or 3 years old, I didn't see much recent discussion, so I was hoping there was a concrete fix for it. Hopefully it gets some consideration.

Thanks again for the assistance, and sorry for the essay!

[dimitris]

Hey Joe, I couldn't agree more with the 'always align midi item ticks with project ticks' option.

Perhaps it's worth submitting this as a feature request as well. If this is not considered a bug, maybe the alternative option will be considered as a feature. And you have already done a great job detailing the problem with GIFs and all.

[juliansader]

Originally Posted by dimitris

A simple drag the start of a Midi item to a grid division is not enough, there must be a new split.

It is correct that a simple drag is not enough: the ticks are counted from the start of the *source*, and dragging the item edge merely determines what part of the source is played and visible in the arrange view.

Be careful with splitting: it only works if you have enabled "Allow trim of MIDI items when splitting".

Originally Posted by dimitris

Hey Joe, I couldn't agree more with the 'always align midi item ticks with project ticks' option.

Perhaps it's worth submitting this as a feature request as well. If this is not considered a bug, maybe the alternative option will be considered as a feature. And you have already done a great job detailing the problem with GIFs and all.

Myself and others have already submitted this as a FR, long ago, but Schwa replied that it would cause troubles with other stuff (I can't remember exactly what), so it was never implemented. It may be a good time to resurrect the FR, though.

BTW, here is where it all started: Error MIDI editor in Reaper (FIXED). As Heda suggested there, perhaps only MIDI *recordings* need to be forced to start on the grid. Note that, even if a MIDI items starts on the grid, if it is stretched, it will lose alignment again.

Another suggestion was to use huge 64bit PPQs by default, with the same resolution as REAPER's floating point time positions. Unfortunately, REAPER currently encodes PPQ as a 32bit value, and it turns out that REAPER rounds MIDI timing to the samplerate during rendering, so fine positioning would be lost.

Even better: why use ticks at all? Instead, use floating point time positions, similar to audio envelopes. Only convert to ticks when exporting MIDI.

[dimitris]

Thanks for the insight Julian!

I can't believe that aligning ticks might break something that's worth more than the Midi artifacts that are created because of this.

Seeing how much work has been put lately into the Midi Editor, I think that this may be a good time to ask for this issue to be reconsidered. Do you have a link to that FR? I'd upvote it and I'm sure others would too.

[Joe90]

Yes, thanks Julian for providing more info and context around this issue.

I would be very curious to know what functionality would be potentially broken by providing an option for a global midi tick, or forcing all recorded midi items start time to the grid, or using floating point time positions as you suggested Julian, because the current method is clearly causing some major headaches and has been for some time. If the devs were going to change the way that PPQ/midi timing is handled project-wide, then it should probably be a 'project settings' option, so that it doesn't break old projects.

I'm sure it's not that simple, but who knows? Any time I find a reference to this issue I see a post from Schwa basically saying it's by design, it's working as expected, yes it can appear a tiny bit off when zoomed in very far, but it makes no real-world difference (apologies to Schwa as I am paraphrasing, but that's the gist of it)... and while it's correct that it doesn't make a difference in terms of playback timing, it really DOES make a difference for all the other reasons discussed here, which Heda rightfully pointed out when the issue was first raised.

I'd also be willing to bet that this discrepancy between midi item ticks and the global ticks is the reason that we have no native 'quantize notes in item' function from the arrange page, and that most of the other functions that manipulate items around grid from the arrange page, (including SWS) are broken with swing grid on.

I hadn't considered the potential issues when importing midi, rather than recording it. Although I must say that it's generally accepted that exporting/importing midi (particularly from one DAW to another) carries an inherent inaccuracy. The accepted convention is that if it needs to sound EXACTLY as it did when you sent it, you need to send the audio stem. So if the concerns around changing this relate to imported midi, I'd say that concern is unfounded.

Yes I experimented with very high PPQ settings myself, and found that all it did was reduce the amount by which midi could be 'off' but this just made the phantom notes even tinier and more difficult to detect, not to mention the very high PPQ seemed to break functionality of certain midi scripts.

Another thing that can exacerbate this issue is 'preserve PDC monitoring in recorded items', as that function doesn't just delay the midi information being recorded, it delays the START time of the item, so not only is it not on the grid, you get this weird situation where if you have a note on beat 1, you can't actually drag the note back to beat 1 until you've bounced the item to extend it's perceived start time to the start of grid (slightly separate issue I know, but another one that would be fixed by forcing all recorded midi items to the grid).

Dimitris - I think there used to be some kind of FR tracker that is no longer used, so I expect Julian's original FR might not be on the forum. I'm happy to raise a new FR, linking back to this thread, so we can hopefully get some clarification. If the devs still feel that this is not worth looking into, or there are issues that mean it CAN'T be changed at all, then I'd like to know that.

Julian - feel free to raise the FR yourself, as your knowledge around this subject is deeper than mine, and you'd be better positioned to discuss the intricacies of the issue with the devs. No worries if not though, I'll just raise it myself.

Thanks again.

[Joe90]

Made a new FR for this here - https://forum.cockos.com/showthread....24#post2225324

I've summed up the various posts discussing it, linked back to this discussion, and provided links to possible solutions including your excellent suggestion here Julian https://forum.cockos.com/showpost.ph...6&postcount=97.