thetechnobear's Recent Posts

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 :) )

Hi,

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

SpLive

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.

so...

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 bela.io , 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 ;))

10.11.4
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.

observations:

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

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 : http://madronalabs.com/topics/5521-virta-setting-up-with-daws

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 :)