Vital's preset sizes very large - my disk space!!

[Tj Shredder]

One could use such a zip format for patches including the wave tables, and the other to save them without. If you load a .vitalz it could ask you to convert it and save the containing wavetables at a default place. Then the identification must not be the file name though, as it would easily happen that different wavetables have the same name...
If you want to share, you need to export/save as...

[Koshdukai]

One could use such a zip format for patches including the wave tables, and the other to save them without. If you load a .vitalz it could ask you to convert it and save the containing wavetables at a default place. Then the identification must not be the file name though, as it would easily happen that different wavetables have the same name...
If you want to share, you need to export/save as...

Indeed. Vital could use that .vitalz as an export/import format for preset(packs) exchange which would obviously include everything the preset needs.
Importing .vitalz's would save the preset part as a wavetable-less preset file and dump the wavetable(s) to Vital specific resource folders where something like <checksum>.<OriginalWavetableName>.<ext> file naming scheme could be used, to help keeping duplicates to a minimum i.e. if there's already an existing 123456789.XYZ.wav file in there, there's no need to save another copy.

[Tj Shredder]

Well, its easy to check similarity even without storing a hash in the file itself...
If we could agree on a universal wt file format, we could store wavetables for all wt synths supporting it at a common place like we do with VSTs already...

[Koshdukai]

Yeah.

Just suggested that name format as middle-ground solution, since that would still allow duplicates of renamed WTs.
Actually, let me edit that post and switch the positions from <OriginalWavetableName>.<checksum>.<ext> to <checksum>.<OriginalWavetableName>.<ext> which would help to quickly find those, visually, just by sorting by filename

Anyway, there are better ways to keep dups to minimum. It's in Vital's dev's hands to make that a reality.

[] Peter:H []

choose to use the *SAME* format for exporting a preset and managing them locally.

i like your idea of using different methods for local storage and file export.

So if a preset is stored localy, different presets with the same wavetable, sample, lfo use only one file as a source. And if you export presets it adds the needed wavetables, samples and lfos one time into the vitalbank. Or something like that.

Think this would be a cleaner way then just compress the multiple WT, SMP, and LFO data.

But on the other side this sounds like a lot of things to do, to make it work. And it has to work with presets from older versions and stuff. What would happen if two WT´s have the same name and different audio data in it, and lots of stuff like that.

And for example i have about 3,5 GB of data in my vital folder and it´s allready more than i´m really using. So i´m not sure it´s worth the effort, to change the file size of vital presets.

Another thing is when someone tries to make a big complicated project perfect, he will probably never finish it. Even big companies with many people can´t think on everything and have to make compromise from time to time, witch includes some things are hard to change at a later state.

Hey garryO,

you're completely right with all what you say.

And you're right as well with that may ideas mean "a lot of thinkgs to do". You mentioned "naming clashes" with samples with the same name but different content. True, I would add a "content based hash value" along side the name, so "This is my sample", 0xaabbccdd is different to "This is my sample", 0xeeffeeff. The Patch would then reference the name+hash pair and not only the name.

(Edit: Oh only after writing my post I saw that the checksum idea has already been mentioned before )

Anyway that's making it even more complex ... and actually, I'm just thinking loud with all my IT background of being like 20+ year in SWE. Finally it's about Matt and the community. When most say ... damn I don't care about disk space ... give me more filters ... then my suggestions will be to the bottom of the priority list anyways.

So let's wait and see

[garryO]

This is the problem you could do so much, but time is short...

Sorry but i would vote for filters or stuff like that

I hope the bugfixes and makinging vital work with different daws and computers goes fast! I´m sure when this is done mostly, new things are planned/almost ready for release and maybe some holliday time for matt.

[Teksonik]

Create a very small .wav file then load that into the SMP Osc. Then save that as your INIT patch. It will make every patch you create smaller if you don't then load another sample into the SMP Osc.

I agree that stability across all platforms and DAWs and CPU optimizations should probably be the priority now.

[] Peter:H []

Create a very small .wav file then load that into the SMP Osc. Then save that as your INIT patch. It will make every patch you create smaller if you don't then load another sample into the SMP Osc.

Sure, that was exactyl my tipp here: https://forum.vital.audio/t/patch-size- ... ed-of/4112

I agree that stability across all platforms and DAWs and CPU optimizations should probably be the priority now.

Definitely ... in some post I suggested to put such a change earliest on the 1.1.x stream after ironing out all high prio bugs in 1.0.x

[Tj Shredder]

Certainly it should be easy to exclude any factory wt, and don’t save it if the smp isn’t used...