don’t get me wrong, but it’s a little bit annoying: sometimes it’s impossible to cut or copy large (>100 mbyte) wav-files with renoise / with the sample-ed … and after some heavy sample operations (or working in other apps) the song needs his time to play without any problems.
it’s not a new problem … also with lower cpu and memory configs it’s hard to work with heavy weight VSTi and so on … other apps are working flawless with big files and VSTi’s …
with some small little samples or some easy VSTi-synths everything is fine in renoise but working with big sample-based VSTi’s and some >30mbyte samples … . . . . . . . . .
(and i’m working with 1.5gigs 400mhz ddram … and a high optimized xp system …)
The sample-editor in Renoise is indeed memory based.
Processing large samples can best be done in applications that use peak-files and process them from harddisk rather than in memory.
Using large VSTI’s is not a problem that can be overcome in Renoise either since Renoise doesn’t handle the memory-management for VSTi’s in particular, other than that it get’s instanciated and being communicated with, the VSTI will have to do it’s handling on it’s own from there.
A VSTI is an add-on DLL and is actually an executable being started from within an executable (Renoise in this case).
There are VSTI-samplers that have DirectFromDisk options which make them less bulky (and less loading time in Renoise). The freeware SFZ VSTI is one of them. If a specific VST-Instrument doesn’t have a sort of DirectFromDisk option or does not use data-management through disk (though RAM-memory is faster, if you run out of it, the page-file is being used which makes things much worse than when just either one of the options are used at the same time) and you have no alternatives, you’ll have to learn to live with it, or make a remark towards the developers of the VSTI that you encounter such problems in host-applications.
i’m not sure about this … compare with / try other VSTi hosts … there is a difference … i know all you said … but i don’t know, i don’t know … … i’m no coder but … if i compare with other hosts - it’s more flawless there …
try to leave renoise with a heavy weight song loaded in the taskbar for a while … reactivating renoise is so ponderously … is it not possible to optimize or enhance this? … i can’t believe that there are no possibilities!
As voois already said: The only problem is that Renoise stores the samples in memory, instead of reading them on the fly from disk. We can not affect the memory usage of VST`s.
ok … … and it’s not possible to optimize something … Renoise is also really slow on closing the app. sometimes it needs more than 20 sec … can’t understand why …
sample-ed:
but if there is not enough ram available, the result shouldn’t be the losing of the whole sample on undo operations … i had some curious things with copy/cut/undo and a 150mbyte wav file: 2times cut, paste, undo and my the sample was gone???
IMHO, it would be a more wise decision to change sample-processing in the sampler to DFD mode when a certain size is being exceeded. (e.g. 16MB)
And the trigger size (and toggling DFD) could be user configurable in the Misc settings.
I think some ppl with very fast HD configurations would probably like that idea a lot.
It would however, not dictate VSTI’s to do the same though. They still keep operating by themselves.
The reason why it takes so long for loading and unloading a plugin is because they have their own routines to load and unload the samples or either their properties from memory.
The only thing to circumvent the slow process would be not calling the shutdown routine of the plugin, but it would not free memory and the plugin would remain in memory totally uncontrolled. (That and the fact you have less RAM to use for what you actually were removing the plugin for in the first place)
… i’m no coder but … if i compare with other hosts - it’s more flawless there …
… and it’s not possible to optimize something … Renoise is also really slow on closing the app. sometimes it needs more than 20 sec … can’t understand why …