Well, just stop using so damn many notes! [;)]

I'm not sure... it seems to me that the dynamics remain flexible but the articulations are "locked". But when you're talking about basically using all the RAM during the course of the piece, then RAM optimization is kind of a moot point, isn't it?

I am kind of confused about your piece, though... Such a tiny RAM improvement would imply that you're using almost all the pitches for all the articulations; is that really the case?? I suppose it's not too hard to imagine, over the course of an 18-minute concert piece, but still, that seems like a *lot* of articulation switching...

J.

@jbm said:

Another option that might be nice is a "Learn then Load" option: same idea, but running the "Learn Music" step *first*, then only loading the learned pitches from all articulations in the preset. This would be essential for working on a single computer, or a smaller "farm", since you'd never get all the articulations loaded in the first place, and how can you optimize when you can't even load?

J.

Even better idea.

One reminder: if I understood the tutorial correctly, the dynamics are saved only if Velocity Xfade is enabled. In that case, all velocities are part of the playback note even if you're not hearing them. If Xfade is not enabled, only the sample triggered by a given note velocity would be "learned."

Aaaah, very good point! Yes. Makes sense. So that makes me wonder whether the Learn function is inserted somewhere between the matrix and the actual sample database(??). That is, just spying on the sample references and storing them in an array, or something... That might make things a little trickier, since there may not be any actual note info by the time the Learn function runs, only sample references. Still, considering that a "Learn Music" option would just be storing references to *all* articulations for the input note list, it shouldn't be too difficult. Anytime you're dealing with 'everything' it tends to be a bit simpler; it's the designation of specific subsets that complicates things.

Anyway, I'm just flapping my gums at this point.... cheers.

GREAT IDEA!!!!!!! VSL please consider this!

Thanks,
Jay

The "Learn" function simple memorize which samples are triggered during the "Learn" period is active.
If the velocity XFade is active, simply four velocities are triggered at once, so all velocites of a certain key are memorized, that's all.

The sample database itself knows nothing about the mapping structure or the matrix design, so it's impossible to make any intelligent calculations.

best
Herb

But Herb, VSL has made a business out of transforming the "impossible" into the "possible!" [:D]

Best,
Jay

@herb said:

The "Learn" function simple memorize which samples are triggered during the "Learn" period is active.
If the velocity XFade is active, simply four velocities are triggered at once, so all velocites of a certain key are memorized, that's all.

The sample database itself knows nothing about the mapping structure or the matrix design, so it's impossible to make any intelligent calculations.

best
Herb

The sample database doesn't need to... hmm... Wait. Are you saying that the Learn function currently listens only to the return of the sample calls, not the sample calls themselves?
Either way, this wouldn't happen during playback, of course (since you wouldn't want all the articulations to play back!), but would rather be done after the "optimize" button was clicked, and just before the samples are actually dumped from memory.
It seems to me that, even taking the above into consideration, it would still be relatively simple to implement. The VI is realtime anyway, so it can't take long to call a sample reference based on a pitch/velocity pair. Just store the pitch/velocity pairs while Learn is active, run a quick loop calling those pairs from all loaded matrices, then update whatever map is used for the memory optimization step. Obviously, I've no idea how the VI actually works in this regard (so this is totally naive 'advice'), but wouldn't this do the trick? I suppose it could take 2 or 3 ms longer, but I wouldn't lose any sleep over it! [;)]
I can imagine that a "Learn then Load" function would be much more difficult, since I'm sure the loading is currently done without any reference to the state of the VI...

J.

Please keep in mind, that the mapping structure on patch level (which you dont see) is pretty advanced, there are patches which use up to 200 different samples triggered by the same key.
It depends on velocity, speed, intervalls, repetition counts and more which wav file is triggered.

best
Herb

@herb said:

Please keep in mind, that the mapping structure on patch level (which you dont see) is pretty advanced, there are patches which use up to 200 different samples triggered by the same key.
It depends on velocity, speed, intervalls, repetition counts and more which wav file is triggered.

best
Herb

Sorry... very true. I don't know that in detail, obviously, but I understand that it must be the case.

However, that would still be the case in the "Learn Music" option I'm talking about - it wouldn't change. What I'm suggesting is that, if playing one pitch on a given articulation requires 200 samples for all the realtime stuff to work, then those 200 samples should *all* remain in RAM. The idea is to retain 100% felxibility *but only for the notes in your piece*. The RAM savings won't be anywhere near what you've managed with the general purpose Learn scheme, but considering that many pitches will likely not be needed, they will still be considerable in many cases. Obviously, if your piece uses every chromatic pitch, for the entire range of the instrument, then such a function would offer 0% improvement! [;)] However, in such cases you'd probably just do all your tweaking with a non-optimized VI, then optimize when you were done, since you would know beforehand that you were going to use just about ever sample available!

But the more I think about it, it seems as though this idea of mine is really a matter of creating a sort of "partial keymap". The function would keep a record of all the pitches used in the score, then dump all the samples for any pitches that weren't used. And actually, it might even make sense to only perform this optimization step for the more "costly" performance instruments, since the more "effect" oriented articulations, like trills, trems, pizzes, and so on, are used pretty deliberately during composition; it's not likely that one would be nit-picking about whether to use a perf-legato, a perf-detache, or a pizz sample! So perhaps it could just optimize performance patches? Any sense in that?

Please keep in mind, I'm not trying to drive you mad, just rattling off some possibilities! [;)]

J.