randy's Recent Posts
OK, totally heard about poly AT and MPE interaction, that is indeed weird. My intent is to combine mono + poly AT as you are describing Pigments does.
Thanks for the update, I appreciate it and I'm glad to know the issue is fixed. I think you're right about it being a by-product of fixing something else. I worked on bullet-proofing some things having to do with parameters and hoped that a few mystery issues like this would be solved as a result.
heard.
The Sumu 1.1 update is out, bringing MPE support as well as a bunch of bug fixes and enhancements. These include:
- gui: fix scrolling after setting default in popup dials
- gui: fix missing update bug when pasting registration
- osc: fix zipper noise in AM mod index
- AU wrapper: fix Obj-C namespace collisions
- fix UI scale bug with muliple displays of different scales
- allow slower LFO times
- increase LFO popup dials precision
- adjust text position for negative numbers in Dials
- increase pulses ratio dial precision
- fix slow LFO sync
- improve host clock sync
- reset pulses hi scale offsets when adjusting past zero
- fixed issue loading state saved by beta version
- added MIDI learn for dials via popup menu
- added main […] menu with gui and input settings
- gui : added numbers on / off menu
- gui : added scroll normal / reverse menu
- input: added protocol [MIDI / MPE] menu
- input: added MPE bend range [ 0 / 12 / 24 / 48 / 96 ] menu
- input: reduced latency of gate and pitch in patcher
- input: added MPE mode
- input: don't reset voice time in unison mode legato
- partials: add interpolation to time dial
NOTE: we are still working on meeting the latest requirements for Windows code signing. Windows will claim that the Sumu installer may be dangerous and you will need to click "Keep anyway" a few times. We'll update the installer as soon as we can address this.
OK, I still have a 10.13 Mac and I have reproduced this. I have an idea about what might be wrong. I had to switch to a new version of the VST3 SDK and it seems likely that it (or the way I’m using it) has stopped older systems from opening the plugin.
I don't have a way to open a VST3 on this computer, but it should be the same fix as the AU issue.
Thanks for the info. It looks like there's some validation issue with older systems. I'm investigating.
yes please email me the validation report!
there are no CPU optimizations. that will be my focus for the next update.
Sorry to hear that. My focus has been on MPE. Hopefully that could be a workaround for you? You need to enable MPE in the INPUT [...] menu now.
I'll look into making sure regular Poly AT works also. There should be less time between updates now that I have the MPE work out of the way.
When you log in here, you should see a menu in the upper right with your first name. (Mine says "Hello, Randy".) In that menu there's an option "My licenses" that takes you to the page with all your licenses.
If something's still not working right, please send email to support@madronalabs.com and we'll figure it out!
Hi and thanks for your question. My guess is, Vutu generated more than 64 partials in the .utu file. When you export a file for use with Sumu you have to look at the "max active" number in the Vutu info display. If this is more than 64, Sumu, will not be able to play the sound and it will be as you describe.
Vutu allows exporting these files so they can be used in other software. It's open-source and I did not want to make it completely Sumu-specific. But, I should enable a warning or some nicer way of preventing this for Sumu users.
In this video, I show using the controls in Vutu to manage the number of partials: https://www.youtube.com/watch?v=crvpsnbLtt0
No worries
Thanks for letting me know. I too have seen the older, JUCE-based plugins (that's Kaivo, Aalto and Virta) get slower over time. Meanwhile of course I've been working on Sumu (and Aaltoverb) and a whole new, GPU-based graphics framework.
I'll see if there is a quick fix for the behavior of the older plugins on newer DAWs. If there's no such quick fix, I'll update them to use the new graphics code. Either way I'll have a fix soon.
Here's a temporary link to the Beta discord (expires Aug 13, 2025):
https://discord.gg/TSzkZ2Ry
Please read #read-me-first and take some time to catch up on the recent conversation when you arrive!
Hi Dylan, thanks for the clear report and your update. I've chased similar issues with the body module and thought they were fixed. It could just be very rare now. If you find it's a specific body type that makes it stop, or anything else that makes it do that again, please let me know.
Thanks for the support! Humorous and otherwise. :-)
I have a release candidate up now, and I'm putting the wheels in motion. Please subscribe to the newsletter for the freshest news!
I understand it seems like a long time for this update, it's been a real battle for me this time. I've had to deal with low-level Windows API stuff, which is not my happy place, and honestly with unrelated life stuff, which I'm not going to vent about here except to say it impacts a one-programmer company a lot more than a big one. I hope we can both enjoy a more regular release schedule soon.
I just posted a release candidate to the beta list, so fingers x'd we will have 1.1 next week.
Thanks for writing in about this. This has been a problem off and on with some versions of Live, and I'm eager to fix it in all the plugins it effects, either by releasing the new versions I have in the works or interim updates to the v.1s. Meanwhile I apologize for the inconvenience.
There's at least one tutorial online— does this help?
https://www.youtube.com/watch?v=sUOsGtB0MDY
It sounds like you are doing things right. When Aalto is set to MPE mode, the channel aftertouch should come out of the "after" input to the patcher. Through the patcher, each voice gets its own aftertouch data depending on the channel.
You do need to set "MPE MIDI" explicitly in Aalto using the "Input Protocol" choice in the settings (gear) menu.
Been a long road this time but it's in beta finally!
Sorry I missed this- I've been cleaning up so much spam every day and we're working on a solution for that.
So there are other posts on the forums about how the import is done—I'll be working to make it more obvious in the future. I think you figured it out.
You can clean up and move the files around however you want. On Mac OS, partials are stored in (Your home directory)/Music /Madrona Labs/Sumu/Partials. On Windows, in C:/AppData/Roaming/Madrona Labs/Sumu/Partials.
Hi Damo,
It's OK to post this here. But, this forum is not very busy. You may have better luck on for example KVR Audio, or on a Reddit synth forum where selling is allowed.
best,
Randy
Hi Chris, thanks for your patience, I didn't see this until now. Kaivo 2.0 will be a paid upgrade, unless you've bought the v1 recently, in which case it will be free. I haven't figured out the details yet.
We have updated all of our software instruments—Aalto, Kaivo, and Virta— to version 1.9.5, bringing native Apple Silicon support for M1 and M2 Macs. The new versions are Universal Binaries, which support both Apple Silicon and Intel processors. Users with Apple Silicon computers should be able to run 30% more voices or more, as compared with the previous versions in Rosetta 2 emulation.
This update is free. Installers contain Universal Binaries for both VST2 and Audio Units V2 versions.
Windows versions are unaffected by this update. Aaltoverb, previously released with Apple Silicon support, is also unaffected.
Adding popups to UI elements that move is going to be a little tricky, but it's not rocket science and I will definitely do it at some point. The popup menu can stay put while the "tail" follows the loop bracket.
I hear that the slow pace of bug fixes can be frustrating. I'm working to improve that this year. One way is by making it easier to deploy my software so that doing so doesn't take me away from other work for too long. (if you are a software person, think CI / CD)
I believe I am very close to shipping a 1.1.0 version of Sumu right now. Please stay tuned, and thanks for your patience.
Are your plugins registered? If not, that's why you hear the ocean sound. The demo versions play the sound until you register them.
Now that I think about it I should add a popup message when the demo sounds plays also, to make this clearer.
Thanks for writing.
Hi, welcome. Thanks for your support, and the nice words about Sumu.
I definitely hear you on this. There are a couple of way Sumu could be changed to work better for you. One is an MTS-ESP mode, which would take over and change the scale only under MTS-ESP control. I looked into this a couple of years ago and ran into some technical issues with MTS-ESP that I think have been resolved by now.
Another way would be a parameter lock. A number of people have asked to be able to lock various things when a patch changes and this could include the scale. I'll definitely make this possible at some point.
Thanks for writing with your feedback. I have good news: you can scale Kaivo by grabbing on the little triangle in the bottom right corner, then dragging the window to the size you want.
I am working on a dark mode that will provide more contrast and I'll include it in all the plugins when I update them.
You should not need to move or rename any files outside of the Vutu app or Sumu plugin. Renaming a file will definitely break things. (It shouldn't crash, though—I'll fix that.)
I'll go over the steps to turn sounds into .utu files and import them into Sumu.
We start with a sound in wav or aiff format.
- open Vutu and click "open" in the source row to open the sound.
- if desired, move the endpoints in the waveform display to select the start and end.
- if desired, click "play" in the source row to preview the sound.
- click "analyze" to analyze the sound.
- click "export .utu" to write an utu file to disk wherever you keep your partials files. Let's say it's in MyPartials/acoustic/violin1.utu.
Now we have an .utu file which is a JSON text format, you can open it with a text editor to look at the partials data.
Now open Sumu.
- click "..." in the PARTIALS module and then click "import folder..." in the menu.
- select the folder containing your partials files. In this case it would be MyPartials.
- the MyPartials directory and all subdirectories will be scanned for .utu files. All the .utu files will be converted into .sumu files in .../Madrona Labs/Sumu/Partials. So if you did not prebiously have a .../Madrona Labs/Sumu/Partials/acoustic directory, that directory will be created and the file violin1.sumu will be created in it.
The .sumu files are partials in a compressed binary format that Sumu can read.
So:
audio -> export to .utu using Vutu -> batch import into .sumu in Sumu.
Yeah I'm hard at work on Sumu using my primate brain and I didn't really know what to say about this. AI in the form of smart code completion like Copilot is something I'm already using and find helpful. More ambitious tasks like optimization and maintenance of this type of code are not things AI is going to be helpful with anytime soon.
I'm finishing up the beta of MPE support right now, and am also testing Channel aftertouch in both MPE and MIDI modes. I'll send out the newsletter with a beta link as soon as I post it.