thetechnobear's Recent Posts

Ableton Push supports browsing in the same way as Ableton Live generally does... i.e. what you can view in Lives browser is available in Push. (so doesn't need special testing)

basically there are two (actually 3) ways ;)
two described here;

a) AU - save your presets as aupresets... this works for everthing (well thats is an AU :))
b) VST - save as PC banks (ML doesnt support this)
c) put plugin in a instrument rack, and then save the rack.

I use (a) the most, but of course this wont work if your on a PC (only Mac), (c) is ok but a bit cumbersome, but has the advantage that you can assign some macros whilst you are there :)

In some ways I quite like saving these presets separate outside the ML preset system, as it means I have only my presets on the push :)

the main 'pain' is if you use other DAWs (that dont support AUs) then you cannot get to these saved presets...
to get around this I save in both .aupreset and in the ML browser, which of course means there can be 'discrepancies'

its a pain, plug in developers dont like the au/fxp format as they are limiting, and of course means you need to dupe au and fxp formats (and others if you support aax etc), but its not ideal for users either, as DAWs can only use these standards... they know nothing of internal presets. (though bitwig, seem to know something about u-he's preset)

Native instruments are trying to get around this with NKS, and a few developers have jump on board... but Im not sure they are making this technology available to DAWs, or if its just for their controllers.

anyway, its only really a pain, if your using multiple daws, otherwise there is a way to get these things to work :)

Cubase 9 now supports Audio IN for VST3 instruments.

are you planning to support VST3?

there were some problems reported with some recent MBP - I think Randy fixed these, so you might want to see if you have the same issue with the betas Randy has recently posted.

yup that fixes crash for both Cubase 8.5 and 9.0 :)

btw: Im not really able to test much more than loading, cant live with demo restrictions :)
if you send me my license keys, I'm happy to install all the betas and then use daily.

its also crashing Cubase 8.5 (Sierra)

 0   com.madronalabs.aalto          0x000000013d5a6aa7 juce::BigInteger::BigInteger(juce::BigInteger const&) + 23
 1   com.madronalabs.aalto          0x000000013d53ae81 JuceVSTWrapper::getSpeakerArrangement(VstSpeakerArrangement**, VstSpeakerArrangement**) + 449
 2   com.madronalabs.aalto          0x000000013d5371af AudioEffectX::dispatcher(int, int, long long, void*, float) + 767
 3   com.madronalabs.aalto          0x000000013d539d1b JuceVSTWrapper::dispatcher(int, int, long long, void*, float) + 427
 4   com.madronalabs.aalto          0x000000013d537fa7 AudioEffect::dispatchEffectClass(AEffect*, int, int, long long, void*, float) + 23

looking forward to trying these, once all the keys are sent out :)

Softube Modular has just added a RISE module, which can also be used with MPE mode on the soundplane ... lots of fun :)

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!