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

VST, AU, AAX, CLAP, etc. Plugin Virtual Instruments Discussion
RELATED
PRODUCTS

Post

SSDs can be chock full and their read performance doesn't really degrade. So that statement is not completely true. :)

Post

SSDs used to typically ship with a large amount of reserved diskspace, so can't ever become 'chock-full', has that changed? I've read 'in the past' where extra unallocated space was also good luck for the ssd internal filesystem maneuverings. As for spinning disks used by recording musicians, I'm 'guessing' that fragmentation of large files gets worse as the last 20 % of a disk is used. Then trying to cram in a new sound library purchase on a drive with little space to spare sounds like bad luck on the hoof to me. Drive failures happen, I hope I can help my stack to last longer.

Even NI products seem to require five times an installer's size in contiguous diskspace, just to 'maneuver' during the install, so there may be different definitions of 'chock-full' in the wilds.

And there are always 'slow loading time' topics in the forums, so I think many people would benefit from not pushing their luck, when drive space in various forms is delightfully inexpensive.
Cheers

Post

Yeah over-provisioning on SSDs is an option you can toggle, not something that is fixed.

Post

worried about Vital's preset disk usage? wait till you get suckered into omni and kontakt
HW SYNTHS [KORG T2EX - AKAI AX80 - YAMAHA SY77 - ENSONIQ VFX]
HW MODULES [OBi M1000 - ROLAND MKS-50 - ROLAND JV880 - KURZ 1000PX]
SW [CHARLATAN - OBXD - OXE - ELEKTRO - MICROTERA - M1 - SURGE - RMiV]
DAW [ENERGY XT2/1U RACK WINXP / MAUDIO 1010LT PCI]

Post

Peter H at the Vital forum mentioned that you can save 100k per preset by shrinking the whitenoise sample...

https://forum.vital.audio/t/patch-size- ... ed-of/4112

Post

layzer wrote: Fri Jan 15, 2021 1:27 am worried about Vital's preset disk usage? wait till you get suckered into omni and kontakt
What problems have you experienced with these 2 plug-ins that you don't use?
I lost my heart in Cap de Creus

Post

OMG. 4000KB's? Holy shit! This place sometimes... :help:
Imagine being bent out of shape about something that's 4MBs and exaggerating your outrage by expressing it as 4000KBs!!!!!!!!

:dog: :dog: :dog: :dog:

Post

EvilDragon wrote: Thu Jan 14, 2021 8:48 pm
fmr wrote: Thu Jan 14, 2021 7:14 pmPretty much any wavetable synth I'm aware of store their wavetables in a wavetable folder, and then reads them from there.
Surge doesn't. Nobody really objected to this.
I didn't notice that (it's been sitting on my computer, but so far I didn't do anything with it. I'm waiting for a stable version that includes all the promised changes. But if it doesn't, then it should. It's in your hands :shrug:
Fernando (FMR)

Post

Surge is quite stable since 1.7 really. 1.8 is gonna be released on Sunday. Please define what are "all promised changes"? We're usually not promising anything (just sometimes mildly hyping something up, but we never explicitly said "we promise to get this done for x.y" I don't think). Everything is always in a stable state of flux (like, we reserve the right to pull some features from current milestone and move it to a later release), and GitHub milestones are open for everyone to read and comment on.

The hard truth is that it's far easier to just embed the wavetable. If it's referenced, it's a waterfall of things that need to be taken care of (missing wavetables, how to deal with that, duplicate WT filenames but different WT content, etc etc etc.), and that stuff is not necessarily straightforward or fun to deal with. At Surge Synth Team, the keyword is "fun", not banging our heads against the wall to get something finished (although, VSTGUI, UI scaling across DAWs, weird issues in Live and FL... can leave some scars!). After all, it's all done as a hobby in our free unpaid time.
Last edited by EvilDragon on Fri Jan 15, 2021 1:48 pm, edited 3 times in total.

Post

Please let's not mix up things
1.) Use Case: Editing Presets on my own, or using the Synth in a Project
I really don't like to get by default the White Noise Sample blob in every of my Patch even if I don't use the sample player at all. Just doing a Sawtooth-Filter-That's-It-Patch contains the whitenoise sample. The consequence of doing this is that if I create 100 patches I have stored 100 times the same whitenoise sample waste as a base64 encoded string. JSON text encoded binaries is btw a very good idea;-) Oh no wait ... that is waste! And unwanted waste, and unclever wasting my resources gives me headaches
I participated in the Vital OneSynthChallenge - And the Vital Project is really slow in loading and saving because of waste and clutter.
2.) Use Case: Sharing and Exporting Presets: The conceptual problem is that Matt choose to use the *SAME* format for exporting a preset and managing them locally. If he chose to use ".vitalexp" as an export-fully-self-contained format additionaly then he could optimize for both use cases. And second thing is that he forgot to use "logical" names to reference stuff. What do I mean.
If i import a vitalexp patch which contains full sample data as well as a logical name for the sample then vital could try to match it to my current collection and say while importing ... oh well, it's already there, I can use the .vitalexp file without again adding a new sample to my collection...
The result would be a .vital patch which has just a "logical name reference" to a sample or wavetable which has been imported earlier.

Anyway, I tend to not dicuss about the two points I have mentioned, just use it as my two cents.
But I really get headache if somebody waste my resources with unsable waste/noise, even if we live in the age of terabytes ... nevertheless stupid waste ... sigh ... I repeat myself.

Just my two cents ...

Post

EvilDragon wrote: Fri Jan 15, 2021 12:23 pm Surge is quite stable since 1.7 really. 1.8 is gonna be released on Sunday. Please define what are "all promised changes"? We're usually not promising anything (just sometimes mildly hyping something up, but we never explicitly said "we promise to get this done for x.y" I don't think). Everything is always in a stable state of flux (like, we reserve the right to pull some features from current milestone and move it to a later release), and GitHub milestones are open for everyone to read and comment on.

The hard truth is that it's far easier to just embed the wavetable. If it's referenced, it's a waterfall of things that need to be taken care of (missing wavetables, how to deal with that, duplicate WT filenames but different WT content, etc etc etc.), and that stuff is not necessarily straightforward or fun to deal with. At Surge Synth Team, the keyword is "fun", not banging our heads against the wall to get something finished (although, VSTGUI, UI scaling across DAWs, weird issues in Live and FL... can leave some scars!). After all, it's all done as a hobby in our free unpaid time.
Please don't take it personally. I understand the nature of your work, and I am thankful for it. :)

If you think that's the way things should be, so be it.
Fernando (FMR)

Post

Oh I'm not taking it personally :) I'm saying that's how it is now, it's not likely to change soon. That said it's not impossible to change it or add it as an optional workflow - it's just not "fun to do" as opposed to adding more filters, oscillators, effects, etc. But it probably won't be coded by our current team of coders, I don't see it happening personally. But that's IMHO, there's a few other coders with their own opinions on things. :)


Would still like an answer to "all promised changes", what are they? (Also feel free to move this to PM.)

Post

The only mention I recall that could loosely be construed as a promise,
is that new nightly builds are often available. Having Surge, Vital, and Odin2
cross-platform synths available means that almost anyone can get a used or cheap midi controller and have three powerhouse instruments and the Surge effects, just to start with. Thanks for your many contributions.
Cheers

Post

Back to topic - Vital Patch Sizes
I have proposed to create a new file format ".vitalz" which is basically a vital patch wrapped into a zip file.
Because Vital uses JSON text format which is bloat in itself and the patch contains sample data as text zipping could do some magic here: https://forum.vital.audio/t/add-new-pat ... chive/4700
I would propose to add it to the 1.1 stream.

I did an experiment:
I started with one of my Mellotron-based Vital Patches which is 1.5 MB in size
After applying LZMA2 (7Zip) Compression Algorithm it was about 900 Kb left.
So I think my Idea would work and would reduce data bloat considerably.

Post

] Peter:H [ wrote: Fri Jan 15, 2021 12:25 pm 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.

Post Reply

Return to “Instruments”