Sampleconstruct wrote:There is a bug in v 4:
When trying to save the Vapor Buffer to .wav it always saves to aiff - I tried several times, no luck. As I never use aiff this would be helpful if it worked.
EDIT: And when listening to the files that were save from the Buffer they sound nothing like the sounds I heard when saving - it's mostly the unprocessed audio before it even hit crusher with some strange artifacts included.
I see the saved vapor files are 32 Bit - where can I change the defaut format - I can't use 32 Bit Audio in my DAWs.
This bug is known and can be workaround by just add ".wav" extension to file name in the save dialog. The decision of the file format is done by the extension and we have to rework that, sure.
Regarding saving the buffer and file format: I see that the use case of that save buffer feature is not clear. What we had in mind is the following:
You start do live crushering and at a certain point you decide to switch to manual trigger mode by releasing the Auto button in the trigger panel. Ok, from now on you are "offline" and the grains are generated out of the fixed, no floating buffer. Maybe you are so satisfied with the result you hear (while modulating or playing modulations on the keyboard) that you want to freeze that patch. This is the moment you press save on the vapor panel. The buffer is dumped to the file and you can reload it and save your patch. Done.
To run this usecase it is not necessary to use the file in a DAW (sure, you can do it but it does not feature the intended usecase). Your DAW is perfect for recording the sound you hear, right? So use the DAW for this normal recordings.
Why the saved file is 32bit floating format? The vapor buffer needs headroom, much headroom. Just think about the headroom needed if you added feedback.... A 16bit format would not hold the information needed for reproducing the buffer situation.
What area of the buffer is saved? There has to be a decision what area of the buffer is needed to save. The buffer size is flexible and has a limit on the Delay max offset + Delay max depth modulation + Length max offset + Length max depth modulation. This is quite big and no one wants to store the whole buffer to disk. For that we build in an "intelligent" mechanism that decides what part of the buffer has to be saved with the current patch. So on loading the buffer back, it is ensured that the sound you need for reproducing the patch is captured. In general the rule is: The more Delay offset/modulation plus the longer the Length offset/modulation the larger the file is.
Hope that clarified our Approach a bit - I know the crusher is a bit academic
But, hey that is the brain twirl you and me may like (or not).
Have fun with the new tool, and additional I hope that the other pricing and "spamming" chit chats will end up in a creative discussion about how we want to see the world and tools changing towards a new music creation style.