A Bestiary of MIDI Bugs

[jmorel33]

Talking about Child Windows; should it be normal that the Quantize window absolutely need to be displayed in order to have Quantize ON ?

[ivansc]

X-raym: Agreed but I remember how the old one became a dumping ground.
Newbies who had meatware problems posting them as bugs, people galloping around on their hobby horses for pages and pages...
It would probably need someone specifically to vet user posts including comments.

Maybe not allow comments at all and only permit redirects to discussion threads?
If that were policed 100% it WOULD cut down on the spurious crap and make it easier for the devs to read and analyse.

[EvilDragon]

It might be the case that devs have their own internal tracker now and they're putting bugs that are actually bugs in it, at their own pace. Probably best way of doing it. I agree that the old tracker was not a good solution because lots of people abused it, or didn't know how to use it properly.

[noise_construct]

Or maybe they don't.

Systematic approach would save our time, and as long as we pay them and not the other way around, the time and effort contributed by users/beta-testers shouldn't really be treated with such a careless attitude as BR and FR forum sections are treated.

This chaotic mess of multiple forum posts on the same issues where 99% of threads get no dev response isn't the most efficient way. Now if they would do their own testing and QC, they could just delete these forums, but REAPER functioning depends on users reporting the bugs from final releases.

[juliansader]

v5.27 will soon be released, so the Bestiary has been updated for v5.28.

Sadly, the list of known MIDI bugs has actually *grown* during the v5.26 and v5.27 cycles.

A while ago on the KVR forums, when we were all still giddy from the many bug fixes in v5.25, I stated that "the devs are currently on a WoW-like raid quest to squash MIDI bugs, and if they carry on at the present rate, REAPER's MIDI may well be bug-free when we reach version 5.28". Now, two cycles later, it may seem that time is running out, but the dream of bug-free MIDI can still be achieved in v5.28 - the devs are great programmers, folks, they can do it!

[schwa]

Originally Posted by juliansader

the list of known MIDI bugs has actually *grown* during the v5.26 and v5.27 cycles

What bugs were introduced in 5.26 or 5.27?

[juliansader]

Originally Posted by schwa

What bugs were introduced in 5.26 or 5.27?

I do not know if any new bugs were introduced by REAPER's new features, but several (probably older) bugs were discovered.

Comparing the v5.25 Bestiary with this thread, I find the following newly discovered bugs (I may have missed a few):

Multi-channel MIDI editing
"Draw/edit CC events" mouse modifier buggy in multi-channel situations
"Edit CC events" mouse modifier buggy in multi-channel situations
"Move CC event on one axis only" mouse modifier buggy in multi-channel situations
Shorter (lower-valued) CC events are hidden behind taller (higher-valued) CC events

Mouse modifiers and editing actions
"Linear ramp CC events" does not work in velocity lane "MIDI CC event" context
"Adjust value for events (mousewheel/...)" does not work on Pitch

Tempo envelopes
Tempo marker on first beat of region does not move with region
Gradual tempo changes: gridline display/snapping and envelope pasting issues
Inserting new tempo point changes value of envelope at point

Lyrics
Lyrics don't work on 16th notes
Lyrics bug when note stretches past middle of measure
After editing lyrics several times, sometimes they can't be deleted

Creation of zero-length notes
Zero-length notes created when swapping MIDI Editor view or closing/re-opening MIDI item

Quantization (macro scale)
When just opened, Quantize window shows "Triplet", but "Straight" is applied

Diverse
Midi note name files not merging
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"

[schwa]

Well, new bugs will always get priority. But I don't think anything on that list is actually a new bug, just newly added to the list.

It is a great service to create and maintain this list -- thank you. I have gone through the first half dozen items on the list and responded in the relevant threads. Please be aware that some list items (like the first one on the list) are not clearly bugs with definable solutions.

[FnA]

I mentioned this in a different thread yesterday. I might just not be able to find the correct options.

There is an inconsistency between double clicking a note to switch items and double clicking an item in Arrange view to switch. Double clicking a note leaves the item as Editable. Double clicking the item leaves it as Visible (this is what I want, and accords with my settings IMO.)

One editor per project
Open all selected items
Active item follows selection changes in arrange view
Selection linked to visibility
--both in Prefs and in Tracklist menu. The wording involved here confuses me as to whether or not these are one and the same setting(s)

I think if the bold setting is in effect, it should revert to Visible. If selection is linked to Editability, it should be, then, left as Editable. (why an action for both of those now? I thought it was a toggle. They can, according to tracklist right click menu, both be on.)

[lolilol1975]

Just noticed: has this long overdue bug/feature request been overlooked in this bug list ? (which can be boiled down to: MIDI Thru is missing in Reaper)
MIDI timing in Reaper

It was asked for by a number of people in that thread (among which EvilDragon), and it appeared today in the french forum.
So following the 2009 thread, here are some threads that mention the issue:
http://forum.cockos.com/showthread.p...76#post1405876
http://forum.cockos.com/showthread.php?t=144134
http://forum.cockos.com/showthread.php?p=1752003

[juliansader]

Originally Posted by lolilol1975

Just noticed: has this long overdue bug/feature request been overlooked in this bug list ? (which can be boiled down to: MIDI Thru is missing in Reaper)

In order to keep things manageable, I have included only bugs in this list, not yet any feature requests. (Although I sometimes found it difficult to distinguish between the two.)

It would be nice to have a separate "Wishlist" of MIDI feature requests. If I am not too busy, I will try to compile such a list once the majority of bugs in this Bestiary have been fixed.

[karbomusic]

Although I sometimes found it difficult to distinguish between the two.)

It can be but the way it generally works is that if the code is doing what it is expected to do, even if it is or seems silly, it's a feature request.

If the behavior is not what the code is expected to do (via the person who wrote that code, aka not an end-user misinterpretation of what it should do), then it is a bug.

That subtle distinction is important from a development standpoint and often confuses, rightfully so but is important to properly categorize them.

[noise_construct]

Originally Posted by karbomusic

It can be but the way it generally works is that if the code is doing what it is expected to do, even if it is or seems silly, it's a feature request.

If the behavior is not what the code is expected to do (via the person who wrote that code, aka not an end-user misinterpretation of what it should do), then it is a bug.

That subtle distinction is important from a development standpoint and
often confuses, rightfully so but is important to properly categorize them.

Users can not know what code is expected to do, we don't have access to it. Neither is there any documentation of any features. Therefore if a feature does not behave as expected by users, it is a bug.

If this is undesirable, roll up your sleeves and man up- document your code. It is what would be demanded from you if you were employed by a software company.

[karbomusic]

Originally Posted by noise_construct

Users can not know what code is expected to do, we don't have access to it. Neither is there any documentation of any features. Therefore if a feature does not behave as expected by users, it is a bug.

It is more valuable for those users who are genuinely interested, especially when they are trying to compile an organized list (as evidenced by the OP's statement and this thread) how that decision is made and what the terms actually mean. Of course one has the right to remain ignorant of everything behind the curtain but the OP doesn't seem to be someone who wishes to exercise that right; hence the reason I provided 'them' the info.

[juliansader]

v5.28 has just been released and it is another humdinger for MIDI!

Most excitingly, all the known bugs in multi-channel editing has been fixed!**

I expect that users will find novel applications of these multi-channel features: If track routing or a JSFX is used to force all MIDI playback into a single channel, then the MIDI inside the track can freely be assigned to any channel, and channels can be used as all-purpose groups that can be independently edited, similar to FL Studio's "color groups".

** There are still one or two Feature Requests related to multi-channel editing that will hopefully soon be implemented.

[noise_construct]

Originally Posted by karbomusic

It is more valuable for those users who are genuinely interested, especially when they are trying to compile an organized list (as evidenced by the OP's statement and this thread) how that decision is made and what the terms actually mean. Of course one has the right to remain ignorant of everything behind the curtain but the OP doesn't seem to be someone who wishes to exercise that right; hence the reason I provided 'them' the info.

You're a smart fellow, but you're pretty deep into the cult and it somehow fogs your vision.

Every user who ever reports a bug is genuinely interested, compared to dozens or hundreds or thousands of those who encounter the same bug, but

a) know it's pointless
b) don't care
c) switch DAW


Cockos is no different from MS, Steinbeg, Adobe or Avid. Commercial enterprises. Do you think Adobe expect their users to keep bug logs for them, or compile lists of neglected bug reports?

[karbomusic]

Originally Posted by noise_construct

You're a smart fellow, but you're pretty deep into the cult and it somehow fogs your vision.

I'm describing how commercial enterprises have to deal with it internally and some users *are* interested in that. I can appreciate your reference to other companies since that process I described is decades old and used by every one of them including reaper, so it really has nothing to do with how I feel about Reaper or fog or cult or vision - it's just how the process works - Some like to know that, others don't - nothing more.

Do you think Adobe expect their users to keep bug logs for them, or compile lists of neglected bug reports?

^Of course not but it is off topic and irrelevant to my original post. I think you're projecting compared to my simply helping a member understand how bugs/feature requests get evaluated internally. That's really all there is to it - how do they get evaluated - the answer is academic so if someone happens to be compiling a list and categorizing them, that knowledge may be helpful to 'them'. Your idea that I'm somehow placing the onus on end-users is completely missing the idea presented not to mention false.

I'll leave it be for now because this debate probably doesn't belong in this thread.

[juliansader]

Updated for v5.29!

(There were so many bug fixes in 5.28 that I can now finally fit all bugs into a single post!)

[karbomusic]

Nice job.

[ivansc]

Originally Posted by noise_construct

You're a smart fellow, but you're pretty deep into the cult and it somehow fogs your vision.

Every user who ever reports a bug is genuinely interested, compared to dozens or hundreds or thousands of those who encounter the same bug, but

a) know it's pointless
b) don't care
c) switch DAW


Cockos is no different from MS, Steinbeg, Adobe or Avid. Commercial enterprises. Do you think Adobe expect their users to keep bug logs for them, or compile lists of neglected bug reports?

Saw you quoted and took you off my ignore list specifically to comment on this.

I for one dont give a damn what other users want/need/etc., I am more than happy to accept that someone has gone to the trouble of creating and maintaining a central repository for bugs in a specific area and that the devs are happy to use it.
Pragmatically, since you are still here and evidently still using Reaper, YOU are equally "deep in the cult" as you choose to describe it.
The phrase "dont bite the hand that feeds you" comes to mind.

Any enterprise always succeeds better by looking after the customers it has got and trying to retain them than worrying over those who try the product and move on.

Interestingly on the couple of occassions I have lifted you off my ignore list recently, I notice you have accidentally started posting a fair bit of decent advice and polite comment in with all the bile and vitriol. Scary!

[hamish]

This thread has been amazingly well maintained and props to julian.

[Lokasenna]

Was going to report a MIDI bug (quantizing won't shorten notes) when I stumbled across this. Nice work!

[sproost]

Just a minor thing and I hope I'm not repeating anyone, but it would make more sense if exporting midi would remember the last folder saved in.

Every midi export, even within 1 session, resets the base folder resulting in having to browse to the desired folder each time.

[Mordi]

Just discovered this thread. This is fantastic! Kudos to juliansader for keeping it updated.

[David Perry]

I looked at the first page and didn't see this OLD bug (first reported in 2010). Confirmed by me to still exist:

All muted notes in MIDI items disappear (seem to be deleted but maybe just hidden from view?) whenever any gluing is done involving the items.

This is a big problem, IMO because if you do any gluing, like for instance putting different phrase fragments together, you really can't hold any notes over as muted notes or you lose them. Makes muting much less useful.

[dimitris]

Originally Posted by David Perry

I looked at the first page and didn't see this OLD bug (first reported in 2010). Confirmed by me to still exist:

All muted notes in MIDI items disappear (seem to be deleted but maybe just hidden from view?) whenever any gluing is done involving the items.

This is a big problem, IMO because if you do any gluing, like for instance putting different phrase fragments together, you really can't hold any notes over as muted notes or you lose them. Makes muting much less useful.

Confirmed. Nasty bug. Has it really been there since 2010, or did it reappear?

[X-Raym]

@David Perry, @dimitris

All muted notes in MIDI items disappear whenever any gluing is done involving the items.

This is by design :/

But there is a script out there which allows glueing preserving muted MIDI notes.

Look for Script: Breeder_spk77_GlueTools.lua in Reapack.

It also allows to preserve color and other items properties.

[juliansader]

Thanks for letting me know - I have added the bug to the list.

Schwa mentions the reasoning behind the deletion of muted notes in the old thread Glueing midi items drops muted notes, but I also think that it should be changed.

[David Perry]

Originally Posted by X-Raym

@David Perry, @dimitris



This is by design :/

But there is a script out there which allows glueing preserving muted MIDI notes.

Look for Script: Breeder_spk77_GlueTools.lua in Reapack.

It also allows to preserve color and other items properties.

Ok, great, thanks. I'll look in ReaPack.

I can't tell if you're joking about it being by design, but if it is it shouldn't be.

[David Perry]

Originally Posted by juliansader

Thanks for letting me know - I have added the bug to the list.

Schwa mentions the reasoning behind the deletion of muted notes in the old thread Glueing midi items drops muted notes, but I also think that it should be changed.

Absolutely it should be changed. it makes no sense to delete anything you didn't tell it to delete.

Add this also to the list of Reaper defaults that make little sense.

I adore Justin and wish no ill on him but I've felt and still feel he doesn't understand MIDI very well. I hope that evolves in a better way.

[EvilDragon]

It IS by design (as explained by schwa there). And it does make sense. When you glue audio items, some of which are muted, would you expect them to be unmuted in the glued result? Of course you wouldn't - doing such glue operation will result in only audible items being glued, and those that are muted will be silent (as expected). This is just MIDI following the same line of thought.

Also Justin isn't the one doing the MIDI side of the things, for the greater part, it's schwa.


Well thankfully it can be worked around with scripts, so...

[David Perry]

Originally Posted by EvilDragon

It IS by design (as explained by schwa there). And it does make sense. When you glue audio items, some of which are muted, would you expect them to be unmuted in the glued result? Of course you wouldn't - doing such glue operation will result in only audible items being glued, and those that are muted will be silent (as expected). This is just MIDI following the same line of thought.

Also Justin isn't the one doing the MIDI side of the things, for the greater part, it's schwa.


Well thankfully it can be worked around with scripts, so...

I still disagree. What is the purpose of muting anyway? Why not just delete all notes you want to be silent to begin with? Why even use muting?

Obviously if you have any purpose to use a mute function this isn't something you want the software to decide for you if that mute state will be preserved AS YOU designated it. You want to decide that yourself (i.e. whether or not to preserve muted notes) and that includes before and after a gluing function.

I glue clips ALL the time in the process of joining sections of work together and I DO want to preserve muted notes for possible future use even after gluing. Without the workaround this would be a serious problem for me. It's not something I've used in the past but I plan to use it in the future based on some new uses for muted notes I have.

As to the point of Justin not handling MIDI development personally, that reinforces my point. I wish he personally was more aware/motivated to develop and understand the MIDI and sequencing side of his product. I feel it wouldn't be in the partially formed (and bug filled) state it lingers in for years if he was more involved.

[EvilDragon]

Well, and there you have it, v5.32 will preserve muted notes when glueing/consolidating.

[cjaxis]

Steps to reproduce:

1. Start play and then press record MIDI, so left edge of MIDI item not start on grid division.
2. Quantize recorded notes 100% by grid.
3. Zoom in maximum to left edge of any quantized note.
4. See that note start is not on grid, a bit earlier or later.
5. Snap left edge of item to grid and glue.
6. Now see on notes like in p.4 - they now start on grid.

[carbon]

Docked MIDI Editor not positioned correctly until resized:

http://forum.cockos.com/showthread.php?t=186493

EDIT: Happens only if a second monitor (a TV) is connected via HDMI.

[juliansader]

Originally Posted by cjaxis

Steps to reproduce:

1. Start play and then press record MIDI, so left edge of MIDI item not start on grid division.
2. Quantize recorded notes 100% by grid.
3. Zoom in maximum to left edge of any quantized note.
4. See that note start is not on grid, a bit earlier or later.
5. Snap left edge of item to grid and glue.
6. Now see on notes like in p.4 - they now start on grid.

This is not actually a bug: As per MIDI specifications, MIDI events can only fall on discrete tick positions, counted from the start of the item. So if your item does not start on a grid position, the ticks *inside* the item may not correspond to the project's grid.

More info in Comprehensive ELP MIDI rounding problem thread (FIXED) and Error MIDI editor in Reaper (FIXED).

[dimitris]

Originally Posted by juliansader

This is not actually a bug: As per MIDI specifications, MIDI events can only fall on discrete tick positions, counted from the start of the item. So if your item does not start on a grid position, the ticks *inside* the item may not correspond to the project's grid.

More info in Comprehensive ELP MIDI rounding problem thread (FIXED) and Error MIDI editor in Reaper (FIXED).

Hi,

Tick sync is understandable but in which case item-based ticks are more beneficial than project-based ticks? The distinction seems to cause problems only. To overcome, lots of tedious work is needed... max zooming in and out, snapping items to grid lines, etc.

Thanks,
Dimitris

[X-Raym]

@juliansader
A bit of topic,
but your MIDI Bestiary thread inspired me a ReaComics Strip :P
Cockos Confederated Forums - View Single Post - ReaComics: A WebComics about REAPER and its community
Thx again for your work with MIDI bug reports !

[juliansader]

Woohoo! I have been immortalized in a comic!

If all REAPER's MIDI bugs get fixed, will my character gain a superpower?



"Don't lose hope Julian, they may be working on your MIDI bugs at this time, as we speak."

[X-Raym]

Originally Posted by juliansader

If all REAPER's MIDI bugs get fixed, will my character gain a superpower?

We don't know julian, we don't know... :P