v6.27rc3 - April 6 2021

[STOP]

v6.27rc3 - April 6 2021

• * Includes feature branch: media item channel mapping
• + Project time offset: preserve maximum resolution when setting project time offset to edit cursor position [p=2428360]
• + Timeline: when displaying minutes:seconds and a project start offset exists, center ruler major tick marks on project time zero rather than the start of the timeline
• + macOS: add prefs/general/advanced option for window fullscreen button to activate fullscreen rather than OS fullscreen
• + macOS: add prefs/general/advanced options for rounded buttons and big sur listview margins

This thread is for pre-release features discussion. Use the Feature Requests forum for other requests.

Changelog - Pre-Releases

Generated by X-Raym's REAPER ChangeLog to BBCode

[Coachz]

Changelog link no worky ?
https://www.landoleet.org/whatsnew-pre.txt

[schwa]

https://www.landoleet.org/whatsnew-rc.txt

I think x-raym's changelog to bbcode script may need an update.

[BPBaker]

Originally Posted by STOP

[*]+ macOS: add prefs/general/advanced option for window fullscreen button to activate fullscreen rather than OS fullscreen

I'm running into an issue with this where after this advanced option is checked, then un-checked, the behavior doesn't seem to save the unchecked state--even after restarting. (On Mojave 10.4.6)

[vitalker]

Originally Posted by Coachz

Changelog link no worky ?
https://www.landoleet.org/whatsnew-pre.txt

When you'll open the site, you'll know why is that. Just to remind: there are no pre's anymore, only dev's.

[Rodulf]

What are this..." Includes feature branch: media item channel mapping"?

[rstockm]

macOS: add prefs/general/advanced option for window fullscreen button to activate fullscreen rather than OS fullscreen

\o/
Thank you very much for this one.

[vsgrt]

If i enable fullscreen on macOS, quit Reaper, and open it again, it opens in a glitched state where the menu bar is supposed to have been (with a gap at the top).
Then i need to deactive/activate fullscreen again to fix it.

[PhelixK]

+ macOS: add prefs/general/advanced option for window fullscreen button to activate fullscreen rather than OS fullscreen

Thanks for considering having both options available!

When unchecked, there’s two options: OS fullscreen from the application main window menu, OR, native fullscreen from within Reaper. Personally I prefer this setting in Prefs.

When checked, both options put Reaper into native fullscreen, however in rc3 the preference can no longer be changed (also reported by @BPBaker).

Tried resetting Advanced UI, restarting Reaper or running an older version to see if reset.
Setting osxdisplayoptions=0, or removing the line inside reaper.ini will bring back the OS FS mode.

When changing modes, I haven't encountered any glitches or gaps at the top.

macOS10.14.6

.

[vsgrt]

Ah, it was loading a screenset as "global startup action", and since i quit reaper in a fullscreen state, it loaded the pre-fullscreen screenset once i launched it again, but didn't load menubar (because that part is gone in fullscreen). So it was half-working

Saved my screenset in fullscreen, and everything is working now.

[X-Raym]

Changelog link in changelog formatting should be fixed for next release thread.

[nicholas]

Originally Posted by Rodulf

What are this..." Includes feature branch: media item channel mapping"?

In short, you can map channel outputs for individual media items or selections of media items.

Have a look at Item Properties, Channel mode, Open channel mapper.

First (incomplete and unpolished) draft of documentation (unformatted) is attached.

[juliansader]

+ Project time offset: preserve maximum resolution when setting project time offset to edit cursor position [p=2428360]

I'm glad that the devs are looking into this issue! There are many other examples of misleading rounding in dialog boxes.

+ Timeline: when displaying minutes:seconds and a project start offset exists, center ruler major tick marks on project time zero rather than the start of the timeline

* Time 0 and frame 0:0:0:0 do not fall on the same position -- is this intentional?
* Would it be possible to display the edit cursor position with more accuracy? Even if not in the ruler, perhaps in the help bar or transport?
* There is still the strange bug of Seconds and Minutes:Seconds displaying different values:



EDIT: Quoting from another thread:

Originally Posted by juliansader

* If project offset uses the full *time* precision and if ruler time 0 is set to the exact offset position,
* but frames and samples must start on a integer number at the project leftmost position,
* then frame 0 (or 00:00:00:00) will not correspond exactly to time 0,
* unless offset is an exact integer multiple of frame length.

Would this be a problem?

[cohler]

The timeline issue is a simple math problem of doing the integer (discrete) arithmetic correctly even though internally time is represented in 64-bit floating point. The sound files have discrete digital samples in them, so all calculations should be done so as to preserve sample accuracy which is a discrete integer math problem.

64-bit floating point (IEEE 754) format has between 15 and 17-digits of precision, and if a decimal string with at most 15 significant digits is converted to IEEE 754 double-precision representation, and then converted back to a decimal string with the same number of digits, the final result will match the original string. Furthermore, if an IEEE 754 double-precision number is converted to a decimal string with at least 17 significant digits, and then converted back to double-precision representation, the final result must match the original number.

At a sample rate of 384Khz the space between samples is 1/384000 seconds or 2.60416666666667E-6 seconds (to 15 significant digits) so if the cursor is within half a sample from 0 the timecode should read exactly 0. So in other words any time value of 0 +/- 1.30208333333333E-6 should read as exactly 0 to be sample-accurate.

There are 3600 seconds in an hour or 86400 seconds in a day (5 digits of precision), so as long as the timeline isn't much longer than 24 hours in a given project, you should be able to maintain complete sample accuracy across the entire 24-hour timeline.

Since the RPP format requires that we enter the timeline offset using fixed point (decimal string) it should be restricted to no more than 15 significant digits to ensure no change in the conversion process to and from floating point, and to maintain sample accuracy. Then the timeline 0 point is precisely maintained.

Here is a function that gives you sample accurate time code in the hh:mm:ss.ms:smp format:

hhmmss = function(t)
  local neg
  if t<0 then t,neg=-t,true end
  local mf,mc,sr = math.floor,math.ceil,_c.sg1("srate")
  local samples = _c.samples(t)
  local ss = mf(samples/sr); samples = samples - ss*sr
  local hh = mf(ss/3600); ss = ss - hh*3600
  local mm = mf(ss/60); ss = ss - mm*60
  local ms = mf(samples/(sr/1000)); samples = mf(samples - ms*(sr/1000) + .5)
  
  return string.format((neg and t>.1/sr and "-" or "")..(hh>0 and "%02u:" or "")..
    "%02u:%02u.%03u:%02u",_c.U(hh>0 and {hh,mm,ss,ms,samples} or {mm,ss,ms,samples}))
end

I should note that the _c.samples function returns integer number of samples in t; _c.sg1("srate") returns the sample rate as an integer; and _c.U is just an alias for table.unpack.

[cohler]

At high zoom levels, the timeline should be displayed with sample accuracy.

And given that the timeline offset can be any floating point number of seconds (and I would recommend limiting it to 15 digits of significance as explained above), the left edge of the timeline (which people here seem to like to call "start of Project" for some reason, although it has nothing to do with where one chooses to start their audio, which is the actual start of project) will not in general fall on a frame, millisecond, or even exact sample boundary.

What is important is that 0 falls exactly at 0 and then everything on the timeline will be sample accurate from left edge to right edge (as long as you don't go much over 24 hours at 384Khz).