randy's Recent Posts


Thanks folks!

Thanks Andrew! Nice to see you getting along with the instrument.

I've done a few on YouTube, this one most recently:

Thanks for the feedback. I have plans to add to the preset system for v.2 and make a sample pack format with export / import functions.

I guess currently you're seeing the influence of my working methods where I tend to make patches as I go. I have not put as much energy into systems for sharing patches as making them on the fly. But I recognize that people out there want to have better ways to share and receive patches, and adding features to Aalto could help with this.

In MPE mode, only the mod output is controlled by the mod cc# dial. The x and y outputs for each voice are fixed to CCs 73 and 74. So you get for each voice an independent cc#74, as required by the MPE spec, and then two additional mod sources: cc73 and one more you can select.

As MPE outputs go in general, any input from the main channel (typically channel 1) will be added to all the voice channels. This goes for mod, x and y.

This setup follows the MPE spec as far as cc74 but the names are a little funny—this is because I set up the Soundplane->Aalto connection over MPE before the MPE spec was really finalized. Now that MPE is settled I may make some changes for compatibility.

Thanks very much for writing. I love hearing that Aalto's design is helping you make your own patches for Linnstrument. Enjoy, and keep in touch!

I think the best solution here would be a "parameter lock" mechanism, already planned. With this feature you could set any parameter to a fixed value that will not change upon loading a preset.

Thanks for the feedback!

That's a good idea to make an MPE or Soundplane specific group of presets. Mostly you can take any existing preset and then patch the y output to something interesting, so I hope you have fun playing with it anyway—please let me know if you have more questions.

Hi Greg,

There's nothing special about the signal from the "y" (or CC74) output as opposed to the other modulation sources you can use in the patcher. You could test this by using a different "mod CC #" in combination with the "mod" output. If you set "mod cc" to 1 for example you could use the modulation wheel on most controllers.

In the case of the sequencer rate, possibly you have host sync on?

In the case of the body, there's only one body and multiple voices, so all of the params except for x and y use the average the voice inputs. In the case of x and y there is one input location per voice, so these work as usual.

Thanks for the feedback. Feel free to use the beta as long as you need—it's fully functional, non-expiring, etc. I'll send out an all-plugins update in a bit.

Welcome! There are a bunch of patches in the Aalto patch thread up above in the Software section. You can copy and paste these using "Paste from clipboard" in the Aalto patch menu.

Thank you so much!

I'm not using Logic much so I don't feel like the best person to provide details, but it's definitely doable. I think there may be a trick with sending the track to a bus and recording that.

I don't know why I just saw this... Josh has moved on to other things but is well AFAIK, maybe he'll chime in.

I just uploaded a beta installer for Aalto MacOS. Please give it a try: http://madronalabs.com/media/aalto/Aalto1.8.4b1.pkg

Sumu is going to be only an instrument, not an effect—so live processing won't be part of the fun. You'll have to import a sound clip and analyze it, like in Kaivo.

Virta does a great job with live formant processing though!

The Soundplane is currently Mac only but I see that changing with the Model B release.

OK thanks for the info, I'll be in touch here about a plugin update.

In the first crash with the VST, you can see at Line 30: Crashed Thread: 5 AudioCalc

So you can scroll down to thread 5, which starts at line 114. The function calls are in order of most to least recent. Each line has the name of the executable module that is running, followed by hopefully the name of the function inside of it. For com.ableton.live you don't usually see function names, just numbers, because the function names have been stripped from the executable.

Roughly speaking, thread 5 tells you that the crash was in the kernel library, called by the C ++ standard library, called by Aalto, called by Ableton Live. My own code is trying to print some debug information, which it shouldn't be doing in a release build for various reasons, one of which being that the string library might allocate memory as we see here. Allocating memory in an audio processing thread is always something to avoid. Even so, it should not be crashing, so I will look to see what is causing the crash before simply removing the debug printing.

This change would be a fundamental one and is not going to happen in a minor update. It is exactly the kind of thing I will be looking at for a major update (Aalto 2).

Sorry you are running into problems. These are new to me. I appreciate the detailed reports.

You seem very on top of the latest from Ableton so you probably heard that Live 10.0.3 had some bad bugs with AU parameter updates. You say you are using 10.0.4, and I think these have been fixed in that version. Just FYI.

The VST crash report does not indicate the JuceVSTWrapper is the problem. It does point to some debugging code of my own. I should be able to post a beta very soon that I hope will fix this.

The AU crash you sent later does not point to Aalto. It looks like purely an issue with Live. If you want to experiment you might try the same track copying operation with a different AU instrument plugin.

Hi, if you give the .kbm file the same name as the .scl file except for the extension, the mapping will load for that scale. Do you have a mapping you are using with the other programs? If so, try loading it using this method and you should get the same results.

If you are not using a mapping, you could try transposing the notes to get the same results.

I'll check out werck3 when I get a minute here.

Ah yes, it only loads them when the plugin starts, good thing to go into the docs. Glad it's working.

Hi Greg, yes I know this works because I've used it in a performance. Maybe check the spelling of the "MIDI Programs" folder?

Yes, yes, I know this feature is not the best. It is just a stand-in that allows the job to be done, until I have time to make a good UI for associating patches with numbers. So far there have always been more critical things to do, and unfortunately it's just me writing the software.

Thanks for the feedback, though. If it's any consolation I have to use it for my own shows as well. I'll definitely change this for Aalto 2, which is the next update or very nearly so.

Because you say "go to the GUI" I guess you are talking about using the controls of your Push here? From the GUI itself the dials snap to the quantized positions. The shift modifier allows a fine adjustment from there.

I should really get a Push 2 and do a run-though thinking about usability in general. It's a nice controller!

Thanks for the feedback. What format are these other plugins in? I'm not sure that VST2 for example supports this concept. I agree it would be a nice usability improvement for formats that support it.

seq_wave is only there to communicate between the interface and the parameter system within Aalto. It shows up automatically as an automatable parameter but is not useful.

Later I added the concept of a non-automatable parameter, but to remove this one would break patches by changing the order of parameters. I could rename it "unused1" or something.

Hi Wolfgang, I'm sorry to hear this bug is still happening after the update. I'll check into it using Reaper.

@brianleu You can still find all the DIY stuff at madronalabs.com/DIY. Feel free to download it all!

Well OK, last in this series anyway. These four instruments make a great kind of group and next I need to do something different. I could put a patcher in the middle of something again, someday. But it will probably look different. Hopefully I'm always learning.