It's a commonly asked question so I'm copying this info to a new thread in hopes it will be found more easily.
The Vutu app makes .utu files. These are a plain-text, editable, JSON format containing partials maps.
In Sumu, you can import the .utu files. The import process creates .sumu files, which are compressed to save space. The import also does some more analysis and saves it in the compressed file.
To import .utu files in Sumu, click the [...] in the Partials module. There's just one choice in this Popup menu: import partials. Then select a folder to import.
When you import a partials folder, it imports the whole directory tree underneath the one you pick, including any folders that contain .utu files.
So if I have on my disk
~/VutuFiles/Strings/cello.utu
~/VutuFiles/Strings/viol.utu
~/VutuFiles/Noises/tinkle.utu
~/VutuFiles/Noises/harsh/blender.utu
and then bring up the import dialog (partials/...) and select the folder ~/VutuFiles to import,
the files
~/Music/Madrona Labs/Sumu/Partials/Strings/cello.sumu
~/Music/Madrona Labs/Sumu/Partials/Strings/cello.sumu
~/Music/Madrona Labs/Sumu/Partials/Noises/tinkle.sumu
~/Music/Madrona Labs/Sumu/Partials/Noises/harsh/blender.sumu
will be created, along with the directories on the way.
Importing again will (for now) overwrite these files.
The intention is to "sync" your entire partials development folder at once. So if you make a folder somewhere called "VutuPartialsForSumu" or something, with everything you want to import into Sumu, and always select it when you import, you will keep your partials organized based on that folder's structure.
-Randy
How do I get Cam's new THEORY (chords, arps, scales) partials into Sumu? I tried importing the folder as detailed above, and I tried dropping the folders into the Roaming AppData as detailed elsewhere in your documentation. What am I missing?
These are already imported into .sumu format! So, you do the following:
- go to our Google drive
- click the "..." to download the whole theory folder
- put the theory folder in .../Madrona Labs/Sumu/Partials with all the other partials.
The "import partials" converts utu files into .sumu format. You do not need to do that here.
thanks, I tried it with the individual folders, the entire folder worked
VUTU —> SUMU:
Hi Randy, I just had some questions as I devour all there is to know about Vutu/Sumu and I just wondered, based on your knowledge of how Vutu digests samples: Are their best practices for optimal preparation of samples for Vutu?
- Does Vutu process stereo or mono samples (or both)?
E.G. If you feed Vutu stereo samples does it collapse them to mono?
-
Is there a difference that affects translation regarding sample rate or bit depth into Vutu (or is it open to just whatever you throw at it)?
-
Is there a limit to the shortest time or longest time Vutu can process a sample (or is it open to just whatever you throw at it)??
E.G. Single cycle, drum transient to a 60 sec passage of time?
- Do samples benefit from being normalised prior to import (does this drive Vutu’s engine more optimally)?
My apologies if any of this is already apparent elsewhere but I read the documentation for Vutu 1st, scoured the forum for posts relating to Vutu (which brought me here); and I’m now working my way through the PDF body concerning Sumu (but still a little unsure about the above)…
However, from what I can understand so far, you can seemingly feed Vutu diverse sample material (which it loves the taste of as it isn’t picky) then using the GUI, fixate on a suitable Point Of Interest (POI) using the scope area and provided there’s a maximum of 64 partials …it’s good to go?
Sumu/Vutu are super cool tools anyway and with having very little previous experience with modular, naturally I’m having lot’s of fun exploring the GUI and discovering the crazy sonic worlds that Sumu unleashes …this is certainly one exotic specimen! Many thanks! :)
If you feed Vutu stereo samples does it collapse them to mono?
Yes. Sumu partials maps are all mono.
Is there a difference that affects translation regarding sample rate or bit depth into Vutu (or is it open to just whatever you throw at it)?
Above a reasonable sample rate like 16 bit / 44100Hz here will be no difference. I just took a look at the code and it looks like Vutu resamples to the current system sample rate for playback, then analyzes the audio at that sample rate. That's a bit weird but again, there should be no real difference since we are converting to a rate-independent format.
Is there a limit to the shortest time or longest time Vutu can process a sample (or is it open to just whatever you throw at it)??
I think it gives you up to 60 seconds?
Do samples benefit from being normalised prior to import (does this drive Vutu’s engine more optimally)?
the partials maps get normalized on output, so there should be no need to normalize your sample first.
Thanks for going over the docs first. These are good questions probably not covered anywhere else. I'll get this info into the Vutu docs!
Hi Randy, thank you for your super helpful reply! Typically the 1st sample I threw at it was exactly 60 seconds long (e.g. torrential rain beating down on the roof of my car making lots of weird transient percussive pings and k’twangs) …so I wouldn’t have noticed the 60 sec limit! Weirdly it later became an infinitely shorter preset called “Alien asking a question?’ lol…
If humanoids haven’t already asked it’s probably because I’m likely the most painfully pedantic user you now have (and I feel sorry for you all @ML already) ha ha, …but I do hope it helps or is useful regardless!?
Speaking of documentation, I noticed a few typographic errors and an illustration disparity that doesn’t match the supporting text. Would it be helpful to annotate any errors I discovered in the PDF (with bright pretty colours and intriguing doodles) as I devour it then email it back to you?
My brain always flags things like this since I contributed to developing beta documentation for a 3D company that makes intriguing UVW unwrapping software, so if it’s a useful contribution to the ML cause, it certainly isn’t a problem (e.g. …to at least say thanks for the brilliant help and support)! :)
If you want to contribute some feedback about errors or whatever that's always appreciated. Best for us is to send an email to support@madronalabs.com. Thanks!
Sure thing! :)
BTW: I just wondered is there a specific thread to make feature requests in future regarding individual software products (so you can see if they’ve already been asked for etc)?
As it is, mine is likely a more general one (that applies to all your VST instruments) but it would be really wonderful to have standalone versions of your apps (especially Sumu as it’s pretty heavy being additive) so it would be invaluable to run it as lightly as possible and in full screen)!
Sorry if the above has already been requested previously! However, I also just wanted to mention, that after my 1st few days with Sumu I’m really enjoying exploring it as I love programming and sound design too, so I’m smitten (the documentation is also the best I’ve encountered) …I’m just learning so much and I really like the laid back, humorous chill prose! :)
I've gotten a few requests for standalone versions. I don't have anything against it but it's not super high on the list to be honest. From my end it would be one more entire "product" to deploy and support that not too many people are using. I really have to focus, in these aspects.
For the lightest possible use I recommend a simple free VST host. There are some for both Mac and Windows that basically just give you a window where you can hook plugins together with MIDI and audio I/O. I use JUCE Plugin Host on Mac (Claude can probably help you compile it if you can't find a downloadable version) and VSTHost for Windows—there are some other choices as well and probably more recent options.
Thanks for the nice feedback!
Hey Randy, thanks for your helpful advice, and no worries I totally understand! I think it can be difficult for end users like myself to fully appreciate just how much is entailed behind the scenes of plugin creation, but also as you say if not many users request it either; prioritising things they do lust after makes way more sense!
However, it’s been a really interesting thought journey too as initially contemplating; I figured that a standalone version would be something akin to a VST embedded within some kind of executable wrapper (so to speak)!? This made me wonder if there was already such a thing anyway (essentially a test environment that’s not a DAW but will still run a VST windowed, bare bones with no unnecessary RAM/CPU overhead)!?
Remarkably the thing you suggested (JUCE library) sounds ideal (and useful for any VST you want to run in isolation for that matter) so many thanks for the insight! The only reason I even know JUCE exists is because I’m intrigued by the dark art of audio programming myself (purely for fun/experimentation mind)! But I understand JUCE is used widely across the plugin industry so it sounds a perfect way to get acquainted!
There’s actually only a few synths that I own that are particularly heavy that being Generate (New Fangled Audio), Mariana (Moog), SkyDust3D (Sound Particles) and my current obsession Sumu (via yours truly)! I think it’s actually more to do with some rather problematic ASIO drivers from Steinberg however running on old kit (and I hope to update my sound card in due course which should make the issue NULL anyway).
A lite VST environment to test things sounds really useful regardless, and actually due to your recent user feedback survey I was inspired to start learning Ableton and I found it really wonderful (just so immediate, intuitive and hands on)! As such, you can see it’s been quite the inspiration for me discovering Madrona Labs and marks a shift into new creative territory! Thanks for your help anyway which is always appreciated! :)
In case its useful to anyone else in the forum with similar needs:
JUCE LIBRARY - Plug-in Host
Windows - MS Visual Studio IDE (Community Edition):
VISUAL STUDIO IDE - Win Compiler
Mac - Apple Xcode IDE (Developer):
XCODE IDE - Mac Compiler