randy's Recent Posts

A few months of quiet work on the foundations of things is wrapping up, and I'm feeling certain enough about it to give you a preview. I'll be releasing a revision of each of the Madrona Labs plugins within a few weeks. Aalto, Kaivo and Virta all share a common core library, and I've updated it for improvements in compatibility and stability.

Text handling has gotten an overhaul to allow for use of Unicode in patch names and registrations. If your name is Фёдор, Zoë or 郎, or you want to name your patch, say, デトロイトテクノ, we've got you covered.

The code that turns messages from the host DAW into stable clock got a big overhaul: a new software PLL implementation. In case you missed it, here's a demo:

Aalto PLL test from Madrona Labs on Vimeo.

In order to stay compatible with upcoming versions of MacOS, the license code has been reworked. When I first started making plugins, I thought it would be the most convenient for everyone to download uniquely watermarked software right from the website, because just one install and no registration steps are required. So that's how we've been doing it. This was a neat idea, but it is a very inconvenient idea if I want to codesign the binaries to make Gatekeeper and its Windows equivalent happy. With every plugin being different, a dedicated code signing server would be needed to sign each copy, and that’s not practical for me to maintain.

I'm moving to a system where instead of downloading the whole binary, you just download a license code and paste it into the plugin to turn the demo version into a licensed one. (Yeah, like 99% of the plugins in the world.) All the other license terms will stay the same—installation on multiple computers is still fine, for example. I've worked to make the registration experience, from website to plugin, as smooth as possible. It may even be better than my old system, because you can turn the demo into a licensed version while it's running.

Timing problems affecting Reaper and a problem I introduced with Virta 1.0.2 are also getting fixed.

Because of the need to change the website, all the plugins are switching over to the new license code at once. Probably within a few weeks. It's a big change that should make deploying new versions easier for me, and should also make life easier for all users of the software. I'll keep you posted!

Yup, got the message re: MIDI learn and will add it soonish.

You don't want me designing any circuits! Maybe Brian will chime in if he has a minute.

:smile:

Ten years ago, I didn't foresee a time when I would want another big, bulky server again. Laptops were plenty fast for all of my development work. MacBook Pros just kept improving with every generation, secure in their well-deserved status as the developer's machine of choice.

Now things are different. Clock speeds have long been stuck on a plateau for most of the past ten years, and the number of cores available at a reasonable power budget is not making up for it. So I got a machine that sits on the floor in the new office and lets me forget about the power budget:

eight-core xeon

It took a little learning on my part because I was unfamiliar with all the CPU options for a Windows machine. But now I have a dev box that well outpaces my MacBook Pro, and it cost all of $600. From http://theserverstore.com. A good experience, would repeat.

I've long been compiling on both Windows and Mac OS—each environment has its pros and cons. Visual Studio looks kind of ugly, if you're used to XCode, but the debugger actually works. On the other hand, its C++ compiler is a lot slower.

I have no plans to move away from Mac OS—not only does it do some things I can't live without, but cross-platform development, more fundamentally, is a crucial aspect of making good code here. I am scripting both XCode and Visual Studio from the command line so that building just means typing "build," both on Windows and Mac OS. This will hopefully pave the way for Linux support in the near future.

I've had some reports of problems from people using Mac Pros, with Kaivo in particular. These will hopefully be gone with the update coming very soon, and having a seriously multi-core machine to test on has helped with that. It also means I'm chomping at the bit here to make all the instruments able to distribute their voices across multiple processors.

Did I mention this thing was $600? I had more budget I could have spent on a new development machine, but there was no current offering from Apple at any price that seemed as exciting to buy. I hope Apple will astound me again with the shiny one day. Until then, I'm way more excited about making Aalto run on some little quad-core ARM (say) appliance I can throw in a bag and take to shows.

Considered Hackintosh?

I guess it breaks license terms, which I can't really do as a grownup developer. Also with all operating systems wanting to auto-update these days, I wouldn't feel like this is a stable platform for getting work done.

Thanks for the feedback re: additive synth. I'm kicking around a few ideas for the next instrument still. Too soon to report anything.

I thought this was fixed. I'll make sure to test it for the next release.

Thanks. I've logged this as an issue and will investigate after the next release.

Sorry I didn't acknowledge your bug reports! I do value them. I'm frustrated that I haven't had time to investigate these issues. I have had a show-stopper preventing release of the update still, and I have been trying to focus on that. I should have replied to you with a simple acknowledgement though.

I've logged your report in my GitHub issues and will get to it ASAP.

Sorry you had problems with the site. Please stay tuned for winter sale news shortly.

I just set up the patch you mention and played with modulating the ratio. I see what you mean - it makes sense that the range would be bigger.

Tip: you can use the "vox" output as a reference because it always outputs the signal values (0, 1, 2, 3) for Aalto's four voices. So doing this I see that the range 0-3 with ratio attenuverter set to max makes ratios of (0, 4, 8, 12). Mod outputs translate MIDI [0-127] into signals [0-1] so that gives you your 0-4 you were seeing.

When I decided on the amount of scaling possible for each patcher destination, I was usually making some "musical" decisions. An envelope sent to the ratio made a pretty extreme change in the ratio in any musical context, and I was optimizing for a nice range there.

Probably the mod cc outputs should be able to have their outputs increased. This could be buried in a KEY module settings page.

Sorry I missed this post for a bit!

I didn't give any thought to making the ratio snap to whole numbers. So it's not easy to do. I'm not sure what you expected to happen differently in the example you give, but it seems like normal behavior to me.

In the future, dials will be getting some kind of contextual menus, probably. So that would be a place you could choose to quantize the value.

There is a patch called "harmonic wind" in the textures folder. It shows another way you could try it using the sequencer to set up some quantized values. You could then patch the mod output to the sequencer step offset.

I wouldn't expect Aalto or Kaivo CPU to drop, but any intermittent pauses/crackling should hopefully be gone.

The fact that you're using a powerful machine and seeing these troubles is a hint to me that the crackles should be fixed by the next update. I've put a Virta beta out and it's available here on the "Virta beta" thread. If Virta works well for you I think that Kaivo will too, after the update.

The need to move the Labs impeded progress over the last two months but I'm working full time to get these updates out now. Thanks for your patience.

A reasonable question, given that a few weeks turned into a few months. I guess you heard I had to move the Labs, somewhat unexpectedly. I'm just now getting settled into the new space and back to working full time. A few issues remain on the Windows side of things but hopefully I'll be done very soon.

If changing the preset fixes it, this is likely a different problem. It could be that the default patch makes no sound in the DAW setup you are using?

Model B is what I am calling the next version of the Soundplane.

Hi Giorgio,

What comes off the DIY controller is a few steps away from being MIDI. You need some kind of computer reading the pressure matrix to recognize the touches and then transmit MIDI data.

I would start by making a 1x1 controller. in other words, a single point pressure sensor. When you do this you will get a good feel for the materials and all the steps involved.

Yes, I think I know what this is. There was a bug that only affected certain machines, more often the more powerful ones, unfortunately. I believe I have fixed this for the next update.

I had to move the Labs across town, so it's taken a while to get this update out, but I'm pretty much back to going full time on it until it's done now. Thanks for your patience.

Yes, we're at https://www.facebook.com/madronalabs/

I don't check it very often though. If you have support questions, you will get a faster response here on the forums or from emailing support @ madronalabs com.

MPE uses the Channel Pressure for each channel and not Poly Pressure.

Yes, velocity should be the same, whether regular or MPE.

Aalto (and other ML stuff) doesn't respond to release velocity.

Hi Greg,

If you are seeing x and y then you are in MPE mode. those two outputs change according to the "protocol" setting in the settings menu, where protocol can be either MIDI, MIDI MPE, or OSC. The manual usually refers to MIDI mode things though out of habit. I'll try to correct this.

In MPE I am always using 1 for the "main channel" and 2 and up for the others.

I'm feeling the same. Expect more serious effort on Linux and Windows support as we work on Soundplane B.

I always planned to have Windows support "soon" but it turned out to be much harder than expected. A nice contractor did a Linux driver for me and we intended he would go on to Windows work, but he ran into problems. Maybe in Windows 10 this is easier. If not, we'll just do whatever we have to including possibly contracting the work to someone who has low-level driver experience on Windows.

I still have my sights on making a well-designed "music appliance." I'm always looking at ARM vs. Atom vs. DSP and so on. I think enough power for lots of audio processing, just about anything I'd want to do on stage, can go in quite a small box now.

Nice and prickly, thanks for sharing.

Hmm. Google search brings up mostly whole threads for me.

No problem, I wish searching the site were more obviously possible.

MIDI itself should be fine—it's all about when the messages are actually getting sent in Max. I tend to use a lot of signal-based control flow in Max. When signals break, at least you know they are breaking, but messages can kind of start degrading in performance and drive you crazy trying to figure it out.

I would use the setting "Scheduler in audio interrupt" in Max, along with a small vector size of 64 or 128, maybe. This should give the most repeatable performance with messages. Unless something in Max has changed since I used this stuff...

My usual goal is to make things sound the same at different sampling rates. Doing this perfectly would take a lot of CPU in some cases, though. So there are optimizations that you might be able to hear sometimes, like calculating certain signals only once per signal vector instead of every sample. (Usually these should be only every N samples regardless of signal vector, but maybe sometimes it's the latter.)

I'll take a listen...

This is fixed for the release. I'm afraid packing / moving is slowing everything down significantly. Will release ASAP when landed, probably next week.