Another thread made me curious about this. Since VCV patch files can contain samples and other data, which sampler modules store samples in patch files?
1 Like
My TapeRecorder does it.
1 Like
Neat, thanks!
Curious how often this is done or possible. Pinging some folks @baconpaul @sickozell for thoughts. It would be great for things like wavetables and samples, esp when moving patches to different computers or sharing with others.
Surge wt stores wavetables in patches but I was unaware of this sample file approach so if stores as base64 encoded string in the json, I may change that with the next release
2 Likes
last I knew (a long time ago, now) all DAWs stored references to the wave data, they didn’t make a copy of it. It was thought to be too wastdul of disk space to put all your audio into a session file. Things are different now, I guess.
I think if the sample is not too big it can be saved in the patch file, let’s say with a limited number of samples, otherwise it has to be loaded using an external audio file. This hybrid solution might be the wise one. As @baconpaul did, to maintain patches easier to transport, I’d prefer it should be converted to a string in the json, along with its samplerate to allow it to be resampled on initialization or when the working samplerate of vcv changes. Maybe in a future update this system will be implemented in the wavetabler and drumplayers, where usually the samples loaded in are short.
[edit] Sorry, I didn’t realize that @Ahornberg 's tape recorder stores the real wav in the .vcv file. It’s a very good idea
It is pretty easy to store large sample data in the patch file. It is explained in the manual and the Fundamental WTO can act as a good example.
However, if you want to save sample data in a preset file or in a selections file, you have to serialize the data inside the .json file.
In my module TapeRecorder, I deeply hacked the Rack to store the sample data in presets without serialization to .json, but instead as a separate .wav file.
2 Likes
I was thinking, however, that by keeping the audio data either in the json or as an audio file, every time there is an autosave the system saves everything again, with an increase in the necessary resources, right?
Of course, saving large amout of data needs ressources. But saving is done in a lower priorized (background) thread.
reading the manual saving audio files seems the best solution compared to serialization, in terms of resources.
however in either way you shouldn’t lose the links to the original files. I say this because my players use references to scan and browse samples from the same folder, and it would be a shame to lose this feature. I have to think very carefully about how to combine all of this.
3 Likes
Awesome @baconpaul and @sickozell I’d love this feature for both Surge and your Sampler modules. Thanks for considering.
A lot of DAWs have a Collect all and save samples feature which pulls all referenced files into the same folder as the DAW session. Since VCV files are self-contained, this could be alternative, though I agree it make patches much larger depending on how many samples are referenced.
Ideally, it would be an option to choose between referencing locally or saving in patches, but ultimately I’d prefer portability for my patches with samples.
Surge already stores the wave table in the patch as I mentioned. It just doesn’t necessarily do it in the most efficient way (but is a way which works for presets)
The wave tables are pretty immutable so I might hash the encoding at least …. Probably new surge release in the early fall so I will add an issue pointing at this thread
2 Likes
Got it, thanks for the clarification.
Sure, it’s nearly trivial. That doesn’t mean it’s always a good idea, thought. In many cases, I’m not sure it always is.
What would you have recommended that my SFZ player save in a patch? It would be easy to save all the samples in the patch, but SFZ sample sets are often in the gigabytes.
And yes, as everyone has said, saving a wavetable or short sample is a fine thing to do (imao).
My personal guideline is: If I save a patch and reopen it later, all audio data should be accessible without reloading additional files by hand.
Yeah, but that’s true with any sane way one might store media files on a disk. You know, just put the path in the patch. This feature, saving samples in the patch, is so you can transfer the patch to a different computer. Is that what you require?
I think of it like synth presets such as Serum or Phase Plant. A few megabytes to achieve this is a reasonable sacrifice. Definitely wouldn’t want it for multisamples like SFZ which are external. But if I had a drum machine patch, with 8-16 samples, it would be ideal to save them in the patch.
1 Like
Yes, there are 2 different requirements:
- save and reopen the patch on the same machine
- save and reopen the patch on a different machine
In the first case, saving the path of the used audio files does the job, but only for (audio) files that already exist.
If audio is recorded inside VCV Rack, I think it’s a good way to save it with the patch. Otherwise the user has to specify path and filename for the recording. If the audio is recorded to be used outside the Rack, then it is a good thing to let the user specify path an filename.
In the latter case, it would be more handy to have everything inside the patch.
2 Likes