Should my MacBook Pro M2 be performing better?? Or is this how VST life goes with only 16GB

[MartinH.]

I understood.


But these are just tautologies: "they're big because they're big"; "they're big because they were smaller and got bigger". An explanation, on the other hand, would look like "each zone entry refers to a sample's full pathname and there's no dedupe" (though that would require ~3million entries to get to 1.5GB.)

I've worked on plenty of systems more complex than this, and even those involving some flabby interpreted DSL had a significantly smaller footprint.

I mean, wouldn't it be a bit annoying (yet useful) to discover it was 1.5GB of sample filenames?

I got curious and found this breakdown for Symphobia 1 (without any instrument loaded, just the blank all-in-one patch) under the "expert/engine" tab in Kontakt 6:



My first interpretation of that was that the groups where the sampler is set to TM Pro always loads the sample, even if it isn't used at all. But loading adaptive synced articulations further increases the "sample memory used" value and it can total up to almost twice what is listed here under "TM Pro Voice Memory" if you touch the mic balance slider to load the second mic position (if applicable).

It does seem a bit excessive to me too. I was trying to find out how many samples there are in Symphobia 1 and couldn't find a clear number anywhere. The zone IDs go up to about half a million. If that's a good approximation it would be roundabout 2kb of data per sample. That still seems like more than it should be, but would not be as outrageously high as I expected at first seeing the 1gb for an empty (!) instance.

My conclusion is that the all-in-one patch approach is a deadend for huge kontakt libraries and it will factor into future purchasing decisions for me. I'm still using the patches from an older version of the library because the new ones also bloat the project filesize and save/load times too much. Ideally I'd prefer single articulation patches like in the Metropolis Ark series.

 

[Guy Rowland]

I understood.


But these are just tautologies: "they're big because they're big"; "they're big because they were smaller and got bigger". An explanation, on the other hand, would look like "each zone entry refers to a sample's full pathname and there's no dedupe" (though that would require ~3million entries to get to 1.5GB.)

I've worked on plenty of systems more complex than this, and even those involving some flabby interpreted DSL had a significantly smaller footprint.

I mean, wouldn't it be a bit annoying (yet useful) to discover it was 1.5GB of sample filenames?

No, it's not a tautology. I explained that these extra layers of facilities act as multipliers. You need 10 x 6 x 5 x 7 x 12 x 6 zones or whatever it is. Each extra layer of complexity causes a huge scaling up, an order of magnitude of difference rather than a few extra mb here or there.

@MartinH - interesting sluething, thanks. I think these big patches can be really user-friendly, but it's good to have a more svelte alternative for templates, mobile rigs etc.

 

[aldous]

No, it's not a tautology. I explained that these extra layers of facilities act as multipliers. You need 10 x 6 x 5 x 7 x 12 x 6 zones or whatever it is. Each extra layer of complexity causes a huge scaling up, an order of magnitude of difference rather than a few extra mb here or there.

I understand multiplication pretty well I was asking for specifics: what those layers are, what objects they're composed of, and what determines those objects' counts and sizes. I only asked because you implied knowledge of memory management and the instrument's implementation; without that, the question may not have been clear - I think this is where we've got stuck.

I got curious and found this breakdown for Symphobia 1 (without any instrument loaded, just the blank all-in-one patch) under the "expert/engine" tab in Kontakt 6:

Thanks, that's really useful - or will be, when I find an instrument amenable to experimentation.

AIUI, "Sample Management" refers to sample locations in Kontakt... I was joking about MSB being 1.5GB of filenames before, but seeing that 120MB of "Sample managm. memory" makes me wonder

It does seem a bit excessive to me too. I was trying to find out how many samples there are in Symphobia 1 and couldn't find a clear number anywhere.

The value of "Sample Memory Used" after loading, minus its unloaded value, all divided by "Preload buffer size" should be pretty close too, I think? (It'd double-count very short samples, but I don't think preload goes high enough, realistically.)

If that's a good approximation it would be roundabout 2kb of data per sample. That still seems like more than it should be, but would not be as outrageously high as I expected at first seeing the 1gb for an empty (!) instance.

Not outrageous, no. It'd be jumping the gun, but I've a feeling my question will turn into "why aren't these objects flyweighted?" and/or "...shared copy-on-write between instances?" (Of course maybe they are, and it'd be even worse otherwise.)

 

[jbuhler]

I got curious and found this breakdown for Symphobia 1 (without any instrument loaded, just the blank all-in-one patch) under the "expert/engine" tab in Kontakt 6:



My first interpretation of that was that the groups where the sampler is set to TM Pro always loads the sample, even if it isn't used at all. But loading adaptive synced articulations further increases the "sample memory used" value and it can total up to almost twice what is listed here under "TM Pro Voice Memory" if you touch the mic balance slider to load the second mic position (if applicable).

It does seem a bit excessive to me too. I was trying to find out how many samples there are in Symphobia 1 and couldn't find a clear number anywhere. The zone IDs go up to about half a million. If that's a good approximation it would be roundabout 2kb of data per sample. That still seems like more than it should be, but would not be as outrageously high as I expected at first seeing the 1gb for an empty (!) instance.

My conclusion is that the all-in-one patch approach is a deadend for huge kontakt libraries and it will factor into future purchasing decisions for me. I'm still using the patches from an older version of the library because the new ones also bloat the project filesize and save/load times too much. Ideally I'd prefer single articulation patches like in the Metropolis Ark series.

The new gui is quite lovely but I can’t say that it has solved the difficulty of use problem for the Symphobias (I have the first three). The sounds are often beguiling—and this was true of the first version too—but I find them hard to work with and the new versions haven’t helped that. So even without the bloat I’m not sure the all-in-one patch approach facilitates use. At least not the way I want to use them.

 

[MartinH.]

AIUI, "Sample Management" refers to sample locations in Kontakt... I was joking about MSB being 1.5GB of filenames before, but seeing that 120MB of "Sample managm. memory" makes me wonder

Maybe you could find a library with a known number of samples, batch resave to absolute filepaths, take a memory measurement, move it to a considerably longer filepath, batch resave to absolute paths again and re-measure the memory consumption. The delta should be just the potential increase in file path length I would hope.

The value of "Sample Memory Used" after loading, minus its unloaded value, all divided by "Preload buffer size" should be pretty close too, I think? (It'd double-count very short samples, but I don't think preload goes high enough, realistically.)

Not outrageous, no. It'd be jumping the gun, but I've a feeling my question will turn into "why aren't these objects flyweighted?" and/or "...shared copy-on-write between instances?" (Of course maybe they are, and it'd be even worse otherwise.)

Probably best we just ask @Wytse @ ProjectSAM how many samples there are in Symphobia 1 and why an empty instance of the all-in-one patch takes up so much RAM :D.

The new gui is quite lovely but I can’t say that it has solved the difficulty of use problem for the Symphobias (I have the first three). The sounds are often beguiling—and this was true of the first version too—but I find them hard to work with and the new versions haven’t helped that. So even without the bloat I’m not sure the all-in-one patch approach facilitates use. At least not the way I want to use them.

I don't have enough experience to make any meaningful comments on optimal workflows, I can just say that for me I feel the least amount of friction when I have single-articulation patches where it takes just one click to switch between modwheel dynamics and key velocity dynamics. I'd rather solve things like keyswitches with tools like flexrouter because that allows me to combine different libraries. The whole all-in-one patch concept would make more sense to me if it wasn't part of one specific library. I would want the workflow to be unified accross libraries and for that I need libraries to offer single articulation patches to use with such an external system or else I'm jumping through yet more hoops trying to make keyswitched libraries not be keyswitched etc..

 

[aldous]

Probably best we just ask Wytse @ ProjectSAM how many samples there are in Symphobia 1 and why an empty instance of the all-in-one patch takes up so much RAM :D.

Well, we could... I guess... if you want to pass up a perfectly good maths opportunity...