Vienna Symphonic Library Forum
Forum Statistics

195,339 users have contributed to 42,978 threads and 258,212 posts.

In the past 24 hours, we have 2 new thread(s), 9 new post(s) and 57 new user(s).

  • Questions, suggestions

    On the whole, I'm extremely pleased with my recent VI leap. So, congrats to Golem and the VSL team! One of the first things to really strike me (well, there are many), and something that I didn't expect, was just how improved the actually sound quality is... seems much cleaner, and more vibrant. Don't know if this is just me, or if it's the 24-bit, or what, but it's very impressive. Also, it seems to me that some of the instruments I've grown accustomed to sound quite different. Are there more new samples than meet the eye; i.e., were some instruments we already know actually re-sampled, or re-engineered somehow?
    Anyway, great work!

    Regarding memory management, will the VI dip into virtual memory if you pass the available-RAM-per-app limit, or will it crash? (I guess I could just try it, couldn't I...) I'm wondering this because it seem to me that the memory management features (which are great, btw) work on the assumption that we can load the samples we want VI to "Listen" to in the first place. Once we've Optimized, no problem, but how do we manage the Listen part when RAM is at a premium?
    And on that note, would it be possible to implement some sort of "Level 2" memory management system for the Listen function, whereby extra articulations are only accessed by the Listen process itself? I'm thinking particularly of speed-related repetitions and legato instruments, perf-trills etc., which could be used automatically, and without user-tweaking, by the Listen function alone, but not used for composition/realtime playing. The idea being that when you hit "Listen" and start playback, the Listen function replaces the currently loaded samples with references to the more advanced, performance-related samples. When you hit Optimize, it does what it already does, but in addition, loads notes from articulations that aren't actually loaded (perf-trills, speed legs, reps, etc.) for the final, optimized version. This would obviously make for a larger "optimized" version, but would take a big bump up in musicality, and since full maps of the advance performance material would never be loaded, would probably not use too much RAM.
    Anway, just a thought.

    J.

  • ...oh, damn, almost forgot.

    Would it be possible to integrate the "loading" alert into the VI window? It's really annoying that (at least on OS X) the alert always pushes itself to the front, thus bumping you off anything you might be trying to do while an instrument is loading. Doesn't seem necessary, and it would be good to do things (like post to the forum!) while instruments are loading in the background.

    J.

  • Okay, so another option... I'll just keep posting my ramblings until somebody tells me to shut up! [;)]

    Would it be possible to have a "placeholder" state for a matrix/cell? The idea is to be able to build patches, but selectively load/unload the memory on individual articulations. This would make it possible to specify, in advance, detailed patches, but only actually load the RAM for the articulations we need, when we need it. This could, obviously, be done in conjunction with the Memory Manager functionality. The workflow would be something like this:

    1) design an exhaustive instrument, with all the articulations you require
    2) unload the memory for the articulations you _don't_ need in a given passage
    3) record the passage
    4) otimize in memory manager

    If another special articulation in your master patch is required:

    1) buffer the memory for that articulation (it's already in the patch, so no need to alter any controller mappings you may have created)
    2) optimize the passage again in memory manager

    The default behavior would be to buffer the samples when adding a patch/matrix, just as it is now, so that the option of freeing memory _without_ altering your patch would be an added feature.

    Just a thought... probably more to come.
    (Sorry if it's bugging anyone.)

    J.

  • Oh, oh... I'm daft. Not to mention the fact that I'm talking to myself!

    I've just realized that I could do a similar thing to what I'm after by building a patch with empty cells and/or matrices! Very cool! (As long as I write the layout of my master patch design down somewhere, since the empty cells won't help me remember it...)

    Anyway, I give up. You guys did, in fact, think of everything. [;)]

    cheers,

    J.