randy's Recent Posts

Soon. Overall it looks a lot like Aalto and Kaivo.

Well, audio input and frequency analysis of said audio, and of course an envelope follower, will be available in the patcher. So you can make audio-controlled synths or effects with it. You could even patch up something like a de-esser. But it's definitely more a creative tool than for utility effects.

Visually, it will be a lot like Aalto and Kaivo because I think that's a good interface to stay with for now.

More soon!

All versions of all software come with free upgrades until the next major version (2.0 Aalto will be next). The major version will be a small purchase. I've been updating Aalto for five years and I'm still on 1.x, it's all been free upgrades.

I hear you.

the 1.3.1 fix doesn't work with kyma

re: Kyma, can you give me any more detailed report of the problem? What step exactly do you notice something went wrong?

If you look in the Soundplane app console, is there any information? Any error messages?

Is the kyma switch in Expert page on? If so, try turning it off and on, then look for any error messages.

I can make a debug version to display more info. Please contact me by email at support@madronalabs so I can keep track of the conversation better.

That was my guess... voices canceling each other. Thanks for the followup.

Aalto 2.0 will be after the new plugin, not soon. Please stay tuned for beta calls etc...

@zgoheen I know exactly what you are talking about. It's a basic problem with the way OSC / t3d voices are allocated and I didn't realize it until the zone split thing was done and I really had to move on and ship something. OSC voices have always been set up kind of like independent channels of CV / gate / etc that are always on. This model works for one Soundplane->Aalto connection but not for splits. To fix it I have to write a voice allocator for OSC like there is for MIDI. This won't be too hard so you can look for it soon.

I'll check into this, thanks.

seems reasonable! I plan to rework the sequencer for Aalto 2.0 so it could happen then.

Hey, I hope it was a simple matter of resetting the port # so I just distributed a fix.
[Soundplane1.3.1.zip]

The problem is I picked a UDP port for the incoming Kyma information that duplicates the default port with offset = 1 (3124). So if you have a Kyma connection that port will be busy and offset 1 will not for for Soundplane->Aalto connection. I can change the default in the next Aalto version, or maybe ask Symbolic to change the Kyma default port.

What would you want to control via OSC? I feel like maybe I asked you this so if you can point me to an answer that would be great. I'll make sure it makes it into the new feature requests list on github.

I think I know what the problem is. Sorry to have overlooked this, but Kyma isn't part of my testing here because I don't have one. I needed to change a port number because of a conflict. I'll figure out a fix.

If you look at the new split example zone maps they show different zones being sent to different OSC ports. So you could have Aalto listening on one port and Kyma on another one, yes.

ah crap. why OSX 10.7?

I know, I hear you, but I had to do this sometime in order to update my development tools. Apple only supports the C++11 language as far back as 10.7. I wish very much they had made it accessible on 10.6.8 because that was indeed a good solid operating system.

Meanwhile, Aalto 1.6.1 is very stable and should keep you going for years on 10.6.8 if you want.

pitch bend range is not changing when the soundplane tells it too via the NRPN

Hmm, I thought that was working, I'll check into it, thanks.

Midi Learn in this release?

Nope.

BTW why dll began to weigh less? (about 2mb) :D the same as whole installer (Win), about 5 mb.

I'm always working to optimize things where I can. The new Microsoft libraries I use are a little smaller too.

mavericks 10.9.5
64 bits

Hmm, strange, no reason that shouldn't work. I'm guessing you have some AU update problem.

If the plugin is not showing up, you can look to verify that it's in the AU Library folder: /Library/Audio/Plug-Ins/Components. If it is there, you could try removing it using the Finder, then running the installer again. You can also try this voodoo to remove your Audio Units cache: http://support.apple.com/kb/ts1086

Hi. I just install the update and does not work me in Logic x or DP9

In what OS and host versions? 32 or 64 bit?

If you have patches made in Aalto 1.6 or before that you are using with the Soundplane, a little manual tweaking will be needed. These same instructions will be needed to go from Kaivo 1.2 to Kaivo 1.3 when that is released.

The patcher inputs from the KEY module were rearranged and a velocity output added, which has a great benefit: you can now use any Aalto patch with the Soundplane, and make new patches using the aftertouch / z output that are both MIDI and Soundplane compatible.

Here are the outputs from the KEY module using different protocols:

protocol    out1    out2    out3    out4    out5    out6    out7
            --------------------------------------------------------

MIDI        pitch   vel     vox     after   modcc   modcc+1 modcc+2

MPE         pitch   vel     vox     after   modcc   cc73    cc74

OSC         pitch   vel     vox     z       dy      x       y

OSC (old)   pitch   z       vox     dx      dy      x       y

Since aftertouch from MIDI is a lot like z from the Soundplane, patches designed for the Soundplane can now be used expressively with MIDI kayboards and vice versa.

To convert an old OSC patch, open it in Aalto 1.7, and then just grab all the patches coming from patcher input "vel" and move them to "z."

Patches don't store the input protocol they use---that information is sent by a DAW outside of the patch so that your protocol choice won't keep switching when you change patches. Unfortunately that makes it impossible to convert patches automatically for these OSC changes. I apologize for any inconvenience.

Ooh, if it overwrites a version without asking that's a nasty bug. I'll investigate ASAP. Thanks for the feedback.

64-bit windows is good to go, now. I'll be sending out the news in the morning.

Yes, yes it is. After uploading I found a problem with the 64-bit Windows build that I'm still working on. Feel free to have a go at the 32-bit Windows or Mac versions.

Hopefully I'll sort this out within a few hours... but that's what I said last night.

Hi Tibor,

Aalto and Kaivo will read any tunings in Scala format in the Scales directory. This always includes a .scl (scale) file, and can optionally include a .kbm (key mapping) file. If there is no .kbm file, as with most (all?) of Aalto's scales, the default mapping A=440 will be set. To override this default, include a .kbm file with the same name as the .scl file. Here is an example:

! keyboard mapping my12-equal.kbm:
! 
! Size of map (greater than or equal to the number of notes in the scale 
! to be mapped). The pattern repeats every so many keys: 
12 
! First MIDI note number to retune: 
0 
! Last MIDI note number to retune: 
127 
! Middle note where scale degree 0 is mapped to: 
60 
! Reference note for which frequency is given: 
69 
! Frequency to tune the above note to (floating point e.g. 440.0): 
440.0 
! Scale degree to consider as formal octave (determines difference in pitch 
! between adjacent mapping patterns): 
12 
! Mapping. 
! The numbers represent scale degrees mapped to keys. The first degree is for 
! the given middle note, the next for subsequent higher keys. 
! For an unmapped key, put in an "x". At the end, unmapped keys may be left out. 
0 
1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 

For more information on Scala, see: http://www.huygens-fokker.org/scala/

I work to make things solid but I've come to accept that AUs will always be a little fiddly, sometimes. Thanks for the update.

I'm just saying if you have a computer and a rack module you want to connect to at the same time, you can use the computer as a passthru. Say out a little DC-coupled interface or something. This seems like an OK solution.

That said, if there are easy ways to allow for future expansion that don't significantly delay the release of the Soundplane, we will probably take them.

Good news, this is done and will be shipped as soon as I can tidy up the releases. You will need a new Aalto and Soundplane app.

Reasonable idea, talking to both modular and computer. The thing is, the Soundplane just puts out raw data, and doing the touch detection from that data takes a significant amount of CPU. So the upgrade would be a whole new processor board.

Since the computer is in your hypothetical setup already, allowing it to pass the touch data to the module somehow strikes me as a possible solution. I guess it's still not likely to happen given the time involved.

54: from second run, not first. OK that's good information about timing. The spacing material is the same in both cases.

If you have time to mess with spacing, send me an email and I can send you some spacer material. It's sounding more and more like maybe a new touch detector is going to be the best fix for you, however. Luckily you can try and even build dev versions, so it shouldn't be too long until you have something to test.

The situation with the ghost notes and the existing tracker is a little complicated. Your idea is reasonable but doesn't take into account that touches can start out in one place and get moved frame by frame in an attempt to converge on the best solution. So even setting a high inhibit threshold, a touch can start out two keys away from the existing touches and then get sucked in, so to speak. The new tracker uses a different approach and will not have this problem.

this also confuses me a bit, really the difference between the first step (with palm) and second.. are they calibrating different things? It would I think be useful to know a little more about this.

The first pass gathers the normalize map. This tells the software how much each taxel (sensor junction) moves when the same amount of pressure is applied. Typically there are small variations over the middle of the surface, and big consistent changes around the edges, due to the way the instrument is held together. The normalization corrects for both of these.

An ideal way to get the normalize map would be to have a weight of around 100-200g with a flat bottom. Moving this weight around would put a consistent force everywhere on the surface. In practice, moving a palm around with a consistent pressure has given good results, and most people have hands permanently attached, so I have been recommending this instead of something more complicated. But if you are getting inconsistent normalizations, maybe try some kind of moveable weight setup.

The second pass generates a template touch. This is used to discriminate touches from ghost touches and other noise by recording the shape of data a single finger makes. it's important to move reasonable slow here! I would allow at least 10 seconds to traverse a row in one direction.

In the second pass, consistency of pressure is not required. I recommend a medium to firm pressure. If the pressure is too light then the resulting template will be quite large, and will not have a well defined effect.

I looked at the disassembly video again, and I seem to have totally hidden the spacers, because I wasn't thinking about showing them. So your confusion is natural—sorry about that. If you look on the underside of the aluminum back you will see five wooden bars glued on. These hold the sensor layers in place and allow room for the ribbon cables.

The thicker the bars are, the more they put the sensor layers including the foam rubber "waffle" into compression. Ideally, when the instrument is at rest, everything fits tightly together but the foam is only compressed a very small amount: 0.5 mm or so.

On Monday I can get back to the shop and take some pictures of the bars if that would be helpful. Or, I can simply make a sketch of what should be going on. It's really simple.

Now with two reports (above) of changes maybe due to heat, of course it has me thinking that there is something I can do better. I tested the response of the foam over many months before shipping an instrument, but not at temps of 30C. Possibly the foam rubber will permanently deform enough under these conditions that it will be noticeable.

However, a sample size of two instruments is not a lot! So I have to proceed carefully and avoid jumping to conclusions about what might be happening. One thing I can do here is try some experiments with the rubber under compression at higher temperatures.

Every kind of compressible stuff loses some of its ability to return to its original dimensions over time. The foam rubber was chosen after testing around ten different materials and reading specs for many more. It worked well in testing but everything degrades over time and it is certain that heat accelerates this process. Luckily, there are two fixes we can do: add spacing material, or replace the foam layer entirely. I would like to get more data and try a fix with spacing but can also send you a new foam layer if that turns out to be a fix.

Mark, you have a Soundplane you bought second hand, is that correct? Can you remind me of the serial number?

I know I sent one instrument to a hot climate—I can ask the customer how it's going or maybe @rastkopravi will see this and give us some info.

Please understand that I stand behind the instruments and it bothers me a lot when any of them are not working well. Certainly my goal is to make them play consistently and accurately. I agree these are important qualities for any instrument. When I say "accept the ghost touches for now" I'm not trying to say there is no problem, but rather trying to give you another option until the time I can do work on the issue.

The new tracker is a big priority. Luckily for me, you are in a great position to test any changes and seem to have some time to do so—I'm thankful for your involvement and look forward to getting you some options to try ASAP.