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.
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.