randy's Recent Posts
It turned into a pretty ambitious project and I'm reworking a ton of the enabling technology as well. I appreciate that you are still interested!
I have put some of the behind-the-scenes work into a smaller new release. More info on that in the next couple of weeks.
I've finished version 1.5.0 of the Soundplane software. This release is recommended for all Soundplane owners. It fixes some possible crashes and has an entirely rewritten touch tracker, almost a year in development. The benefits of this new tracker should be obvious as soon as you play it!
Direct link: Soundplane 1.5.0.zip, 5.9MB
version 1.5 changes:
- 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
In case you missed it, you can see me playing a Satie piece using the new software here:
I'm taking on some "real pieces" in addition to improvising, to feel out what changes will make the next model of Soundplane the best instrument we can make it.
The documentation does not reflect many aspects of the new software yet. Please post in the forums or email me anytime if you have questions.
NOTE: to install this version of the software I recommend removing the existing files in ~/Library/Application Support/Madrona Labs/Soundplane. Then running the new version the first time will run the carrier selection and create new defaults.
After the new prefs are made, select "default" from the OSC destinations menu to get OSC flowing again.
If I did this I would probably make it quantize to whatever scale is selected in the KEY module. Then adding a scale that just has the dial detents in it should give you what you want also.
Can you turn on record automation to record the manual tweaking of the knob you are doing? That should work. Then if you want to edit it you'll have all those values in the automation track to cut and paste.
I forgot to add that search is on the Resources / Support page.
No idea of when exactly. But it's clear tablets are a big part of the future.
Been vector-based here since 2009. I don't see all the trains coming, but I saw that one.
Yes, I can invoice you via PayPal. Please email me at support@madronalabs.com.
Fedor Pereverzev, AKA Moa Pillar, is an artist who specializes in deep, dark electronic sounds. Hailing from Moscow, Fedor works by day as a sound designer for the audio company Monoleak. His recent album Humanity was released by the label Full of Nothing. A label based in Karelia and run by Anya Kuts and Ivan Zoloto of the noise duo Love Cult. Humanity is a beautifully textured journey through the Moa Pillar world, all while showcasing Pereverzev’s sound design expertise. We were happy to have the chance ask him some questions after learning he used Aalto as the main tool on his new album.
You’ve described your music as “Spiritual Bass”. Can you elaborate on what this means to you?:
Spiritual bass is a journalist’s term. I used tag “spiritual” only in track’s description on Soundcloud. This word is important because it allows me to show that this music is not only about dancing (although I attach great value to this aspect as well) but about my own way of understanding the world. The tag “Spiritual” points out that this music is a result of my own discoveries and experiences regarding to metaphysics of the world.
What is Moscow like as a place to be making electronic music like yours? Would you say that where you are physically, and a sense of place, is important to your work? Do you enjoy performing live?
I think Moscow, like any other big city, is a comfortable location for music making. There is always something going on. You can feel this eternal motion that motivates you to move on. You can always find somewhere to go or to be inspired. But at the same time, I can’t say that Moscow inspires me. I’m not interested in reflection on the aesthetics of the city or its metaphysic in my music.
I’ve truly started to enjoy live gigs just recently. Until now I had pretty mixed programme that didn’t allow the most important thing to happen - going deep into the music. It didn’t allow me to do this. Today meeting people is important for me. New programme is strong and solid. This is where the magic happens. Anyway, live performing is still a tricky thing for me technically. I never write music keeping in mind the way I will perform it. I always consciously choose building complicated structures instead of the ease of performance. So the question "how to play it?" is always acute. My music has lots of layers and I can’t play them all. You have to find balance between audio, that plays automatically, and structures, that should have been manipulative. This kind of analysis of my music is an interesting game for me.
You mentioned that you work as a professional sound designer by day. How does this line of work relate to your personal musical expression? What can you tell us about Monoleak?
Monoleak is a full service audio production and music agency, formed by me, Savely Shestak and Savva Rozanov. We’ve been producing music for movies, advertisement and shows for almost five years now. For the last couple of years we’ve worked with dozens of automobile brands with their launches in Russia and abroad. Our latest significant achievement is creating original soundtrack and sound design for the biggest show in world history of 3D-mapping created by Sila Seta Inc. covering huge Ministry of Defence building in Moscow.
The working process helps me with my own music growth. Working on the projects as part of Monoleak I better understand what is really interesting for me in music and what is superficial. I can realize all of my spontaneous desires, not allowing them to get into my personal field. For example I can write “sweet” house music, edm and so on. It’s also a constant improving of technical skills. By the way, we use Aalto pretty often in production. It’s perfect for background atmosphere and sound design.
You mentioned on our forums that your new album is 85% Aalto. What is it about Aalto that you connect with so well? Can you tell us anything about how it fits into your process? For example, do sounds tend to come first and lead to rhythms or vice versa?
Yes, that’s true. In fact I used Aalto (and sometimes Kaivo) for all the sessions except melodic bass and rhythm. Tracks without rhythmic structure (Essence and Magnets) had been made with Aalto. I can honestly say that I’m in love with this synth. I like its clarity, intuitive interface and certainly the sound! I had a feeling that I was working with a live instrument because with Aalto you can achieve tones and rhythm imperfection. And I really appreciate it. Should also note the ability to download different musical temperaments. It’s great! I was really impressed when I found variety of my favorite composers (Terry Riley and La Monte Young) in the list of “key tuning”. I dream about modular synth by Madrona Labs (as many other people I think).
My work starts with opening the session where all the knobs of Aalto are connected to Launch Control XL. Further, if I don’t have any specific idea, I just turn on the recording and improvising. Most often something impressive comes out during this process and I use it in further work. This approach and scopes of Aalto were very useful during my trip to the Caucasus, Kabardino-Balkaria. The purpose of the trip was the musical commination between me and the guys who play and learn traditional Kabardian folklore. The result of it was a documentary “Bonfires and Stars”, which is now being prepared to be shown at international festivals. It was filmed by Stereotactic team.
profile: Josh Leibsohn
photos: Fedor Pereverzev
Listen to Humanity: http://everything.fullofnothing.net/album/humanity
Moa Pillar:
Soundcloud
Facebook
Twitter
Monoleak:
Soundcloud
http://www.monoleak.ru
Thanks for the thoughts. I'm more and more certain I'll do tablets eventually—it's just the way things are moving and an undeniably useful form factor for playing. This weekend I taped my macbook pro to a stool at a show. I would rather just not bring it.
Most iOS developers I know are moving towards AUv3 only, with a standalone if that makes sense.
It's easy to set up vox in a predictable way when you want certain intervals or differences. For example when the input has a default that gives you a useful value. like the oscillator pitch default of one-per-octave. Attaching vox to this will shift each voice after the first up by an additional octave. I guess this is covered well in the manual.
Where things get tricky, as you point out, is dialing in small variations that you want. Here I think Aalto could use some UI additions, such as text entry or other fine controls for the attenuverters. I do plan to add those.
The attenuverters do have a fine-adjust mode like the other controls. Holding shift while dragging can help with fine adjustments.
Maybe a precision attenuator on the vox output itself could help too? I'm open to ideas.
Sorry, there's no way it can be made to do that currently. A few people have asked for that feature, so I will add it at some point.
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.
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.
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.