thetechnobear's Recent Posts

I get similar behaviour using the Soundplane with MPE,
so I think its likely its aalto/kaivo rather than MPE implementation on the Linnstrument.

(its a bit different behaviour if I use rotate channels or not, but similarly 'confused' :) )

not a big issue for me, as I tend to use polyphonically, and also with T3D which doesn't have any legato behaviour (as far as i remember)


I know your not looking at the soundplane software at the moment, but for your 'issue' list, when you get to it after Verta

I notice my console logs filling up with hundreds of :

4/2/16 00:12:36,000 kernel[0]: Limiting icmp unreach response from 6710 to 250 packets per second
4/2/16 00:12:40,000 kernel[0]: Limiting icmp unreach response from 22822 to 250 packets per second

a quick tcproute trace led me back to the source being the soundplane client software.
as i could see it constantly trying to reach ports 3123 to 3138


00:14:10.331996 IP > ICMP udp port 3123 unreachable, length 36
00:14:10.332014 IP > ICMP udp port 3124 unreachable, length 36
00:14:10.332022 IP > ICMP udp port 3125 unreachable, length 36
00:14:10.332025 IP > ICMP udp port 3126 unreachable, length 36
00:14:10.332028 IP > ICMP udp port 3127 unreachable, length 36
00:14:10.332034 IP > ICMP udp port 3128 unreachable, length 36
00:14:10.332038 IP > ICMP udp port 3129 unreachable, length 36

I had a look at the code, and in sendFrame(), sure enough I can see it attempting to transmit to every port offset for every frame.

from a quick test it appears this can be rectified by adding to the loop

if(!mSocketInitialized[portOffset]) continue;

Im not sure if this is the full picture however, as it may not cover the split case,
I also assume there is some 'logic' behind this, to do with the fact that the frame message needs to go to every client regardless of if theres a touch or not.
Id need to do further testing to check this, though of course I'm limited on how I can fix the protocol as I cannot alter the client software (aalto/kaivo)

btw: I suspect mFrame++ is not correct, should it not be contiguous for each client, i.e. you want it outside the port offset loop.

as I said, I know your busy with Virta, but I hope once thats done you will have some time to resolve some of the issues in the soundplane software, so hope the above will assist you,


happens with just the soundplane client running.

the above fix, I think is fine, I just need to check some of the surrounding logic to check that the initialised flag is set in the appropriate cases.

hope virta development is progressing nicely :)

Since the Soundplane software is open source, Ive developed a few extensions to the Madrona Labs (official) application which I thought Id share. my changes are also open source.

you can download a build version from here click

Obviously this is not supported by ML, so post here if you have issues (unless of course the issue is also present in the official release).

also if you like a feature, let me know... or if you want other features let me know, perhaps I may be working on them, or want them too :)

which version is it? - I always keep my build in-line with the latest ML version, usually the current development version (rather than released)... assuming I don't find any major issues with the dev version.

how well tested is it? - I use it everyday, but of course my usage may vary from yours, so cannot guarantee it. personally I have this, and the official version installed. so that if I have any issues I can cross checked with the official release.

changes included in TB141

  • bug fixes (from official release) related to note on/off behaviour and sending got pitchbend and cc messages

changes included in TB140 :

  • Midi modes (click here to see screenshot)

single channel with poly or channel pressure


MPE ext - extended midi with 14 bit midi support

Multi 73,74,11 (CC x,y,z)

Multi PB,1,CP ( pitchbend, CC 1, channel pressure)

its easy for me to add more if needed...

  • unquantize mode
    when quantize is off, the touch has an indicator of how far you are from being in tune. I use this to practice playing unquantized tuning. (click here to see screenshot)

  • xyz zone
    just like the XY zone, but has a 3rd CC for pressure.

  • OSC fix
    don't send touch data when a touch is not active.

Im also working on a couple of other features,

  • Midi Pedal Input
    I want to be able to publish sustain (& perhaps expression) pedal info out on the MIDI Soundplane OUT, and also OSC.

  • Midi Program change for setups, to allow me to use a midi pedal to switch between different soundplane setups, so i don't have to use the soundplane app during play. e.g. so I can have a full surface playing Kaivo, then switch it to playing aalto

no promises, if/when this is coming... quite a few projects on the go, but I wondered if others have thought the same.

finally, a thank you to Randy/Madrona Labs for making the source code open source, so making this is possible!

updated version TB141 - I found a number of bugs in the midi handling from the official release concerning note on/off and the pitchbend and CCs sent.
These are now fixed in TB141

Randy, if you look at my latest checkin on my repo it will be pretty obvious the issues.

unfortunately, I can't issue a pull request as my code base now contains quite a few 'enhancements', so there a bit I divergence. and I dont have the time to do changes on both my build and yours.
(my build is a superset of yours, i.e. includes all your changes, should you wish to 'take as is' )

Dying to show you something!

Dying to hear something :)

I don't have any issues with bitwig/aalto (or kaivo) but may be because Im no a Mac.

for what its worth, I use Bitwig 1.3.5 , Aalto 1.7

Bitwigs options are simply setting a fixed buffer size (which Id recommend) or Auto which I assume 'calculates' one for you. (rather than varies it, but hey might be wrong)

some options to perhaps try are:

  • put aalto in the same process as Bitwig, rather than run it as a separate process.
  • try turning auto-suspend off

neither should be necessary, though the later may be useful with aalto, as it kind of expects to be running all the time (afaik)

Im not sure the above will do anything, as its not necessary on Mac OSX, but perhaps windows is a little more fickle

N4 has the host clock, and all sorts of interesting clock manipulations...
not seen the new PLL in Aalto yet, so hard to say... Im not sure if N4 uses PLL to keep its internal clock in sync with the host, Ive asked on the N4 forum.

I have to say I don't use the sequencer in Aalto for much more than a modulator, an LFO with waveshaping (and sometimes at high rate), so quite possibly under utilising it :)

why not use dedicated sequencer VST (etc)?
if your on a mac take a look at Numerology 4 ( its a fantastic match to Kaivo/Aalto, its a sequencer+++ :)

I don't really do PC, so only know things that are cross-platform, in that sense, other options would be Reaktor/M4L both offer really rich sequencing options

Im a little surprised to hear, you saying you can hear quarter tone steps on the Seaboard... as Ive not heard this expressed before - have you got an example of that?

(though id have thought the piano layouts perhaps doesnt lend itself to microtonal configuration anyway... but perhaps I'm wrong)

Ive seen a few comments on microtonal music here, but randy is the best to answer...

but from what Ive seen in the software/code, if you turn quantisation off, then the soundplane presents a continuous value for pitch, and I don't hear stepping... but frankly its only very recently I've started to "understand" microtonal music :)

like the continuum, of course continuous in digital systems, is not really continuous discrete steps are at affected by sensor accuracy, and any touch detection and following processing.

my new interest in microtonal music, makes me intrigued, on your thoughts on how you would setup the soundplane for this use.

btw: do you know of any good introductions to playing microtonal music, ive little idea where to start... but if i could figure that out, id be interested in experimenting in ways to use the soundplane in this context.

ooh - cool :)

Dec 15-20, possibly to coincide with a Virta release ?
(or just wishful thinking :) )

@theheliosequence , I don' think they have a demo currently, but there are quite a few (excellent!) tutorial videos, sound demos, and the manual online. i know, not quite the same but gives a pretty good impression.
(other UVI products have demo versions so perhaps they will have one the future)

@andrewj, my pleasure , I'll update if I think of more, or get others :)


this is a bit of a follow up to a previous topic, where I have issues with setting Kaivo/Aalto mode, but also after some experience using with the new Bitwig (1.3.3) which has much improved MPE support.

below are some suggestions, on improvements that I think could significantly improve the usability of the Soundplane and also aalto / kaivo with other MPE enabled devices.

a) MPE mode in Bitwig/ canDo()
Issue: Bitwig does not automatically detect Aalto is MPE compatible, this means you need to use 'FORCE MPE' option when loading the VST.
this appears to be something to do with the canDo message, Id recommend, putting some trace in Aalto, and see what Bitwig is requesting.

b) Pitchbend range (PBR)
Issue: currently you have to change the PBR in both Soundplane app and Aalto, auto slide range was one of the main selling point of MPE, getting wrong means slides are incorrectly calibrated,

Kavio - should support +/- 48 semitones
Kavio/Aalto should process the NRPNs to set the PBR automatically

c) MPE detection
Issue: Aalto/Kavio does not automatically swtich to MPE, you have to currently select in both soundplane app and VST. if you get this wrong, you get silence/incorrect behaviour
the MPE standard documents how MPE mode is selected, via CC 127, Aalto/Kaivo should when they receive this switch to MPE mode automatically. also when it is 'switched off' it can be set to single channel midi mode.

d) T3D/OSC detection
Issue: Aalto/Kavio does not automatically swtich to OSC, you have to currently select in both soundplane app and OSC, you also have to be careful to use the correct port. if you get this wrong, you get silence
Ive thought about this, I think the easiest solution is to take the same/similar approach as MPE. have an NRPN which users can sent to put Aalto/Kaivo into OSC mode.
the NRPN value could be used as an offset to 3122 , such the 0 means OFF, others are the 3122+offset = udp port.

for splits these would be sent on different midi channels. so in a DAW you could route to different instances of Aalto/Kaivo

why use NRPN? because this completely open to your use, no need for ratifying etc.

why use MIDI for OSC? because its there... the plugin has to support it anyway, and allows us to setup routing for the OSC within the DAW. using UDP to do similar is a bit of a pain, as you need to listen to this to know if to switch to OSC, and midi to know if to switch to MPE etc.

(btw: if aalto/kaivo is told to use both OSC and MPE/Midi it should take OSC in preference, arbitrary decision though ;) )

I really do think the above could really streamline the whole connection process, and make it easier for users to just play music, without the tech getting in the way. something I know you are passionate about.

I mention it now, as with Virta in the pipeline, perhaps its good to address in Virta now, so that it would not have to wait for an update to get these features,

of course, these are just my thoughts and ideas, and I hope are reasonably straightforward to implement.


some 'asides' :

there is a new version of the MPE spec, but I think staying with 1.0 is reasonable until this is ratified, as BWS is still using the old version.

On my side Im planning on making the following changes to my version of the Soundplane app.

always have a midi Input : "Soundplane", this will accept

  • the MPE messages to set PBR and OSC/MIDI mode

  • program change... to switch 'presets', so I can change setups to reflect instruments, or switch to a split setup, without having to interact with Soundplane GUI

  • a few standard midi messages and pass them though to both T3d/OSC e.g. sustain pedal/breath. ... really this is designed to be use with pedals

Midi output : rename Soundplane IAC out to "Soundplane",
cosmetic/consistency with other devices.. "out" is redundant, in the midi api, you always know if its input or output, they never get listed together. I think "IAC" is pretty redundant, 'techie talk'... as far as I see its just the Soundplane :)

Im using a combo of Live and Bitwig...
Now MPE is supported in VSTs, I started using Bitwig more...
But funny, soon after BWS released 1.3, Ableton released 9.5 and the new Push 2 ... so that has tilted me back a bit, as the Push 2 is really good.

Im a bit caught,
I love using Live/Push as its 'hands off computer' (which is partly what this is all about) and use it just with audio input (i.e. dont bother recording midi), BUT setting up multiple midi channels to feed VpC/MPE is a pain!

on the other hand, Bitwig with MPE support, makes this side easy, but whilst I hugely respect the guys that added Push support (its a huge endeavour) its not as 'complete' as Ableton (partly due to the BWS controller API not being complete)

So, I guess for me its kind of a race, Bitwig getting better push support, or Live getting multi channel midi support , till then I switch between them, depending on what Im doing, and if I think midi is important. (when Im using Ableton, I tend to use OSC/T3D and then record the audio)

hopefully, Ableton 10, or BWS 2.0 will be perfect ;o)

Bitwig, yeah I like it, some things are really well thought through, but every now and then you stumble across things that are missing or awkward (e.g. you cant bounce in place real-time, a pain for hardware synths)... but I guess comparing a 1.3 product to a 9.5 product is hardly fair (also big price difference between Live Suite and Bitwig)
... so on balance I think they are doing a good job, and it looks to be a promising DAW for the future.

Not sure if anyone else has been having fun with Reaktor 6, and the new modular blocks

I certainly have, and there are lots of new user blocks :)

anyway, I thought Id do my bit of the community, and publish 2 blocks which soundplane owners might be interested in:

MPE Expression - a midi polyphonic expression block for 8 voices

T3D OSC - a block supporting T3D

both pretty easy to use, create a set of voice chains as normal in Reaktor blocks, and then link P/G/X/Y/Z where you want :)

If you have a soundplane and havent tried Reaktor 6 yet... why not :)

blocks are really cool, just build patches like a physical modular synth, loads of modules, and the user library is growing at an amazing rate... link this up with a soundplane and its a fantastic playground.

its almost worth it alone, to build an 8 voice poly Monark (takes about 5 minutes!) ,that is completely controlled by x/y/z... the oscillator and filters are lovely


(Id assume this also applies to Kaivo, but not checked)

Ableton Live (9.5) now supports loading VSTs/AU from the Push (yippee!)

so now my workflow is to use the Push to create new sets and tracks without having to go back to my computer/mouse ...
this is really working nicely, as I use AUs I can save presets in ableton and all is good, I can browse them and load them
(I don't need all aalto presets, just a few of my own, so I'm not too fussed that I cannot get to the Aalso 'factory presets' as they are not stored as aupresets)

EXCEPT... when I load an au preset, it doesnt restore the input transport properly.
It correctly displays that i have it set to OSC and to offset 2, but its not actually listening.
so I have to go back to my keyboard/mouse, bring up aalto and change it back and forth.

please... can you fix this, with Push/Maschine and controller like the P8 (and quite a few others) its becoming more common place that people work away from the computer ... and don't want to return to it have to 'set things up' ... which is a real workflow killer.

also it would be handy to have the transport and port and automation targets, this would mean that I could adjust them from the push, handy if Ive put the soundplane in VpC mode, to use other instruments (e.g. u-he) and then need to switch to aalto.

BTW: I don't know if your considering NKR support but might be worth it, if this becomes a standard for preset browsing.

Im not sure how much you've been considering this trend for musicians to (physically) move away from the computer and treat it as an instruments, I find it enjoyable, allows me to focus more on music making...

I'm finding the soundplane software also needs a bit of tweaking for this... e.g. due to limitations of software synths, some might require me to use VpC, but I use T3D for ML... and also I sometimes want to switch the SP to single channel midi to control hardware synths. again these kind of things I don't want to have to come back to the computer to do...

ideally Id like to be able to do this 'switching' via midi, so I could either do via the Push, or use a midi pedal.
but perhaps thats for a different discussion ...

Ive found another issue with Live/Aalto not going into T3d mode

Im not sure if its related...

due to the limitations above, as a workaround I decided to save an Aalto track (using AU) as into my default template (which is just a project) with the OSC mode already enabled.

this nearly works.... but not quite...
what happens is Aalto is correctly loaded but it does not start processing OSC/T3D messages until you make the aalto window visible

after some experimentation, i found this is because before the UI is displayed it is actually in midi mode i.e. only when the UI becomes visible does it 'switch' over to T3D mode.

*note: the same happens with saved projects when I reload them :(

EDIT: I can also confirm both issues occur on VST as well as AU

hmm, but MPE mode should theoretically also be automatic... as MPE sends an mpe on/off from the controller.

but yeah, tricky as also if your using multiple kaivo/aalto you also need to specify offset port.

I can understand your reluctance to not save in the patch... as you may not consider it a sound parameter, but being able to alter it (and also offset) via automation would appear to be the best option given there is no real alternative.

sorry, I'll be more explicit

  • start live & soundplane app (in OSC mode)
  • add aalto AU to track
  • change aalto to OSC mode
  • save aalto as aupreset (save icon in live device) lets call it test.aupreset

so lets try to now reload it

  • delete previous aalto track
  • locate test.aupreset
  • double click, or load into a track

you will see the aalto AU says its in t3d mode (and also in the menus)
but the soundplane will not play it....

this is because its not really in t3d, its in midi mode... ie. the UI is not consistent to its real input protocol , you need to reselect OSC from the input menu

from what you saying above, you view this as a UI bug.

however, the issue, and hence why I tried to explain my 'use-case', is when you create a new instance of aalto its always in midi mode, I really just want to be able to create new instances of Aalto, and it to be in OSC mode (or to be able to remotely put it into OSC mode, probably more useful), and not to have to go back to my mac/mouse and go into the input menu, to change it.

this was the advantage of the way the previous version of aalto worked, which auto detected OSC, it just worked, your didnt have to go and configure it each time you dropped a new instance in a daw.

I definitely want to release a fully modular system in the future. Stay tuned (for a long while, maybe).

Id love to see this, partly just so we can have some utility 'modules' , e.g. so we can mix and attenuate signals when we have multiple inputs into a modulator.
(e.g. I'm having real issues balancing mixing Y axis and pitch tracking into cutoff in aalto... want high modulation on Y, and much less on pitch)

on the other hand, id like a modular that allows mixing of other developers modules, e.g. bring in say vahalla reverbs :)

worth musing over whilst I await verta :)

cool, just be careful with midi monitor, I know sometimes I forget Ive filtered out certain messages when Ive been looking for others.

I can really think of any reason why the soundplane app would stop sending, but if you can find a reproducible scenario let me know, and I will look into it.

greetings from sunny spain :)

agreed, good software design is about clean interfaces which hide complexity, and yet provide functionality its users require.

with expressive controllers its a tough area, they are a musical instrument but at the same time they are required to interface to existing vsts/hardware which take no heed of their requirements. (e.g. they are much more sensitive than keyboards, AT is not the same as continuous pressure) ... so 'tuning' them in, unsurprisingly takes a bit of customisation either on the synth side or the controller.
(MPE is only going to make a small in-road into this issue)

imho, this is why Kaivo/Aalto are so good with the soundplane, they are designed with it in mind, they work as 'a whole'
(its the same reason EaganMatrix + Continuum ... and perhaps Seaboard + Equator, make good pairings)

"Everything Should Be Made as Simple as Possible, But Not Simpler" A. Einstein (?)

The only thing is that it would be great to have pitch control on the x . Not sure why you did not put it

not quite sure I understand you, in single mode PB is also sent, and operates exactly as official app. i.e. single PP sends out PB, 1, PP. (assuming bend range >0)

I guess we could have an option to send X on a CC (rather than PB), but usually you don't need this, since in the synth you turn bend range to 0, and then use a mod matrix to route PB to a control. (this has the advantage PB is 14 bit)

could you describe exactly what you would like... as I'm a bit confused.

frankly, I don't use single channel mode much... Ive not got enough synths (+reakto / max / axoloti) that support VpC or MPE that I just stick with them, and when I do (rarely) use single channel mode, its usually for something like pianoteq, or something with pp (alchemy)

what exactly do you use x/dX for? personally I only use pitch, as I use it for key tracking, I never used dX as to modulate it would also affect pitch which is undesirable for me.

the only use I can see is, if you are not using not using continuos pitch (e.g. synth PB range = 0) then of course you could use X as an additional modulation source.

note: PB in midi is essentially dX.

This is the great thing about the SP we all use it in different ways, but it does make it tricky when adding features, as obviously I add for how I use it :)

x/dX... yeah there are quite a few options once you get into this.. (e.g.key position)
i support with dX we could send 0 to 1 rather than -1 to 1, where 0.5 = original position. this would essentially be the same approach as midi. the 'downside' is things like aalto, currently have dY as -1 to 1...

frankly this, is what I was saying about the Eigenharp approach, its much better, as it allows all aspects to be changed... because there are just so many possible combinations, depending upon the capabilities of the synth.
check this out: EigenD Matrix
note: this is an older version, the newer one has curves, so you can choose anything from exponential/linear (by varying degrees)

I think randy is not in favour of this, due to the 'complexity', but Im getting increasingly tempted to add something like it to my setup. probably a simplified form, as its true, i tend to use only a few different combinations.

my pleasure, good to know it works for you.

adding toggles for x/dX y/dY to the client app is pretty trivial,
(guess they could go up the top with vibrato etc, as they can apply to both midi and osc)

the slight question is how will they be interpreted at the synth end, when using the dX/dY

for midi its straight forward we use 0,63,127 as -1,0,1

for osc, well its only really aalto/kaivo (& my reaktor macros etc).
will they be ok with x/y coming across as negative...

and I think they will actually be fine, as I seem to remember when I added OSC T3D to the eigenharps, I implemented this incorrectly initially, and was sending -1 to 1 , and it still worked... so as long as they have not changed i think it will be ok, but would need to check again.

personally, I'm not sure this is really the correct solution... dx/dy are easy to calculate on the synth end, so whilst i think it was a good idea for aalto/kaivo to have OSC be made compatible with midi. I think an extra output should have been added... so we have dx/dy x, y and mod , +1 +2 +3 in midi.

anyway, its not going to happen so I can add dX/dY to client.

it would be nice longer term if the soundplane client had more options for output.

on the eigenharps not only can you select absolute or relative (for every input), but apply curves, scaling etc... (you can also output to multiple CC with different scalings etc)

It might seem overkill, but it means you can really 'dial in' how a particular vst/preset feels.

do you want it in max/msp? the issue is you still won't be able to use it in Kaivo/Aalto?

its pretty easy to implement.... (following assumes OSC/T3D)

  • at the start of a touch, store x (orig x=x)
  • every touch , dx=x-orig x


  • you need to do this independently for each touch, so in max you would store in a coll, or similar
  • 'start of a touch', this is a little 'tricky'. you have to use the fact when there is no touch, note = 0, so when you first see note != 0, then its a new touch.

you can actually combine the two, by storing 0.0 in the coll for a touch on note-off, and then only store X when you get a touch and coll value = 0.0

I can post a patch if you want, but Im not sure how you plan to use it... it will be no use in kaivo/aalto, so only really useful if you are using it for another synth.

anyway, let me know if its still useful to you.

ok, posted details on a separate topic, in case others are interested.

Ive developed an 'extended' soundplane app that allows this, if your interested I could post it. it has a few other 'extras' and bug fixes too :)

I use it all the time so is stable, and is always based off the latest Soundplane app so 1.4 at the moment.

obviously, it cannot be supported by Randy, though what I do is have both my version and the official version installed. Then if I find an issue with mine I test to see if it exists in the official release.

fyi: I asked Urs @ Uhe when they would start supporting MPE, and he said once it accepted by the MMA. he didn't want to do it whilst it was a draft.
so it could be quite a while yet. (the MMA are notoriously slow, like most standards committees )

interesting a 5 by 4 grid... or is it just a small section for prototyping?

and the cells are independent, will the sensor stack be too? to avoid 'bleed' between cells, or your thinking an independent top layer will reduce this as it doesn't pull down adjacent cells?

does this fit on to your curved surface you showed previously :)

looking forward to see how this goes.

The main problem I'm thinking of is pressing very hard and then sliding your finger, which tends to create an unpleasant squashed-finger drag feeling

no your not pressing that hard (its configurable too), so thats not an issue... in fact, if anything its slightly more pleasant than the continuum where you are sunk into the surface. (not that that is bad either) , as you say this is probably down to the fact you are not pressing that hard, and the surface is easy to slide on.

(I can understand the concern though, as Ive head some reports that the linnstruments rubber surface is a bit 'sticky' for some... Ive not tried myself, so don't know if this is true or not, or if its personal preference)

haptic feedback...

hmm, wouldn't that cause vibration, which might interfere ( or create noise) with the soundplane surface? I'm sure Randy could provide details.

frankly though, I don't think its necessary, the give on the surface + audio feedback is already sufficient for me to feel 'in touch' with the surface.

(I suspect Id actually get fed up of a buzzing under my fingers before too long too :) )

its tricky, the best way, is to some how get to try one hands on... ideally, we could get in a room and try all the controllers side by side, and see which one works for us, as really they are all different, rather than better/worst.

where are you based?