thetechnobear's Recent Posts
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
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 Driver.it 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.scale(2.0f); 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 )
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.
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"
I get similar behaviour using the Soundplane with MPE,
so I think its likely its aalto/kaivo rather than MPE implementation on the Linnstrument.
(its a bit different behaviour if I use rotate channels or not, but similarly 'confused' :) )
not a big issue for me, as I tend to use polyphonically, and also with T3D which doesn't have any legato behaviour (as far as i remember)
I know your not looking at the soundplane software at the moment, but for your 'issue' list, when you get to it after Verta
I notice my console logs filling up with hundreds of :
4/2/16 00:12:36,000 kernel: Limiting icmp unreach response from 6710 to 250 packets per second 4/2/16 00:12:40,000 kernel: Limiting icmp unreach response from 22822 to 250 packets per second
a quick tcproute trace led me back to the source being the soundplane client software.
as i could see it constantly trying to reach ports 3123 to 3138
00:14:10.331996 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 3123 unreachable, length 36 00:14:10.332014 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 3124 unreachable, length 36 00:14:10.332022 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 3125 unreachable, length 36 00:14:10.332025 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 3126 unreachable, length 36 00:14:10.332028 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 3127 unreachable, length 36 00:14:10.332034 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 3128 unreachable, length 36 00:14:10.332038 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 3129 unreachable, length 36
I had a look at the code, and in sendFrame(), sure enough I can see it attempting to transmit to every port offset for every frame.
from a quick test it appears this can be rectified by adding to the loop
Im not sure if this is the full picture however, as it may not cover the split case,
I also assume there is some 'logic' behind this, to do with the fact that the frame message needs to go to every client regardless of if theres a touch or not.
Id need to do further testing to check this, though of course I'm limited on how I can fix the protocol as I cannot alter the client software (aalto/kaivo)
btw: I suspect mFrame++ is not correct, should it not be contiguous for each client, i.e. you want it outside the port offset loop.
as I said, I know your busy with Virta, but I hope once thats done you will have some time to resolve some of the issues in the soundplane software, so hope the above will assist you,
happens with just the soundplane client running.
the above fix, I think is fine, I just need to check some of the surrounding logic to check that the initialised flag is set in the appropriate cases.
hope virta development is progressing nicely :)
Since the Soundplane software is open source, Ive developed a few extensions to the Madrona Labs (official) application which I thought Id share. my changes are also open source.
you can download a build version from here click
Obviously this is not supported by ML, so post here if you have issues (unless of course the issue is also present in the official release).
also if you like a feature, let me know... or if you want other features let me know, perhaps I may be working on them, or want them too :)
which version is it? - I always keep my build in-line with the latest ML version, usually the current development version (rather than released)... assuming I don't find any major issues with the dev version.
how well tested is it? - I use it everyday, but of course my usage may vary from yours, so cannot guarantee it. personally I have this, and the official version installed. so that if I have any issues I can cross checked with the official release.
changes included in TB141
- bug fixes (from official release) related to note on/off behaviour and sending got pitchbend and cc messages
changes included in TB140 :
- Midi modes (click here to see screenshot)
single channel with poly or channel pressure
MPE ext - extended midi with 14 bit midi support
Multi 73,74,11 (CC x,y,z)
Multi PB,1,CP ( pitchbend, CC 1, channel pressure)
its easy for me to add more if needed...
when quantize is off, the touch has an indicator of how far you are from being in tune. I use this to practice playing unquantized tuning. (click here to see screenshot)
just like the XY zone, but has a 3rd CC for pressure.
don't send touch data when a touch is not active.
Im also working on a couple of other features,
Midi Pedal Input
I want to be able to publish sustain (& perhaps expression) pedal info out on the MIDI Soundplane OUT, and also OSC.
Midi Program change for setups, to allow me to use a midi pedal to switch between different soundplane setups, so i don't have to use the soundplane app during play. e.g. so I can have a full surface playing Kaivo, then switch it to playing aalto
no promises, if/when this is coming... quite a few projects on the go, but I wondered if others have thought the same.
finally, a thank you to Randy/Madrona Labs for making the source code open source, so making this is possible!
updated version TB141 - I found a number of bugs in the midi handling from the official release concerning note on/off and the pitchbend and CCs sent.
These are now fixed in TB141
Randy, if you look at my latest checkin on my repo it will be pretty obvious the issues.
unfortunately, I can't issue a pull request as my code base now contains quite a few 'enhancements', so there a bit I divergence. and I dont have the time to do changes on both my build and yours.
(my build is a superset of yours, i.e. includes all your changes, should you wish to 'take as is' )
Dying to show you something!
Dying to hear something :)
I don't have any issues with bitwig/aalto (or kaivo) but may be because Im no a Mac.
for what its worth, I use Bitwig 1.3.5 , Aalto 1.7
Bitwigs options are simply setting a fixed buffer size (which Id recommend) or Auto which I assume 'calculates' one for you. (rather than varies it, but hey might be wrong)
some options to perhaps try are:
- put aalto in the same process as Bitwig, rather than run it as a separate process.
- try turning auto-suspend off
neither should be necessary, though the later may be useful with aalto, as it kind of expects to be running all the time (afaik)
Im not sure the above will do anything, as its not necessary on Mac OSX, but perhaps windows is a little more fickle