randy's Recent Posts
I have to get Sumu out first. My plan is to be working on v2 by this Fall.
Hi, Aalto v.1 does not do MIDI mapping in the synth itself—you will need to use the MIDI mapping features of your favorite DAW.
By popular demand, version 2 will have MIDI mapping.
good to hear it's working well.
Yeah! I was very stoked to see this.
Just wanted to follow up a little late here and say thanks for sharing the nice words and a bit of context about what you are doing. In this pandemic time I've been largely "working in the code mines" and I'm excited to show off the fruits of my labors soon.
Sumu might not have "spectral editing" either—it's very much built around live patching like Aalto and Kaivo. Instead of fiddling with individual partials, you'll have modulation sources that are designed for spectral synthesis and dials on some transformations that will be globally useful.
Hi, this is on my list but I haven't had a chance to get to it. There's a chance I can sneak it into an Aaltoverb update that's coming soon. But if it turns out it's not a quick thing, it will have to wait until after Sumu ships.
Thanks for the feedback. I've gotten a few requests for it over the years and it's on my list of things to add to version 2 of the plugins.
I have to stay focused on releasing a new plugin for now but I'll be interested to see where this goes and will consider adopting it.
It's high on the list. Have you tried using https://github.com/DLTcollab/sse2neon ? Hopefully I can use it to get madronalib working on NEON relatively easily.
Do you mean, play an audio file through Virta? I have not used savihost so maybe someone else can answer.
This year it seems desirable and possible for Madrona Labs to make a Soundplane to CV device. This would be primarily a Eurorack module, but the circuit could also be built into its own enclosure for use with vintage synths etc.
Normally I do most of my design work in private, and only announce a product when it's pretty much done. But we (Brian and I) are going to change it up this time. Because neither of us is that deeply into the Eurorack world, it makes sense to solicit input early on in the process this time. This is going to be a utility device (though hopefully an elegant one) — so before we get too far along, let's make sure it will be useful to you!
The basic idea
USB jack for powering the Soundplane. Module puts out CV / gates / mod outputs for individual touches. Like the Soundplane app, a zone map decides how the Soundplane surface is divided up into notes and what those notes are. You can switch between zone maps, and the name of the current one should be displayed somehow. Aside from this, visual feedback will be at least an LED per Z value. To keep costs low, probably nothing too graphical or fancy.
We're looking for input on things like:
How many voices?
Each voice of touch output will probably have 4 outputs for pitch, x, y and z. Setting up many voices on a modular is not the way most people use them, so I'm guessing that two voices of output will take care of 90% of what people want. We would probably add an expander module for more voices.
Any interesting modes?
A switch that changes z (pressure) into a strict on/off gate might be useful. Any other things like this?
individual voice groups vertical or horizontal? voice outputs at bottom or top? I'm thinking top, because a USB jack on the bottom will go to the Soundplane.
The module will need roughly 250mA at 5v to power the Soundplane. Brian will correct me if I'm wrong. Then there's whatever computing and display the module needs to do, and the outputs. Do we need our own power supply, or a list of compatible Euro power supplies that we can point people to? Any choices in connectivity to make here?
Finally, we're still looking for a great name…
Hi Scott, thanks—it's been a difficult year! with the coming of Spring and, hopefully, a vaccine on the way I am finding myself more energetic and less distracted. Getting Sumu done is the first step to what will hopefully be a year of progress on all fronts.
Nothing yet, sorry.
I'm going to make this thread sticky. It should be a good place to find and share Aalto patches. I'll try to post one every day or two for a while.
It would be cool if we could embed Soundcloud links here, but setting that up will take some time.
I'm definitely interested in hearing other ideas for resonators. I'd like to sneak at least one into a free update, then add some more ambitious stuff with the next major version.
Wind sounds are definitely a gap at present! You can kind of get there with the chime, and I think i have a couple of presets that attempt it. But a real pipe resonator is definitely called for.
The difficulty of the work depends on quite a few things. Even with mathematically simpler resonators, dialing in useful ranges and curves for parameters can take a lot of playing and listening.
I have a list of UI features like this to add to the next major version. This is on there. Thanks for the reminder.
I have verified the problem on my Windows machine and I'm working on a fix to test with Live 11 and release. Thanks for your patience.
Good looking out garf.
Hi Marc, I personally have never used Mainstage so I can't be as helpful as I would like. My advice is definitely to try the Kaivo demo and see how it goes for you. DAWs are usually not too different from one another in terms of performance but really the best thing is to try it.
To scrub a sample position per note, you can use one instance of Kaivo with either poly aftertouch or MPE data patched to the sample offset. It's up to you whether you want to use MPE for this. If you might have other things to control per note that would be an argument for MPE. But not all DAWs support it well yet.
From looking at Iris just now, my reaction is: not very similar. It will be semi-modular like my other synths, for starters.
Thanks for the additional info. This situation looks a bit complicated.
Interestingly, on my M1 Macbook Air here, Kaivo's interface is definitely slower than it should be, while Aalto's is fine—and all the audio processing is very fast. The presence of the emulator definitely complicates things further, however this setup might be a basis for figuring out what's going wrong here where I have a development environment.
I'm nearly certain this is my own problem.
Thanks for the clear description. A really stellar bug report, I have to say. I wish they were all this helpful.
I'm very sorry to hear you're having trouble. I've also heard from other users about slowdowns in Logic. for example here: https://madronalabs.com/topics/8040-extremely-slow-ui-for-all-the-plugins
I can't reproduce these issues here, or I would have put out an update by now. And oddly, it happens on a variety of machines including a setup very similar to my daily driver (MacBook Pro with Mojave). I'm going to look again at what all these setups might have in common and hopefully I can come up with a test to try.
I can also make a version that would collect usage data on the affected systems for debugging. If you have time to try beta versions specifically aimed at fixing this please let me know and I'll be in touch.
@progster to clarify, if you run into this problem you'll see that after you set the MPE bend range menu it just does not keep the setting.
When I can make time for playing, I try to practice my Soundplane. I know the Linnstrument is a good instrument too. In an ideal world I would have one of every MPE controller for testing!
The thread you point to is mainly related to an issue with pitch bend at the start of notes. This got fixed with version 1.9.4.
Sadly I don't have a Linnstrument.
For some hosts on Windows 10 the MPE pitch bend range menu (in the "gear menu") simply does not do anything. So maybe this is what you're running into and the value is set to something small while the Linnstrument is sending out a much bigger range. I'll fix this ASAP. Meanwhile you could try a smaller pitch bend range setting on your Linnstrument.
Hi and welcome.
I don't know if any patch is a canonical start. Maybe I should make an "MPE default."
The settings in the "gear" menu don't change when you change the patch. They are saved in your project in whatever your host DAW is. These things like MPE pitch bend are meant to reflect things about your controller that would presumably stay the same over use of multiple patches.
I hear you about the manual updates. Meanwhile here's a table of the KEY outputs in the different protocol modes: https://madronalabs.com/topics/4718-key-outputs-by-protocol
Are you on Windows? There is an MPE pitch bend issue there where the menu doesn't work. Please share more info or a link to "bend to the moon" because I'm not finding that.
We are not there yet, but getting close. What I said in the newsletter was, I'll be showing off some new features made possible by my new plugin framework. Nothing about a finished Sumu, which is still a little ways off, but I hope you'll enjoy seeing these new LFO / MIDI learn features.
I just received my first Apple Silicon-based computer this past weekend. Of course I was excited to find out how all the Madrona Labs software worked on it, so I dove right into some informal tests and benchmarks.
None of my plugins are yet released in native versions for the Apple Silicon-branded ARM processor in the new Macs—rather, they run using Apple's Rosetta 2 emulator which translates their Intel code into ARM instructions. Kaivo is definitely capable of putting a heavy load on the CPU, so I used it as a basis for testing. Because Ableton Live is the hosting environment my customers use the most, and also because it's not yet released for native Apple Silicon, I did the bulk of my testing in Live 10. So the test is all in emulation, and hopefully gives a good general indication of what moving your existing software setup over to an M1 Mac would be like. I tested both the M1 and my 2015 MacBook Pro, which is my daily driver and a pretty typical machine for a lot of my customers out there.
I said above that these tests are informal. That means I didn't take the average of multiple runs, I just did my measurements by looking at Apple's Activity Monitor, and my reports of inferface speed are subjective. That said, I have seen the same behavior while working on the new Macbook Air over the last few days, and everything is consistent with the reporting I've read on these new computers.
- MacBook Air (M1, 2020)
- 8GB RAM
- macOS Big Sur v. 11.1
- MacBook Pro (Retina, 13-inch, early 2015)
- 2.7 GHz Intel Core i5
- macOS Mojave v. 10.14.6
- Ableton Live 10.1.30
- Kaivo 1.9.4
All tests were run at 48000Hz, with Live's sample buffer size set to 512. Built-in audio was used. Each voice used the factory patch "peaking lights," a high-CPU patch with all the resonators and body code in use.
I looked at the CPU percentage used when no Kaivo windows were visible. In addition, I noted if there were any audible glitches, how Live's UI performed with one Kaivo window showing, and how warm the computer was. Here's the data I collected:
Test 1: 32 voices of Kaivo (4 instances x 8)
%CPU: 138, ± 1
UI: a bit slow but usable
%CPU: 310, ± 10
heat: warm, fan audible
Test 2: 16 voices of Kaivo (2 instances x 8)
%CPU: 82, ± 1
%CPU: 133, ± 5
UI: slow but usable
heat: warm, fan audible
Test 3: 12 voices of Kaivo (2 instances x 6)
%CPU: 78, ± 1
%CPU: 101, ± 2
UI: slow but usable
An Ableton Live project with 32 voices (4 instances) of Kaivo is totally usable on the M1 Macbook Air, with only a little bit of UI slowdown evident with a Kaivo window open. The same project is definitely not runnable on my old MacBook Pro.
Interestingly, looking at the eight cores of the M1 running all these voices, it appears that only four of them are doing the heavy lifting. This probably accounts for the fast UI response even under the most load I tested. The M1 has four performance cores and four less powerful efficiency cores—my guess is that cores 5–8 here are the performance cores. Right now it takes more esoteric tools to really determine this.
On my old MacBook Pro, I can add up to around 12 voices of Kaivo before glitching is audible. (This is over two instances of the plugin. The same number of voices over more instances will take a little more CPU because of the overhead of each instance, but may be less glitchy because the scheduling is easier, soooo... it's complicated.)
It may not seem too amazing that a new machine is much faster than a five year old one. But remember, both Live and Kaivo are compiled for a different processor and running in emulation! This is an impressive feat, especially if one can remember the lackluster performance of the original Rosetta's PowerPC to Intel emulation.
I tested my five year old laptop against the M1, not to be mean, but because I don't have a newer one. Since the work that Kaivo is doing is basically CPU-bound, looking at relative CPU benchmarks for newer machines should give us a decent guess at how they would perform in the same test. Geekbench gives us the following numbers for multi core tests, where higher is faster: New Air: 7614 , Old Pro: 1358, Recent 13" MacBook Pro (13-inch Mid 2020): 4512. So going from my old Pro to a current 13" model should give us roughly (4512 / 1358), or three times the number of voices, or what the M1 can do in emulation.
If you have a Mac that's more than a couple of years old, the upgrade to any Apple Silicon Mac should be a big leap in speed, even when running applications that are not yet native. If you have a high end or more recent Mac, one that pulls in a Geekbench 5 multi-core score of around 5000 or higher, it probably makes sense to wait—either until your favorite apps are all native, or for the next generation of Apple Silicon computers.
This is old too but should still be correct: outputs from the KEY module described in MIDI, MPE and OSC modes.
in MPE mode the X output sends out cc#73 for each note by default.
It's a different VST/AU plugin.