Vienna Symphonic Library Forum
Forum Statistics

181,887 users have contributed to 42,190 threads and 254,623 posts.

In the past 24 hours, we have 3 new thread(s), 17 new post(s) and 61 new user(s).

  • how does "ram management" work in practice?

    if i understand the concept correctly, one will need only one VI instance for e.g. the solo violin.
    lets say, i load an articulation (e.g. one of these automatic performance legato/detache/staccato combinations - which will already fill my entire ram [;)]), record a few bars, press the "free memory" button and all except the few samples that are actually used in the sequence are gone. can i now go ahead and load another articulation in the same VI-instance (e.g. a performance trill), record a few more bars and empty all unused samples again - and so on? if yes, how is this realized? where is the information which patch is played by a given note stored?

    ... or is this not how it works and actually ALL articulations that are used within a sequence have to be ENTIRELY in ram (as parts of a huge matrix) EVERY time i hit the "free memory"-button??

  • If it works like Kontakts purge feature, its not 'as you go'. The piece would need to be semi-realized before you purge it, or you'll end up needing to reload the instrument into RAM since the samples you'll need won't be there.

    Its still a kick-butt feature mind, its just that its kind of, when you're done kind of thing.

  • joseph,
    you say its a "when you're done kind of thing" - but then again when i am already done with a track i could just as well freeze [:D]. i hope you are not right, since the video at least seems to indicate that this function offers more.
    for instance when i have recorded already 10 different articulations on a track (including those cool but probably ram-hungry combis an average sequence uses only a few samples of) and need to tweek say one staccato note. does this mean i have to load all 10 again? "in the old days" with 10 different tracks one could "defrost" only one of them and keep the rest as it is. i hope something like this is possible here too because otherwise to use this new function would require even more ram than before [[:|]]

  • I can't say. What you're asking for isn't clear from the video as a whole Matrix was unloaded/reloaded. I'm not sure how that would work in the grand scheme of things for just one articulation.

  • The memory management will work in a similar way to the RAM save features that have been available for other samplers such as Halion and Kontakt for several years... this is nothing new.
    e.g. not good enough from my perspective.
    If requires you to play in the midi notes for it to learn them... then manually press a button to unload the samples that it didn't play.
    If you then use an unloaded note, you will not hear anything until you physically reset the ram save.
    Very simple really... and it is because it is so simple and reliant on us to set it up... that I don't like it. Performance features (and I mean IT performance features) should never be exposed through the API to the user. They should take place under the covers.
    The big issue I have is that in a large orchestral composition, you may not notice when some notes are not being played unless you solo each instrument all the way through. Especially if you cut and paste parts like I do...
    It is a far-too-simplistic a model. Such RAM handling features should not be exposed to user error but should be handled under the covers... it is not that difficult to lazily load samples when they are first used or indeed to unload samples that we 'detect' have not been used for quite some time... this is a standard IT technique that I use all the time in my day-job as an IT developer.
    And again, I emphasise that this is hardly revolutionary... just re-creating the work that other sampler vendors have been using for a couple of years... with presumably similar bugs?

  • just to clarify:

    the RAM management features in other sampler platforms is based on our concept
    we offered these ideas some years ago, so that our users can profit from this also on other sampler platforms

    best
    Herb

  • last edited
    last edited

    @herb said:

    just to clarify:

    the RAM management features in other sampler platforms is based on our concept
    we offered these ideas some years ago, so that our users can profit from this also on other sampler platforms

    best
    Herb


    herb,
    thanks for your reply, but it didn't answer my initial question ...
    i'm really curious if this function allows me (like freeze did so far) to use more articulations and performance instruments for a given track than i can load into ram at the same time.
    thanks in advance
    kai

  • Did you watch the Ram management video?

    From that I gather that you can indeed benefit greatly from it. Lets say you have a violin performance. Once you have nailed it like you want it you tell the program to discard all unused samples. This will reduce the amount of samples loaded into your ram dramaticly. Now with all the extra space you could a new instrument, and do that trick again once you have nailed th passage.

  • last edited
    last edited

    @Christian Marcussen said:

    Did you watch the Ram management video?

    From that I gather that you can indeed benefit greatly from it. Lets say you have a violin performance. Once you have nailed it like you want it you tell the program to discard all unused samples. This will reduce the amount of samples loaded into your ram dramaticly. Now with all the extra space you could a new instrument, and do that trick again once you have nailed th passage.


    Yes I did watch the RAM Save video... it was like deja vu and reading the Halion manual all over again [[[[;)]]]]
    But seriously, I don't like the approach particularly; it find it very clumsy...
    A better approach would be to automatically detect this under the covers and never expose this?
    I don't want to unload half my instrument manually, or even have to think when would be a good time to consider doing that! I don't want to unload them, then copy and paste a new part and not notice the missing notes... it is all too much of a pain... why can't the VSTi automatically detect the unused samples (say - by timestamping each sample) and unload them after a period? It has more knowledge than I do... it is a computer! Then, if I use them again, lazily load them in the moment the midi note arrives? This is EASY to implement... as an IT architect and developer, I'll show you how [[[[;)]]]]
    My choice on the matter would be if the VST didn't load any samples AT ALL when I loaded my patch and had the option to just pull the notes from disk rather than memory, with the obvious and expected latency (which I could live with for the sake of the massive upside of flexibility especially since I always notate my compositions using the mouse).
    I write this sort of lazy loading code all the time in my day job so know it is easily possible.
    Exposing this sort of performance tuning into the user interface is clumsy and error prone. I'm always having a go at developers for doing this. I don't give the guy at the shop instructions for how to best find the washing machine I am after in the warehouse... that's his job... not part of the client/customer relationship. The same customer principle applies here with the user interface...
    Not having a go, just pointing out opportunties [[[[;)]]]]
    I have been pointing this out to Steinberg for sometime now and I believe they may even be implementing this in the next version (he says hoping).
    For those of us who don't care about real-time playing, why can't the VST act like a sample-file indexing tool that streams the samples into memory as they are played and doesn't load anything other than program parameters? This could be optional for those of us who don't care for real-time playing.
    THEN - and this is the real-plus, you could have the entire VSL library running on a single lap-top... or integrated into a single DAW program with zero load times... FANTASTIC... so long as you had the disk-space for it... the disk is the memory... sort of.
    Then I may consider upgrading... should be a 1 day job to implement I'd have thought...
    Now that would be worth some money (even if it is easy to implement [[[[;)]]]]

  • last edited
    last edited

    @paynterr said:

    should be a 1 day job to implement I'd have thought...
    Now that would be worth some money (even if it is easy to implement [;)]

    I agree it would be a good option to have sometimes, but as a software architect you also know that your 1 day guess should be multiplied by the standard murphy-and-time-optmism factor before it becomes a valid estimate. Never underestimate a task involving software...and it would complicate the logic in the sampler engine. I wonder if anyone ever has tried to implement a diskram rather than the old ramdisk? [8-)]

    /Mattias

  • The disk ram would'nt last very long, as memory is getting cheaper, why avoid it ?