randy's Recent Posts

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.

Heard.

Aw, thanks! A very thoughtful testimonial and very much appreciated. That feeling of getting lost in music making is very important to me. I'll check into the patches. :-)

Good questions! I know I can do a better job of demonstrating Virta. I would love to get some tutorial videos out for it like the ones Josh did for Aalto.

Hey, thanks a lot for the note. Glad Kaivo is a part of your dive into physical modeling!

Hi there,

The .mlpreset cross-platform format is the most recent one. Hopefully anyone selling presets is providing them in this format. This has been the case since, I want to say, 2012 or so?

For a while I was supporting the .aupreset format on Mac OS but to make the overall code more simple and robust I'm no longer doing that.

Aalto presets on Mac OS live in the folder ~/Music/Madrona Labs/Aalto. Likewise for other plugins. On Windows they are in C:/AppData/Roaming/Madrona Labs/Aalto. To install presets, just put the .mlpreset files into these folders and they will be scanned every time you open the main preset menu. There's no need to restart Aalto.

I'm happy to announce that our home here on teh interwebz, has a brand new look. The old site got the job done, but was not working on mobile and was generally starting to look a little, well, old.

Now we have a better-looking interface that's more usable. An update from 2009 to 2019, if you will. A year in the making, this overhaul brings our look up to date and supports mobile browsing. It should also respond quicker, and the infrastructure sets the stage for new features I want to add over the coming years.

Big thanks to the friends who have helped with this work: Joel Marchand, Brit Hansen and Philip Kobernik.

Thanks for your interest. I have not finished a Model B prototype. Currently I'm working on new plugins. When I have news it will be here on the website, as well as on the Soundplane mailing list.

An update of Aalto and Kaivo to 1.8.5 is out, fixing a possible crashing bug introduced with 1.8.4 and optimizing file handling. Because the bug only manifested for certain users, it was an interesting one to fix and I wrote a little about it, afterwards:

Six days ago, I was feeling happy and content at the end of a work day. I'd just deployed my 1.8.4 release that added a useful expert feature and a handful of bug fixes. I'd tested in all the usual hosts on both MacOS and Windows, and both plugins were making the right sounds and not eating too much CPU and most importantly, not crashing. So with my celebratory bourbon in hand... you already know where this is going.

I got a couple reports back right away that Aalto was crashing immediately on being scanned. One person reported in that Kaivo was crashing too, but most people were not having problems with it. In short, a whole rotten gift basket of ugly issues was collected in the field, but nothing was reproducible here. This was one to sleep on.

The next morning I upgraded one of my Macs to Mojave to match a customer's software and hardware setup exactly. Still no problems here. I spent the day reviewing code I'd just written and looking for bugs. I'd just done some fairly low-level work on timing, changing a lot of objects to use the C++ std::chrono library for their clocks. (C++ is what I use to write all the plugins, a sprawling mess of a language that can make very fast programs, used by most all audio software developers.) I found a couple of suspicious areas and spent a day on that, making the code more clear and obviously correct. Sent out an update to a few folks—same results. Guessing about what might be crashing and fixing anything suspicious is not a great way to track down bugs, but sometimes it's all I can productively do until a better course of action becomes clear.

One of the crashes seemed to be in code that was making lists of files. What if a particular preset was causing it? So, I asked a nice Aalto user to send me their preset library. And boom! Right away the crash.

I looked at the offending C++ code, which began:

void Path::parsePathString(const char* pathStr)
{
  const int pathStrBytes = strlen(pathStr); 
  SmallStackBuffer<char, kShortFragmentSizeInChars> buf(pathStrBytes);
  ...

What this parsePathString does is read a raw sequence of characters in memory and turn it into a compact Path object that can refer to an object in a collection, like DSP objects in a graph, or files on disk.

The strlen function is from the old C standard library that, for better or worse, is available as part of any modern C++ toolset. It counts the number of characters in a null-terminated string—that's some piece of text defined by where it starts in memory and containing all the bytes in the following memory until a zero is reached. Sensibly, (?) the zero is not counted as part of the length.

The text SmallStackBuffer<char, kShortFragmentSizeInChars> buf(pathStrBytes) is an description of an object to be made. The presence of the <> brackets tells us the object is defined by a C++ template. Inside the brackets are the arguments to the template, and these describe a kind of variation on the theme of the basic object. In this case, SmallStackBuffer is one of my own memory utilities that holds some data in a different place depending on how much data there is. Without getting too deeply into it, if there's a small amount of data it can go into a commonly used area called the stack, ensuring that other memory is not allocated, an operation that may lead to audio glitches. kShortFragmentSizeInChars is the constant that determines how much data will go onto the stack.

Back to the scene of the crash. The file name "Xenos Soundworks - Forbidden Experiments/MA Bass Engine (Use MW)" was being read at the time. (Check out their Soundbanks for Aalto and many other synths.) Calling the strlen function on this string returns: 64. That's a power of two, which might be a clue, and sure enough, it turns out that 64 was the value of kShortFragmentSizeInChars. The crash starts to look like a crime scene. Time to look at what happens next, very carefully.

The next thing that happens to a 64-character file name is, it gets written to the SmallStackBuffer object—including the final null terminator which goes to location 65 out of 64, overflowing the object's memory on the stack. The null might be written to part of another object, which could lead to the program crashing right away. Or, depending on when that other object is accessed, it might not crash for a while, which is why memory corruption like this can be so hard to diagnose.

How do we fix this? The easiest fix is very easy. Just change strlen(pathStr) to strlen(pathStr) + 1. Then there will be room for a 63-character file name and its terminator byte. Post update, go upstairs, back to celebratory bourbon. But hold up. To improve stability and efficiency over time I treat each bug as an opportunity to make all the code better, to fix not just this one instance of something having gone wrong but rather a whole class of things with the potential to go wrong. What can I learn from this mistake? Instead of just adding a +1 I'm going to look at all of my code and tests, and I've got four tasks ahead of me.

The first task is to look at my use of strlen across all of the code for all my plugins. If I messed up this way once, I'm likely to have done it elsewhere. Thankfully I have not used strlen many times, because of the potential for problems like this very one. The only good place to use it is in a higher-level object or function that will abstract away the confusion. Searching, I find there are only five other places in my own code where I've used strlen, and I can quickly verify that I'm doing the right thing in all of them.

Secondly, I'm going to look at all the code for parsePathString. Zoom out a bit. Could I have been doing this whole operation in a different way that didn't open the door to the problem? Yes, it turns out. The stack was getting corrupted because I was writing the path string to a temporary buffer in the process of decoding it to make symbols. That was the easiest way to use the Unicode text library I'm relying on. It should be possible to do the same thing just reading the path and not writing it, which will make the program a little faster, but how to do that wasn't clear the first time around. Digging into the library a little more deeply, I understood how to do it, and made a faster version of parsePathString that never has to allocate any heap memory at all.

Third, I'm going to add tests that could have caught this problem before it happened to anyone else. The Path object is a part of my core library madronalib and it really should be tested automatically as part of each release. Testing it with a string of length 64 is the edge case that would have caught this, so I'll add that as well as the neighboring lengths and some weird strings like empty and badly-formed ones.

Finally, there's a simple way I could have figured this out sooner: by having had the magic preset file in my collection to begin with! I usually have on hand only the "factory patches" I've made here, because when I make music I'm always making patches from scratch. But lots of people have made Aalto patches over the years and they are a bigger collection of data that might help shed light on other aspects of the code in the future. So I'll be grabbing some sample banks to have on hand.

Every programmer I know has days like the past few, and could empathize if I'd just said "I got stuck on a stack corrupting off-by-one bug" instead of the above. I wrote this more for myself, to cement good practices, and for the non-programmers out there, to share some feeling of what it's like to do this work. Some days it's even more fun.

Version 1.8.3 is now available. I fixed a rendering issue that came up with 1.8.0, where it was eating lots of CPU.

version 1.8.3
April 23, 2019
link: Soundplane 1.8.3.dmg, 6MB

release notes:

To install this version: move the "Soundplane" application to your Applications folder, then move the directory "ZonePresets" to ~/Music/Madrona Labs/Soundplane.

When you launch the Soundplane application, the menu at the top of the "Zones" page should contain three presets: chromatic, rows in fourths and rows in octaves, followed by a list of all the JSON files in the ZonePresets folder. If the JSON files do not appear, the ZonePresets directory is probably not in the right place.

The format of the zone .json files is human-readable and relatively self-explaining. Take a look to see how to make your own zone maps.

The Soundplane Max/MSP examples require the CNMAT Max externals to run. These can be found at http://cnmat.berkeley.edu/downloads .

The Soundplane application is open-source, available under a permissive license. For source code and more technical information see http://github.com/madronalabs.

changes:

1.8.3:

  • fixed issue with excessive CPU use / repainting since 1.8.0

1.8.0:

  • cmake build rewritten for compatibility with new madronalib and soundplanelib.
  • fixed graphics incompatibilities with OS X Mojave
  • fixed controller Zone outputs and reduced redundant data output

1.7.0:

  • fixed possible crash starting for the first time with Kyma connected
  • "destination port" menu now allows connecting to other hosts on the local network
  • added wait on startup to resolve ports on other hosts
  • added clear all notes when switching OSC destinations and on shutdown
  • added test pattern mode
  • allow running app hidden / in background without added latency
  • fix redundant calibrate on startup
  • fix a stuck notes issue
  • add quick recovery after unplug / replug instrument

1.6:

  • improved isochronous USB driver: lower latency, allows restart after pausing app
  • fixed an issue selecting cleanest carriers after "select carriers"
  • fixed possible crashes on startup/shutdown
  • now distributing as signed .dmg

1.5:

  • new touch tracker algorithm:
    • consumes much less CPU
    • improved latency
    • improved pressure sensitivity
    • improved pressure uniformity
    • improved position accuracy
    • allows better tracking into corners
    • lengthy normalization step no longer required
    • fixed hanging touches
  • fix Kyma connection
  • improve selection of lowest-noise carrier set
  • fix a possible crash when switching zone presets
  • fixed a window-related crash on shutdown
  • fixed latency issue when in background for an extended time

1.4:

  • fixed a problem with MIDI output preventing slide between rows
  • tweaked pre-touch filtering for lower noise
  • (dev) new cmake-based build system
  • (dev) experimental Linux build
  • (dev) added HelloSoundplane command line app for low-level testing

1.3:

  • MPE MIDI support. Requires Aalto 1.7 / Kaivo 1.2.
  • Implemented note splits to multiple ports over OSC.
  • Improved stability and sensitivity of MIDI velocity
  • changed "z max" control to more intuitive "z scale."
  • fix crash with uninitialized driver on shutdown
  • allow 1-500Hz MIDI data rate
  • fix bug where pressure wasn't getting set w/o a MIDI connection
  • send quantized pitch bend on MIDI note off
  • fix touch tracker issues including zone-switch bug
  • fix to allow MIDI note 0
  • fix for double note off problem
  • fixes for MIDI glissando

1.2.5:

  • [1.2.5.1] Fixed a crash on startup if no preferences folder was present.
  • Kyma listener off by default to fix collisions on port 3124. Use 'kyma' toggle on Expert page to turn on.
  • fixed automatic connection to selected OSC service on startup.
  • restored some values from 1.1.2 to improve touch tracking.
  • add automatic saving of window dimensions. This is saved in /Application Support/SoundplaneViewState.txt.
  • fixed a problem resolving OSC services
  • fixed wrong MIDI note offsets in default Zone setups

1.2.4:

  • rendering fixes for Retina display
  • make touches easier to get into top and bottom rows
  • code signing application
  • turned Kyma polling over MIDI OFF by default
  • fixed some state issues on startup that required reselecting zone to refresh
  • clamp zone outputs to [0, 1] as documented
  • fix touch rotate bug
  • fix OSC browser
  • made normalizing easier and mre accurate
  • sending out x, y, and z from zones via MIDI.

1.1.2:

  • more complete fix to the note-off problem
  • restored the note lock feature for new zones.
  • fixed an odd font-related bug

1.1:

  • PLEASE NOTE: moved support files to ~/Music/Madrona Labs.
  • fixed a problem where the wrong note value was sent on note-off
  • fixed a potential crash sending MIDI if a MIDI device was not set
  • made benign errors less alarming

1.0a2:

  • two new kinds of zones: z (pressure only) and a toggle switch.
  • fixed an error where inactive touches were continuously sending their data
  • shortened some JSON zone names (just remove "controller_" to fix your presets)
  • updated Max/MSP examples
  • moved matrix message into t3d OSC bundle with touches
  • restored some debug printing in the in-app console
  • added error info for JSON parsing
  • fixed possible bug with zone parsing
  • clarified the T3D format in docs
  • fixed an error reading calibration files
  • fix view issues for Retina display

1.0a1:
-new Zone features allow mapping notes and controllers to key grid
-changed t3d format for wider OSC compatibility
-OpenGL accelerated graphics
-fixed graphics for Retina display
-fixed a bug where SoundplaneController was initialized twice
-fixed OpenGL errors on quit
-fixed a possible crash in adjustPeak()
-fixed note release when quantized
-new raw matrix output

After installing Aalto 1.8.5 and then running it for the first time, sometimes Aalto's UI will come up "blank"—with no cables, preset text or dial indicators. This looks bad, but fortunately the fix is easy: just relaunch the application. The next time Aalto is launched it should have all of its UI.

Thanks, I'm on top of this... I like Numerology :-)

FYI I can duplicate this in Numerology.

Did you try other hosts? Is it still broken in Numerology?

with Aalto 1.8.5? Are you still using Live 10.0.5? What OS version?

No I haven't seen any crashes like this. Next time you get one please send a crash log.

Yeah, these are complicated systems, especially when using things like Max and a bunch of plugins—adding more processing / threads can easily manifest a bug in some other piece of code somewhere that just wasn't showing up otherwise. Likewise I can't rule out Aalto as being the problem just because it's not crashing in Aalto's code.

You could also try leaving Aalto and removing all other plugins that aren't part of Live—if this eliminates crashing then finding the offender should be quicker.

I don't see a problem with this. Will add to my Kaivo list.

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?

Layout?

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.

Power?

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…

I will be very excited to share news when there is any. For the time being I have to work on software.

This crash does not look Aalto-related. I would send it to Ableton support.

You can usually tell what crashed by looking where the report says "thread crashed" which is 0 in this case. Then look down to thread 0. The first column of info is numbers, the second is the running process. in this case it's all Live and macOS.

I don't know of any crashing problems with 1.8.5. Please keep me posted.

I updated the Soundplane app to work with OS X Mojave. The signed 1.8.0 dmg is available at the above link.

This update also fixes recent bugs with controller messages and reduces redundant data output.

I definitely plan to add more models.

Hey @shadowmusic, thanks for your patience. I don't usually work on Sundays but I was at the computer today so I'm glad I was able to help you out.

Not sure why I missed the above message... Sorry about that, I hope you found the way by now.

interview by Geeta Dayal

At age 29, Kaitlyn Aurelia Smith is a rising star in the world of electronic music. Her music was shaped by her years spent exploring the pastoral landscapes of Orcas Island in the Pacific Northwest, which led to a chance encounter—via a neighbor—with a Buchla 100 modular system. This, in turn, led to an affinity for the Buchla Music Easel, a unique, portable synthesizer invented in the 1970s. After several experiments with releasing her own material, her first full-length album, Euclid, was released in 2015 on the label Western Vinyl. Her new album, EARS, is receiving major acclaim; NPR recently raved that it "elevates the warm pulse of the Music Easel into the realm of the divine" and Spin wrote that Smith's album is "startlingly, richly fulsome, commingling the mysticism of Smithsonian Folkways LPs, IDM’s furrowed futurism, and the free fall questing of Laurie Spiegel’s 1980 landmark, The Expanding Universe."

What drew you to composing electronic music in the first place? Can you talk about some of your early inspirations?

I studied orchestral music and composition in school, and my first introduction into making electronic music was on a Buchla 100. Immediately I felt like I had a personal orchestra at my fingertips with only my time to worry about.

In the beginning of my experience with electronic music, listening was my inspiration. Taking time to listen to one oscillator and then adding another and hearing how they interact. I spent a lot of time with the Buchla 100 trying to learn what It seemed like the machine wanted to do, rather than what I wanted it to do. I found this approach to be more enjoyable and less frustrating.

You’ve talked a bit in interviews about the natural environment of Orcas Island in Washington, and the profound effect it had on you. Can you briefly describe the landscape, for people who have never been there?

There are endless evergreen, aspen, madrona and cedar trees. The ground is lined with thick pads of moss. Lots of mushrooms. It is an island in the Puget Sound, so it is surrounded by other islands that look very similar. No poison oak. Lots of deer, rabbits, hawks, eagles. A lot of moisture in the air.

I was struck at how you are able to coax beautifully tonal music out of the Buchla Music Easel. It’s not an easy instrument to play in the way that you do. Can you talk about why and how you use the Easel? Some of your techniques and tricks?

Thank you. I approach the Easel in a similar way that I did the 100 but with a bit more intention now. I have spent enough time with it that it feels like an extension of my limbs, like how an acoustic instrument does. When I am composing, I use a mixture of intention and happy accident to guide the intention. If I could, I would use a Buchla 200 but since I don't have access to one, I am more than happy with the Easel. When I compose electronic music, the electronic part is always secondary to me. Composition is first.

You’ve used a combination of hardware and software instruments. Can you talk a bit about how you’ve used Aalto?

I love Aalto; it feels like a software version of a Buchla. Very intuitive to work with. Inspiring interface. It has a very complimentary tone to the Buchla. I like to map it to a hardware device and compose with it in real-time along with the Easel.

What’s your setup like at home for making music? How do you work?

My setup changes a lot depending on the project. Sometimes it is just a piano and sheet music; sometimes it is notation from Finale sending MIDI to the Easel; sometimes it is really elaborate with many synths connected to each other using the same clock, and a vocal mic so I can make everything in real time.

I find that I create best when I experience novelty, so I tend to not stick to a routine or similar setup when I create.

 

What are your plans for future projects? What are you looking forward to in the coming year?

I have a new album that I am very excited about — it combines synthesis with orchestral instruments and voice. I will be touring a lot over the next year and making more music.

Kaitlyn Aurelia Smith’s EARS is now available from Western Vinyl and at bandcamp.com.

If you want to get the same effect as the bug, you can add a square wave at half your sampling rate to the output. That is really all that was happening. I don't doubt that you found some kind of magic in it somehow, but there is no way this will become part of the instrument on purpose.

You can also continue to use the version with the bug, if you so desire!

An update of Aalto and Kaivo to version 1.8.4 is available now on the product pages. This fixes a few compatibility issues that showed up in recent versions of Live, and a bug introduced in version 1.8.3 where Kaivo would stop making reasonable sound.

Aalto and Kaivo changes:

  • removed debug code that was causing a crash in certain hosts
  • streamlined OSC services
  • add master_tune program parameter, accessible via program text
  • fixed t3d input in unison mode

Kaivo-only changes:

  • fixed a filter bug that could lead to runaway noise
  • improve interpolation filters in Body

The master_tune parameter addresses the need of some players to move the reference pitch of A to some value other than 440 Hz. This parameter is saved with each patch. To edit it, first select "copy to clipboard" to get the patch as text then paste into a text editor. Change the value after "master_tune", and then paste the text back into the plugin using "paste from clipboard." I'll be adding a UI for this feature in the future but for now, this works and lets you tune Aalto to your old piano or whatever.

The interpolation filter change to Kaivo should not be too obvious, but may be noticeable as a reduced harshness when sending bright tones to the body.

Hi, no I haven't sent out an email about this. I have been waiting to finish something else I'm working on so I can combine the two news items into one message. I'll send it out soon in any case. best.

No worries... Audio CPU use should be more or less the same in 1.8.5. I've changed a lot of interface timer code so UI stuff may feel snappier, which I don't have a good way of quantifying but it does feel better to me.