search

reaper-oss / sws

The SWS extension is a collection of features that seamlessly integrate into REAPER, the Digital Audio Workstation (DAW) software by Cockos, Inc
https://www.sws-extension.org/
MIT License
455 stars 85 forks source link

SWS freeze function? #305

Closed Jeff0S closed 10 years ago

Jeff0S commented 10 years ago

From thoughtp...@gmail.com on June 12, 2011 01:48:55

Seeing as Cockos has a strange aversion to implementing this, is it possible to have an extension based freeze?

Yes, we can hack together 20 step macros for crippled freeze like functionality, but surely there's got to be an easier way!

If there was a simple action that amalgamates all of the background hassle I'm sure it would be greatly appreciated. :)

Original issue: http://code.google.com/p/sws-extension/issues/detail?id=305

Jeff0S commented 10 years ago

From jeffos...@gmail.com on June 12, 2011 06:38:22

will do (it'll run be faster but will most probably be added as a "SWS/Mercado_Negro" action due to intellectual property reasons ;-)

Status: Accepted

Jeff0S commented 10 years ago

From jeffos...@gmail.com on June 12, 2011 06:38:38

Owner: jeffos...@gmail.com

Jeff0S commented 10 years ago

From swstim on June 12, 2011 10:50:40

Jeffos, thanks for taking this one on as I don't have much interest in it. I tried this before GetSetObjectState existed and had issues; you will be able to do much better now.

It might be worth deprecating all my code for freeze functionality, I can mark the actions as such once you're done.

Do you think there's a way to lock the track controls, or at least warn on say FX/FX env changes?

Jeff0S commented 10 years ago

From musicbynumbers@gmail.com on June 12, 2011 13:01:01

This could be an interesting action here, how about storing the original track in the ini file for restoring on using the "un-freeze" action :)

(note the other reason I mention it is because it could then also double up as an "archive tracks" function later on! ;)

Jeff0S commented 10 years ago

From jeffos...@gmail.com on June 12, 2011 14:16:50

Following the OP, I was just thinking to integrating/improving MN's freeze macro.. But if we talk about undo, unfreeze, etc.. well, yes, something much powerfull based on GetSetObjectState() + persistance of unfreezed tracked (but in RPPs, mbn) is possible.

what to do? the true thing or a simple helper?

@Tim:

Do you think there's a way to lock the track controls, or at least warn on say FX/FX env changes? I didn't test but yes, I'm pretty sure we can lock the track. On my end, if we go for a "real" freeze, my idea was to also simply remove all FX and envs from the freezed track (but save everything in the RPP for later unfreeze, of course !). On unfreeze we could also probably clean-up rendered things.

Jeff0S commented 10 years ago

From jeffos...@gmail.com on June 12, 2011 14:51:03

ha ha! I guess I already know the answers to my Q above..

If we go for the true thing: ideas (*) are needed in this thread! .. begining with my idea of removing everything on freeze (i.e. post-fader render): if freeze/unfreeze is fast enough it could work no? what do you think?

(*) for ex., one of the recent freeze idea I liked was mikael's one: TCP/MCP freeze layouts.

Jeff0S commented 10 years ago

From musicbynumbers@gmail.com on June 13, 2011 19:26:05

That would be cool and then later on it could be used to create a "archived" section in the "resources" window! :)

where we use an action to "archive selected tracks" which would remove the tracks from the arrange, store them in the bottom of the project's RPP and put the track name (and any related track notes) in a list under "archived" in the resources window.

You can then right click the track to "restore" or simply drag and drop!

I would donate a good sum for this! :)

(now I'm going to sneak back off to my cave!)

Jeff0S commented 10 years ago

From swstim on June 13, 2011 19:29:39

Archive would actually be quite easy, and I actually would prefer it to be in the tracklist, see issue 177 . (It's your FR MBN!)

Jeff0S commented 10 years ago

From musicbynumbers@gmail.com on June 14, 2011 03:13:01

Cool! :) I forgot about that! Lol been too busy marking students work! ;)

Excited about it as if you do find time to do it, it's one of those "game changers" for me :)

Look forward to it at some point then when you have time! :) thanks!

Jeff0S commented 10 years ago

From thoughtp...@gmail.com on June 24, 2011 12:35:03

This will be huge for a lot of people, so it's great to see discussion on implementing this. After years of convoluted workarounds I think it would be better to do 'the real thing' if possible, rather than an amalgamated macro.

One important consideration which I'm sure you guys are aware of is speed. For this to truly be useful, only the required tracks need to be processed. If it takes the same amount of time to freeze a track as to render the whole project, that won't be much of a time saver.

Jeff0S commented 10 years ago

From d...@puzzlefactory.com.au on August 10, 2011 19:12:48

Hey guys, I'm a producer and engineer who's just transitioned to REAPER from Samplitude after over 3 years on their beta team. One of the reasons I left is due to the on-going problems with freezing.

I would be more than happy to offer any advice regarding implementation of a freeze function in REAPER.

Best regards, Dax Liniere.

Jeff0S commented 10 years ago

From d...@puzzlefactory.com.au on August 10, 2011 19:25:54

"If it takes the same amount of time to freeze a track as to render the whole project, that won't be much of a time saver."

Hi thoughtp...@gmail.com (sorry I don't know your name) To me, time-saving is not the most important reason to have a freeze function.

The reasons I use a freeze functions are: 1) To free up RAM (multiple intances of Mokafix pedal simulators and Kontakt instruments can use a LOT of RAM) 2) To 'lock in' an effect that has random elements in it's output. 3) To free up CPU - These days, computers are so powerful that this is hardly necessary.

As far as time required to process the single track, this should be much better now that Justin has implemented this: http://forum.cockos.com/showthread.php?t=84945 All the best, Dax.

Jeff0S commented 10 years ago

From jeffos...@gmail.com on September 12, 2011 04:52:37

native implementation is coming (see v4.03pre) => closing the issue..

Note about previous discussions: with my "limited" API power, I was going through a post-fader render + lock track solution (so that FX but also envelopes were removed on freeze) but the native "pre-fader" (but with post-FX render!) solution is much better: possible mix of frozen/unfrozen items, faders & envelopes still usable, etc.. Also for "track archives", it would now be better/easier to rely on those native freeze features..

Status: Done

Jeff0S commented 10 years ago

From jeffos...@gmail.com on September 12, 2011 04:58:59

Status: NoChanges