A Bestiary of MIDI Bugs

[juliansader]

Update v5.80 and v5.90: After a long, excruciating hiatus, MIDI bugs are being fixed again!

Our intrepid heroes, Schwa and Justin, have vanquished many a MIDI monster in v5.24. Will the upcoming v5.25 be the fabled, long-prophecied version in which all MIDI bugs are banished from Reaperland?

To aid our heroes on their quest, I have compiled this Bestiary of Bugs. I have not encountered or tested all of these bugs myself, so some of them may have fled since they were first reported, but most are definitely still roaming the lands.

For an older thread (that includes Feature Requests), please refer to MIDI - a summary of important pending things.


(Please do not report new bugs in this thread; rather, create a separate thread with a descriptive title.)


Bugs that affect ReaScript performance and user experience
Sluggishness: REAPER's audio engine is famously efficient and optimized. Sadly, the piano roll is the opposite, and it's getting worse and worse: v5.40 is THREE TIMES slower than v5.00! This negatively impacts ReaScript responsiveness:
Recent versions get terribly bogged down when multiple takes visible in MIDI editor
Standard toolbar arming cannot be used in CC lanes:
Actions armed by right-clicking toolbar button do not work in CC lane [Fixed!]


Multi-channel MIDI editing
Most of the channel-related bugs were fixed in v5.30. These somehow remain:
Bullets in channel dropdown list always show channel 1 being used [Fixed!]
Notes get deleted or extended when channel is changed to same channel as adjacent note [Fixed!]


Regions versus envelopes
Most of these bugs were fixed in v5.75!
Copying or moving regions messes up the tempo envelope [Fixed!]
Copying or moving regions messes up automation envelopes [Fixed!]
Moving regions drops multiple copies of existing tempo markers
If Allow trim of MIDI items is off, moving region across tempo change drops notes


Other tempo envelope and time signatures bugs
Important tip: As discussed here and here (and elsewhere), the tempo map can easily get screwed up if options such as the following are not carefully and correctly set:
* Timesig markers "Allow partial measures",
* Add edge points when ripple editing or inserting time,
* Timebase for tempo envelope,
* Timebase for MIDI items.
One of the most common complaints concerns timesig markers jumping around. This is usually the result of "Allow partial measures" = OFF, combined with Timebase for tempo = Time.
"Create new measure from time selection" alters tempo at *end* of time selection [Fixed!]
"Create measure from time selection" calculates wrong tempo if there is a tempo marker close to end of the time selection
"Insert empty space" deletes time signature at start of time selection [Fixed!]
Select/Copy/Delete "points in time selection" unreliable - depends on how time selection was drawn [No recent reports - perhaps fixed?]
Gradual tempo changes: gridline display/snapping and envelope pasting issues
Inserting new tempo point via right-click menu changes value/shape of previous point
Inserting square tempo point into linear envelope creates weird new timesig changes [Fixed!]
When copy/pasting points into tempo envelope, it always acts as if Timebase=Time
Time signatures with partial measures cannot be inserted when timebase=time


MIDI import and export
Certain time signatures cannot be exported to MIDI, but no warning is given
After importing XML, quantization makes notes disappear [Fixed!]
If project start time < 0, export only starts at time 0:0.000


Quantization and snapping
Quantize window applies wrong settings to non-active tracks [Fixed!]
Quantize moving items which are already on the beat [perhaps expired - no recent confirmations]
When just opened, Quantize window shows "Triplet", but "Straight" is applied
When using "CC selection follows note selection" to coordinate notes and CCs, CCs follow manual note movements but not note quantization [Fixed!]
Snapping to time position after linear tempo transition when the previous tempo marker does not fall on the grid
"Quantize notes position to grid" uses "Strength" setting from main Quantize window (for that we have the "Quantize ... last quantize dialog settings" actions)


MIDI note names
Note names not displaying in first track [Expired]
Midi note name files not merging when shift+click on recent list [Fixed!]
Actions and menu items to change CC names misleadingly refer only to "note names" [Fixed!]
CC names does not immediate update [Fixed!]


Stuck notes and missing note-offs
Record settings: Input quantize results in stuck MIDI notes
Stuck notes when playing MIDI through VSTi - perhaps due to reaperhost bridge? (and perhaps also reported here)
Note-off not sent when using replace/enclose and a note overlaps the start of the enclosing item
"Send all notes off to all MIDI outputs/plug-ins" action is unreliable
Stuck notes can be caused by doing certain unusual edits *during* playback


Mouse modifiers and editing actions
Win key is not available as modifier for mousewheel shortcuts [Fixed!]
Deselection: Double-clicking in CC lane still automatically deselects all events, even if "No action" is selected
Deselection: Left-click on MIDI note deselects all events, even if "No action" is selected [Fixed!]
Velocity lane: "Erase event" mouse modifier does not work in velocity lane [Fixed!]
Velocity lane: Cannot edit velocity of single note in a chord [FIXED]
Velocity lane: If drawing fast, some notes are skipped
Short notes: "Erase notes" with left-drag skips short or zoomed-out notes
Actions "Add previous/next note to selection" sometimes get stuck or slip notes Fixed!
14bit CCs: Unselected CCs disappear when range-selecting via shift-click [Fixed!]
14bit CCs: Ctrl-click in 14-bit CC lanes selects only the MSB CC, not the LSB CC [Fixed!]



(Continued in next post...)

[juliansader]

Artefacts when gluing MIDI items
R4.78 creates CCs when Gluing...! [FIXED!]
If using large PPQ, note position and length change by thousands of ticks when gluing


Event list needs some love
MIDI Event List not updating after changes in arrange view or other MIDI editors
MIDI editor event list mode: display update bug (selections)


Inline MIDI editor and arrange view
Drag Midi item from VSTi onto track: wrong piano roll notes mode in arrange view
Notes not displayed and not moving with item
MIDI Markers position not right in the arrange view if take has rate change
Weird barcode-like patterns are drawn over MIDI items
Inline Editor: Mousewheel shortcuts don't work, pass through the main window
Inline Editor: Zoom changes when duplicating or undoing


Notation editor
Tempo change and bar numbers overlay each other
Problems creating tuplets over tied notes
Display in Musical notation, blinking channel dropdown
Accidentals of chord overlay each other in unreadable mess [Improved]


Note preview and chasing
MIDI preview on new note, not working
Note preview doesn't "chase" notation text
Previewing notes in MIDI editor doesn't do MIDI chase (envelope automation gets chased, but not CCs)
MIDI item CC-chase doesn't respect "Reset all controllers" #121

Item length in MIDI editor
Editing item length in MIDI editor is buggy when the item length is shorter than 1/4 note and item properties are set to "loop item source"
A MIDI clip with a Rate > 1 does not loop correctly
Extending MIDI item over tempo marker causes misplaced notes


Explode by note row
"Explode MIDI item by note row (pitch)" leads to empty channels for E♭-1 and E-1 [FIXED!]
"Explode MIDI item by note row (pitch)" leads to note lengths being increased


Overlapping notes and infinitely extended notes
REAPER uses the standard specifications for MIDI files to store the data of MIDI items. According to the specifications, overlapping notes (with the same pitch and channel) are not valid. Many of REAPER's native actions, as well as scripts, will go haywire *without warning the user* when applied to overlapping notes.
Humanize removes overlapping notes, but incorrectly
Humanize function is affecting non-selected notes in a MIDI item


Copy/pasting and duplicating notes
The setting Autocorrect overlapping notes while editing is supposed to make editing safer, but is unfortunately buggy:
Pasting or duplicating note deletes non-overlapping adjacent note [Fixed!]
Pasted note disappears if it overlaps existing note


MIDI recording
MIDI ASIO Latency Compensation Problems
MIDI input quantize bugs (overlapping notes during recording)
MIDI overdub is cut off if it extends past first item into a second item


Display bugs in piano roll
Midi editor grid glitch and Erratic grid lines in MIDI Editor
MIDI editor displays bank select incorrectly when item looped
CCs disappear when events earlier in MIDI string go offscreen
No indication of source end when looping is disabled


Lyrics
On 32nd and 64th notes, the lyrics 'stepper' skips notes or get stuck
Lyrics 'stepper' skips note if it start slightly behind beat
After editing lyrics several times, sometimes they can't be deleted


Reascript bugs
Large state chunks are truncated by GetTrack/ItemStateChunk [Fixed!]
Using MIDI_InsertEvt to insert a Note On automatically insert a (wrong) Note Off (resulting in zero-length notes)
MIDIEditor_GetTake returns take object even if no take is active
MIDI_GetNote returns endppqpos different from visual appearance in editor
MIDI_DeleteNote ADDS note to another pitch
MIDI overlapping note issue


Zooming bugs
Double-clicking MIDI item doesn't open item fully expanded in MIDI Editor
MIDI Editor "Zoom to Content" ignores single row of high or low notes
MIDI editor auto-zoom bugs (constant unnecessary auto-zooming) [Fixed!]
Opening/closing docked MIDI Editor can cause irretrievable loss of arrange view vertical zoom


MIDI editor window management
Docked MIDI Editor not positioned correctly until resized
Toolbar buttons for child windows such as Event Properties and Humanize behave inconsistently
MIDI editor loses focus after closing script GUI or contextual toolbar
Shortcut key in docked MIDI editor doesn't work after clicking MIDI toolbar
Docked toolbar steals focus
MIDI editor resizes itself after creating new MIDI item

Child windows disappear offscreen: MIDI Problem Transpose and Selecting "View -> Transpose..." doesn't open the transpose dialog box
The disappearing window problem seems to involve two separate bugs:
* REAPER does not check the screen resolution before opening windows offscreen, and
* the "Cascade all floating windows" action does not work for some windows.
(This bug also affects non-MIDI windows such as the script/JSFX IDE, script GUIs, and the ReaScript console.)


Diverse
MIDI link parameter modulation: Parameter locked to last received MIDI CC value

MIDI feedback routing bug? (MIDI routing + audio feedback depends on track order)

MIDI editor: Actions that refer to "all" events are named incorrectly/inconsistently [Temporary workaround in thread]

MIDI Editor Key snap status incorrect after switching items

Undoing with Ctrl-Z causes notes to shorten, and cannot be undone [No RPP or MIDI for replication]

When very small sized, docked Virtual MIDI Keyboard octave transpose is buggy

Instrument definition file (.ins) parser bugs [FIXED!]

MIDI Editor Key snap status incorrect after switching items [FIXED!]

Strange doubling of MIDI events at top of FX chain when certain VSTs are added after

[Mordi]

Wow, that's quite comprehensive. Great work!

[Sju]

The toolbar context bug is still there apparently. (http://forum.cockos.com/showthread.php?t=137657)

Clicking on a docked MIDI toolbar button changes action context to Main.

Nice list btw! It seems to me like there are many small inconveniences/bugs in the MIDI editor, but I've learned to work around them. Gotta pay more attention and type them down and maybe report here.

[lowellben]

Thank you for making this thread.

[mccrabney]

yes, thanks for this summary. i've been watching your posts a lot (and scripts) and i think you're a very valuable person for those of us who use REAPER's MIDI editing functions. the following is not specifically addressed to you, but is regarding beta testing and REAPER forum etiquette in general:

don't take it personally that this thread got moved from Pre-release. my understanding is that the discussion there is strictly only for current pre cycle discussion. i've wrongfully posted there in the past and realize that it might seem like a good place to bring attention to the right people at the right time -- but the right people do read every single bug report posted. as such, the best possible thing you can do is exhaustively test bugs that affect you - multiple licecaps, multiple steps, multiple "and that's why this is bad" descriptions, etc. perhaps a "number of independent confirmations" could be referenced as well.

[juliansader]

Originally Posted by mccrabney

don't take it personally that this thread got moved from Pre-release. my understanding is that the discussion there is strictly only for current pre cycle discussion.

I posted in the Pre-release subforum since
1) the prototype thread, MIDI - a summary of important pending things, is in that subforum;
2) my compilation is not itself a bug report, but is intended as a discussion document for v2.25 pre-releases; and
3) I would like to update the thread during the 5.25 pre cycle.

Oh well, let's see how things go.

[lowellben]

Originally Posted by juliansader

I posted in the Pre-release subforum since
1) the prototype thread, MIDI - a summary of important pending things, is in that subforum;
2) my compilation is not itself a bug report, but is intended as a discussion document for v2.25 pre-releases; and
3) I would like to update the thread during the 5.25 pre cycle.

Oh well, let's see how things go.

Makes sense to me. Oh well.

[semiquaver]

excellent list.

...I think the thought is that newly introduced bugs, or regressions belong in the pre-release forum - I've seen Justin ask that older bugs be discussed elsewhere.

If any of these bugs are recently introduced or have recently re-appeared they could be reposted there.

[noise_construct]

But but, all these bugs have already been reported, seen and reviewed by the devs (as can be seen from their comments on the reports), transferred to their internal issue tracker and scheduled for fixing.

Right?

[Ulf3000]

Originally Posted by noise_construct

But but, all these bugs have already been reported, seen and reviewed by the devs (as can be seen from their comments on the reports), transferred to their internal issue tracker and scheduled for fixing.

Right?

yes but users should be aware of this don´t you think ?

thanx to op ...

[juliansader]

Woo-hoo! Go take a look at v5.25pre1's changelog!

I will provisionally mark the relevant bugs as "FIXED" in the list above, but everyone should please test and confirm the updates.

[hamish]

Thanks for your work not only in collating this list julian, but also in maintaining it. Great use of red. Seriously helpful for MIDI users.

[juliansader]

It seems that the 'micro scale' quantization bugs -- in which MIDI events are somehow displaced a single tick or less from their correct PPQ positions, and which have provoked several long and esoteric threads over the years -- are now fixed in v5.25pre3!

[vitalker]

Hello, Julian.

Could you please look into this one: http://forum.cockos.com/showthread.php?t=181277 ?

[snooks]

Originally Posted by juliansader

Zooming bugs
MIDI editor auto-zoom bugs (constant unnecessary auto-zooming)

Fingers crossed for this in 5.25... the requests for controllable zoom go back years.

[noise_construct]

Originally Posted by Ulf3000

yes but users should be aware of this don´t you think ?

thanx to op ...

What I mean is that this bug reporting system does not work. We shouldn't need to repeat these reports over and over and over and over for years or half a decade before they get noticed.

After reporting a bunch of bugs six (6) times in total in various forums before they got attention in a pre-release thread and fixed, I realized I have better things to spend my time on.

I appreciate julian's efforts, but I do think a professional software company should be capable of the modest amount of organisation it requires to handle an issue queue.

[ELP]

believe me, noise_construct
latest when bugs are really confirmed, they notice this.

And a bug report don´t need always and every time an comment from the
"We are great programmers, folks. We make the best software" REAPER Devs!!

If they find it important and or fits into the momentary Developer circle or whatever it would be fixed.

At least with REAPER..
like Ali always said "I´am the greatest!!" ^^

--
Other have an nice looking issue queue, make standard comments and at the end do nothing...
Or have only an selected testers circle and the masses never really know real bugs except they find one them self. Mostly it needs sometimes years before real bugs
are fixed... or never fixed
Believe me within cubase 8xx there is a "some say little others big" MIDI engine spider which was already there in cubase 2.0 Atari time

[lolilol1975]

OK, didn't see this list.
Please add
http://forum.cockos.com/showthread.php?t=181338

edit: FIXED

Maybe the FIXED bugs should be marked as such in the original list.

[juliansader]

In the final, epic Boss Fight of v5.25, the heroes have overcome a major bug that -- for seemingly inexplicable reasons -- caused ReaScripts and even MIDI-related SWS actions** to mess up note lengths or even freeze REAPER completely:

ReaScripts turning non-overlapping notes into extended notes [ALL FIXED!]
These bugs may also have something to do with notes ending in Note-Ons with velocity=0, instead of normal Note-Offs:
Using MIDI_SetNote with noSort=true to move notes onto same pitch [SOLVED!]
SetNote Bug on Not Overlapping Notes? [FIXED!]
MIDI_Sort extends non-overlapping notes that end in Note-Ons with vel=0 [FIXED!]

This bug fix will certainly improve users' confidence in scripts, and will open the wonderful world of ReaPack to more users.


** Such as SWS/BR: Enable "Ignore project tempo" for selected MIDI items and preserve time position of events (use tempo at item's start), which is essential for proper Timebase=Time editing of MIDI items.

[noise_construct]

Originally Posted by juliansader

Display bugs in piano roll
MIDI editor: Cannot grab note start to change length (various issues when notes start before item)[/url]

This was connected with the older behaviour with drawing note borders at item border (printing note start where it really wasn't), which has been fixed... sort of, the velocity handle start is still drawn at item border, but it's still much better now.

I don't think we should be able to grab note start from the item border, if the note starts earlier tbh.

[hamish]

Yes fantastic work by all concerned over 5.25!

I feel so much better about recommending REAPER now, and look forward to my next major MIDI projects.

[ELP]

BTW Stuck Notes and Stopping within the Range of the Note length

These can refers to overlapping Notes/Stopping within the range of overlapping Notes and some bad Plugin & also Hardware behaviors.

Some rare plugins and Hardware need for every overlapping "open"Note ON also one
Note Off event to "close" the Note ONs, which is not really the MIDI Standard.
One bad behavior VSTi is for example this newer Roland Sound Canvas VSTi.
So if you have three overlapping Notes, example "C4", and you stop the playback before the
"Normal" C4 Note Off events occur,
REAPER send one Note Off after pushing Stop for C4 instead of one for every open Note On in a row(as it would be if you not stop the playback in between Note ON to Note OFF.)
The result is that two #C4 Note OFF events for the same C4 Note are missing
and this VSTI example above get stuck.. -----meaning after Stop the playback in between overlapping Note ON/OFF..

I really thing many Stucks can only related to this VSTi/Hardware overlapping events behavior.

[noise_construct]

Originally Posted by ELP

believe me, noise_construct
latest when bugs are really confirmed, they notice this.

And a bug report don´t need always and every time an comment from the
"We are great programmers, folks. We make the best software" REAPER Devs!!

If they find it important and or fits into the momentary Developer circle or whatever it would be fixed.

At least with REAPER..
like Ali always said "I´am the greatest!!" ^^

--
Other have an nice looking issue queue, make standard comments and at the end do nothing...
Or have only an selected testers circle and the masses never really know real bugs except they find one them self. Mostly it needs sometimes years before real bugs
are fixed... or never fixed
Believe me within cubase 8xx there is a "some say little others big" MIDI engine spider which was already there in cubase 2.0 Atari time

Well, the others have significantly less bugs, so guess they are onto something.

Anyway, my main gripe is just unorganized approach. It doesn't value user time, and users do the testing for free for Cockos. Bug reporting becomes frustrating, when the reports are read only randomly, and we have no way of knowing if they are ever read or considered at all.

A real life example: I assembled a similar list like this from the surviving MIDI bugs I had reported during my time on these forums. I posted the list here, bumped it a few times, e-mailed it to support, and finally to a pre-release thread. This post in the pre-release thread was the first time to incite a dev response, which was "thanks for reporting, all valid, but not part of this release cycle, we'll get to them in next cycle".

Well, time passed by and next release cycle came, but these bugs weren't fixed, so I posted the list again- and got the exact same response. I informed them about this, they apologized and fixed all the bugs bar one, which I have reported again as I have no way of knowing if it's still on their lists.

Now I understand the amount of bug reports you get from a substantial userbase power/ab/using a complex, untested application. Extremely difficult to manage the amount of info, but this is exactly why software-assisted issue tracking exists. There is obviously administrative overhead involved in maintaining it, but sometimes work is boring, hard and lousy. I'd personally prefer not wasting the time of my customers, who in the end pay for it all.

A simple issue tracker with user verification threshold (need x users to verify a bug before devs need to take action) and vote-based priorisation recommendations for example, and a link to associated release so the reporters can (and should) test the fix.

Multiplying work just because the system/process is weak just doesn't really float in 2016, that's all I'm saying. It's an efficiency issue, and I question their choice to offload this on their customers instead improving their internal processes.

[ELP]

@noise_construct I understand you but
The more possibilities a program offers, the more little or sometimes bigger bugs may be present!

for me it is not really a problem

And REAPERs "thousands of possibilities" makes REAPER for me and many others clearly to the No.1 at the market

AUDIO & meanwhile also for MIDI

[EvilDragon]

So are we going to have a thread now for each point update? I don't think that's efficient.

You can rename the thread, you know? Edit the first post, it's right there.

[juliansader]

Originally Posted by EvilDragon

So are we going to have a thread now for each point update? I don't think that's efficient.

Not necessarily. In this case, I just felt that the first thread's bug list was getting too long and overcrowded. Better to focus on current bugs than long-solved ones.

EDIT: I merged the threads.

[juliansader]

Originally Posted by ELP

BTW Stuck Notes and Stopping within the Range of the Note length

These can refers to overlapping Notes/Stopping within the range of overlapping Notes and some bad Plugin & also Hardware behaviors.

If any of these bug reports regarding stuck notes have been fixed or solved, please let me know (in the relevant thread), so that I can mark the threads as fixed/solved/no bug.

[noise_construct]

Originally Posted by ELP

@noise_construct I understand you but
The more possibilities a program offers, the more little or sometimes bigger bugs may be present!

for me it is not really a problem

And REAPERs "thousands of possibilities" makes REAPER for me and many others clearly to the No.1 at the market

AUDIO & meanwhile also for MIDI

Yep, tons of features, no testing and only two developers is a solid base for bugs to grow, it's only natural. I'm just suggesting a more efficient method to report them, that's all. Even if users give their bug hunting time for free, it's still valuable time.

[noise_construct]

MIDI editor window management
Various inconsistent behaviors of child windows: Event properties window does not deactivate toolbar button.
MIDI editor losing focus: MIDI Editor - no focus (the FR Keep MIDI editor focused after opening and closing popup windows touches on the same issue)

Can't replicate "MIDI Editor - no focus", but the focus remaining in dropdown menus (and not in MIDI editor) after using them still remains.

See #3 here http://forums.cockos.com/showthread....61#post1735461

[juliansader]

Originally Posted by noise_construct

Can't replicate "MIDI Editor - no focus", but the focus remaining in dropdown menus (and not in MIDI editor) after using them still remains.

See #3 here http://forums.cockos.com/showthread....61#post1735461

I will update the links in the first post.

[G-Sun]

Thank you juliansader
for compiling this list!

Bug-reporting is a tedious task..

[lolilol1975]

I have a feeling this effort is very useful, as it makes it easy for developers to have an overview of the bugs that concern MIDI, and see which ones can easily be fixed and where there is an effort to make.

It's probably not stranger to the important number of bug fixes concerning MIDI in the last few versions.

[slum_x]

Originally Posted by ELP

BTW Stuck Notes and Stopping within the Range of the Note length

These can refers to overlapping Notes/Stopping within the range of overlapping Notes and some bad Plugin & also Hardware behaviors.

Some rare plugins and Hardware need for every overlapping "open"Note ON also one
Note Off event to "close" the Note ONs, which is not really the MIDI Standard.
One bad behavior VSTi is for example this newer Roland Sound Canvas VSTi.
So if you have three overlapping Notes, example "C4", and you stop the playback before the
"Normal" C4 Note Off events occur,
REAPER send one Note Off after pushing Stop for C4 instead of one for every open Note On in a row(as it would be if you not stop the playback in between Note ON to Note OFF.)
The result is that two #C4 Note OFF events for the same C4 Note are missing
and this VSTI example above get stuck.. -----meaning after Stop the playback in between overlapping Note ON/OFF..

I really thing many Stucks can only related to this VSTi/Hardware overlapping events behavior.

I have the problem with stuck notes on my Nord Lead 4, Nord Wave, NI Kontakt (vst) so it sounds weird if this is solely af hardware/vst plugin problem.

[viper-2]

I am having an issue with the newest update not loading my controllers. My NanoKontrol2 and Presonus faderport have disappeared.

[MikComposer]

Not sure if I see this in the list, but when you have two midi items, one short, and other long, with short on top somewhere in the middle, when you glue both, it will extend notes until they hit anther note or end of item.

[juliansader]

Originally Posted by MikComposer

Not sure if I see this in the list, but when you have two midi items, one short, and other long, with short on top somewhere in the middle, when you glue both, it will extend notes until they hit anther note or end of item.

I don't think this bug is in the list yet. If it has been reported, could you give me a thread reference?

[juliansader]

Thread updated for v5.27...

[G-Sun]

Don't know if this is on your list:
http://forum.cockos.com/showthread.php?t=182386

[X-Raym]

@juliansader
Thanks for keeping this post updated,
it is currently the only way we have to get an overview of which MIDI bugs are still present.

It remember me when REAPER had a proper bug tracker, which quickly allowed to see which bugs were still present etc...

I think everyone could benefit from a more modern solution (like github issue tracker), with visible tags, status filter, category archive etc...

What do you think of the closure of the old bug tracker ?
And do you think a modern bug tracker could be cool for REAPER users (and devs ?) ?