Go Back   Cockos Incorporated Forums > REAPER Forums > Recording Technologies and Techniques

Reply
 
Thread Tools Display Modes
Old 10-02-2022, 11:19 PM   #1
mazegeek999
Human being with feelings
 
mazegeek999's Avatar
 
Join Date: Jan 2015
Posts: 225
Default Multiple instances of the same plugin... more RAM?

Hi there,

I recently downloaded the orchestral libraries from East West and I'm loading them into REAPER. If I have multiple instances of the same plugin loading the same instrument (same samples, same settings, same everything), it appears that the total amount of used RAM grows each instance. This is counterintuitive to me; I would assume that because all instances of the plugin are grabbing the same sample data loaded into RAM, it wouldn't need to duplicate that data (in fact, that sounds extremely inefficient). Is this normal behavior... and if so, why?

An example of this in action would be to have multiple instances of solo violins to create (part of) a string quartet/quintet. Ideally I would have assumed that those identical plugins would be searching for the same samples loaded into RAM, so there would be no reason to load duplicate samples into RAM.
mazegeek999 is offline   Reply With Quote
Old 10-02-2022, 11:54 PM   #2
Tod
Human being with feelings
 
Tod's Avatar
 
Join Date: Jan 2010
Location: Kalispell
Posts: 14,745
Default

Quote:
Originally Posted by mazegeek999 View Post
Hi there,

I recently downloaded the orchestral libraries from East West and I'm loading them into REAPER. If I have multiple instances of the same plugin loading the same instrument (same samples, same settings, same everything), it appears that the total amount of used RAM grows each instance. This is counterintuitive to me; I would assume that because all instances of the plugin are grabbing the same sample data loaded into RAM, it wouldn't need to duplicate that data (in fact, that sounds extremely inefficient). Is this normal behavior... and if so, why?

An example of this in action would be to have multiple instances of solo violins to create (part of) a string quartet/quintet. Ideally I would have assumed that those identical plugins would be searching for the same samples loaded into RAM, so there would be no reason to load duplicate samples into RAM.
Hi mazegeek999, I'm not so sure it's Reaper's fault in this situation. I'm a heavy Kontakt user and it will load the samples every time you load an instrument too. The good thing about Kontakt is you can purge the samples so that the only samples loaded are the ones that are used, but they will still use the same sample twice it it's used.
Tod is offline   Reply With Quote
Old 10-03-2022, 11:44 AM   #3
Pollo
Human being with feelings
 
Join Date: Jan 2015
Location: Amsterdam
Posts: 94
Default

I'm afraid this is one of those situations where one's intuition is at odds with reality. I am a programmer and I have a good understanding of memory management. I am not surprised that multiple instances of the same plugin don't share RAM storage. It is not impossible, that is not the point. The thing is that it would add a lot of complexity whereas the benefits are small. Most of the time the plugin will not be used in the way you describe. If you need two instances with exactly the same settings, why do you need two instances?
Beside that, RAM is cheap.

Therefore, the programmer spends her time on the things that yield the highest benefits. But maybe you can convince her that she sees it wrong.
Pollo is offline   Reply With Quote
Old 10-03-2022, 06:52 PM   #4
mazegeek999
Human being with feelings
 
mazegeek999's Avatar
 
Join Date: Jan 2015
Posts: 225
Default

Quote:
Originally Posted by Tod View Post
Hi mazegeek999, I'm not so sure it's Reaper's fault in this situation. I'm a heavy Kontakt user and it will load the samples every time you load an instrument too. The good thing about Kontakt is you can purge the samples so that the only samples loaded are the ones that are used, but they will still use the same sample twice it it's used.
The purge feature is quite neat... unfortunately I seem to get pops when I use it on the OPUS software as I often have my buffer size set low enough (256 samples) for live monitoring. I imagine this is only useful purely for mixing and not for real-time recording.

Quote:
Originally Posted by Pollo View Post
I'm afraid this is one of those situations where one's intuition is at odds with reality. I am a programmer and I have a good understanding of memory management. I am not surprised that multiple instances of the same plugin don't share RAM storage. It is not impossible, that is not the point. The thing is that it would add a lot of complexity whereas the benefits are small. Most of the time the plugin will not be used in the way you describe. If you need two instances with exactly the same settings, why do you need two instances?
Beside that, RAM is cheap.

Therefore, the programmer spends her time on the things that yield the highest benefits. But maybe you can convince her that she sees it wrong.
This is so bizarre to me but I'll take your word for it. I can think of many reasons why I'd want multiple instances of the same instrument. Applying different sets of FX on the instances? Adjusting volume/pan/other parameters per track? Applying portamento to one instrument, but not to another? The list goes on.

I won't pretend to understand why sharing RAM storage is a complex issue. I write scripts but I've never written a full-fledged VST. But that's a real bummer.
mazegeek999 is offline   Reply With Quote
Old 10-04-2022, 11:44 AM   #5
MiddleC
Human being with feelings
 
Join Date: Apr 2021
Posts: 565
Default

There are a number of strategies for shared memory programming. The trick is, the further away you get, the more it gets complicated. When both processes are running on the same core you have the easiest (relatively!) situation. Once you're running on different cores, it gets more complicated.

Used to be all memory could be read by any process. Proper system design separates things much more rigorously these days. There are solutions like "Boost" - basically interprocess C++ libraries.

But... it's a lot of investment to get around memory limitations in a time when memory is incredibly cheap, and only getting cheaper. A VST developer would want to know how that investment translates into additional sales, and it's doubtful that the market size for that feature is significant enough to warrant it.
MiddleC is offline   Reply With Quote
Old 10-04-2022, 04:28 PM   #6
Pollo
Human being with feelings
 
Join Date: Jan 2015
Location: Amsterdam
Posts: 94
Default

Another option is to let the operating system take care of this. I think most or at least some sample based plugins will let you configure whether to read from memory or from disk. If it reads from disk, the operating system will cache the files (provided the file caching system is working properly) and the plugin instances will automatically share the resources.

Personally I think in most cases I would prefer to use more RAM.
Pollo is offline   Reply With Quote
Old 10-04-2022, 07:03 PM   #7
MiddleC
Human being with feelings
 
Join Date: Apr 2021
Posts: 565
Default

Using a RAM disk does lower retrieval time. However, if three processes use the same files they all make copies into RAM just as they would for non-virtual drives. In other words,three processes using the same sound files would mean four copies in memory - the ram drive plus their own reads.
MiddleC is offline   Reply With Quote
Old 10-13-2022, 01:24 PM   #8
Pollo
Human being with feelings
 
Join Date: Jan 2015
Location: Amsterdam
Posts: 94
Default

Quote:
Originally Posted by MiddleC View Post
Using a RAM disk does lower retrieval time. However, if three processes use the same files they all make copies into RAM just as they would for non-virtual drives. In other words,three processes using the same sound files would mean four copies in memory - the ram drive plus their own reads.
Are you talking about disk caching? Not exactly the same as a RAM disk, as far as I know. I also don't know about processes making their own copy of shared files. If you are sure about that I am willing to take your word for it.

But in this case the plugin instances run in the same process, so that would not be the case anyway.
Pollo is offline   Reply With Quote
Old 10-14-2022, 07:47 AM   #9
MiddleC
Human being with feelings
 
Join Date: Apr 2021
Posts: 565
Default

Not disc caching, no. A ram disk is a section of memory set aside that acts as an actual disk. The operating system abstracts it so that applications are unaware of the difference. A mounted ISO is a form of a ram disk.

So when a VST comes along and uses, say, a set of sound files, it does what it would do if it were a normal drive - it reads those files into memory. And another VST would do the same. Hence, two VSTs, three copies in memory.

Disk caching of a RAM drive is redundant.

Systems don't make their own "copies" in the storage sense when they load a file. They read it into memory. That's why traditional file access is non-destructive. Ever have old-school Word crash on you and you didn't hit "save"? That's because you are working on a copy in memory. Newer versions of Word don't change this paradigm - they just save A LOT as you go. Same for apps on the phone.

Not to get too far into the weeds, but with really, really large files sometimes programmers have to read in "parts" of a file instead of the whole thing... but the basic pattern is still there. To use it, the application loads it into memory. And because by default applications do not share memory, each VST gets a copy.
MiddleC is offline   Reply With Quote
Old 10-14-2022, 09:25 AM   #10
Pollo
Human being with feelings
 
Join Date: Jan 2015
Location: Amsterdam
Posts: 94
Default

You are making the assumption that a plugin/process always reads a file into RAM, but that is not necessarily so. That was my point. The plugin could read the data from file as needed, in which case the file caching systems kicks in and makes sure that files are kept in memory and can be quickly accessed the next time they are needed. I am pretty sure that works between processes, certainly between instances of a dll (which is what a plugin is). That is what disk caching is meant to do.
Pollo is offline   Reply With Quote
Old 10-14-2022, 10:19 AM   #11
MiddleC
Human being with feelings
 
Join Date: Apr 2021
Posts: 565
Default

Yes, I am making that assumption. And it's not much of an assumption. For some things, it's perfectly fine to let things sit on the disk until you need them. Audio work is not one of those things. The moment you need those samples, they are brought into memory. End of story. And the act of loading them into memory takes time.

And "sitting on the disk" means either on the actual disk or in intermediary caches. Either way, it will be moved from there into memory. You don't just suddenly have a pointer shift for instantaneous access - being in the cache or on the drive is irrelevant to the consuming process, excepting for speed of retrieval.

Don't confuse the disk cache with something easily swapped as ram. It's not. It's just a high speed temporary buffer to hold things the system thinks you might need next.
MiddleC is offline   Reply With Quote
Old 10-14-2022, 10:58 AM   #12
MiddleC
Human being with feelings
 
Join Date: Apr 2021
Posts: 565
Default

I guess just to close the loop on this, it is possible for multiple instances of a VST - or even different VSTs to share the same part of memory and avoid sample duplication... but those processes would all have to be built from the bottom up to support it, and they would all have to agree on and implement a common method of doing it.

Possible in theory, unlikely in practice. Expensive to retrofit.
MiddleC is offline   Reply With Quote
Old 10-14-2022, 11:39 AM   #13
Pollo
Human being with feelings
 
Join Date: Jan 2015
Location: Amsterdam
Posts: 94
Default

I get the impression you don't really know what you are talking about. There is a concept called buffering. Take a DAW like Reaper, do you think that all audio track files are loaded into RAM when you open a project? Of course not, they are loaded when needed, and then only the specific portion of the file is loaded into a buffer. As playback progresses, new parts of the file(s) are loaded into the buffer and so on. That's the way that works.

And probably a lot of sample players work the same way. Some may not. I know that when you load a drumkit into SSD (Stephen Slate drum VST), all the files are loaded into RAM. But these kits or only about 1.5 GB in size, so that makes sense.
Pollo is offline   Reply With Quote
Old 10-14-2022, 12:46 PM   #14
MiddleC
Human being with feelings
 
Join Date: Apr 2021
Posts: 565
Default

You can certainly question my knowledge. I'm not particularly fussed by that. But understand you're squarely in where I've been living my professional life since 1992. for about 20 years I worked on processing data steams requiring sub-millisecond response times, and occasionally with data sources that wouldn't fit within a 64GB memory space.

Regardless, this isn't happening any time soon.
MiddleC is offline   Reply With Quote
Old 10-15-2022, 05:15 AM   #15
Pollo
Human being with feelings
 
Join Date: Jan 2015
Location: Amsterdam
Posts: 94
Default

I had to read your last post a few times but I still don't fully understand what you are trying to say.

You tell me something about your past and present experience. Good. I am always interested in what other people do. Myself I've been a programmer since 1990. The last 25 years mainly C++. Since about 15 years I have been developing VST plugins. I now have about 23 plugins that I developed. So that is to give you a bit of my background. It is not meant as a pissing contest. But I do know quite a lot about audio processing and related issues, memory management, file management.

I am curious about your data streams requiring sub-millisecond response times. What kind of data streams? High speed stock trading? Something military? Maybe you are not allowed to talk about it, but I'm curious.

Your last sentence I don't know how to interpret. This isn't happening any time soon? What isn't happening? I'm at a loss what that means. Please help me out.
Pollo is offline   Reply With Quote
Old 10-16-2022, 03:21 PM   #16
MiddleC
Human being with feelings
 
Join Date: Apr 2021
Posts: 565
Default

Not high stock trading, no. In a former life I was a developer working on Gensym's G2 platform. http://dev.gensym.com/platforms/g2-enterprise/

After leaving there, I spent some time doing implementations on systems built on it, and other industry software. Following that I was working in SCADA, mining very large datasets for analysis to feed alarms for critical systems.

Since we're both professionals (apologies, I did not know that), we can elaborate a bit.

I think where we diverged is that this thread is about VSTs, not large static media files. You're right - when large files are used, they are read piecemeal, and on demand.

VSTs have to be able to produce the required output within the window granted by the latency needs. They can either compute the waveform (a la pianoteq - love that thing), or they can serve it from samples. But because it can't predict which samples will be needed, all must be loaded. You can't take a trip through I/O to retrieve it when it's not present without blowing your response time.

And given that ram drives abstract ram as storage, they have to adhere to the principles of storage. Processes cannot simply reach in and access the store as ram - they have to retrieve what they need just as they would from a disk.

What won't happen is the industry coordination needed to arrive at common interfaces for ram sharing amongst their plugins. Even sharing ram amongst instances of the same plugins requires rework that bubbles to the bottom of the list of "things to do".

Last edited by MiddleC; 10-16-2022 at 03:31 PM.
MiddleC is offline   Reply With Quote
Old 10-17-2022, 09:12 AM   #17
MiddleC
Human being with feelings
 
Join Date: Apr 2021
Posts: 565
Default

Quote:
Originally Posted by Pollo View Post
I'm afraid this is one of those situations where one's intuition is at odds with reality. I am a programmer and I have a good understanding of memory management. I am not surprised that multiple instances of the same plugin don't share RAM storage. It is not impossible, that is not the point. The thing is that it would add a lot of complexity whereas the benefits are small. Most of the time the plugin will not be used in the way you describe. If you need two instances with exactly the same settings, why do you need two instances?
Beside that, RAM is cheap.

Therefore, the programmer spends her time on the things that yield the highest benefits. But maybe you can convince her that she sees it wrong.
I apologize, Pollo. I don't know how I missed this.

We agree more than disagree.
MiddleC is offline   Reply With Quote
Old 10-17-2022, 05:58 PM   #18
Pollo
Human being with feelings
 
Join Date: Jan 2015
Location: Amsterdam
Posts: 94
Default

I agree.
Pollo 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 02:49 PM.


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