jcsteh
When reporting note lengths in the MIDI editor, OSARA doesn't currently factor in tempo markers (unless a tempo marker is positioned at the beginning of the project)
Reproduction steps:
- Create a project with a BPM of 120 and a 4/4 time signature.
- Insert a blank MIDI item, open the MIDI editor and insert an 8th note at bar 1, beat 3.
- Hit UpArrow or DownArrow on that note to verify that OSARA reports the note length as 50%. All good so far.
- Now insert a tempo marker at bar 1, beat 2, changing the BPM to 140.
- Here comes the bug. Revisit the 8th note you inserted, and you'll find that OSARA is now reporting note length as 43%. Expected behaviour would be that the note length is still reported as 50%, given that the note starts after the tempo marker.
I reckon this is an OSARA bug, because Reaper displays 50% in the Length field of the Event Properties dialogue.
Thanks in advance for any fixes. Shout out to Matej for the example.
Curious. Does the problem go away if you close and re-open the MIDI editor, or close and re-open the project? OSARA asks REAPER for time information, so I don't understand why it would be wrong.
Nope, neither of those things made a difference. Here's an example project: https://www.dropbox.com/s/3flmswsjxe6mycx/OSARA%20incorrectly%20identifying%20note%20length%20after%20tempo%20marker.rpp?dl=1
I think this is a bug in formatTime() when it is formatting a length. Without knowing a start and end time on the timeline it couldn't calculate lengths correctly when there are tempo markers. I think a new function is needed for calculating lengths that takes a start and end time. It would have to convert to beats before subtracting.
Alternatively it might be easier to get the note length directly from the ppq values.
I made another test today. I used the tempo envelope on the master track instead of tempo markers and the result is absolutely the same. It may not come as a surprise to you, but I wanted to post it here for the sake of completeness.
Alternatively, if fixing this on the REAPER side would be more appropriate, I can try and open a thread over at the Cockos forum. In that case, could you knowledgeable people tell me which REAPER API function would have to be updated? Many thanks.
This can be fixed in osara by using ppq position to calculate note length. I'll do it when I get some time.
@RDMurray, thank you. I have read your previous replies, but I did not really comprehend what they implied. :D For those who work with MIDI this is a pretty crucial feature IMO. As it is now its rather confusing, because after a tempo change one can't tell whether a given note has the desired duration or not, unless he or she opens the event properties dialog.
wouldn't it be better to report note lengths as qualter note, half note etc instead of trying to match the way it is shown in the event properties dialog? I think it would be more consistent if after inserting a quarter note it was reported as a quarter note. in event properties, a quarter note has length 0.1.00 in 4/4 time, but if you change the time signature to 6/8, the note length in event properties is 0.2.00. I could try to match that behavior in OSARA, but it would make it more complicated and I don't see the benifit.
For note lengths that aren't exact, I was thinking it could say something like "quarter note + 5%".
What do you all think?
I'm generally in, but I wonder whether there are any other scenarios that would need to be covered. For example, what would be reported if a given note was longer than a bar (perhaps even several bars)? To give just a basic example, what would get reported instead of something like "2 bars 3 beats 49%" (4/4) or "3 bars 2 beats 49%" (the same in 3/4). "2 whole notes + 3 quarter notes & 49%" is the friendliest thing I can come up with, but that's still a bit cumbersome (especially when not in 4/4).
I agree it's a bit cumbersome, but it would be the same regardless of the the time signature. As tempo markers can change the time signature, a single note could easily extend across a time signature change. I just tested it, and reaper doesn't have a solution to this either.
I wasn't really planning to have it say things like "4 hole notes + 3 quarter notes + 1 8th note + 3 64th notes + 7%" I was thinking more of restricting it to the note lengths you would find in music notation and then adding a percentage. So for your example it would be "2 hole notes +87%" regardless of the time signature.
Does anyone know how other DAWs and midi sequencers handle this?
Thanks for the clarification. I think that your approach could work. It could take a little bit of time to get a feel for the 'odd' durations, but all in all it seems like a pretty nifty solution. Especially considering that note extending thing you mentioned. I myself don't have any experience with other DAWs, but perhaps someone else will chime in. @ScottChesworth what do you think?
It's been so long since I've used any other DAW, I can't comment on how it's being handled elsewhere. I can relay Robbie's example above to observational users of Pro Tools and Logic though. Will do that and report back.
Thanks Scott. It would be interesting to know how they represent note lengths. Qws uses beats and ticks, where by beats they actually mean quarter notes. Reaper has a different (but still wrong) idea of what beats are; see this forum post for details of one way Reaper gets it wrong.
I'm starting to think that maybe just reporting it in quarter notes + percentage would be the best solution, avoiding the confusion people often seem to have with beats and barrs and hole notes.
In my opinion, this is your best suggestion yet. If we take my example again, 11 quarter notes + 49% seems ultimately more useful than having to think about how long 87% of a whole note actually is, because you instantaneously know that you almost have one additional eight note. I was wondering whether we couldn't have the best of both worlds by reporting whole, half, quarter triplet, eight, eight triplet and so on if a given note matched the corresponding duration exactly. Everything else could be reported based on your quarter notes approach, or so I thought. This could be nice for single note durations, but than again it could urge one to apply something similar to multiples of these durations as well and that would probably complicate things unnecessarily. To put it simply, my idea was to report "whole note, half note, quarter note triplet, eighth note, eight note triplet" ETC, but "4 quarter notes & 66%, 2 quarter notes & 50%, 1 quarter note & 33%, 8 quarter notes & 25%, 10 quarter notes & 80%". It may not be a good idea to mix it like this, but I wanted to put it out there. Any thoughts? Interesting thread BTW. I wonder if Reaper's behavior will ever change in this regard.
Ok, forget about what I said earlier. Here's what I found from googling other DAWs. Logic: bars,beats,ticks sonar: beats and ticks qws: beats and ticks
It looks like matching the values in the event properties dialog is the only sensible option.
The only response I got from asking around was about Pro Tools, which also reports bars beats and ticks. So yep, seems matching what's in the Event Properties edit field is gonna be the way to go.
I of course don't mind that either. And the advantage is consistency. One could argue that people would expect things being displayed in an uniform fashion whenever possible. How difficult would it be to implement though? I'm not a programmer, but it's odd that REAPER just doesn't simply pass the same info as seen in the event properties dialog regardless of tempo or time signature to Osara.
I think I can implement it. There's one case that causes a problem though and that is when ignore project tempo is checked in take source properties. There is a function in sws that can help with that however. @jcsteh how do you feel about depending on sws for correct output in this case? I would just assume that ignore tempo was unchecked in the case that sws was unavailable. I don't think anyone is using OSARA without sws anyway. The function required is BR_GetMidiTakeTempoInfo (). It is implemented by parsing the take state chunk.
@MatejGolian Unfortunately the API doesn't give us note length in any format, just start and end in midi ticks. This means project tempo and time signature have to be taken into account, and in the case that ignore tempo is checked the midi take can have a different tempo and time signature from the project.
@RDMurray, that explains it then. Thanks. In that casehaving a native API function seems a good idea. Than again I understand that adding it may not be top priority for the REAPER devs. I'll file a feature request for it when I'll have more time. I think it's at least worth a shot even if it doesn't get added.
@jcsteh how do you feel about depending on sws for correct output in this case? I would just assume that ignore tempo was unchecked in the case that sws was unavailable.
I'm okay with this as long as it behaves as best it can without SWS installed.
I don't think anyone is using OSARA without sws anyway.
Most users aren't. Interestingly, I currently am, but that's more out of laziness than anything else. I would still rather not have OSARA break completely without it, though.
@MatejGolian Unfortunately the API doesn't give us note length in any format, just start and end in midi ticks. This means project tempo and time signature have to be taken into account
I don't think you actually need to think about this, but an idle thought: This could get really interesting if notes span two bars with different time signatures. It's rare, but it does happen in obscure cases like some progressive rock/metal. :) That said, REAPER itself would probably produce some intriguing output for length in the properties dialog in that case.
I don't think you actually need to think about this, but an idle thought: This could get really interesting if notes span two bars with different time signatures. It's rare, but it does happen in obscure cases like some progressive rock/metal. :) That said, REAPER itself would probably produce some intriguing output for length in the properties dialog in that case.
I thought about it, but decided not to handle it, so if the time signature changes in the middle of a note it will break. Fixing this could get quite complicated because there can be any number of time signature changes and/or partial bars during a note.
Reaper doesn't even handle time signature changes before the note when calculating the values for the event properties dialog. It gets the start time wrong. I don't think OSARA should try to emulate this behavior.
It should work without sws, it just wont give the correct note lengths if ignore project tempo is checked.
Ignore project tempo would mess up note start times as well. I'm thinking I should probably fix this issue and then open another one for that. Ignore project tempo probably isn't used very much anyway.
Where are we at with this one chaps? Best I can tell, looks like there's a commit from @RDMurray that's yet to be merged?
I need to rewrite that code before it can be merged. Hoping to get round to it soon.
Gotcha. Adjusting the label to medium priority then. I'll also be assigning it to you once Jamie adds you as a contributor. Trying to keep things a little tidier and easier to track round these parts. :)