v5.95pre15 - August 30 2018 (more inside)

[vitalker]

v5.95pre15 - August 30 2018

• + Notation: pasting/inserting events via action goes to the selected track context [t=210542]
• + Opus: add options to encode 3-8 channel audio as discrete channels, bitrates specified per-channel
• + Elastique: update to 3.2.7
  >> could everybody please test all 3 elastique 3.2.7 modes
  (pro, efficient, soloist), on all available architectures
  (test 32-bit versions too even if you normally just use 64-bit)?
  also: please test both the icc18 builds and classic macOS builds.
  please post all related feedback (positive or negative) in the
  pre-release thread. thank you. -justin <<

Changelog - Pre-Releases

Generated by X-Raym's REAPER ChangeLog to BBCode

[SonicAxiom]

Opus multichannel rendering now works as expected with 8 channel files, thanks! What about other (higher) channel counts? I sometimes render (archive) entire live recordings I made in multichannel wave format as Opus multichannel files to save considerable amount of disc space. For instance, original wave recording may have been made as one 28 channel wave file.

1. Will rendering/glueing this to Opus keep the discrete channels intact?
2. Can the hitherto glueing issue occur with other multichannel formats?

.

[JHughes]

I see Opus will support 255 channels. Does that mean ReaDave can feed his 255 speaker Ambisonic rig with one file in Reaper?

[D Rocks]

Nice for Elastique!!

[RobinGShore]

All 3 Elastique modes seem to be working here on Windows, both 64 and 32 bit

[RobinGShore]

A problem (not really sure if it could be called a bug) related to the new envelope copying behavior: Say I have three items on a track and I select only the first and the last one, if I move these two items then the envelopes on the unmoved middle item get wiped out. This is esepcially problematic if I want to move some, but not all items from one track to another along with their envelopes, something I do fairly often.




I think there are a couple ways this could be handled. One solution would be to leave a copy of the original envelope behind when moving items to different tracks, another (probably better) solution would be for envelopes outside of items to only move if they are also within a time selection

[juliansader]

Originally Posted by RobinGShore

another (probably better) solution would be for envelopes outside of items to only move if they are also within a time selection

Agreed.

(In addition, *selected* AIs should also move along with selected MIs, whether or not "Envelope points move with media items" is enabled.)

[juliansader]

Originally Posted by vitalker

[*]+ Elastique: update to 3.2.7
>> could everybody please test all 3 elastique 3.2.7 modes

Is there anything in particular that we should look out for? (I couldn't find a changelog for Élastique 3.2.7.)

[Justin]

Originally Posted by JHughes

I see Opus will support 255 channels. Does that mean ReaDave can feed his 255 speaker Ambisonic rig with one file in Reaper?

we only support up to 64...

[Justin]

Originally Posted by SonicAxiom

Opus multichannel rendering now works as expected with 8 channel files, thanks! What about other (higher) channel counts? I sometimes render (archive) entire live recordings I made in multichannel wave format as Opus multichannel files to save considerable amount of disc space. For instance, original wave recording may have been made as one 28 channel wave file.

1. Will rendering/glueing this to Opus keep the discrete channels intact?
2. Can the hitherto glueing issue occur with other multichannel formats?

.

files with more than 8 channels used discrete channels previously, and old configuration presets use surround mode for 3-8 channels until updated (though new settings will be discrete). This issue is specific to Opus afaik.

[Justin]

Originally Posted by juliansader

Is there anything in particular that we should look out for? (I couldn't find a changelog for Élastique 3.2.7.)

Not really, just that it works properly

[Justin]

Originally Posted by RobinGShore

A problem (not really sure if it could be called a bug) related to the new envelope copying behavior: Say I have three items on a track and I select only the first and the last one, if I move these two items then the envelopes on the unmoved middle item get wiped out. This is esepcially problematic if I want to move some, but not all items from one track to another along with their envelopes, something I do fairly often.




I think there are a couple ways this could be handled. One solution would be to leave a copy of the original envelope behind when moving items to different tracks, another (probably better) solution would be for envelopes outside of items to only move if they are also within a time selection

Updating this to: 1) keep the new behavior when ctrl+dragging to copy and 2) when moving items (rather than copying), include the automation between the items provided there is no non-selected item between the items -- if there's a non-selected item in between, it will use the old behavior and only move the automation within the selected items.

[EvilDragon]

Originally Posted by Justin

we only support up to 64...

Why not increase it then?

https://forum.cockos.com/showthread.php?t=210491

[Justin]

Originally Posted by EvilDragon

Why not increase it then?

https://forum.cockos.com/showthread.php?t=210491

Maybe someday, but it would require touching a ton of code and converting various INT64 using things to use a different data type...

[EvilDragon]

Oof, that doesn't sound easy!

[Xenakios]

Originally Posted by EvilDragon

Oof, that doesn't sound easy!

Maybe make a C++ class that acts like an int with all the needed overloaded operators... (I know Justin hates operator overloading... )

[D Rocks]

when you have 255 speakers, I hope theres not a solo electricity outlet in your room lol

[Justin]

Originally Posted by Xenakios

Maybe make a C++ class that acts like an int with all the needed overloaded operators... (I know Justin hates operator overloading... )

That’s the easy part, the hard part is that a thousand places in various modules limit channel counts to 64 (eg a stack-local array of 64 pointers)...


also as the channel count gets higher the cache thrashing effects get more severe. Maybe 64 channels (per track) will be enough for anybody?

[RobinGShore]

Similar problem to my previous post:



Here the automation being wiped out isn't part of the original selection, so changing it to revert back to the old behavior when there is an unselected item between selected ones won't help things. Also in this case the problem would happen with cut and paste via action, not just by dragging.

Again this is something I could see myself running into from time to time, and since I usually keep most of my envelopes hidden, there's a high potential to screw things up without even noticing for a while. I'm really starting to think that moving/copying of "unaffiliated" envelopes should be tied to time selection not item selection, and that ultimately the long requested Area Selection feature (with the ability to have multiple non-contiguous selections) would be the best solution for all of this.

[alextone]

Originally Posted by Justin

Maybe someday, but it would require touching a ton of code and converting various INT64 using things to use a different data type...

Not trying to start a fight here, it's because I simply don't know.
Is this why there is a limit on midi ports in the linux version?

Alex.

[EvilDragon]

Windows version also has the limit of 64 ports. It's a 64-bit mask used (int64) so that's that.

Yeah, I know, it's a shame. Synth-based studios would go over that limit very easily.

[JHughes]

If the code ever does get refactored to include support for more channels, I wonder what the internal Reaper limit would be. 1024? 2048? Infinite channels? Does it matter?

[Xenakios]

Originally Posted by JHughes

If the code ever does get refactored to include support for more channels, I wonder what the internal Reaper limit would be. 1024? 2048? Infinite channels? Does it matter?

I suppose it could be made "as much as memory capacity allows", but that would likely come with some performance hit. (Apparently the current code uses statically sized arrays and such, the "unlimited" option would need heap allocations which can end up slower to access.)

[D Rocks]

And honestly 255 speakers... you guys know anybody really using that much?

[Xenakios]

Originally Posted by D Rocks

And honestly 255 speakers... you guys know anybody really using that much?

Well, it's not just about speakers, there might be some esoteric needs with Reaper internal routing too. (For example a mixer plugin that would handle dozens of surround sound channels...)

[Soli Deo Gloria]

[QUOTE=vitalker;2029442]v5.95pre15 - August 30 2018

• + Notation: pasting/inserting events via action goes to the selected track context [t=210542]

Hi Justin!

Just as you´ve been dealing with notation pasting/inserting, I´d like to say that it would be extremely useful to be able to set items/tracks for inserting events while the cursor is over the staves in notation view (that is, without having to jump to track list all the time when you want to change their status). That is badly needed, for example, for all of us who enter notes with a MIDI controller (in this case, jumping from staff to staff to enter notes here and there implies going to the track list again and again for each move). Unless I´m missing some magic functionality buried in the Action List, you can test for yourself what I describe.

Since I don´t see any action to set items for inserting events, maybe one which could be assigned to a mouse modifier could be the solution (for example, ALT + left clicking on a staff could set the corresponding item for inserting notes).


I hope you can take this into consideration. I´m not prone to ask for things lately and I know that this is not the place to do so, but that entry in the changelog was just too close to this topic...


Thanks for all, as usual, and greets!

[juliansader]

Originally Posted by Justin

Updating this to: 1) keep the new behavior when ctrl+dragging to copy and 2) when moving items (rather than copying), include the automation between the items provided there is no non-selected item between the items -- if there's a non-selected item in between, it will use the old behavior and only move the automation within the selected items.

If a user wishes to move automation that isn't directly below selected items, then automation before and after items may be just as important as those in-between.

I'm just spitballing here, but perhaps the criterium should be:
* if the time selection covers all the selected items, then copy/move all the automation in the selected area (before, in-between and after items);
* if the time selection doesn't cover all items, then follow the old behavior?

(In both cases, selected AIs move/copy with selected MIs.)

[juliansader]

Originally Posted by RobinGShore

Again this is something I could see myself running into from time to time, and since I usually keep most of my envelopes hidden, there's a high potential to screw things up without even noticing for a while.

In my own duplication scripts ("Duplicate items and automation in time selection of selected tracks"), I found it useful to optionally exclude hidden envelopes from duplication. This allows users to determine which lanes are duplicated and which are not, and avoids screwing things up without noticing.

[jm duchenne]

Originally Posted by vitalker

v5.95pre15 - August 30 2018
[*]+ Elastique: update to 3.2.7
>> could everybody please test all 3 elastique 3.2.7 modes
(pro, efficient, soloist), on all available architectures
(test 32-bit versions too even if you normally just use 64-bit)?
also: please test both the icc18 builds and classic macOS builds.
please post all related feedback (positive or negative) in the
pre-release thread. thank you. -justin <<

Alas, it hasn't change anything to the multichannel bug I have reported :
https://forum.cockos.com/showthread.php?t=181279

Could you take a look at it, at least to know if there is a chance that it will be solved at some point ?
Thanks.

[jm duchenne]

Originally Posted by Justin

That’s the easy part, the hard part is that a thousand places in various modules limit channel counts to 64 (eg a stack-local array of 64 pointers)...

also as the channel count gets higher the cache thrashing effects get more severe. Maybe 64 channels (per track) will be enough for anybody?

Perhaps that since we can already adress more than 64 ouputs with several 64 "master" tracks, is there some possibility to allow a kind of global routing to these tracks without changing all the internal structure ?

Some kind of "track bundle" that could group for example 2 64 tracks as if they were only one, and thus allowing to insert 128 channels plugins and files on it while in reality two invisible tracks/bus were used ?

I know that it can seem silly, but I am confronted to such questions for spatial sound installations.

[D Rocks]

I tested TimeStrecthing and Pitch Shiting samples today with the new release of Elastique and I did not notice any problems with it.

I did not know what to look for so maybe I missed something obvious but as far as I can tell, it was possible to pitch multiple times and end-up creating a new song.

[beingmf]

Elastique timing glitch seems to be gone! Phew, what a relief! Thanks