Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER General Discussion Forum

Reply
 
Thread Tools Display Modes
Old 08-27-2021, 12:36 PM   #81
COCPORN
Human being with feelings
 
Join Date: Jan 2008
Location: Oslo
Posts: 175
Default

Quote:
Originally Posted by Pashkuli View Post
Not at all. I am learning about it. I use FLAC for my music collection (I've got probably 500 CDs).
I assume it is only a container (zip) but it can be lossy as well, depending on the compression used.

I was being really serious:
Can't we include the lazy GPU in this process of encoding\decoding?
Freaking shitcoin miners do it. I really do not know, but seems plausible to me.

I really would love this GPU to do some heavy work for audio production.
After all it is just data flow. The chips know nothing about sounds and pictures.

My ideal setup would be as such:
CPU, RAM, GPU

CPU: for normal things (OS calls and such), over-sampling for DSP

RAM: for temporal storage and allocation of data (that is why I have my own customised Windows 10 Pro - stripped down version, which is only 2.2GB and after installation takes up 8GB and 1.2 GB of RAM, 92 processes at idle state).

GPU: I want this quite substantial chunk of metal and PCB to do some work while working with audio (not playing games, not VFX\CAD rendering at the same time). THis shit should be able not only to render the GUI of my DAW and plugins, but also allocate some big data execution instructions such as real-time conversion of audio-data and the aforementioned "auto-freezing"?

Can it be done? I do not know.
If a "genius" such as Steve Jobs could not demand to the Apple employees to do it... so it probably can not be done! Huehuehuehue.

Hello, friend!

What I am suggesting will just work with absolutely anything. With minimal (hihi) effort on the developer's part.

If you start adding the GPU it would need plugins to be rewritten. And I really do not see the reason for it, as what I am suggesting would make it unnecessary.

There is no heavy work for the GPU to handle if you consider my thing. Even if you utilize a GPU for highly tuned processing/modelling, what I am suggesting will just automatically offload it.

Goodbye (for now), friend!
__________________
https://www.cocporn.com
COCPORN is offline   Reply With Quote
Old 08-27-2021, 02:30 PM   #82
Kenny Gioia
Human being with feelings
 
Kenny Gioia's Avatar
 
Join Date: May 2010
Posts: 3,929
Default

Quote:
Originally Posted by COCPORN View Post

What I am suggesting will just work with absolutely anything. With minimal effort on the developer's part.
No offense meant but when I read these types of statements I'm sure you don't know what you're talking about.
Kenny Gioia is offline   Reply With Quote
Old 08-27-2021, 06:58 PM   #83
thevisi0nary
Human being with feelings
 
thevisi0nary's Avatar
 
Join Date: Nov 2011
Posts: 367
Default

There isn't a practical scenario where this would be beneficial. People freeze tracks for utility, not for performance because it isn't faster.

If you're experiencing stutters with large vsti projects, then spend your $1000 on a 2nd computer and offload the work with VE Pro.
thevisi0nary is offline   Reply With Quote
Old 08-27-2021, 08:34 PM   #84
n997
Human being with feelings
 
Join Date: Dec 2018
Posts: 401
Default

Quote:
Originally Posted by COCPORN View Post
If REAPER was open source I could probably implement this myself in about 12 years.
I'm not sure, but somewhere on git (or in SDKs, or on the web in general) there could be source code available for a basic DAW with VST hosting.

If you could provide a proof of concept with measureable results, developers of DAWs might be more interested in the idea.


Also, I'm not sure if it has been mentioned yet, but REAPER already has "Anticipative FX processing" which includes "rendering ahead". I don't know how comparable it is technically to what you describe, though.




Quote:
Originally Posted by thevisi0nary View Post
There isn't a practical scenario where this would be beneficial. People freeze tracks for utility, not for performance because it isn't faster.
Well, in my workflows at least, freezing is used primarily to reduce CPU load. Otherwise I try to avoid rendering to "printed audio" mid-project, in case something needs to be changed at a late stage (as often happens, for whatever reasons).



***


For what it's worth, if the idea in this thread can actually be realized and would work seamlessly (no waiting for spinning beachballs or hourglasses after clicks and other user actions) then of course, as a user I'd welcome it.

For example, it would be wonderful to be able to use portable, fanless Windows tablets for moderately heavy projects.
n997 is offline   Reply With Quote
Old 08-27-2021, 08:42 PM   #85
Dex
Human being with feelings
 
Join Date: Sep 2017
Posts: 417
Default

The problem with all the suggestions of manually freezing, or using a script to automatically freeze and unfreeze things, is that FREEZING LOCKS REAPER while the freezes are rendering. You can't do anything while Reaper is freezing your tracks.

The whole point of the OP's suggestion is to have a low-priority background thread constantly "freezing" things without blocking you from working on your song. During playback, if you change something on a "frozen" (memoized) track, Reaper would discard its memoized version of the track and immediately switch back over to its normal realtime processing until it has a chance to memoize the track again.

I can think of no reasonable downside to memoization, as the OP has suggested.
Dex is online now   Reply With Quote
Old 08-27-2021, 11:00 PM   #86
thevisi0nary
Human being with feelings
 
thevisi0nary's Avatar
 
Join Date: Nov 2011
Posts: 367
Default

Quote:
Originally Posted by Dex View Post
The problem with all the suggestions of manually freezing, or using a script to automatically freeze and unfreeze things, is that FREEZING LOCKS REAPER while the freezes are rendering. You can't do anything while Reaper is freezing your tracks.

The whole point of the OP's suggestion is to have a low-priority background thread constantly "freezing" things without blocking you from working on your song. During playback, if you change something on a "frozen" (memoized) track, Reaper would discard its memoized version of the track and immediately switch back over to its normal realtime processing until it has a chance to memoize the track again.

I can think of no reasonable downside to memoization, as the OP has suggested.
Not saying it’s impossible but it’s sort of pedantic, you are trading one cpu expense for another since it’s constant rendering instead of real time playback. It’s also wasted cpu resource if it applies to a track you are currently working on / editing, as it’s creating and generating audio to immediately be replaced. The sound also needs to come from somewhere so reaper would essentially need to make a duplicate of the track if you want it to create audio while still having access to that track.

Maybe automatically freezing tracks in the background that haven’t been touched for X period of time could be helpful.
thevisi0nary is offline   Reply With Quote
Old 08-28-2021, 12:31 AM   #87
akademie
Human being with feelings
 
Join Date: Mar 2007
Posts: 2,473
Default

Quote:
Originally Posted by Dex View Post
...<snip>
During playback, if you change something on a "frozen" (memoized) track, Reaper would discard its memoized version of the track and immediately switch back over to its normal realtime processing until it has a chance to memoize the track again.
<snip>...
I would say it is almost impossible because Reaper would have to put offlined FXChain back to online, which requires loading all plugins (AND ITS SAMPLE CONTENTS eventually) back into memory - so it would take few/many bars when ready to be online again for the realtime tweaks which occured actually those few bars back in time already

Last edited by akademie; 08-28-2021 at 01:24 AM. Reason: typo
akademie is offline   Reply With Quote
Old 08-28-2021, 07:04 AM   #88
Pashkuli
Human being with feelings
 
Pashkuli's Avatar
 
Join Date: Jul 2006
Posts: 1,694
Default

Quote:
Originally Posted by akademie View Post
I would say it is almost impossible because Reaper would have to put offlined FXChain back to online, which requires loading all plugins (AND ITS SAMPLE CONTENTS eventually) back into memory
The premise of this idea is that they are already in the memory (RAM) or in real-time execution by the CPU from the moment you press Stop\Play, pre-buffered, cached whatever it is.

This would require a knowledgeable Computer Science engineer to delve deep into it. We are just chatting about it, contributing almost 0 to eventual implementation.
__________________
♦ video → .: Pashkuli Keyboard :.
♦ instagram → @pashkuli.keyboard
Pashkuli is offline   Reply With Quote
Old 08-28-2021, 07:09 AM   #89
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,593
Default

If the track has time-based FX such as reverbs and delays, I'm not sure that it would be possible to switch back in real time.

Another potential problem is the fact that plugins (VSTs as well as JSFX) can communicate with plugins on other tracks, and there is no way for REAPER to know which plugins and which tracks are communicating. These tracks will not memoize correctly if pre-rendered individually.

Perhaps the user can manually indicate which tracks should be automatically memoized?


Nevertheless, if the OP's suggestion can be implemented, it seems like a great idea to save resources.
juliansader is offline   Reply With Quote
Old 08-28-2021, 07:19 AM   #90
COCPORN
Human being with feelings
 
Join Date: Jan 2008
Location: Oslo
Posts: 175
Default

Quote:
Originally Posted by Kenny Gioia View Post
No offense meant but when I read these types of statements I'm sure you don't know what you're talking about.
That is fair. Of course, listening to a no-face-stupid-name nobody takes a leap of faith. I fully understand and respect that.

Background: I have worked as a professional developer on three continents since the nineties and I have worked with eCommerce (North Europe's largest solution at one point in time), point-of-sale, as a CTO, and recently been instrumental in vaccination planning writing key parts in Norwegian COVID-passports. My CV is long and my list of successes is relatively long. If I walk 250m in any direction from my apartment dead center in Oslo, there is a chance that I will pass one or two things I have helped make. I have coded C++ for a number of years and my specialty right now is high performance and low latency solutions that scale wildly. It is not important that you or anyone believe me or have an opinion about my pedigree.

It is fair that you know that I don't know what I am talking about. I am not a relativist, but an opinion, however uninformed is something you are welcome to.

You have to read what I am actually writing, in context. I am suggesting that I could probably do it in 12 years. I have only ever written a single VST using IPlug and a couple using JUCE. But I am comparing this to the work the REAPER team already does, and in that comparison, it is not particularly complicated. I like to attack the hardest parts of systems development first, and as far as I can tell, the hardest parts about this have already been tackled. If there is a huge oversight on my part, please let me know.

When I consider it "minimal" I compare it to the huge, huge benefit this brings to me. My previous workstation could chug through any project that I currently have and then easily double it. That would save me $5000. I would not get a new soundcard. That would save me another 1000.

I have updated my blog post about it, but this is the gist. As far as I can tell it will (in addition to all the stuff we've already talked about):

- Increase stability (no need to load VSTs that are potentially flawed, REAPER still crashes for me at least once a week)
- Startup time (no need to load VSTs that are heavy, they can be lazy-loaded, that is, they will be loaded when you open them)
- Latency (Nothing that is hogging the RT CPU that is doing the same time it has done 10,000 times before with the exact same outcome), so you can basically sum already computed things with stuff from the live channels
- Audio quality: Because the CPU is offloaded by doing something once instead of 10,000 times, you can actually make plugins that model things more closely at the cost of CPU and it will still just work. This also goes for constantly oversampling
- Deterministic MIDI playback, today the playback in REAPER is not deterministic depending on if you put the play-head in the middle of a MIDI-item. This is probably true for all DAWs and super irritating in loops.

You don't need to believe me, and this is why I have the bounty out.

My prediction is that most DAWs will do this by 2025 and the ones that are left will be dead by 2030. As always happy to take any wagers on this, as it will potentially help me cover the bounties.

Again: If you are happy with a workflow where you manually freeze, good for you! If you are happy with going to Blockbuster to rent the 14th season of Lost, great for you!
__________________
https://www.cocporn.com
COCPORN is offline   Reply With Quote
Old 08-28-2021, 07:23 AM   #91
COCPORN
Human being with feelings
 
Join Date: Jan 2008
Location: Oslo
Posts: 175
Default

Quote:
Originally Posted by juliansader View Post
If the track has time-based FX such as reverbs and delays, I'm not sure that it would be possible to switch back in real time.

Another potential problem is the fact that plugins (VSTs as well as JSFX) can communicate with plugins on other tracks, and there is no way for REAPER to know which plugins and which tracks are communicating. These tracks will not memoize correctly if pre-rendered individually.

Perhaps the user can manually indicate which tracks should be automatically memoized?


Nevertheless, if the OP's suggestion can be implemented, it seems like a great idea to save resources.
You bring up valid points. Making a track "go live" would indeed make a skip because the internal state of the VSTs in the relevant tracks would not be aligned with the auto-frozen tracks. For me this is not at all an issue, but I can totally see how it could be for others.

I also know that plugins can do IPC "behind the scenes", I use smart:EQ3 a little and I know it does this. I haven't considered this scenario, and it is definitely a problem. I am not sure how common the problem is, but it is definitely a source for woe if you are unaware of it.

Stuff like Trackspacer would work perfectly, however, as it has deterministic playback.

Good points!

EDIT: BTW, as I mentioned before, you already do not have deterministic playback in REAPER or any DAW that I know _while editing_, because depending on where in a MIDI item you start (as in, before note-on and note-off), the results will vary wildly. So you're sort of already used to the issue with time based effects. The IPC I am not sure of how to handle, to be honest, very valid case I didn't think of. The simple way of "fixing it" would be to manually exempt a track from ever freezing, or perhaps maintain a list of plugins that cannot easily be autofrozen. I cannot think of many more than smart:EQ 3 and some of the Nectar stuff off the top of my head, but I am sure you can.
__________________
https://www.cocporn.com

Last edited by COCPORN; 08-28-2021 at 07:37 AM.
COCPORN is offline   Reply With Quote
Old 08-28-2021, 07:28 AM   #92
COCPORN
Human being with feelings
 
Join Date: Jan 2008
Location: Oslo
Posts: 175
Default

Quote:
Originally Posted by akademie View Post
I would say it is almost impossible because Reaper would have to put offlined FXChain back to online, which requires loading all plugins (AND ITS SAMPLE CONTENTS eventually) back into memory - so it would take few/many bars when ready to be online again for the realtime tweaks which occured actually those few bars back in time already
If you go into your mastering chain and BYPASS MD4 HD, Blyss, Gullfoss, Limitless, Weiss DS-1, you will see the CPU and PDF seamlessly return to 0% and 0. This would conceivably be the same with my suggestion, except what juliansader mentions earlier. You don't _need_ to lazily load VSTs, you just can.

You can actually choose to progressively load VSTs in the background while playback is immediately available on project load, so you "get the best of both worlds"; immediate loading times and full access to VSTs. Again, just slap it in a priority queue and playback from the proxies. Everything is a tradeoff, however.

But keep in mind it would only have to load it if you actually decide to edit the track again. So that might be never.
__________________
https://www.cocporn.com
COCPORN is offline   Reply With Quote
Old 08-28-2021, 07:48 AM   #93
COCPORN
Human being with feelings
 
Join Date: Jan 2008
Location: Oslo
Posts: 175
Default

Quote:
Originally Posted by juliansader View Post
Another potential problem is the fact that plugins (VSTs as well as JSFX) can communicate with plugins on other tracks, and there is no way for REAPER to know which plugins and which tracks are communicating. These tracks will not memoize correctly if pre-rendered individually.
BTW, how does this work with manual freezing? Gut feeling is that it is the same problem.
__________________
https://www.cocporn.com
COCPORN is offline   Reply With Quote
Old 08-28-2021, 08:32 AM   #94
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 10,416
Default

Quote:
Originally Posted by COCPORN View Post
My projects usually end up with around 150 tracks and I usually have 79 instances of Falcon. I need this. Give it to me.
That's not a large project. Perhaps more than some netbook style of machine could handle but overall it's on the small-ish side.

Do you perform through instrument/sampler/sound module plugins when you track or overdub? If yes, what is the block size you arrived at for your latency needs?

Dialing the system latency down for live work (tracking or performing) literally gives the system only that interval to process everything. (And of course pre-processing anything performed live is not possible without time travel technology. )
That leads to less CPU available for large track/plugin counts.
That also leads to vetting ALL plugins used at that latency setting for their internal latency. You can't use any plugins live that have a higher internal latency that what you have your block size set to. You could be only using 2% CPU and you'd still have clicks and pops from dropouts if you tried to.

I suspect you're having setup issues around live tracking and perhaps neglecting to address that. Again, any live component is a hard stop that you can't pre-process for. When the project gets big to where you need to use your CPU for mixing and up the block size, when you need to record more you need to print stems to track to. Open a new tab, paste the stems in, block size back down to live tracking setting. Record. Cut/paste the new recording into the original project tab. Block size back up. Keep moving.

I think what you really want here is the ability to run with two different latencies. Like two instances of Reaper with one dialed down to low latency for live tracking and one set high for mixing. Two RT threads: Low latency RT and high latency RT. I'd use a feature like that! Run a live reinforcement mix in a room and a simultaneous broadcast mix (that often needs extra delay anyway to sync up to the always latent video). Or just the classic live tracking scenario where you want to perform through a plugin and hear that sound but not have to prepare stems as the workaround I suggested when the mix work takes off.

I still like your idea! Reaper already does some things like this as mentioned. AfxP for one. I just think something else is messing with you and there may already be a solution.
serr is offline   Reply With Quote
Old 08-28-2021, 09:07 AM   #95
COCPORN
Human being with feelings
 
Join Date: Jan 2008
Location: Oslo
Posts: 175
Default

Quote:
Originally Posted by serr View Post
That's not a large project. Perhaps more than some netbook style of machine could handle but overall it's on the small-ish side.

Do you perform through instrument/sampler/sound module plugins when you track or overdub? If yes, what is the block size you arrived at for your latency needs?

Dialing the system latency down for live work (tracking or performing) literally gives the system only that interval to process everything. (And of course pre-processing anything performed live is not possible without time travel technology. )
That leads to less CPU available for large track/plugin counts.
That also leads to vetting ALL plugins used at that latency setting for their internal latency. You can't use any plugins live that have a higher internal latency that what you have your block size set to. You could be only using 2% CPU and you'd still have clicks and pops from dropouts if you tried to.

I suspect you're having setup issues around live tracking and perhaps neglecting to address that. Again, any live component is a hard stop that you can't pre-process for. When the project gets big to where you need to use your CPU for mixing and up the block size, when you need to record more you need to print stems to track to. Open a new tab, paste the stems in, block size back down to live tracking setting. Record. Cut/paste the new recording into the original project tab. Block size back up. Keep moving.

I think whet you really want here is the ability to run with two different latencies. Like two instances of Reaper with one dialed down to low latency for live tracking and one set high for mixing. Two RT threads: Low latency RT and high latency RT. I'd use a feature like that! Run a live reinforcement mix in a room and a simultaneous broadcast mix (that often needs extra delay anyway to sync up to the always latent video). Or just the classic live tracking scenario where you want to perform through a plugin and hear that sound but not have to prepare stems as the workaround I suggested when the mix work takes off.

I still like your idea! Reaper already does some things like this as mentioned. AfxP for one. I just think something else is messing with you and there may already be a solution.
This is my problem, related to another thread. I would not think this to be a huge workload for my current workstation. I never do live stuff. Your workflow might work, but I am ideally looking to do "no work" except musical work. I know how to bounce already, I just see it as the ultimate cop-out.

I experience strange pops even with an "RT CPU" hovering around a max of 50% which is why I got the Babyface, but it just made it worse. This is not local to this computer.

If you have links to possible solutions for doing (semi-)aggressive preprocessing I am all ears.
__________________
https://www.cocporn.com
COCPORN is offline   Reply With Quote
Old 08-28-2021, 09:33 AM   #96
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 10,416
Default

50% RT CPU is the point Reaper starts to get squirrely. Just FYI. This usually takes some doing to accomplish!

Again though, the starting point includes the data points: What is the block size you are running with? What is the internal latency of the most latent plugin you are trying to use? These aren't theoretical questions. Just matter of fact, what are those numbers?

You don't record anything live? So all programming or arranging pre-recorded material kind of thing? That would be a "set the block size high and forget it" kind of setup.

Forgive me for the "Is the unit plugged in?" style of question on the block size but that's a starting point in any performance issue.

The 2nd question is always: How are you controlling sample rate and block size for the system? Reaper control panel, OS control panel, or 3rd party?
serr is offline   Reply With Quote
Old 08-28-2021, 02:57 PM   #97
Newman
Human being with feelings
 
Join Date: Oct 2018
Posts: 85
Default

I don't know what anyone is talking about...

but I do find "cocporn" entertaining. How could anyone who calls themselves "cocporn" not be.
Newman is offline   Reply With Quote
Old 08-28-2021, 03:55 PM   #98
COCPORN
Human being with feelings
 
Join Date: Jan 2008
Location: Oslo
Posts: 175
Default

Quote:
Originally Posted by serr View Post
50% RT CPU is the point Reaper starts to get squirrely. Just FYI. This usually takes some doing to accomplish!

Again though, the starting point includes the data points: What is the block size you are running with? What is the internal latency of the most latent plugin you are trying to use? These aren't theoretical questions. Just matter of fact, what are those numbers?

You don't record anything live? So all programming or arranging pre-recorded material kind of thing? That would be a "set the block size high and forget it" kind of setup.

Forgive me for the "Is the unit plugged in?" style of question on the block size but that's a starting point in any performance issue.

The 2nd question is always: How are you controlling sample rate and block size for the system? Reaper control panel, OS control panel, or 3rd party?
A $1000 Babyface with 2048 block size works worse than a simple MOTU M2 with 1024, which is the maximum.

Feel free to contact me about this, but fully expect that I am on a mushroom trip.
__________________
https://www.cocporn.com
COCPORN is offline   Reply With Quote
Old 08-28-2021, 04:29 PM   #99
nappies
Human being with feelings
 
nappies's Avatar
 
Join Date: Dec 2017
Posts: 237
Default

Great idea if I get you right! Now we have Anticipative FX processing it is like pre-render all fx stuff to buffer.This is a dynamic buffer now, do you want to make it large(for whole of track) and static?
nappies is online now   Reply With Quote
Old 08-29-2021, 12:00 AM   #100
3mph
Human being with feelings
 
3mph's Avatar
 
Join Date: Feb 2007
Location: Denmark
Posts: 284
Default

Say I have a HW-synth MIDI-controlled by REAPER and the audio from this coming back through some FX. Wouldn't post rendering require the altered events played back a second by the synth? Reverbs would have to have zero audio before rendering again in the background too.

In fact a lot of problems turns up when using MIDI and plugins that rely on random behavior (like analogue emulators). It would the user doing "not-music" by telling REAPER which tracks or busses that meets the requirements of background rendering.

I wonder if the audio from the countless times I've listened to a work-in-progress project could be somehow stored or used in some way. If I listen to the project from start to finish, the master-output(s?) are "recorded". Then, if I alter something one minute into the project, all data after that moment gets deleted. It could be done so there's severeal pieces of the song are stored at different times. Then, when I'm done and render the whole thing, the pieces already stored while listening are inserted saving time rendering it. That would make me happy as a podcast-editor, where rendering of long sessions can take a long time. If the client want a tiny thing changed 56 minutes in.. then.. *sigh*..
__________________
Music is everybody's possession. It's only publishers who think that people own it. (Lennon)
3mph is offline   Reply With Quote
Old 08-29-2021, 03:31 AM   #101
Pashkuli
Human being with feelings
 
Pashkuli's Avatar
 
Join Date: Jul 2006
Posts: 1,694
Default

Quote:
Originally Posted by COCPORN View Post
- Deterministic MIDI playback, today the playback in REAPER is not deterministic depending on if you put the play-head in the middle of a MIDI-item. This is probably true for all DAWs and super irritating in loops.
Logic Pro has had this "MIDI chase" feature since 2019 (search it on YouTube).
But I would assume that by now Reaper has it too. If not... shame on devs.!
__________________
♦ video → .: Pashkuli Keyboard :.
♦ instagram → @pashkuli.keyboard
Pashkuli is offline   Reply With Quote
Old 08-29-2021, 04:06 AM   #102
brk303
Human being with feelings
 
Join Date: Nov 2016
Location: Serbia
Posts: 122
Default

@COCPORN
I agree your caching idea is good, but it's up to Reaper team to consider it.

In the meanwhile let me ask about your track routing, do you have tracks with pre-FX sends that also have FX on ?

If so, be aware that this is currently inefficient, and you can get better performance if you modify your project to avoid such routing.
See my feature request:
https://forum.cockos.com/showthread.php?t=254993
brk303 is offline   Reply With Quote
Old 08-29-2021, 07:28 PM   #103
Win Conway
Human being with feelings
 
Join Date: Dec 2010
Posts: 3,780
Default

This was already done years ago, the software was called Digital Soup if i remember right.
__________________
Stop posting huge images, smaller images or thumbnail, it's not rocket science!
Win Conway is offline   Reply With Quote
Old 08-30-2021, 06:44 PM   #104
Kenny Gioia
Human being with feelings
 
Kenny Gioia's Avatar
 
Join Date: May 2010
Posts: 3,929
Default

Quote:
Originally Posted by juliansader View Post
Nevertheless, if the OP's suggestion can be implemented, it seems like a great idea to save resources.
Oh. I don't think anyone is questioning whether it would be great to have if implemented. I would just argue that the amount of work it would take would far surpass the amount of people that really need this feature. And most of us would actually turn it off because it would be less useful for us as I, and many others, never freeze anything.
Kenny Gioia is offline   Reply With Quote
Old 08-30-2021, 06:46 PM   #105
Kenny Gioia
Human being with feelings
 
Kenny Gioia's Avatar
 
Join Date: May 2010
Posts: 3,929
Default

Quote:
Originally Posted by COCPORN View Post
That is fair. Of course, listening to a no-face-stupid-name nobody takes a leap of faith. I fully understand and respect that.
To be clear, I was only talking about your comment that this could be done with "minimal effort". Not all of the other stuff you wrote.
Kenny Gioia is offline   Reply With Quote
Old 08-31-2021, 05:31 AM   #106
masonsjax
Human being with feelings
 
Join Date: Sep 2020
Posts: 16
Default

Ardour is open source. Perhaps that would be a suitable starting point for OP to code up a proof of concept?
masonsjax is offline   Reply With Quote
Old 08-31-2021, 06:22 AM   #107
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,593
Default

Quote:
Originally Posted by masonsjax View Post
Ardour is open source. Perhaps that would be a suitable starting point for OP to code up a proof of concept?
Unless someone is going to pay the OP for his time, I don't think this would be realistic.
juliansader is offline   Reply With Quote
Old 09-03-2021, 11:47 AM   #108
COCPORN
Human being with feelings
 
Join Date: Jan 2008
Location: Oslo
Posts: 175
Default

Quote:
Originally Posted by juliansader View Post
Unless someone is going to pay the OP for his time, I don't think this would be realistic.
Hi! I code a lot for free and for fun. This is a little outside my area of expertise, but if anyone is familiar with the source code of, say, LMMS, I would be down to take a crack at it.

Also, the current state of REAPER on my Threadripper is that it takes around 3 seconds to solo/un-solo a track. This is not local to this computer and setup; I have seen it many times before. Heavier workloads, especially VST heavy stuff with PDC makes simple editing operations like the one mentioned, undo, etc, totally unbearable.

If you are a coder that is relatively well versed with DSP, shoot me an email at cocporn@gmail.com. I am cloning it as we speak, also joining the LMMS discord to see if I can get any traction on this.

Thanks for the discussion.
__________________
https://www.cocporn.com
COCPORN is offline   Reply With Quote
Old 09-03-2021, 11:48 AM   #109
maxdembo
Human being with feelings
 
maxdembo's Avatar
 
Join Date: Aug 2011
Location: All Hallows End
Posts: 1,590
Default

Quote:
Originally Posted by COCPORN View Post
Hi! I code a lot for free and for fun. This is a little outside my area of expertise, but if anyone is familiar with the source code of, say, LMMS, I would be down to take a crack at it.

Also, the current state of REAPER on my Threadripper is that it takes around 3 seconds to solo/un-solo a track. This is not local to this computer and setup; I have seen it many times before. Heavier workloads, especially VST heavy stuff with PDC makes simple editing operations like the one mentioned, undo, etc, totally unbearable.

If you are a coder that is relatively well versed with DSP, shoot me an email at cocporn@gmail.com. I am cloning it as we speak, also joining the LMMS discord to see if I can get any traction on this.

Thanks for the discussion.
Sounds like there is something screwy with your PC tbh. That, and/or your personal workflow.
maxdembo is offline   Reply With Quote
Old 09-03-2021, 12:43 PM   #110
COCPORN
Human being with feelings
 
Join Date: Jan 2008
Location: Oslo
Posts: 175
Default

Sorry, true to form I forgot to read some of the other replies. Also, talking to the good people at the LMMS discord a thing that came up was this.

Again: I am not trying to indicate that I know what the "answer" is on this. There are certainly a couple of things that I didn't think of, having a streamlined workflow "in the box".

My original suggestion was to aggressively auto-freeze things. This can introduce another threshold, which is basically to start auto-freezing when you reach a certain RT CPU threshold. This would make the system work "as is now" until the computer sees that there might be an issue accomodating you.

@3mph: If you have record armed tracks or active return tracks, those will not be available to pick up by the auto-freezer. Also, it will make the whole signal chain from those tracks (and up) uneligible. I think the DAW "knows this" already from available information, if it is armed for recording it certainly does, and a return track from a HW-device is also monitoring input. These would be exempt from the "system" for the time being.

One issue that came up before is that of plugins doing IPC (Inter Process Communication). This is a very valid concern. My only comeback to this is that it is relatively uncommon, and DAWs as a whole would probably benefit from knowing which plugins these are, because if you accidentally manually freeze a track with these guys on it, you are in for a world of pain.

Another thing that came up was that of generative VSTs, plugins and intentionally sound different on each playback. This is also a valid concern because what this would do is make the playback deterministic for generative VSTs, and that is obviously not what you want.

I fully disclose that I come from this camp: I use a lot of VSTs and the track should sound the same every time. I understand what needs to be live for tracking. And the issue with freezing IPC plugins is, well, an issue whether you do it manually or automatically.

There are a bunch of ways to tackle this, from more automatic to less.

The less automatic way would be to simply be able to maintain a list of tracks and/or plugins to participate. For me personally, this would probably just be a matter of adding smart:EQ3 and perhaps some Nectar stuff to a list of plugins that would never freeze and manually mark tracks that would never freeze because you want them to play back differently on each playback.

Another way would be for the system to compare a frozen track to the live playback of a track. Is it the same or is it different? If it is different without being dirty from user input, you can make an assumption that it needs to be taken out of auto-freeze.

The idea of just doing freezing when you reach a certain RAM/RT CPU threshold takes a lot of this away, tho.

I don't know. Bounty is still up because it would benefit my workflow massively.

And it is Friday. It is coming up on 1PM on the West Coast. I need to pay my taxes, but I would prefer to spend my money on this.
__________________
https://www.cocporn.com
COCPORN is offline   Reply With Quote
Old 09-03-2021, 12:46 PM   #111
COCPORN
Human being with feelings
 
Join Date: Jan 2008
Location: Oslo
Posts: 175
Default

Quote:
Originally Posted by maxdembo View Post
Sounds like there is something screwy with your PC tbh. That, and/or your personal workflow.
If you have the time and/or inclination, I would be happy to show you how it manifests. I can assure you that after having worked with relatively well-specced prosumer equipment that this is not an issue with that.

If you think it is a problem with my workflow I think we are in the right thread because I do not want the availability of CPU cycles to dictate my workflow.
__________________
https://www.cocporn.com
COCPORN is offline   Reply With Quote
Old 09-03-2021, 01:05 PM   #112
Dex
Human being with feelings
 
Join Date: Sep 2017
Posts: 417
Default

Quote:
it takes around 3 seconds to solo/un-solo a track.
This is tangential to the thread, but perhaps you have the "Do not process muted tracks" option enabled. If so, try disabling it.
Dex is online now   Reply With Quote
Old 09-03-2021, 01:07 PM   #113
COCPORN
Human being with feelings
 
Join Date: Jan 2008
Location: Oslo
Posts: 175
Default

Quote:
Originally Posted by Dex View Post
This is tangential to the thread, but perhaps you have the "Do not process muted tracks" option enabled. If so, try disabling it.
I had it off, but feeling like a maverick I now turned it on to see what happens.
__________________
https://www.cocporn.com
COCPORN is offline   Reply With Quote
Old 09-03-2021, 02:47 PM   #114
COCPORN
Human being with feelings
 
Join Date: Jan 2008
Location: Oslo
Posts: 175
Default

Quote:
Originally Posted by COCPORN View Post
I had it off, but feeling like a maverick I now turned it on to see what happens.
DEAR REAPER CREW.

I will pay you to tell me that I am wrong.
__________________
https://www.cocporn.com
COCPORN is offline   Reply With Quote
Old 09-03-2021, 03:10 PM   #115
White Tie
Pixel Pusher
 
White Tie's Avatar
 
Join Date: Mar 2007
Location: Blighty
Posts: 3,554
Default

Quote:
Originally Posted by COCPORN View Post
I will pay you to tell me that I am wrong.
No one here is your whore. Put your money away and behave.
__________________
The House of White Tie
White Tie is offline   Reply With Quote
Old 09-03-2021, 03:21 PM   #116
maxdembo
Human being with feelings
 
maxdembo's Avatar
 
Join Date: Aug 2011
Location: All Hallows End
Posts: 1,590
Default

Quote:
Originally Posted by COCPORN View Post
If you have the time and/or inclination, I would be happy to show you how it manifests. I can assure you that after having worked with relatively well-specced prosumer equipment that this is not an issue with that.

If you think it is a problem with my workflow I think we are in the right thread because I do not want the availability of CPU cycles to dictate my workflow.
I dunno, people have done a lot more with a lot less. Streamline what you're already doing.
maxdembo is offline   Reply With Quote
Old 09-04-2021, 01:42 AM   #117
COCPORN
Human being with feelings
 
Join Date: Jan 2008
Location: Oslo
Posts: 175
Default

Quote:
Originally Posted by White Tie View Post
No one here is your whore. Put your money away and behave.
Point taken.
__________________
https://www.cocporn.com
COCPORN is offline   Reply With Quote
Old 09-04-2021, 03:53 AM   #118
MixR
Human being with feelings
 
Join Date: Jan 2017
Location: London
Posts: 159
Default

It may actually be worth looking into an DSP accelerated platform.

I started my switch to Reaper from Pro Tools earlier this year. I love Reaper but there are a few things I can relate to from your comments which is why I would consider investigating DSP based solutions.

Pro Tools caches all the audio in the session into RAM (if you tell it to). It's a great feature. It will also do it for any audio you add to the session (which would most likely include frozen audio tracks).

The Pro Tools mixer works on real time DSP. There is no latency, ever, when soloing and muting tracks. There is no latency when writing automation from a fader.

Having been a Pro Tools user for well over twenty years those are some of the hardest things to adjust to for me. Whilst Pro Tools probably doesn't have the exact implementation of your suggestion it may be good enough to get you through your frustrating workflow bottleneck.

I admire your suggestion and am sure it is a valid one for your specific workflow but it would not work for me at all in a serious mix situation as I am running between 48 and 80 hardware inserts per mix - which cannot be frozen in real time.

So in that respect I don't think it is useful to assume that your specific needs will be the be all and end all of performance related improvements to Reaper - I also have needs which I would love to have addressed by the devs - mainly how to improve Reaper's performance with RT hardware inserts. Right now it (and presumably any native DAW) can't touch a twenty year old DSP system when it comes to that.
__________________
PC Laptop i7 10870H|W10|RME MADIface Pro|Reaper (latest)
Hackintosh|i7 3930k|Mac OS 10.14| 2x RME HDSPe MADI FX|Reaper (latest)|
MixR is offline   Reply With Quote
Old 09-14-2021, 04:43 PM   #119
COCPORN
Human being with feelings
 
Join Date: Jan 2008
Location: Oslo
Posts: 175
Default

Quote:
Originally Posted by MixR View Post
It may actually be worth looking into an DSP accelerated platform.

I started my switch to Reaper from Pro Tools earlier this year. I love Reaper but there are a few things I can relate to from your comments which is why I would consider investigating DSP based solutions.

Pro Tools caches all the audio in the session into RAM (if you tell it to). It's a great feature. It will also do it for any audio you add to the session (which would most likely include frozen audio tracks).

The Pro Tools mixer works on real time DSP. There is no latency, ever, when soloing and muting tracks. There is no latency when writing automation from a fader.

Having been a Pro Tools user for well over twenty years those are some of the hardest things to adjust to for me. Whilst Pro Tools probably doesn't have the exact implementation of your suggestion it may be good enough to get you through your frustrating workflow bottleneck.

I admire your suggestion and am sure it is a valid one for your specific workflow but it would not work for me at all in a serious mix situation as I am running between 48 and 80 hardware inserts per mix - which cannot be frozen in real time.

So in that respect I don't think it is useful to assume that your specific needs will be the be all and end all of performance related improvements to Reaper - I also have needs which I would love to have addressed by the devs - mainly how to improve Reaper's performance with RT hardware inserts. Right now it (and presumably any native DAW) can't touch a twenty year old DSP system when it comes to that.
This is interesting to me.

You are telling me that I can get a commodity M1-chipped Apple to work with 4K and a Threadripper cannot really do audio, and it has to be offloaded to DSP.

Yes, it will work for hardware inserts, unless they play differently on a replay and you care about the difference.

It just works for anything that has a sink.

What is it about these 48-80 plugins that cannot be frozen?
__________________
https://www.cocporn.com
COCPORN is offline   Reply With Quote
Old 09-16-2021, 10:08 AM   #120
MixR
Human being with feelings
 
Join Date: Jan 2017
Location: London
Posts: 159
Default

Quote:
Originally Posted by COCPORN View Post
This is interesting to me.

You are telling me that I can get a commodity M1-chipped Apple to work with 4K and a Threadripper cannot really do audio, and it has to be offloaded to DSP.

Yes, it will work for hardware inserts, unless they play differently on a replay and you care about the difference.

It just works for anything that has a sink.

What is it about these 48-80 plugins that cannot be frozen?
I didn't say anything about 4k or Apple or whatever. You mentioned caching/rendering audio into RAM and I pointed you to Pro Tools which does just that (to be confirmed for tracks set to frozen) as a possible solution to the problem you seem to be having right now (track freezing workflow and solos/mutes that take forever to execute).

Background freezing does not work for hardware inserts. Hardware inserts are real time only. They cannot possibly be frozen or rendered, unless you do it in real time, as Reaper cannot possibly know what signal might be coming in via the insert.

Since I am using between 24 to 80 channels worth of outboard gear (via Reainsert plug-ins) they cannot possibly be frozen unless they are printed back into Reaper by recording the output of the hardware units.
__________________
PC Laptop i7 10870H|W10|RME MADIface Pro|Reaper (latest)
Hackintosh|i7 3930k|Mac OS 10.14| 2x RME HDSPe MADI FX|Reaper (latest)|
MixR is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 04:41 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.