randy's Recent Posts

The multiple channels in the granulator source are like a palette of waves. The sound comes from a crossfade of the two tracks bordering any x, y position the grains are coming from. So, the number of channels in the file doesn't really have any connection to a multichannel output.

I might do quad versions of all the plugins if there is a demand. So far just one or two people have wanted this so it's a ways down the list.

Glad to hear, enjoy!

OK! Thanks for the feedback.

I have to get the Aalto update out first, then will address this ASAP.

Hi Rastko,

First thing I'm wondering is, did you do "select carriers" for your Soundplane? This looks at all the possible frequencies and chooses the ones with lowest noise. If you do this you may stop seeing the jittery areas. Go to Expert -> select carriers. The result will be saved in the Prefs file.

In any case the Jitter is radio-frequency noise at some frequencies. Normally the "loudest" noise is from the Soundplane's own power supply, because the frequencies in question do not travel far. But it's possible there may be external noise sources. So if you do "select carriers" when you are seeing the worst noise, you will guard against that particular noise source.

X and Y are absolute positions from 0-1 across the surface. dX and dY are the change in position after a touch is started, until it ends. So, moving right makes dX > 0, moving left makes dX

The matrix switch sends the raw touch matrix over OSC. It is not normally needed. You can see the example Max/MSP patch for an example if you are interested and Have Max/MSP.

Please see your email.

It’s educational


I’ve always been happy to offer educational pricing deals for my plugins, if someone asks. I have not generally advertised it because the selling mechanism was a bit of a pain to deal with for both me and the buyer. Thanks to some improvements to the web site, that is no longer the case, so I'm spreading the news more widely now.


A 50% discount on all Madrona Labs software is available for any person currently enrolled in or teaching school or university. If you would like to use this discount, please do the following:

  • Make a Madrona Labs account if you don’t have one
  • Send an email to support@madronalabs.com including a picture of your current student or faculty ID, and telling me what you want to buy (Aalto and/or Kaivo). Please keep the image size small (< 1Mb) or the mail may bounce!

When I get the email I’ll send you download coupons that you can use at purchase to get your educational discount.


I plan to keep this 50% discount on software available indefinitely, so there’s no hurry. Madrona Labs would not be here without the past support of my research by the University of Victoria, and its future will be shaped by ideas presented at conferences like DAFX and NIME.


For site license pricing, please contact me at support@madronalabs.com.


FAQ


I’m only taking one class, is that OK?

Yes, thanks for asking.



My school or university doesn’t have IDs.

Then it’s probably not an accredited educational institution, which is kind of where I draw the line.



Is there a discount on hardware?

No.



Is this educational version different in any way from the normal software?

No. It is the same license, for commercial or non-commercial use, and does not expire. It will qualify for the same upgrades as the full-priced version.



Can I use the educational discount along with another sale discount?

No, only one discount at once.

You didn't say what software you mean. I'm going to talk about Aalto --- all this should apply to the Soundplane and Kaivo as well.

When you make a view for a new Aalto instance for the first time, it comes up with a default size of 1000x600 or something. This is not adjustable. When you drag the window resizer to change the size this change is saved with the DAW file.

I think you have exactly the right ideas in mind. Most of the difficulty in the touch tracking is doing multiple points. A single-point tracker could just look for the highest peak and would be very simple.

Hi Mark,

The Soundplane is a continuous controller first and foremost, not a keyboard. So the protocol reflects this. The touch number is the only thing that two ongoing touches cannot share. It's fine for them to be on the same note. Or for a touch to start on one note and end on another. So we don't want to be comparing notes to tell touches apart in any case.

I tried to make t3d useful in any environment that can receive OSC controllers and treat them as control signals. The idea would be to have a controller /t3d/tch1/z for touch 1 amplitude and so on. I don't know if Reaktor makes it easy to build things at this level. I know that Max/MSP does.

A visualizer would be pretty easy to do in Max. I believe I already have one in my Max examples folder that came with the Soundplane distribution.

Hi Scott,

It sounds like you are finding the right stuff. I took a look at SoundplaneDriver.h where the whole isoch buffer format is documented in the comments. This should be the main info you need. All the code that runs the Soundplane app is in the repo.

The low-level stuff in SoundplaneDriver gets the isoch data. SoundplaneModel::processCallback() is called on its own thread to get the latest frames.

My guess is that a Due will not have the CPU needed to run the algorithm I am currently using for touch detection. The emphasis was on speed and sensitivity, but CPU use is rather high. I am going to be working on the efficiency thing, so even if it doesn't work on your platform at first, I hope you push forward and see what happens, and we can work on this together over time.

The Soundplane's output protocol has not changed since the first Soundplanes were released.

December.

I'm glad to help you play with this stuff. It is not documented anywhere apart from the C++ code, though I hope that is very readable. One reason it's not documented better is that the algorithm is fairly often in flux as I try and do a better job. In particular there will be a big change coming within a few months as I do a rewrite to make adjacent touches work better. If this is a big step up, then spending some time documenting things will make sense at that point.

Some algorithms are really clean and profound, this one not so much. I am using quite a few techniques to get smooth yet fast touches and increase the sensitivity. It's like a grab bag of everything that helped. So explore and feel free to ask questions along the way.

The basic interesting idea is that it's not just peak picking, but distance comparing the 2D images from a template representing the ideal touch. This helps pick light touches out of noise.

The matrix output over OSC is calibrated to set levels but otherwise unfiltered, if memory serves.

I support your efforts to get something going in Max, but in my experience that is a pretty bad environment for this kind of task. Or rather, flow-based programming is not a good fit. If I had to do something in Max I would use javascript in max.

I realize this only scratches the surface but feel free to ask more questions.

You won't see Aalto or Kaivo in Pro Tools because there are no RTAS or AAX versions.

Here's an article from the Pro Tools Expert blog that covers some options for using VST plugins in Pro Tools: http://www.pro-tools-expert.com/home-page/2013/7/10/7-ways-to-host-vst-or-au-plug-ins-in-pro-tools-11-and-earlie.html

DDMF Metaplugin is a kind of super wrapper that lets combinations of AU or VST plugins run in Pro Tools. It may be another option for you.

I just meant, use the VST version to run the VST presets. Anyway, very soon this issue will go away...

Thanks for catching that. There is an AU version number I have to set separately from my internal version and apparently I forgot to do this. I will automate that step now!

Hiya,

The 'note' property sets the start note of each zone. You can edit this in the JSON file to make your own zone maps. Do you see the zoneExample1 preset and so on? If so, the presets are in the right place. You can put your own zone maps there with notes, sliders and other controls laid out as you wish.

I'm attaching the JSON for the built-in "rows in fourths" below. You can edit this to your liking, and save it in the presets directory for use. Let me know if this makes sense.

{
"zone": {
"name": "B2",
"type": "note_row",
"rect": [0, 0, 30, 1],
"note": 50
},
"zone": {
"name": "E2",
"type": "note_row",
"rect": [0, 1, 30, 1],
"note": 55
},
"zone": {
"name": "A2",
"type": "note_row",
"rect": [0, 2, 30, 1],
"note": 60
},
"zone": {
"name": "D3",
"type": "note_row",
"rect": [0, 3, 30, 1],
"note": 65
},
"zone": {
"name": "G3",
"type": "note_row",
"rect": [0, 4, 30, 1],
"note": 70
}
}

I'm hoping to sneak OSC control of parameters into the next update. But if not now, soon.

Well, I will still have to check out the Yosemite performance soon, but I'm very relieved to hear that there are no serious issues now.

Yes, I have only had Logic do that thing with occasional OSC latency. As OSC is system-wide the problem could be elsewhere, but something Logic is causing somehow.

Amazing, thanks for sharing! I don't have time to try it this week but I hope someone does and reports back.

This really makes me want to add better formatting for things like code to the forums here... we are always tweaking and have some more redesign in the works.

OK, good to hear. The hub may not be capable of transmitting the Soundplane's isochronous data for some reason. Some hubs do work OK.

Sorry the preset situation is a bit frustrating right now. The preset converter has been broken in version 1.5. I'm fixing it and also moving to a new unified preset format for 1.6. This will be out very soon.

I plan to add search to the site, but meanwhile you can use Google with a query like "site:madronalabs.com presets" to see results.

Hmm. This is the first time I have heard of this happening. The Soundplane is being recognized by the app, but data is not flowing.

Can you go to the Expert page and tell me any messages you see there?

Also try plugging the Soundplane in without any other USB devices connected (except keyboard / mouse).

Fixed for the new build, will release ASAP. Thanks for the info.

Thank you for the offer! Since it's a general performance issue but not a crash, there's not too much I can do to move forward short of running some profiling tools on your system.

Meanwhile, if you could look at some things for my sanity, here are my requests:

  • pull up a new Live project and make one instance of Aalto running "ancient 4-voice" preset.
  • close the Aalto window (we are ruling out graphics for now)
  • what is the CPU use in Live's meter?
  • what is the CPU use in Activity Monitor? (will vary by 2--3% after settling down)
  • what is the buffer size in Live under Preferences / Audio?

if you have a minute to look at this on both 10.9 and 10.10 with the same buffer settings and audio interface I would appreciate it. Also be sure Multicore / Multiprocessor support in Live is the same setting on both machines.

Also, please let me know the CPU details for each machine, or if it's the same machine so much the better.

MANY THANKS

Thanks for the info Joel. Looking around I see a lot of complaints like "Yosemite made my audio / view slow."

Try running Aalto with animations ("anim") disabled. Does it help?

@copernikit, there may be a couple of things at play here. Let's separate the OSC issue out first.

The OSC outputs from the KEY module are not compatible with the MIDI outputs. This is by design because the Soundplane over OSC just puts out different kinds of data. So you can't plug in a Soundplane and get anything out of an arbitrary preset. You could have a situation where the ENV is triggering but the pressure from OSC is coming out in place of a gate, and things sound weird and delayed.

Here's a zip of Aalto presets for Soundplane:
http://www.madronalabs.com/media/soundplane/Aalto%20Soundplane.zip

Now, regarding latency, once in a while I have seen Aalto in Logic go into a mode where latency is just horrible, 1/2 second or something. It happens very rarely, and remaking the plugin instance seems to take care of it. I don't know if this is a Logic problem or what and haven't been able to track it down yet.

There is a known fixed latency in Aalto 1.5 of 256 samples. I have reduced this to 64 samples in the 1.6 version coming out soon. The reason it's there is because in a patchable, modular synth with feedback you need some kind of latency to implement patching.

Also there is an issue in 1.5 with playback timing, fixed in 1.6. But it sounds like you are just talking about playing live.

I haven't tried Yosemite yet, but getting Logic + Apple's latest + my plugins running smoothly is always a high priority so it should work. People seem to be saying things work well overall. As soon as I can get Aalto 1.6 out, I will upgrade here and then do more testing myself.

Kaivo can be very CPU heavy, but there are plenty of ways to make it less so. I wrote an article on the topic here: http://madronalabs.com/topics/3565-getting-the-most-out-of-kaivo

I don't know why Reaper is so different in its CPU reporting from Live in your experience. Each host can have its own idea of what CPU means, so it's not always a good comparison to look at in-host meters.

A good way to compare different apps is to look at Activity Monitor (or Task Manager on Windows.)

I found 5-6 small in the box and one large. If you want one, email me your address and I'll request money via PayPal. randy at madronalabs.