You can’t blame the application programmer for the bad memory management the OS performs.
An application requests Windows for memory if it needs some, as soon as Windows says “I don’t have more for you” the deal is over and Renoise simply won’t get more. You can ask Taktik to implement any particular armory to threat Windows and demand more, but it will never work unfortunately.
You might want to check the System Paging file options and see how large the paging file is.
Usually it should be 1.5x the real memory, though it does not matter much when Windows only addresses up to 2GB per application.
If you could ReWire one of your plugins if it was a Stand-Alone app (which some plugin developers also offer) this might also give Renoise and your plugin some breathing space.
i dont wanna blame taktik, i simply tried to told him that the /3gb is not a very good and stable solution.
i have read around: 1.8gb per programm is the maximum which wxp will support in best cases, but i can reach only 1.2 in renoise; the problem seems to be that gigabytes of ram are freally free, but are “fragmented” ? what does this mean technically?
so if a fragment is less than 100mb , and i want to load somethin in renoise that is bigger than 100mb, you get a memory out message from the OS ?
i doesnt really know about the technics behind; but is it possible to allow renoise to use virtual paged memory? would this be not fragmented? i use a ramdisc for pagefile, and for me it would be a solution.
Fragmented memory is like you have a table that you want to put some plates on it.
The table can hold let’s say 25 dishes and there are already 18 dishes on the table, yet they are positioned in a way that you cannot add a dish in between them, so you have to reorder the dishes on the table first before you have a space big enough to add another few dishes.
In graphics it looks similar like this:
For hardrives this is a common problem, but this happens to memory as well.
There are programs that can defragment RAM memory (Like MemTurbo). These kind of programs will improve some of the memory usage but cannot intervene in reserved memory spaces already assigned to programs.
thx 8)
i know what fragmented means, but i doesnt understand why after a fresh boot the 2.5 gigs of ram, which are empty, are fragmented. does this mean a programm (windows driver, gui…) load his code aynwhere at random in the memory? thats not possible, i think.
no other programms would run properly, all other programms would have than the “not enough unfragmented memory” problem.
i will test “mem turbo” and try to load more than the 1.2 gigs of samples (which are effective only 600 mb… and thats what is so bad)
Sorry for bothering you with technical details. Don’t care about this. As long as Renoise is a 32bit application and as long as you are using 32bit VSTs in a 32bit OS, you will quite easily run out of memory when using large samples or a huge amount of small samples with sample VSTs.
Does it really make a difference if you can load up to 1.2 or 1.8 GB of samples?
So the only solution for this is, as said above, for now, to use Direct from Disk streaming sample VSTs. Don’t load everything into memory.
We will in future try to support this in the Renoise internal sampler as well, and will also support 64bit VST and OSs. But until most plugins are only available as 32bit plugins, this doesn’t make any sense, cause we would need to run them “emulated”, which is slow as hell, or you could not use them at all. You can not load a 32bit plugin (and most plugins are 32bit) in a 64bit application without emulation.
One way to already now use 64bit plugins in a 64bit version of windows with a 32bit Renoise, is to use jbridge: http://jstuff.wordpress.com/jbridge/
This will “emulate” 32bit to 64bit plugins and vice versa, so on a 64bit windows, you could run a 32bit Renoise and load 64bit versions of the plugins (if there are some)
Too many 32bit and 64bits in this post. Sorry, but this and will be just complicated.
Don’t know how to explain this more easily…
yes, for me ;(
i already use DfD plugins for all native instruments… but they need the above listed amount of ram with this feature.
and no; its not to technically for me, i try to motivate you to find unusual solutions
(einfach mal den kampgeist des scenecoders entfachen ich arbeite seit nunmehr seit 1992 mit solch talentierten programmieren wie dir zusammen, und ich weiss wenn einer sagt: “das geht nicht, weil…” , gehts meist DOCH, wenn die motivation stimmt sieh es so: dann kann die line mit “professionelles audiosystem” , oder was da stand, wieder in den loadscreen rein weil ich nutz renoise tatsächlich ausschließlich zum arbeiten, und wenn mir was auffällt, was mich beim arbeiten arg behindert, dann sag ich das hier; wurde bisher zwar fast immer ignoriert, aber ich geb nicht auf ^^
auch ist mir das nicht zu technisch, ich hab schon aufm c64 in assembler musikroutinen in den speicher gehackt. bitte behandelt mich nich wie einen ewig unzufriedenen meckerer, der keinen plan hat
Jbridge is only a stopgap though taktik as most developers of DAWs are now developing their own native built in wrapper on the road to 64bit
Taktik is right here and if anybody imagines that their entire range of plugins they use now will be ported to 64bit they are kidding themselves unless they only use plugins from the most active devs around
Truth be told on windows that SE has garned somewhat of a terrible reputation and not because SE is sloppy as a dev environment but because most of the plugins made in SE will never be recompiled with the fixes that have made there way into SE
The same thing will happen with 64bit too and a lot of loved plugins will never make it to 64bit
Having spouted all that crap i would love to see a 64 bit version of Renoise because i see no point at all in stream from disk unless the entire sample engine is updated so that we can make multi zoned multi layered multi random and round robin style stuff
For me personally i cant even see why anyone would use the sample engine in Renoise to make a huge instrument and not just use a sampler
I had the “out of memory” error today for the first time. I was trying to load an 88MB mp3 (DJ mix) so I could edit it in the sample editor. Seemed a bit weird as I had 3GB of free ram at the time. I’ll see if it works after a reboot.
It’s not really a problem though because i’ve never run out of memory when making tunes.
Interesting discussion.
I have a related question. I have 64bit Vista and 8GB of RAM. How much memory can Renoise use on my system? 3GB? Is there any way to workaround this? I am planning to use 32-bit VST instruments.
Is it possible for Renoise to do some kind of a fork() and launch each VST instrument as a separate process? That would probably mean wasting some memory and maybe some performance impact on the communication between these processes, but could it potentially solve the problem under 64-bit OS? (I have no problem adding even more memory and buying faster CPU in that case).
I see more and more VST instruments being 64-bits and having some outrageous memory requirements (just look at some latest VST instruments from Spectrasonics - 4GB recommended). Can Renoise keep up with this?
first of all, take in count that we are aware of the increasing demand for a Renoise 64bit version.
I think that the maximum quantity of memory available in Renoise under a 64bit OS is 2GB, as it’s most likely that the /3GB option is not available there.
about the separate process idea, VST’s already are separate processes loaded as dynamic libraries, so there is nothing more we can do.
Its 3GB when running Renoise version on a 64bit windows without having to set any option…
I think Cadence means something else: By creating a new process for each VST, you do not have to share the memory with Renoise and all the other plugs. So Renoise and each single plugin would have up to 3GB of memory - each. This also has the advantage that you can use 32bit plugins in 64bit hosts and vice versa.
But launching plugins in a separate process creates a LOT of overhead as well, because you can no longer directly call/communicate with the plugins.
I think reaper got this kind of bridging for plugins in one of its last updates. Probably someone here has tested this and could give us a hint how well this works, how big this overhead is?
First off, It-Alien, it is reassuring to hear that Renoise team is aware of the 64-bit issue. I don’t expect immediate solution to this, but it’s good to know it is somewhere on your TODO list.
This is exactly what I was thinking about. Although, I didn’t know it can also potentially resolve problem with 64-bit plugins.
It would be great to know how big is that overhead. To mitigate the overhead, in ideal world, it could work like this:
Keep loading VST instruments the normal way.
Once we get the “out of memory” signal from the OS, Renoise will try to load VST instrument as a separate process. If that doesn’t work, then it means we run out of system memory so the “out of memory” message is diplsayed to the user.
if the VST instrument is 64-bit, Renoise will load it as a separate process, regardless of the current memory usage.
This way the performance impact would be only for those VST instruments that normally wouldn’t be handled by Renoise at all.
No matter which way you guys will decide to go with this, one thing is clear: it is not trivial. It will probably take months before we will see Renoise that can operate above the 3GB barrier. Therefore, in the meantime, I’m wondering if there is any workaround whatsoever. It can be dirty - as long as it works
One thing that comes to mind is to use two Renoise instances at the same time. When you start two Renoise programs, each one can actually operate at the same time (each can play different song for example). If there was a way to somehow synchronize them (ReWire?) that would solve my problem for now (especially that I have two LCD screens so I can work together with two Renoise’s easily). I know it seems ugly (and many features wouldn’t work), but I’m just trying to think outside of the box here. It’s really annoying that I have 8GB RAM in my system, but can use only 3GB…
Any ideas for a workaround?
i’m back 8) i have finished my project, most of the songs excided the amount of memory with 1.4 or 1.5 gigs of ram. (pls read bottom for more)
the /3gb switch in win.ini was the solution for me, but you should take care not to run any d3d programms, the system (with my ati card) becames very unstable and freezes after some minutes with d3d usage (wxp)
(tested with 3 different catalyst drivers, it only happens with the /3gb switch)
i also have tested
and it does the job very well, but you have to buy it. but it solves the problem too! but i think renoise should handle the VSTi’s as single threads byself.
after very intensive research in the last month’s i can say:
wxp only can adress 1.34 gigbytes of ram / thread. not 2 gigs which anyone (including microsoft) claims. (!)
with /3gb switch it raises up to 2.5 gigs of ram.
and one of the major problems is: if the maximum amount of ramusage in renoise is reached (usally at 1.34 gbyte) a warning
message in renoise is popping out, that says something ybout low memory or not more memory free, and after that you can’t save your song nor delete a sample (even with undo off) to free up some memory.
you only can kill renoise in the taskswitch and load the last state of your song.
i called this popup “screen of death” . got this several times. (without the /3gb switch)
From my side I will just add that on Vista x64 I was able to successfully edit my song even when it reached 2.4GB of RAM. Haven’t tried more yet, but I will let you know if I ever hit any limits (3GB?) there.
I’m reopening this, because of one question I want to ask: what’s the problem with building x64 version of Renoise? It’s just a matter of compiler, right? I don’t need anything optimized for x64. I just want it to work in 64bits so that I can use 64bit VST instruments (I don’t need 32bits at all). Is it possible to build such a version? Even just an unofficial “testing” build would do
It is not only compiler, all the internal sample processing routines and the audio engine has to be changed to also do 64-bit audio processing i guess.
Compiling a 32-application with a 64-bit compiler parameter only resolves the part where Renoise can run natively in a 64-bit environment but it will likely crash when you try to use a 64-bit plugin as soon as the plugin has to feed audio to Renoise.
