thetechnobear's Recent Posts

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

Im not sure I get what your doing/gaining @garf
adding a gate and virta to a midi track, sure will get you audio, but you wont get midi through to virta (because its an audio device) ... so being a midi track wont help, the midi is not fed thru. so you'll need another midi track to target virta with the midi out target.

if your just concerned about getting the audio, then I think the easy way is to put virta on a return track. which is what Ive tended to do, so I can send it audio from a number of tracks :)

... and if you want it just on one track, why not just add it directly to the audio or instrument track.

(i'll say, I think for many daws using on a return track is the best approach, as it will often be more efficient due to being place on a separate thread, your daw/project may vary ;) )

he he, sorry antonio :)

EigenD, yeah, just connect the audio and midi inputs ... ready to go, but being single threaded, you'll need a fast computer :)

VEP (Vienna Ensemble Pro) , yeah I had tested this, and actually its a problem, but one Ive had before with VEP. so not really Virta's issue - in VEP it can be either an instrument OR an effect. but the instrument can't receive audio, and the effect can't receive midi. so best I can do is use OSC... ok, usually for me, as Im not trying to record (data, only audio) when using VEP.

it was the recording the data part, that sent me hunting through my DAWs to find the right 'tool' for the job (and I thought I might as well detail findings here) ... usually it would be cubase, but that doesn't work at the moment.

just been through my (many ;) ) plugins, seems all plugs like this (e.g. u-he effects - satin, mfm, filterscape) comes as effects plugins, and where useful as both synth and fx (like virta) they come in both an fx and instrument form (e.g. Reaktor, Kontakt filterscape, virus TI etc )

cubase: doesn't look possible, as far a I can see

see :

oh, I missed that one. Well in that case it should work in every DAW.

no, because as far as I understand, cubase (and others) don't support sidechain inputs for VSTi, I guess as common use is for things like compressors which are VSTfx.

... and i guess its fair to say Steinberg (Cubase) own VST, so if they dont support it - hard to say its part of the standard.

EDIT: btw which daw are you trying?
yes, I think VSTi and VST makes sense, but more work... yet more formats too support :(

"Reaper sees Virta as a vsti instead of a vst"

Ok, I think I see the same problem on Cubase 8.5 Pro (Mac)
Virta is listed as a midi instrument, but not as an FX so cannot be placed on an effects track....
has anyone got this working in Cubase?

(I'm a newbie with Cubase, so perhaps Im missing some way to get audio into an instrument track)

I have it working on Live absolutely fine... switched to cubase as wanted to use MPE.

@Randy enjoy this a lot :)

a small feature request (and one that goes for Aalto/Kaivo too)
can you please reduce the length of the parameters names...

On a Ableton Push 2 , it can show about 15 characters ( 8 on the Push 1) , and because you prefix the parameter names the 'meaningful bit' often gets truncated. so often parameters look identical. this is a real pity, as its a great way to mess with Virtas settings without having to use the mouse all the time.

(Im not sure if vst/au support long and short names like M4L does, but that would be ideal solution)

another small one, it would be nice to have both a VSTi and VSTfx version, the former then could be popped directly onto midi tracks when using in 'synth mode'

anyway, back to having more fun... not even tried audio mangling yet, purely being using as a synth so far ;)

yup, its a long wait for us here in europe :)

but its 8:30 there now, so hopefully we just need to wait for Randy to have his morning coffee, and then hit the big green button.

I ran 'agree to disagree' at 128 samples in BWS 1.3.6 , OSX 10.11.4 no issues, could use all 8 voices without crackles. (latest version of Kaivo)
fyi, I checked my iMac , is an i5 2.9Ghz,

have a look at the DSP graph in BWS thats got a reasonable amount of information. (as you can see load over time, peak loads etc), from that I can see 8 voices are on the limit, as whilst average load is below deadline, the peak load with many touches starts to reach deadline (though in fairness I dont hear crackles, but the assumption is, push it further and I would)

from that graph, you can also see the effect of increases samples, doubling for me, almost halves the load.

are you using an audio interface?

congratulations... looking forward to trying this out, hopefully it will make the soundplane sing :)

bit more progress... on soundplane with beaglebone

Ive now got the thing properly calibrating and filtering on the BBB, data looks cleaner,
though Im sometimes getting lingering touches. I suspect this may be because sometimes Im not using the optimum carrier. (Ive seen this with SP on the mac before). its good to see the extra processing really didnt appear to hit the CPU too much.

now this is going, Im now considering pulling in SoundplaneModel and 'hacking' this back to a slightly more naked form. The reason behind this, is the model has a lot of code that really binds the soundplane driver and touch tracker together. with my current experimentation its clear, if you dont use the model, then you have to still do much of the processing thats in the model anyway.

I need to decide now, exactly where the hatcheting starts and stops...

thoughts so far...

things going : OSC and MIDI output connection, OSC services,kyma, any storage of signals 'for display purposes' (we just don't have the memory to spare), references to the likes of MLFileCollection, anything that refers to Juce.

parameters : 'under consideration' , but I think will stay

zones : 'under consideration', theoretically I dont want the mapping code here, but its tempting to keep the flexibility.

main things Im going to be keeping/modifying are loading soundplaneapp.txt for normalisation maps, general interaction between TT and will probably then have some simple callback which can be overridden for output.

I dont think this will take too long, as I'm 'reasonably' familiar with SoundplaneModel already, main effort I think will be breaking dependancies that i dont want :)

cool, glad its working for you..

interesting you see the same behaviour, it is a bit 'odd' - the cpu usage you've got is pretty good, unsurprisingly better than the BBB.

as you say, time to get it doing stuff thats useful, so we can see how useable it is in a more 'real world scenario'. I do expect to have to do a few changes yet, in particular to some input filtering, and also probably loading the soundplane json file to get some better calibration data, and carrier settings. otherwise I suspect the playability will be variable.

(of course I think this depends on how accurate you need the tracking to be, for me, Im using it as a playing surface, so it has to be pretty good, but if your were after more general x/y/z , simple might work ok)

anyway, Id obviously appreciate it, if anything you can improve is fed back...

yeah, Im not going to spend to much time on this for the same reason, once you get the new tracker working (after virta?!) , I'll then port this newer code (and dependent code), only from there do I think optimisation is worth really looking into.

as I mentioned, as far as I can tell so far, its seems to be 'good enough' so far on the BBB. I only investigated, due to the oddity of seeing CPU load drop as the BBB got heavier loading - so was really looking for some kind of busy wait... but that did materialise, so still at a bit of mystery, but one that currently seems to play to my advantage.

of course, its also fair to say, that the code on the Mac has plenty of performance, its only going to be when your start using low powered microcomputers, like these, that more use of the FPU is really going to be noticeable.

anyway, lots more things to try to improve and tidy up, and get running, before optimisation :)

ok, I've set up a private repo on bitbucket, which has this stuff in it.
you should have an invite, let me know if you would prefer it on a different email address.

yeah, Im not expecting much from the BBB...

Im currently just using it to communicate with controllers, in particular my soundplane , eigenharps and a Push 2 :) Im doing this in C++, and then sending/receiving OSC, which I'm picking up in PureData (-nogui) to translate to MIDI (MPE) and then that gets fired off to a bunch of Axolotis for sound generation and sequencing duties.

Im using pure data as its quite flexible to allow me to do the key/surface mapping, if I find I'm running out of processing power, I'll either move the controller stuff to a pure data external (to avoid osc handling) or just move the midi mapping etc to C++.
the later of course is most efficient, but makes the solution a little less flexible.

so no the BBB wont be running X, or anything else too heavy

the only thing I dont like about the BBB is you can't bus power the soundplane and eigenharps from it. so what Im currently doing is using a powered hub, which then is hosted by the BBB but also powers the BBB.

anyway, Im pretty close to being able to test this out.

Ive being looking at performance....
its a little strange on the BBB, the cpu load is varying quite a bit, from 60-80% BUT oddly if you start doing other things the cpu load drops. (!??) I thought this was some kind of busy wait, but not found any evidence of this.

I did do a gprof thats quite interesting, showing some definite 'hot spots' that perhaps with some fpu could be optimised. (Im sure Randy already knows all this)
convolve3x3r is the big consumer of resources, nearly 25% of time spent in it.

whats a bit odd, is I see in processTouches, its called 4 times but 3 times with same params

        // to make sum of touches a bit bigger 
        mSumOfTouches.convolve3x3r(kc, ke, kk);
        mSumOfTouches.convolve3x3r(kc, ke, kk);
        mSumOfTouches.convolve3x3r(kc, ke, kk);

I wonder if this could be done in a different way, it could make a big difference

setting the coefficients on the background filter is also taking a good amount of time.

apart from that, its a few key functions (like clamp/max) which are called a huge number of times, so any minor improvement in these would make very large improvements.

anyway, as I said, I need to run this 'in context' to see if it its going to work, but good to know there are some things to look into if we need to squeeze a bit more out :)

as such i don't 'need' an x15, it appears the BBB is enough for the soundplane.

(or at least at this stage, I need to connect it up to a synth and play it to check for sure :) )

but perhaps the X15 would give me a bit more headroom, my only real requirement, is I want all this to run off a small battery unit, as I want it all to be portable. Im not after integrating with eurorack.

Im thinking something like this:

Compulab CL-SOM-AM57x , yeah, seems nice, but perhaps not viable for a one off order... and I guess the x15 will see better general support.

hey, but whilst I'm not into eurorack, the idea with the soundplane is enticing, and your products could well tempt me further ;)
(though, Id need eigenharp support too... but I have the code for that already, assuming I can rebuild your firmware ;) )

funny about the SSE2NEON, I thought that was where I got it from... add I only added one function to get the whole ML DSP compiling, and that wasn't it ;)
( we don't need the whole DSP lib for the TT though)
anyway, I'll use vdivq_f32

code... I'll see what I can do. perhaps a private repo might work, would allow us to get the basics worked out. Id like to restrict access at this time to people who can/will contribute.

soundplane - beaglebone black status update.
ok, so Ive now split out all the necessary files for the soundplane and touch tracker
Ive integrated changes made by scott for vector for neon, and also made similar changes for signal.

I've also taken a slightly different approach, rather than using #ifdef which complicates the code line. Ive removed the SSE code and moved to separate files

so, now I have things like


note: the arch sub dir files only contain the fpu code (as much as is possible, without introducing inefficiencies), common code is in the original file (so above MLVector.h)

one question for scott...

in your port of vector you say there is no neon replacement for _mm_div_ps, however, SSE2NEON uses vdivq_f32 , is this not correct?

its not a big deal, as its only used in makeDefaultTemplate() , so not on the performance line... but obviously as TT changes, it may become more important if that operator us used elsewhere.

also is the X15 actually shipping, I can't seem to find a way to order one.
(preferably in Europe, but US would do too :) )

got it... soundplane with touch tracking is now working on my BeagleBone Black.

and also Mac... a simple oversight on my own part...
now just got to pretty the data up a little bit to integrate with my new setup :)

Randy have you fixed the midi/OSC mode in virta?
reported against Kaivo/Aalto ... when plugin is persisted, it will not be in correct mode until UI is shown - most hosts will not initially show the plugin UI when restoring a session.
( I guess since you might have hundreds of plugins in a session :grinning: )
Would be good to know it's fixed from day 1 in virta


I don't have a repo with the code in, but if you wish to collaborate, then you could email me.
( mharris AT technobear DOT com)

Ive got what you have so far, and Ive got it running on Linux (x86_64, PI, BBB) and Mac.

Ive also 'ported' the ML DSP and parts of the MLApp and TouchTracker.
(Ive used SSE2NEON as a starting point rather than updating the code, as at this stage I think its important to remain compatible with the ML code base!)

I made some minor additions to SSE2NEON

Ive also got a new version of the hellosoundplane, (touchtrackertest)that integrates the touch tracker.

I re-tested this yesterday, and found that this touchtrackertest has the same behaviour on the mac as BBB, i.e. its to do with configuring the touch tracker rather than the SSE2NEON code... which his 'good news'... it also means I can debug it in Xcode :)

current status, touch trackers is reporting fake touches..

Im guess this is probably something to do with the calibration or normalisation maps.
(the other more static values Ive set as they are in the app)

Ive two ideas how to move this forward.

  • debug the fake touches, using the current setup

    (and compare to how this goes in the soundplane app)

  • load the calibration/normalisation data from the soundplane json file.
    (id been avoid this for the test to simplify things, but mid-term i need it, as I don't plan to have calibration in this app... rather Id used the calibration thats made in the soundplane app on my mac)


@Randy, I know your busy with Virta, but would you perhaps have a few minutes to look over my test app, and see if Ive got anything obvious missing when initialising the touch tracker?

... its good to know others are interesting/looking into this, I think we can crack it easily together.


Hi Scott
Ive actually got the soundplane reporting pressure data (etc) on a Beaglebone Black.
though it doesn't at the moment quite look correct, as the touch tracker is not quite right.
Im not sure if this is my SSE to NEON layer, or other code Ive written and how its configures the soundplane/touch tracker, and haven't had time to check

I did this quite a while back now, but then got sidetracked on other projects, but Im hoping to get back to it soon. and when I do I'll have a new 'OSC' layer which will allow me I hope to debug the issues.

its tantalisingly close :)

(oh and the pico which didn't work on the RPi does work fine on the BBB, that bit of the code Ive got up and running)

Interesting video, great to hear Virta will be released this week!
good luck with the group, bit too far for me to commute from Spain :) but sounds great for the Seattle area!

@griffley you have to set bitwig to "Force MPE"