thetechnobear's Recent Posts

Put Aalto/Kaivo in MPE mode, and set on range to 48 .
Seaboard in MPE. mode

... and your good to go

X maps to glide, but often not needed since for pitch it's already taken into account

Y is slide.

( this is all standard MPE stuff, glide / slide etc are just Roli speak)

ok, so tested on 10.11 / same issues as macOS sierra

also I think the audio glitch, is possible a bug in the LowPass GATE

easy to demonstrate, ( I use Live/ but same in BWS)

a) load VST
b) load preset Virta Key Synths/Fuzz Trumpet Fifths

you will hear a noise on loading it despite no midi

and if you wait , you will hear it repeats

turn off the low pass and it will stop

(to prove its this, you can also disconnect the inputs on the gate, and also the vocoder, so now the gate has no possible signal input nor, any activation (mod =0, and disconnected, level =0)

interestingly you can only hear it on the wet delay line... I guess some very brief spike from the lowpass gate, which gets amplified?

protocol bug is fixed, Im really happy, this is so useful to me .. thank you, thank you :)

I did a bit more testing and found 2 bugs ...
macOS, Live 9.6.2(64 bit)

a) AU audio 'glitch' on loading

  • load Virta (AU) on to a track,
  • select a ML preset (i used comb organ)
  • use the 'save as preset' on the LIVE device (is not a ML preset, we are doing a live preset) , save as VirtaAuTest (it will create VirtaAuTest, that you can see in Lives browser)
  • delete track,
  • create new midi track
  • select VirtaAuTest from Live browser


  • you will hear a loud glitch/click/bang when the device loads

b) VST not loading selected ML preset when in group (and audio glitch, as per (a))

ok, we are going do a similar thing as (a) , except with a group track and VST

  • load Virta (VST) on to a track,
  • select a ML preset (i used comb organ)
  • put it in a group (select virta device , then CMD+G)
  • on the group device use the 'save as preset' (disk icon), save as VirtaVSTTest (it will create VirtaVSTTest, that you can see in Lives browser)
  • delete track,
  • create new midi track
  • select VirtaVSTTest from Live browser, you will see the group

two bugs:

  • first you will hear the same 'bang' that we got in (a)
  • second, the patch window has no wires AND in fact the preset you selected (second step) whilst being shown in the ML preset box, is actually not loaded.

(b) may only is preset with VST, AU seems ok

anyone tested the Soundplane software on Sierra yet?

on my main music mac, I wont be upgrading till its stable, but Im considering upgrading my MBP since I need to test (and potentially fix) other open source software that I contribute too (mainly Axoloti and Eigenharp).

on the MBP, I only really use Live, Soundplane and a few plugins (including Aalto/Kaivo), so I'm wondering if it will 'get away with it' Id still like to be able to use these after then upgrade.

thoughts? issues? experiences?

BTW: Randy, any news on the touch tracker development ? ;)

EDIT: decided I will upgrade due to the number of other things I need to test/support, so I'll use this thread to detail my 'experiences'.


Platform: MBP / 10.12.0/ latest SP software/Live9.6.2/Aalto 1.7(osc)

  • Soundplane software appears to work, and CPU load seems similar
  • Aalto seemed ok with OSC, in Live 9.6.2

testing so far very limited, as Im doing a number of hardware devices etc, but I'll do more soundplane testing after initial round on all devices.

good news.. it looks like the USB iso issue has been fixed in 10.12... in 10.11 unplugging the Soundplane before exiting app, or the soundplane app crashing - would cause a fatal OS crash. Early testing, it appears Apple has fixed this bug - huge win for stability!

soundplane update- any idea when? Ive been working on my ARM/Beaglebone Black/Bela app - which Id like to migrate to the new tracker.
perhaps you could get the work in progress into github? last commit was over a year ago :(

(of course, I recognise the soundplane is a low priority, given its small userbase - so really just after an indication of timing... are we talking weeks/months/years? ;) )

USB hang
yeah, its seems quite reliable, though then doing the above app, I did find if the app crashed, it could still take down the whole machine - so its not a total fix, but definitely more stable.

btw: not really sure what to do about this... but you may have some ideas
the SoundplaneAppState json file cannot be read in by Max as the calibration array is too big.... perhaps it would be possible to split this up into multiple entries?

I was planning on making a calibration editor in Max, but had to abort due to the above.
I could of course write in C++, or write an max external that can handle it. but thats a 'bigger project', so is not going to happen in the short term.

fixed an issue where the protocol type (MIDI, MPE, OSC) was not loading if the plugin editor did not exist - still not working

its simple to test:

  • create a live session with Virta on, select keyboard patch, select OSC.
    (test you can hear sound) - save session.

  • now re-load the session, no sound... open the editor - bingo it works!

ok, some good news... with port audio installed I can load virta AU/VST in both Live and Bitwig on Sierra.

auval shows same error as bitwig, so confirmed the dynlib is the issue

(otool -L confirms this is the only lib missing)

$ auval -v aumf Vrta MLbs

AU Validation Tool
Version: 1.6.1a1 
Copyright 2003-2013, Apple Inc. All Rights Reserved.
Specify -h (-help) for command options

VALIDATING AUDIO UNIT: 'aumf' - 'Vrta' - 'MLbs'

Manufacturer String: Madrona Labs
AudioUnit Name: Virta
Component Version: 1.2.0 (0x10200)
Component's Bundle Version: 1.2.0

* * PASS

2016-09-23 17:50:22.164 auvaltool[1898:95626] Error loading /Library/Audio/Plug-Ins/Components/Virta.component/Contents/MacOS/Virta: dlopen(/Library/Audio/Plug-Ins/Components/Virta.component/Contents/MacOS/Virta, 262): Library not loaded: /usr/local/lib/libportaudio.2.dylib
Referenced from: /Library/Audio/Plug-Ins/Components/Virta.component/Contents/MacOS/Virta
Reason: image not found
FATAL ERROR: OpenAComponent: result: -50,0xFFFFFFCE

macOS Sierra - not working....

Live 9.6.2 AU shows, but wont load , VST doesnt show

Bitwig, shows an error for VST (which might be helpful)

com.bitwig.flt.library.metadata.reader.exception.CouldNotReadMetadataException: could not read metadata: Could not read VST plug-in metadata
64 bit plugin host reported errors: Pluginhost returned non zero exit code 255
Error messages:

2016-09-23 17:40:50.879 BitwigPluginHost[1837:92385] Error loading //Library/Audio/Plug-Ins/VST/Virta.VST/Contents/MacOS/Virta: dlopen(//Library/Audio/Plug-Ins/VST/Virta.VST/Contents/MacOS/Virta, 262): Library not loaded: /usr/local/lib/libportaudio.2.dylib
Referenced from: //Library/Audio/Plug-Ins/VST/Virta.VST/Contents/MacOS/Virta
Reason: image not found
2016-09-23 17:40:50.879 BitwigPluginHost[1837:92385] Error loading //Library/Audio/Plug-Ins/VST/Virta.VST/Contents/MacOS/Virta: dlopen(//Library/Audio/Plug-Ins/VST/Virta.VST/Contents/MacOS/Virta, 262): Library not loaded: /usr/local/lib/libportaudio.2.dylib
Referenced from: //Library/Audio/Plug-Ins/VST/Virta.VST/Contents/MacOS/Virta
Reason: image not found

32 bit plugin host reported errors: Pluginhost returned non zero exit code 255
Error messages:

2016-09-23 17:40:50.948 BitwigPluginHost[1838:92392] Error loading //Library/Audio/Plug-Ins/VST/Virta.VST/Contents/MacOS/Virta: dlopen(//Library/Audio/Plug-Ins/VST/Virta.VST/Contents/MacOS/Virta, 262): Library not loaded: /usr/local/lib/libportaudio.2.dylib
Referenced from: //Library/Audio/Plug-Ins/VST/Virta.VST/Contents/MacOS/Virta
Reason: image not found
2016-09-23 17:40:50.949 BitwigPluginHost[1838:92392] Error loading //Library/Audio/Plug-Ins/VST/Virta.VST/Contents/MacOS/Virta: dlopen(//Library/Audio/Plug-Ins/VST/Virta.VST/Contents/MacOS/Virta, 262): Library not loaded: /usr/local/lib/libportaudio.2.dylib
Referenced from: //Library/Audio/Plug-Ins/VST/Virta.VST/Contents/MacOS/Virta
Reason: image not found

perhaps you meant to static link libportaudio rather than dynamic link on your build machine?

Give avantronics is saying same for Mavericks,and the above error doesn't look Sierra specific, Im going to assume its on all versions of OS 10.x

I guess i could install libportaudio... I need it for another project anyway ;)

USB has protocols for various types of devices, if the device supports that protocol it is said to be 'class compliant'

there are quite a few, but the most useful ones for music are:

  • Audio Interface - as per this topic

  • Midi - USB midi

  • Mass Storage - appears as a 'hard disk'

the protocol details are all detailed on the usb specification pages:

I think midi and audio interface class compliance have become a lot more common recently due to iOS (iPads/iPhones) which are 'class compliant hosts' , and are also impossible to add propriety drivers... i.e. hardware devices don't have a choice if they want to support iOS

yeah, theres actually a couple of oddities when you add Virta as an Audio FX....

first, if you have a mono audio input channel (so make sure its mono before you try to add Virta) ... then Virta is not shown as a plugin.
you can 'force' the issue by putting it on a stereo channel and changing it.

the other thing, is when its on a stereo channel and only playing LEFT, if you put the pan in Virta hard left, nothing comes out, only when you put it centre/right... so it appears something internally is a bit odd with panning...

I wonder if the first issue may be the heart of the issue, as all other plugins I have, allow you to select Stereo, Mono or Mono->Stereo... this implies Virta is telling Logic it can only do stereo...

anyway, Im sure once Randy runs it up in logic it'll be pretty clear.

BTW: the virta input meters are showing on a mono channel, input on both inputs, so that part appears to be correct, it appears to be the output/pan stage.

I did a quick test too, with a simple synthesis patch (so no input)

if you load as a midi controlled effect, then indeed its mono/left only.

BUT if you load it as an audio FX, then actually its stereo, ( I could do this by sending notes via OSC, so exact same patch.)

so its just midi controlled effects that have the issue, perhaps the differences in reports here.

for midi fx, as a workaround, you can use a Imaging -> Direction mixer... but of course means you cannot pan within virta.

finally, just to check it wasn't some Logic oddity with mono and midi controller effects... I tried softube modular as an midi controlled effect, and that was ok in stereo.

anyway hope this is helpful.

That OSC / MPE bug is fixed.

that is awesome news, its a small thing, but has been bugging me :)

could you do a test, which I think was related...

save a preset (i.e. using ableton option) as an FXP in Ableton with MPE (or OSC) mode selected, and then load it, and check MPE (or OSC) is enabled/working.

I use this a lot, as the ML presets do not store the midi/osc mode, so I use this to workaround in Ableton... i.e. load a preset with OSC set, then use program change to switch between my patches.

(id also be happy to do the test for you, if you want to send me a beta or something)

The library code will make its way into the Soundplane app. This should not produce any major changes in the Soundplane app however. I am excited to work on the new touch code after this release.

cool, yeah, its good to keep these things in step, makes things easier.
Im keen to see your ideas for the touch code :)

anyway, great to hear you have had some time to work on the foundation - I find that kind of work quite satisfying :)

has the Soundplane software been getting any love?

also will the above changes fix the long standing bug (All ML plugins) that MPE/OSC are modes are not activated until the UI is shown?

anyway, good news to hearing the license changes have been done, no real change for musicians, but hopefully means its less administration/hassle for you, so updates can be more frequent.

I like the idea of a connection between ML modules...the issue I see is that its the DAW that hosts the plugins, so whilst you could make Aalto know about an instance of Virta, it'd be hard to know it was on the same track.

but can't you do what you want already ?
there are two types of control really, global plugin control, and per note/voice...

the former can mostly be controlled by plugin automation, in something like ableton, you can use M4L and racks to view a plugin chain (Aalto->Virta) as one device.

per note/voice is a bit more difficult, but if you use t3d(osc) or MPE, then different notes are on different channels, but importantly, its consistent. e.g. the same note is on the same channel across both plugins.
(it limits you to note, velocity, channel pressure, CC74... but thats pretty good)

of course the audio cannot be per voice, as the aalto output is 2 channel, and virta input is 2 channel. that could be an interesting possibility, have multi channel audio input and output on ML plugins... its feasible in the AU/VST specs, but possible on Virta (input) would be very high cpu load.

perhaps we will have to wait for the ML modular :)
(what with Reaktor blocks, softube modular... looks like the time is ripe :) )


Thought Id give a sneak peak on something Ive been working on...


so what is is it?

well, I always run my DAW (Ableton) full screen in a separate desktop BUT at the same time there are quite a few controls on the soundplane app I need access to, and I got a bit fed up switching desktops, and the reaching for my mouse.


Ive added a remote control interface to the Soundplane App, so that it can be controlled from other applications using OSC. (by exposing the internal parameters), its bi-directional so everything is nicely in sync.

Ive also created a small Max 4 Live device, which allows me to control it from Live. (which is what the screenshot shows obviously)

The great thing about M4L is it means I also get the control directly on my Ableton Push, so no mousing arounding, or switching screens...

... and of course, it doesn't stop there, if you want you can use Ableton Midi mapping, to assign midi controls e.g. switching quantise on/off using my Softstep pedal :)

(thinking about it, the KMC softstep could send the OSC directly to switch modes)

anyway just a start, I'm going to add switching OSC destinations, and probably layout changes too.

M4L is pretty cool, so the fun doesn't stop there... you can do things like add a M4L device to a track, so that when you switch to a that track, it can tell the soundplane app to change settings e.g. say switch active control from aalto on one osc channel to kaivo on another osc channel.

thanks the change is pretty simple, your welcome to take the couple of classes that implement it, if you wish... or even just the 'idea'

btw: I suspect you could use exactly the same approach for your synths, in fact its easier as you already have the class in place.... would be nice to allow parameter changes via osc for the synths, Ive seen it requested a few times.

(though you can implement this 'fairly simply' in M4L)

I look forward to seeing the changes in the soundplane software now the 'dust has settled' on virta.

Ive mentioned this before (I think within another thread, so thought id break it out)

Aalto/Kaivo/Virta when saved in a DAW do not remember the midi (or osc mode) they were in when the project was saved until you open the plugin window*.

this means when you open up a project, you have to go to each kaivo/aalto/virta instance and open the plugin, before you start the project if you have saved MPE data, otherwise you get a 'noise' as the respective plugins all play in 'normal midi mode'

(it also happens with osc mode, which means if you have a 'live' set, which you use with the soundplane, you also have to do the same thing)

I know your super busy, but would be cool if you could fix this bug... having to do this every time I open my projects has got a bit tiresome ;)

imho, sounds like a bug in the linnstrument firmware to me...

surely by definition, the pressure on a pad when you have released it is zero ... how can you be exerting pressure on a pad, if your not touching it ;)

(unlike pitch/timbre which could be still non-zero when you release, because you don't have to release the pad in the 'centre')

with MPE both the soundplane and and eigenharp has zero pressure on touch release.
(and i use this a lot on many synths)

from memory, when I last looked, this is not detailed in the mpe spec, so its probably valid to say pressure is only sent when the sensor reports it i.e. don't force to zero... but the spec has quite a few holes like this.... I think its one of those cases where its generally useful, and of course its not going to add much to the data content.

there is only one exception to this...the mpe spec allows for (but few implement) reuse channels when touches > max touches e.g. say there are 16 touches (max is 15 midi channels in mpe) , then channel 2 can actually have 2 active touches which 'share' pb/y/z so in the case you would have to take care and only send zero when no active touches... but it would still work for synths. BUT as I said, this is not really used, because 15 touches is normal enough, and you loose individual note control, which is whole point of these controllers.

(I suspect its in there for when you use splits, so reduce the touch count, but even so its of limited use)

in fairness this is not a libusb issue, looks to either be an SP oddity, or kernel oddity.

but yeah, generally its true iso usb is not well supported for many devices, as I mentioned on the RaspPI is a source of unending issues, due to the chipset not having good support. I have to say its made be a bit wary, of iso usb on embedded devices... as even its suppose to be support, it may not work.
(as you say, because its main use if audio and video devices, which are that commonly supported on embedded devices)

Im going to test later, if the same issues exist on the Mac with the SP, to see if its a matter of the coding using libusb, or the SP sending data with some inconsistencies.

bare in mind Ive got the Eigenharp running using iso usb with libusb, with no similar issues... so I'm pretty confident, its either the implementation or the SP...

I actually suspect the SP, partly I went through the implementation last night, and it looked fine ... actually, it looked better than fine - its a really nice/tidy implementation

as i say though, no real issue, it can be worked 'around', its really just a matter of expectations.

ok.. soundmodel is working and has highlighted a small issue.

I can see that we are getting periods where the driver appears to be sending incomplete data...

what I see is 'diff too large' errors, this means that the driver has determined there is too large a difference between consecutive frames.
we didn't see this on the test program because we did not implement:

    virtual void handleDeviceError(int errorType, int di1, int di2, float df1, float df2) {}
virtual void handleDeviceDataDump(const float* pData, int size) {}

errorType = kDevDataDiffTooLarge , df1 contains the difference, and by default if this is greater than 8.0 it generates a fault.

Im pretty sure this accounts for the 'peaky' cpu I was noticing, as if the error is generated, of course the touch tracker is not invoked i.e. the code executed is significantly reduced, hence the drop in cpu.

could you possibly implement handleDevicError on your board, and see if your getting the same...

The reason I think its a usb error, is the difference are very suspicious when they are dumped on my system

Im seeing the second frame , for every carrier, somewhere across the board the data turns to zeros.....

e.g. for carrier zero only

first frame

[0] 0 0.16 0.16 0.16 0.17 0.16 0.18 0.17 0.19 0.17 0.18 0.17 0.16 0.15 0.15 0.14 0.19 0.19 0.19 0.18 0.16 0.16 0.16 0.17 0.19 0.19 0.19 0.18 0.19 0.19 0.18 0.18 0.17 0.17 0.19 0.18 0.18 0.19 0.19 0.18 0.17 0.16 0.15 0.15 0.18 0.18 0.19 0.19 0.14 0.14 0.15 0.16 0.17 0.18 0.17 0.19 0.17 0.18 0.17 0.17 0.16 0.17 0.17 0

next frame

[0] 0 0.16 0.16 0.16 0.17 0.16 0.18 0.17 0.19 0.18 0.18 0.17 0.16 0.15 0.15 0.14 0.19 0.19 0.19 0.18 0.16 0.16 0.16 0.17 0.19 0.19 0.19 0.18 0.19 0.19 0.18 0.18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

see how about half way across the data turns to zeros, hence causing the large difference

Its a bit deja vue, Ive seen something like this before with the eigenharps and libusb.... something to do with the data not being fully complete.

I will also test on a my Linux VM on my Mac, to just checks its that I'm not polling quickly enough, but i dont think thats the case, as that usually looks a bit different.

Im also assuming no-one has really used the LibusbSoundplane driver in 'anger' so perhaps there is an issue there, or perhaps its just an issue under 'heavy load' conditions....

we will see :)

EDIT: ok, Im seeing it on Ubuntu 14.04 / 64bit (under vmware).
Note: the mac version of my code is not reporting the issue, the only difference being it doesn't use libusb. ( I guess, I could compile the mac version with the libusb code too?!)

Im going to take a look at the libusbsoundplane driver, see if I can find the issue.

EDIT: found the issue and a fix, will detail later... (nearly 3am here ;))
I haven't quite decided if its an oddity in the data sent back by the SP, or libusb , or the implementation using libusb... Ive a couple of things to check to determine which :)

Ive done an initial port of the Soundplane model... need to do some testing, probably next week... but looking good.

hopefully now Virta is done, Randy will be back on to the new touch tracking for the soundplane, so I can integrate that once its complete.

X15, sorry , my mistake, misread your original post.
yes, I signed up for the X15 announcement so got the mail too... could be quite interesting.

I also backed , so Im quite looking forward to getting that, initially for this, it will just mean moving to Xenomai... but looking forward to the possibility of some low latency IO provided by bela.
(might even try some audio, if the soundplane software doesn't consume all the resources ;))

MacBook Pro (Retina, 15-inch, Mid 2014)
2.5 GHz Intel Core i7
16 GB 1600 MHz DDR3
NVIDIA GeForce GT 750M 2048 MB

SR 48000, 256 buffer
Live 9.6 64 bit
Kaivo 1.2.1, VST

Plugin window open:
CPU ~110%
CPU Live ~50-55%

as previously mentioned, no audio issues at 48k 256 except (very) occasionally, if I start doing other work in ableton, e.g moving notes around the grid, or doing stuff in other apps, e.g. safari (to type this ;) )

Plugin window closed:
CPU drop to ~60-64%
CPU Live : same ~50-55%

still no glitches ;) in fact no change at all, working on other things, may cause occasional glitch.

if I drop sample buffer to 128, then I get some glitches, and still seems to make little difference if plugin window is open or not .

can I make a couple of observations:

thinks to check, perhaps to see if they make any difference...

i) I use the 64 bit version of Live, and 9.6
ii) Im using the latest version of Kaivo 1.2.1
iii) use on main power , or make sure in energy settings, automatic graphics switching is OFF.
iv) this might only be on 10.11 ?) in activity monitor, on the energy tab.. can you check that 'requires high performance GPU' = Yes for live.

likely wont make a difference, but important we are all comparing the same thing.


the notable difference so far, is my MBP is using the NVIDIA GeForce GT 750M, rather than the Intel Iris Graphics 6100. given the finger already pointing towards graphics, this looks a likely suspect.

(it may not be just down to hardware, but also how well the driver supports openGL etc)

my MBP is very similar to Randy...
Randy, does MBP start to break up occasionaly at 128 samples?, if so id say we are probably seeing similar. I guess this is 'kind of reasonable', except my iMac outperforms at lower specs, but hey, comparing laptops vs desktop performance is a whole different ball game!

seems fixed now...

think my post came just before your ;)

I've tried to get GDB to tell me what signal it is thats causing the interrupt,but it seems unable to catch it. (handle all print, yielded nothing)

from reading up, re-polling is the normal thing to do, if you get an interrupt during the poll, so in that sense seems like the driver was 'wrong', its a pity I can't find out the cause though... would be nice to know exactly whats interrupting it.

anyway, good news, is it puts me 'back on track', so means I can get back to making it do something useful...

(when the issue cropped up, late at night of course!, I feared it might be the end of the road for the BBB... but no, the journey continues ;) )

btw, off topic... the X15, have you tried the stereo jacks... how much noise is there?
(I'm wondering, standalone synth on it could be fun, but only if the noise floor is acceptable when amplified)

ok, some 'promising signs'....

it looks like it might be some posix event that is indeed interrupting the poll.

(Im not quite sure how to find what posix event it is ... need to research that, but i suspect something from the hardware)

but the good news is, Ive altered the soundplane libusb code to just poll again if its interrupted, and this seems to have cured the issue, been running for 15+ minutes without issue now.

I suspect the hub/sysmsg was caused by reinitialising the device, and since it now doesnt need to do that, all is well.

note: using libusb 1.0.19

yeah I get this

 [  286.283473] usb 1-1-port7: disabled by hub (EMI?), re-enabling...
 [  286.290275] usb 1-1.7: USB disconnect, device number 4
 [  287.343570] usb 1-1-port7: Cannot enable. Maybe the USB cable is bad?

if I use the same hub/cables on the Mac its fine...

I get this from anything from running it for 30 seconds, or might be 4-5 minutes.

and libusb returns LIBUSB_ERROR_INTERRUPTED ... but of course I dont know if this is cause or effect.

tried a different hub, same issue..

Ive noticed sometimes, I get the libusb error, but no sysmsg and the soundplane 'recovers'
Libusb error! -10
Device state changed: 0
Available Bus Power: 230 mA
Device state changed: 1
Device state changed: 2

Im not sure id agree with this:

To be clear I don't think this issue is Madrona Labs software specific. I can get this to happen with ABL3 and the like as well, so it is definitely an Apple issue.

Any VST 'could' produce audio glitches on any platform... its down to how the VST is written, and specifically about ensuring processing is completed in the time.

The issue is, Kaivo runs perfectly on my less powerful iMac... so it clearly is not cpu bound.

from reports here, its seems reasonably clear it something to do with the MBP setup... and laptops usual weakness is graphics hence considering openGL as being a culprit.
(and my openGL tests kind of indicated this too, jitter is the real enemy of 'realtime' programming)

personally, for me its not a big issue... as i said at 256 samples @ 48K SR it works ok for me, and I also have my iMac which is where I do most of my playing anyway.

but its bad for the the original poster who, has with a more powerful MBP, but is having to run at 512 samples. 512 is not good for real time playing , its ~ 10mS, where you don't want to be over 5mS really ,especially for something like a Seaboard/Soundplane

anyway, I was merely correcting my initial statements, as I thought it was ok, on the MBP which was potentially misleading. hopefully, the more info Randy receives, the better position he is to resolve the issue.

yeah, I think keeping it light is probably going to be key... that and I dislike python ;)

if your using UDP sockets, why not go to OSC? not a lot of overhead and a bit more flexible.
( I assume your using UDP, TCP is not really required)

Im a little stalled, as Ive encountered an issue when testing, that the soundplane disconnects, and at the kernel USB level... not the libusb level. I can't find much information about the issue, its possible its application level, but actually looks unlikely, it could be something to do with the BBB debian distro I'm using/kernel version :(

also, Ive learnt I dislike Pd even more than Max... so have to decide if I ditch that idea, and move to doing all the mapping in C++, for that I need to investigate the ALSA api, so that I can output MPE.

so some progress, but the issues, did take the 'wind out of my sails' a bit.

ok, I can confirm MBP i7 with 48k/128 samples also crackles here..

so I decided to run a few tests, in both BWS and Live (AU & VST) , definitely the MBP has an issue even with the init patch (voices = 8).
its not down the raw performance, as the MBP is much more powerful than my iMac i5 , and Ive also now set the MBP up properly, so its not a setup issue.
(I don't use it much for audio, hence id not noticed it was running a 256 samples buffer at 44k)

BWS DSP graph, shows clearly the issue is not really performance, as much as 'jitter' i.e. occasionally Kaivo, is taking too much time to process the sample buffer, but not consistently.

all dial animation was off, and actually appears to make no difference, however, my testing shows it does appear to be graphics related, (as @geremy also pointed out).

so I ran some Open GL GPU tests, and found interestingly, that whilst the MBP has generally better performance than my iMac, I can see with these tests, the test occasionally 'stutter' which they do not on my iMac.
my suspicion therefore, is that openGL is not as 'robust' on the laptops

this leads to one possibility...
its a 'known' issue that retina displays on the laptops are scaled, which is sub-optimum for GL performance. (the reason, is otherwise the display is tiny ;))
what would be interesting is to determine if this is particular to retina displays...

does anyone have a non macbook pro, that is using retina?
what would also be interesting is for someone to test this, by switching their macbook pro to native resolution temporarily (2880x1920), using one of the native resolution apps
e.g. switchresx (you can use it free for testing)

this is best done by someone on 10.10 or below (which is why I cant do it, as I'm not 10.11) as otherwise you need to display SIP which is a bit of a pain.

if switching to native resolution makes the glitches go away, we know the cause for sure....
it will still need to be fixed for sure, since its not practical to run MBP at 2880x1920 unless you like using a magnifying glass ;)

Note: I will say, if I use 48k/256 samples I don't get issues, so not as bad as the original poster.

there is white noise in the demo as 'protection' ( happens every now and then, a minute or so?) ... but its noise not crackling, but perhaps thats what your hearing?

only thing I can suggest (as a test only), is 256 samples, single voice on default patch... do you hear it, if so I'm guessing it must be the demo noise.

(others have confused this when demoing the software)

I run on both an i5 and i7 (Kaivo/Aalto) at 48k SR/128 samples without issue using MPE (and OSC) on a soundplane and eigenharp, so you definitely shouldn't have issues. OSX 10.10 and 10.11 both fine, and Ive used Bitwig and its ok, though not my 'regular' host.

I assume you have equator running, so that should prove the setup.

EDIT: apologies, whilst the iMac is fine, I checked the setup on my MBP, and when I switched it to 48k/128 samples it does have the issue. sorry I don't use it much for audio purposes