v5.50repre3 - August 12 2017
+ MIDI export: fix export when project start time is not zero [t=194713]
+ MIDI export: option to use timecode time rather than wall clock time for SMPTE offset [t=194710]

Thanks for these. Just did a quick test and seems to work as advertised.

Just a couple things. First, there's still a bug in the midi export when exporting a time selection. When exporting a time selection it exports the first tempo marker of the selection but also includes a marker of whatever the previous tempo marker was before the selection at the same measure number. So you end up with two tempo markers in the first measure of the selection (which is very problematic if those are two different tempos).

The second thing is more of a question. When exporting a SMPTE offset of a MIDI file, by definition it is going to be timecode, so having the option to export wall time is confusing to me. I can't think of a single instance when choosing to export a SMPTE timecode offset you would want wall time instead. I think it would be less clutter and less confusing if SMPTE export only exported timecode and not wall time which is a bit meaningless and will never be used, especially as it is not part of the spec. Thoughts?

The second thing is more of a question. When exporting a SMPTE offset of a MIDI file, by definition it is going to be timecode, so having the option to export wall time is confusing to me. I can't think of a single instance when choosing to export a SMPTE timecode offset you would want wall time instead. I think it would be less clutter and less confusing if SMPTE export only exported timecode and not wall time which is a bit meaningless and will never be used, especially as it is not part of the spec. Thoughts?

The SMPTE MIDI spec does not define non-drop timecodes, the only choices are 24,25,30, and 30DF. So providing the option to encode as wall clock vs timecode time seems to be sensible, depending on how the importing software is configured?

The SMPTE MIDI spec does not define non-drop timecodes, the only choices are 24,25,30, and 30DF. So providing the option to encode as wall clock vs timecode time seems to be sensible, depending on how the importing software is configured?

Right, I see what you are saying. I think the better way to deal with it is to have the first SMPTE offset checkbox be DF timecode instead of wall time and the second checkbox Non Drop as you have it. That way if you are in DF it exports the timecode start as expected. Otherwise, wall time as the default SMPTE offset is going to be the incorrect timecode start every time you export something in DF timecode. Also, if you are exporting ND and importing into another program, the only thing you are concerned about is a correct start time. The importing program only cares about the SMPTE offset flag at the beginning of the file, so even if there's a frame rate mismatch the SMPTE start will still be correct.

Since we are talking about SMPTE offset here, it needs to be SMPTE regardless, either DF (as default for the include SMPTE offset checkbox) or Non-DF with the second checkbox. Having the option for wall time is both confusing and dangerous IMHO as it has nothing to do with SMPTE.

Sorry, I'm just realizing it already does work correctly at DF frame rates (uses SMPTE not wall time). My apologies for not confirming that.

That being the case, I would go back to what I had said earlier. Just use one SMPTE offset checkbox for both DF and NDF. I'll do some testing on the SMF import side of things but I don't see it causing any issues.

If it is too much work or a hassle for Reaper to differentiate between DF or NDF on export then it's probably fine as is.

Runs on Raspberry Pi 2 and later, or on ARM Chromebooks in developer mode w/ Crouton...

This warms my heart! Thank you devs and all you Linux guys out there who have made this happen.

After having invested myself deeply into a platform that was a losing game (Atari ST, anyone?) I made the solemn vow to only invest my efforts into software that ran identically on "BOTH platforms". To see this open up to "ALL of the platforms" is exciting!