v5.71pre19 - February 6 2018

[typewriter]

v5.71pre19 - February 6 2018
+ Subprojects: move track to subproject copies markers/regions
+ Subprojects: move tracks/items to subproject copies grid/framerate settings
# Envelopes: save points with more significant digits to avoid region copy rounding errors [p=1950427]
# VST3: inform plugin of track channel count only when it changes [p=1950595]

[EpicSounds]

"+ Subprojects: move track to subproject copies markers/regions
+ Subprojects: move tracks/items to subproject copies grid/framerate settings"

that's awesome

[MRMJP]

Originally Posted by EpicSounds

"+ Subprojects: move track to subproject copies markers/regions
+ Subprojects: move tracks/items to subproject copies grid/framerate settings"

that's awesome

Perhaps inching towards being more mastering friendly though IMO REAPER has a long way to go before it will replace a true mastering sequencing DAW like WaveLab/HOFA/Sonoris etc.

I do love REAPER for the majority of the audio processing though via plugins and analog equipment.

[juliansader]

Originally Posted by typewriter

Envelopes: save points with more significant digits to avoid region copy rounding errors [p=1950427]

Unfortunately, this does not fix the bug reported by theFRSXT:

Originally Posted by theFRXST

Nor any of the tempo envelope bugs that I reported, such as:

Originally Posted by juliansader

[Allspice]

Originally Posted by juliansader

Unfortunately, this does not fix the bug reported by theFRSXT,

Nor any of the tempo envelope bugs that I reported:

If it helps at all, I noticed when I loaded the projects with those issues in this thread/bug-report in 5.71pre19 there didn't seem to be a difference in behavior.

I haven't been able to figure out if the tempo envelope stuff is limited to older projects or not, but it's still there in older projects.

Thanks for the region fix and the subproject feature!

[EvilDragon]

Originally Posted by juliansader

Unfortunately, this does not fix the bug reported by theFRSXT:

Hmmm, I tried making a similar envelope shape and it copied correctly. Perhaps this doesn't work with existing projects, but only on newly created envelope points (hence the word "save" in the changelog entry)?

[theFRXST]

Originally Posted by EvilDragon

Hmmm, I tried making a similar envelope shape and it copied correctly. Perhaps this doesn't work with existing projects, but only on newly created envelope points (hence the word "save" in the changelog entry)?

You can try with the project file i posted and report back if you'd like.

https://forum.cockos.com/showpost.ph...27&postcount=4

[schwa]

Originally Posted by theFRXST

You can try with the project file i posted and report back if you'd like.

With that project file, if you edit the envelope point at bar 17 to snap it to the bar (the bar it appears to already be snapped to), the bug should no longer appear.

The way the project is stored in pre18 and before, that envelope point position gets rounded to slightly before the bar. If the point is edited in pre19 and the project re-saved, its position should be on the bar.

[musicbynumbers]

+ Subprojects: move track to subproject copies markers/regions
+ Subprojects: move tracks/items to subproject copies grid/framerate settings

THANK YOU SO MUCH GUYS!!!

not to seem ungrateful but please please please consider two more subproject reasonably small improvements that would make an absolutely massive difference. Some areas of Subprojects are "kind of" broken because of the lack of these two FRs!

1 = File menu option to "create Proxy file for current project".

Not only would this mean that you can give any song you are working on a full preview in media explorer (so handy for my rough piano ideas) but also that (for example), an external composer on a joint film project can create a piece of music in his studio and then he can have the proxy file rendered locally so that when I import it my end (into the master project), I don't have to render the project myself when I don't have the same VSTs and plugins etc.

It also means that he can re-open and update the project/proxy without having to also open up the master file which saves massive time for both of us.


2 = A pop up box saying something like "Some Subprojects need Proxy files re-rendering." "Skip for now?" or "re-render?".

Could we have the option that when reaper discovers subprojects that seem newer than the actual proxy file to ask in a pop up box to "leave as are" instead of trying to re-render them?

This is because I'm doing a media project with someone at the moment via google drive where they are adding musical subprojects to the master project which is fine until google seems to update/break the dates on the music project's .RPPs which causes reaper to want to re-render automatically on loading the master project.

The issue there is that I don't have the right VSTs and plugins to actually render these subprojects locally so they end up "wrecked" with missing parts when what I would actually prefer is to at least have the old Proxy file intact.

These would 2 FRs would help so much!

Subprojects are one of the biggest reason guys in the games and linear media industry come over to reaper when I tell them how they work, their eyes light up!

[EvilDragon]

Those two subproject FRs seem pretty simple to implement, to me at least. #2 in particular just looks like an if-else thing where instead of just going ahead with rendering, you pop out a dialog asking if you really wanna do that.

[musicbynumbers]

Originally Posted by EvilDragon

Those two subproject FRs seem pretty simple to implement, to me at least. #2 in particular just looks like an if-else thing where instead of just going ahead with rendering, you pop out a dialog asking if you really wanna do that.

Indeed.

The 2nd one nearly caused a brain aneurysm as was up against a deadline, got some music updates via the composer but for some reason reaper still thought they needed updating and it trashed about 5 songs in the film and the composer had just left his studio for the weekend.

It was horrific watching reaper just load them up without asking and wiping over them one by one. argh!


To be honest though, it might be something more fundamental in subproject management that needs looking at as there seems to be something that causes reaper to want to re-render subprojects and I'm not sure if it is the date or something else..

[Luster]

Also a big thank you from my side for working on sub-projects. Have to agree with the above written. Additionally I would suggest some kind of possibility to rename sub-projects, especially for version-control, so you can step back to an older edit or just give the automatic created sub-project a meaningful name.

E.g.: You open up a sub-project and save new version of project, it breaks the link to the mainproject.

[EpicSounds]

Originally Posted by Luster

Also a big thank you from my side for working on sub-projects. Have to agree with the above written. Additionally I would suggest some kind of possibility to rename sub-projects, especially for version-control, so you can step back to an older edit or just give the automatic created sub-project a meaningful name.

E.g.: You open up a sub-project and save new version of project, it breaks the link to the mainproject.

number one reason I haven't been using subprojects.

[ferropop]

I promise I'm not being a dick about this!...it's just a good time to show some glaring differences and make a case for how important area selection is.

Apart from the fact that I had to create an empty item to even copy this splice of automation in Reaper...:

REAPER:


ABLETON:

[EvilDragon]

You could've done that by creating an automation item... No need to use an empty MIDI item at all.


I do wonder, though, if there's a way for Reaper to NOT approximate Beziers and break them down to that many points... it's obviously possible to just put two edge points and recalculate the slope/tension so that it matches the previous curve, Live is doing it, so there must be a way. schwa?

[ferropop]

Hey EvilDragon:



You're so weirdly against area selection lol, I just don't get it.

[musicbynumbers]

Originally Posted by Luster

Also a big thank you from my side for working on sub-projects. Have to agree with the above written. Additionally I would suggest some kind of possibility to rename sub-projects, especially for version-control, so you can step back to an older edit or just give the automatic created sub-project a meaningful name.

E.g.: You open up a sub-project and save new version of project, it breaks the link to the mainproject.

That would be nice.

I also want that but was trying to keep "demands" down

There's a big list of subproject requests that I've collated from various users over the last few years that really would be great to get addressed but happy to just have any of these fixed
https://forum.cockos.com/showthread....81#post1617081



.

[EvilDragon]

Originally Posted by ferropop

Hey EvilDragon:



You're so weirdly against area selection lol, I just don't get it.

Yeah, that's envelope curve approximation that Reaper does and has been doing for some time now. Has nothing to do with area selection at all!


But once again: area selection is a HUGE undertaking considering how Reaper handles selections, nobody should expect it in a minor point update - it affects too many things internally, and can break other things like SWS and most scripts out there. If it doesn't happen for v6.0, keep on waiting for v7.0 is all I can say.

[ferropop]

It's literally related to area selection lol I'm so blown away rn, no offense. Select and AREA, paste that AREA. Doesn't matter if it's automation, items, automation items, just duplicate that section without consideration for what's attached to what, is "follow envelope points" turned on, just --- duplicate this stuff over there exactly!

[EvilDragon]

No, it's not related to area selection. The reason envelope gets approximated is not because of lack of area selection at all, understand that. I'm being very clear here, not sure what's blowing you away. I'm blown away you're not understanding what I'm telling ya. I'm not against area selection, but I'm realistic in that it won't happen overnight, or perhaps not even for quite some more time to come. It doesn't seem to pick up devs interests at all.

[ferropop]

EvilDragon I respect that you've been around for a long time and super active on the forums, and clearly are super invested in the betterment of Reaper.

All I'm saying with my billion posts about Area Selection is that 1. it's sorely lacking.... 2. it's half-implemented already with Regions, seeing that the duplication is not ITEM based but rather AREA based because we don't get the interpolation stuff going on, and 3. I don't understand the resistance to Reaper implementing literally the most obvious version of selection that can exist, which is to create selection-boxes on a grid instead of all this item-point complexity.

[EvilDragon]

Originally Posted by ferropop

3. I don't understand the resistance to Reaper implementing literally the most obvious version of selection that can exist, which is to create boxes on a grid instead of all this item-point complexity.

It's not that devs aren't aware of the request. It was second most voted for feature request in the deprecated issuee tracker. For YEARS (issue tracker post dated in 2009, but there were threads on the topic before that even). There's obviously a lot of obstacles in making it happen. So it's not happening... just yet, or ever, time will tell I guess.

It's not "just" creating boxes on a grid. That is layman oversimplification without having any insight in how things are handled internally by Reaper, and how they tie in to all other stuff: the API, the extensions, the scripts, etc.

[ferropop]

Alright man, well if these two GIFs are the intended behaviour then I retract my posts.

[EvilDragon]

It seems to me that yes, for the time being, that is the intended behavior. Can it be improved? Most certainly, Bezier curves would need to be recalculated from the time selection start to the next actual envelope point, instead of being approximated by many points in between. This again doesn't imply that area selection needs to be implemented for this to happen! It's just a matter of what to do when an envelope within a time selection is copied elsewhere (either via moving an item copy, or an automation item).

My assumption is that it's much simpler/faster to approximate the curve (because math is much simpler to do a piecewise linear curve interpolation) than to try to plug in values to the Bezier curve formula from a different starting point, in order to get the result Live is getting.

schwa would know more about this for sure. But it's pretty apparent to me that this is the case.


And just to add - I also don't like these approximations. There is obviously a way to improve this if other DAWs don't need to resort to this kind of trickery.

[ferropop]

Originally Posted by EvilDragon

My assumption is that it's much simpler/faster to approximate the curve (because math is much simpler to do a piecewise linear curve interpolation) than to try to plug in values to the Bezier curve formula from a different starting point, in order to get the result Live is getting.

schwa would know more about this for sure. But it's pretty apparent to me that this is the case.


And just to add - I also don't like these approximations. There is obviously a way to improve this if other DAWs don't need to resort to this kind of trickery.

Agreed, but watch this though:

[ferropop]

Haha I wasn't actually trying to demonstrate that the right-hand point gets eaten up by the AI (bug?), but rather that just by trimming the AI endpoints you duplicate the curve without approximations, and that internally AIs could just behave this way.

[EvilDragon]

That's not a bug either. Normal behavior when you have underlying envelope enabled and not hidden. AI you created contains the necessary edge points so when you change AI's size, it can show what's necessary correctly.

In your example you contained EDGE points of the two Bezier sections WHOLLY. That's the important part. Reaper only approximates if you start your selection somewhere between two points that have some curvature on them.

[ferropop]

I'll duck out of the thread now, hopefully I left some points to consider (pun!). Any word from the amazing devs would be welcomed on this (and area selection). This is a demonstration of a single track/item -- now consider the implications of this destructive behaviour in a real project.

[EvilDragon]

BTW these are all things that were discussed way back around version 5.5 when automation items were introduced (so, not really related to the current prereleases). That last behavior is not a bug definitely. You should acquaint yourself with automation item vs underlying envelope options.

[ferropop]

Originally Posted by EvilDragon

That's not a bug either. Normal behavior when you have underlying envelope enabled and not hidden. AI you created contains the necessary edge points so when you change AI's size, it can show what's necessary correctly.

Ok I gotcha. The point was though that through edge manipulation, the correct curve is reproduced without interpolating.

[schwa]

The reason the envelope curve gets rendered into many points is that REAPER represents curve segments with a single "tension" parameter. If you split a curved segment in pieces, there is way to exactly represent each piece of the curve with a single parameter. You can see this if you just add a point to the middle of a curved segment and then try to fiddle with either half of the segment to make it look exactly like it did before -- usually, you can't.

We could avoid having to render the envelope curves if we either represented curve segments with more parameters, or just approximated the tension on either side of a new point.

This isn't an issue with automation items, because you can trim the edges to represent any piece of an envelope curve -- the extra "parameters" are, effectively, the envelope points that you can't see because they are not within the visible part of the automation item.

[schwa]

Originally Posted by schwa

This isn't an issue with automation items, because you can trim the edges to represent any piece of an envelope curve -- the extra "parameters" are, effectively, the envelope points that you can't see because they are not within the visible part of the automation item.

Like this.

[PitchSlap]

It would be great if the naming could be improved when moving tracks to subprojects (i.e. don't use the same naming format as recorded files).

Also unchanged subprojects re-render unnecessarily when when doing "save as" with the "copy media" option...

[svijayrathinam]

Originally Posted by typewriter

v5.71pre19 - February 6 2018
# VST3: inform plugin of track channel count only when it changes [p=1950595]

This only fixes part of the problem we have been having with the plugin channels. Having this turned off solves part of the problem but not fully. The bug still exists. When I recall FX chain preset it recalls it fine but the moment I hit play..the plugin pin settings change when it shouldn't change. Ideally it should preserve the plugin pin configuration when recalling from an FX chain preset. This is how it used to be in versions before 5.6. Can you pls fix this ?

Pls have a look at the video from the below link. You will see when "VST3: inform plugin of track channel count only when it changes" is turned off it preserves the settings inside the plugin but not the plugin pin settings. I really hope this gets fixed in the next release. This is an essential part of my workflow..

https://www.dropbox.com/s/1r1202e93i...%2019.mov?dl=0

[EvilDragon]

If it's essential to your workflow, you should be using 5.6 until everything is solid.

Also remember that schwa said that there's some work by iosono developer left to be done to fully fix those bugs. There's some new VST plugin handling introduced in 5.71 so a full revert to 5.6 behavior is not going to be possible (well, 5.71 will be released without that new handling, but work on it will resume thereafter).

[svijayrathinam]

Originally Posted by EvilDragon

If it's essential to your workflow, you should be using 5.6 until everything is solid.

Also remember that schwa said that there's some work by iosono developer left to be done to fully fix those bugs.

For your info...5.6 has a very bad video bug which was resolved only in the clang version but from that time..the VST channels issue popped up..So I cant stay with 5.6 because of the bad video issue (and I work in post production so video is very important). I do remember what schwa said..But it looks like the developers have done a great job and almost fixed it. There is only the plugin pin channel bug when recalled from fx chain or inserting a new IOSONO plugin. All I said was that "I hope this thing gets fixed"as they have sorted the issue with the plugin clearly..now the issue is in the plugin pin connector and I am only bringing that to the attention of the developers. I believe this is what the developers want with the pre releases. As one of the testers I am only reporting bugs when I come across something. I don't understand why you have to tell me off for doing this and sharing my opinions and workflows.

[EvilDragon]

Yes and you've been saying "hope this gets fixed" in nearly every prerelease thread so far. Devs are aware of it for sure when you constantly remind them like that (to the point of perhaps overzealousness?), but as schwa said, work on new VST handling will continue past v5.71 as 5.71 will be released without it (=5.6 behavior), so you might not get that fix in this prerelease cycle, but the following ones. It's also unconfirmed if clang version is going to go mainstream or not, for now, because a decent number of people are not reporting better CPU usage, but worse.

[svijayrathinam]

Originally Posted by EvilDragon

Yes and you've been saying "hope this gets fixed" in nearly every prerelease thread so far. Devs are very likely aware of the bug, but as schwa said, work on new VST handling will continue past v5.71 as 5.71 will be released without it, so you might not get that fix in this prerelease cycle.

"Evil" Dragon, as a honest and passionate reaper user..I am reporting a bug that I see. These pre release threads are there for exactly that reason. If you don't like this I am sorry but I will continue to test and report the bugs that I see. End of story. Thank you for your understanding.

[EvilDragon]

I'm just saying this to keep your expectations in check.

[svijayrathinam]

Originally Posted by EvilDragon

I'm just saying to keep your expectations in check.

THX..I will ..