thetechnobear's Recent Posts
Im trying to get my head around how the soundplane software works, and Id like to understand the principles of how it determines touch x/y/z from the raw matrix.
This is really just 'out of interest' as I love to know how things tick :)
as the source code is open source, I can work through that, but I wondered if there is something a bit higher level.
In particular, are there some details of the basic maths involved, e.g. what maths techniques are used to go from the matrix (which i assume is a 2d pressure values).
(I can then get the specifics from the internet :))
and/or perhaps a max patch that does something similar?
I guess ideally, Id like to try modeling the process in Max, just so i can a feel for it.
note: I know Randy has spent a lot of time refining the touch data, eliminating noise etc, so i know it won't be as good… but more an understanding of the principles involved.
(its this refinements, that make me think perhaps the C++ code might make it tricky to see the basic process)
so i assume I'm after peak detection algos for 2D arrays (3D grid), and looking for one thats not a brute force search thru the grid for maxima (with respect to neighbours).
I've also had a quick check of the DIY projects here, I guess part of this may be a starting point. (just need to remove the bit about converting audio signal, as this is already done in the soundplane)
Q. is the matrix from OSC completely raw, or has it had the calibration data applied to remove 'noise' , if the former, I might look at the source, to see if I can 'optionally' output the later.
fair enough, will check out the code.
Max, agreed, I just thought it might be easier to visualize whats going on.
anyway, once I looked through the code i will have a better idea.
yeah, Im not an expert either, as Ive only built very small things too, really to try to understand reaktor
as far as I've played with it, there are two things you can do with OSC
this basically allows you to take one of the parameters from the messages (using an index), as far as i can tell this has to be 0.0 - 1.0 and then is automatically scaled by the control
this is easy to do :)
OscReceive / Osc Receive Array
the first is trivial to use, just give it a pattern and specify the number of parameters (=ports) - but its limited to 10 outputs
the second, is standard array semantics in Reaktor, Ive not used but I assume it can do greater than 10 parameters... but t3d always has less than 10, so just use OSC receive :)
ok, playing notes into instruments, this is where it gets kind of tricky :)
you have to do 2 things:
- you have to go through you instrument and find all the midi objects and replace them with an osc receive. e.g note pitch. (actually, you'd probably be best using an OSC recieve than then sending this thru the internal messaging of reaktor, as you will find many midi objects are repeated e.g. you might find a note pitch connected to the oscillator AND to the filter (to do key tracking) )
for simple instruments, its straightforward enough, for more complex, it be be quite difficult to find all the midi objects,
partly because there not prefixed with 'midi' or anything, just called note pitch, pb
there are a couple of things i find problematic with the t3d spec when using with reaktor:
- the note off, does not send the pitch, this means you need to look it up in some kind of voice array
- reaktor expects fixed patterns /t3d/tch* is not working, so you need to put a pattern in for N voices, which is a bit of a pain
ok, once you get over that it should work...
the next step brings 'extra fun'
you want to do per note expression, e.g. pitch bend on individual fingers,
this is something as i said, Ive looked into, its possible, but means you need to be tracking voices, and then only affecting the correct voice... this is possible in Reaktor as is has a pretty good poly system, but its not trivial.
(note: also you may have to redesign part of the instrument depending on how its using the poly mapping)
personally, my idea, is to probably build a simple synth of my own first, get used to doing the above
and only then looking a retro fitting existing instruments, which will be much more complicated.
I think its a rich avenue of investigation for sure, my only issue is time... as Im also wanting to do similar things in Max/Msp
which currently has my focus.
hope the above helps a bit.
looks interesting, hope to have a play with this next week, when my soundplane arrives.
Ive not tried SC but looks good, very compact. alot of functionality for a relatively small amount of code.
this is an area I hope to be experimenting with soon (though Ive quite a few soundplane projects, so may take some time :))
what are you trying to do?
use for control? e.g. mapping to sliders?
use for note input?
should be pretty much the same, as doing with touchOSC
basically you will need to set up a zone file, which contains X or Y sliders,
then the messages are
much more effort, and tricker that mapping :)
first most ensembles are build around midi, so you have to find the appropriate midi inputs, and replace them with osc.
one of the difficulties, is t3d is touch focused, whereas midi is note focused.
(this is a problem with the note-off message in particular, as t3d does not sent the note value)
its actual possible to make it work nicely, I experimented with this in the past with the eigenharp, the touchId can be used to drive the poly
(in fairness, its quite a task to get it working, and many parts will be instrument specific)
as i said, ive not got my soundplane yet... but when I do, I will be experimenting.
probably simple control first, and then note input much later.
Randy: perhaps the final touch message should contain the note (but zero x,y,z etc) this means a trivial conversion to midi would be possible, which ignores touchId.
(usually this is not best practice, but for some applications is 'good enough')
I bought it last night ... very excited :)
I'm sure randy will be along soon, but I had a little play to see if I could reproduce,
as i use LPX and couldn't remember any issue
Im using with LPX 10.0.0.7 on 10.9.4, aalto (i could try kaivo, but i have no reason to believe its different)
with OSC on my Eigenharp, I don't notice any appreciable latency, so unlikely to be above 1-2ms, certainly not 80ms...
(I've used this before with both aalto and kaivo and not had issues)
the osc latency is not really possible to time, but I tried with midi
i created a midi track , used a kick on 1st beat then directed that to an audio channel,
that showed no latency, in fact if anything it showed negative latency.
I also tested in AULab, and no issue.
I wonder if for OSC you have your networks seutp correct?
I don't have access to a soundplane or yosemite (I keep my music machine on only proven releases), but perhaps an issue with soundplane software rather than aalto/kaivo?
one thing i did have odd with LPX/Aalto
I did get into a state where Aalto was ignoring first few bars of notes, I know thats sounds weird.... basically start transport and wasn't until bar 4 the notes would come thru as sound. I replaced aalto with another plugin, to check it wasn't me/lpx being stupid... and it immediately worked. I then put aalto back, and it was fine. (so obviously a fresh aalto instance fixed it)
The only thing i wonder about, is originally on the 'bad instance' id being used OSC, and then switched to midi.... aalto did switch (osc message gone etc), but I'm wondering if it was in an odd state.
@wanterkeelt, hard to say if your performance is 'normal' without machine specs/operating system etc.
but I found Live 9.1.6 was not really any different to other hosts, in practical use.
(LPX, Vienna ensemble pro,Bitwig, Max)
Im running Mac OSX 10.9.4, Live 9.1.6 on a i5 2.9Ghz, (so not that powerful) and on default patch, Live shows 9% and on Koto 40% (8 voices).
bare in mind, comments in randys article, about 'always' active.
as for Live…
its 'well known' live cpu meter, is not a cpu reading at all… its percentage time required to process the audio buffer, i.e. 25% means its used 25% of the max time it could to process a buffer.
this is a reasonable way, but its rather subject to external things, like the operating system preempting it, and can be a little misleading with multiple cores/cpus.
one thing is worth noting though, is its worth getting to know how a daw handles plugins with regard to threads (= distribution over cores).
e.g. in Live do not put FX on the same track as a heavy cpu use plugin, as it will be put in the same thread, instead put the fx on a return track.
Randy, a question … if you bypass Kaivo/Aalto does it stop the oscillators, and stop all other processing? i ask, as i noticed it keeps the osc connection open.
It would be nice, if the plugin is bypass if everything is stopped including closing the osc server port.
interesting read v8media :)
if you need any help with setting up the pico, just post on the eigenlabs forum,
or more active is the Eigenharp G+ community.
I agree, the EigenD software can be a bit 'intimidating' initially, due to its flexibility but the 'community' is very helpful, just ask questions on the above, and we will get you up and running quickly.
playing notes out of scale, you can either use chromatic scale, or alternatively try the 'fingerer' setup, which gives you a more wind instrument like setup, with a key triggering accidentals.
breath to open filter: use the midi matrix (same for both external midi and also AU/VST mapping), click on grid which intersects breath (column) and filter cutoff (row, either CC or automation)
if you really want to get deeper (later), then make sure to download the latest version from eigenlabs which now includes Workbench for free.
one thing i would 'recommend', try to play the pico 'as is' with the factory setup initially, learn it as an instrument in its own right. one common mistake new players make, is they see the flexibility of EigenD and start spending hours/days trying to 'bend it' to their vision/preconception.
this inevitably leads to frustration, as they get into complexities before they really understand it.
I liken it to a person picking up a guitar for the first time, and start using a bow on it with some weird tunings,
yes its possible, but most would agree it would be better to learn play it 'as is. first.
oh… and if you have aalto/kaivo checkout my soundplane agent for the eigenharp.
you can see me using it here:
enjoy your soundplane, eigenharp and ewi, your very lucky to have such a great selection of controllers :)
(please bare in mind I'm not connected in any way to madrona labs, just here to help!)
whoa, sounds like you've had a tough time.
ok, so you say you want to run the VST version (due to presets)
you could use any lightweight 'VST host', it doesnt have to be a daw , if you search on google you will find a number of free VST hosts.
e.g. http://www.refusesoftware.com/ugly , but there are lots available.
Max - as you say Max is good if you want to do more, and in fairness only takes 3 objects to create a full solution,
Bidule - Bidule is very popular, and lightweight
if you use OSC, then just remember a number of the presets are setup for midi, and so wont make a sound under OSC because they have xVel set on the envelope, untick this and it will start working. better still disconnect the enveloper and connect Z to the 'level'
been exploring creating aalto with the eigenharps expressive side, just a bit of a noodle really.
Im really enjoying the aalto/eigenharp combo, its very easy to very immersed in for hours.
details: aalto, my own patch (dark eigen), connected via OSC (t3d) using my EigenD soundplane agent.
its really the start of an exploratory piece, which i hope to build upon.
a few things, I'm hoping aalto/kaivo will add to help me are:
more controller support, so I can add breath input ( and possibly strips)
more voices (because its legato I'm stuck with about 3 usable voices, 4th is overlapped, so get too much stealing... id like at least one more :))
separate OSC ports for kaivo / aalto, so i can play a split with kaivo and aalto, I've got some ideas on the kaivo side now :)
there appears to be a regression bug, so this no longer works in 1.5
as params does not return the names, instead on the vst we get
(on the au we get blanks)
attached is my simplified max patch, which you can use for testing:
(tested, max6.1.8, aalto 1.5 mac osx 10.9.4)
Valhalla (VV,RoomShimmer) are fine. tried as many plugins as i could and all others ok.
Its weird, as I said Aalto and Kaivo parameters show up fine in LPX, and EigenD.
BUT... I have got something for you...
With Max, the AU reports the names as 'blank' and the VST reports paramX, e.g. param79
... whereas all other plugins report the names 'correctly'
(remember VEP uses only AU on Macs, so i suspect this is the issue)
I think you have Max... so you can test it for yourself on the vst~ help page
xVel = dZ ??
unrelated, I look at the xVel 'issue'
Ive just noticed that dZ can be populated on a soundplane (touch) message, BUT soundplaneOSCoutput doesnt then send it in the osc message.
(so perhaps this is where the 'confusion' starts?
.. was dZ intended to be velocity?
also, Im looking to add zone support (with the hope you will add to Aalto/Kaivo).
I thought Id send 3 xSym, zone Id 1, 2, 3, with just a 'text' string (i.e. assume this has no purpose)
one thing I'm slighly unclear on, are these syms unipolar?
Id have quite liked unipolar/bipolar variants.
Im a bit confused, why do you have xSym, ySym, zSym... I can understand these represents the axis on a soundplane, but id have thought its irrelevant to the 'client' they will just want to know its a 1 dimensional control,
its orientation is irrelevant? i can see xySym is cool for 2d controls.
Im guessing your idea is that you just define a region on your board, and are then choosing to send x,y or z, which I assume you then scale to 0..1 ?
but id say its more valuable for the client to be agnostic to this...
e.g. if i set up my clients to read a 'virtual slider' on the soundplane, if i change the shape of it on the soundplane, should i really to change the client?
multiple UDP ports an idea
finally I had a thought about using different udp ports, and a protocol to allow multiple instances.
How about introducing a 'change port t3d message'
simple idea, kaivo(/aalto) default listen on 3123, if they receive this message they change to specified port
once client has sent, it then attempts to connect to it (after say 1sec)
when vst is saved, then it saves the port , so when starting next time it uses this new port immediately.
on client and server, logic is 3123 is the default, unless above message used. also if they ever 'fail' then they revert back to 3123.
osc connected messages, should be changed to "osc connected : 3123" (etc)
should work quite well, just means client only has to send the message when vst is very first created (not restored),
and then can remember that new port from then on.
no pesky ui, compatible with existing behaviour, and you don't have to fiddle with both VST and client.
Im using Vienna Ensemble Pro (http://www.viennaensemblepro.com) to host aalto/kaivo,
which is working really well (a great way to get maximum performance).
But Ive just found that VEP cannot see any automation parameters for aalto or kaivo,
(it uses the AU version, no option to use VST)
all my other plugins, I have no issues with, just kaivo/aalto.
this is a problem, as i wanted to use to circumvent OSC not having any support for things like breath controllers
EDIT: tested with LPX, Live, Bitwig - they all show the parameters ok. so I think its an issue with VEP... though interesting, it has no issue with any other plugin. anyway, Ive emailed VEP support.
been playing with both Kaivo and Aalto some more via OSC and thought id put together a few FRs that hopefully are relatively simple to implement :)
(well I can hope)
Configurable OSC port, so I can run both Kaivo and Aalto at the same time on a split,
and also more than one patch (e.g. lead + pad) (K+A)
more voices, (say 8?) in Aalto (A)
(I'm running in Vienna Ensemble Pro, which nicely load balances)
Pitchbend range for OSC (K+A) , i know its in the osc message BUT its nice to have alternative ranges for different patches. so configurable you could the incoming fractional offset perhaps as a multiplier? (K+A)
.. i currently have this in my OSC interface, but it cannot be stored 'per patch' (K+A)
envelope x Vel* , in osc mode should be x Z (as we have no access to sustain) (K+A)
CC support for OSC, or additional 'osc controls'
the drawback with OSC mode is it only has key support, albeit in 3D.
however, Id like to use a breath controller/strips as well for more global control, e.g. say reverb level, I can see this would be useful in the soundplane too, as you may have a number of 'zones' defined for the soundplane as a slider for such things. (K+A)
longer term wishes :)
gate output, and trigger input for Aalto (A) (as done in Kaivo)
voice per channel midi, I like OSC, but voice per channel is more standardised, e.g. linnstrument/continuum also support. (K+A)
modifiers for signals, multipliers/additions/lag ... see u-he bazille for the idea :) (K+A)
envelope x Vel
Q. Am i correct in saying when you put connect more than wire to an input it sums?
(its what it seems to do), it might be nice to have multiply as an option?
then we could do envelope x Z ourselves
(UI: perhaps clicking on the input level, changes colour and so mode between add/multiply?)
Im really enjoying both Kaivo and Aalto, absolutely love the way they allow us to control the envelope directly, really is a unique feature
hope the soundplane build is going well,
thank for the explanation, that does seem to tie up with what I'm seeing.
I even tried using a stick on the eigenharp keys (not as suitable as with a soundplane!),
and indeed it improves it, also upping the sample rate helps too.
but in the end, I think your right envelopes are good for this, in the same way i guess we still use LFOs for modulation.
When in t3d mode I believe the "x vel" setting on the envelope uses a "touch-on" velocity value calculated from the initial z.
hmm this doesn't work for me at all, I've checked the messages sent, and there is definitely an initial pressure but I hear nothing. Ive always had to turn of xVel on all patches to get anything
… does it work on the soundplane?
BTW.. id say you might want to take a couple of Zs as he depending on data rate, at higher data rates, the first few Zs can be quite low.
as you say its an exciting area to explore… great that we have both the hardware and software to experiment :)
Id agree i can get alot of dynamic range, especially on pad/lead type sounds.
one thing I am finding tough though is getting a snappy percussive sound.
lets say we have a sound we want to be percussive (like the koto in Kaivo),
but we want to retain, control over the level...so rather than use the envelope (which we cannot use, as we don't have xVel, and without its a full volume)
instead we connect z to level , (this is pretty much the normal pattern id say for OSC/soundplane - no?)
this works really well for pads...
but if i play a percussive sounds, and quickly tap the keys its a little drawn out,
it doesnt sound percussive at all ... is this really because I cannot remove my finger quickly enough? (id have thought it would be possible at high refresh rates)
have you noticed the same on the soundplane, randy?
perhaps for these percussive sounds the only real way is with an envelope.
one other thought... perhaps initial velocity is still useful in these scenarios?
should kaivo/aalto calc this from Z (i.e. dz?) or would it be useful to send via t3d?
( i think i favour the former, as velocity is a 'derived value', and t3d is as close as possible to raw data)
EDIT: bit more playing, i used some processing in EigenD to compress the pressure input, an this does help alot. but what I noticed that even when I think eigenD is pretty much sending binary pressure, its not as 'sharp' as if I connect the gate input to the level.
(when i connect gate to level, and tap the keys, I get as percussive as with the envelope)
have to say in not totally convinced of my diagnosis though, as I found the more I played with using Z as input to level, the closer I got to percussive sound, and it some cases found I almost need to release a little slower than expected. (i.e theres perhaps a longer release on the env that I thought?)
anyway, no big deal... the truth is you get just get 'different' sounds, some of the 'percussion' sounds played in this way are very interesting :)
(and in non-percussive sounds, its never a problem... its feels very reactive/expressive)
ooh 1.6, do you know the contents yet?
Im pretty desperate to have voice count increased (8), and support for multi instance when using OSC (or at least run Kaivo and Aalto at the same time).
guess though your pretty busy with the soundplanes, must be getting pretty close to shipping time.
I suspect this refers to modulation…
easiest to see when you are using a per note modulation source…
say you have poly aftertouch, this could modulate something in the oscillator, and so each voice could be being modulated differently, say timbre, fm carrier etc
with single channel is a bit limited, as there are few per voice modulate sources - velocity, pitch (key tracking), poly aftertouch.
its a bit more obvious if you are using OSC with say a soundplane (or eigenharp), here you could be modulating all parameters with 3 axis, and each voice would be therefore different
it uses the soundplane OSC addressing (t3d)
a brief description is here: http://madronalabs.com/topics/1740-sticky-t3d-format-description
in practice its better (more up to date :)) to read the soundplane source code, which is located at: https://github.com/madronalabs
its pretty straightforward stuff, you will find the osc mapping in SoundplaneOSCOutput.cpp
a couple of points:
uses UDP port 3123 for both Kiavo and Aalto, so you cannot use both synths at the same time, or multiple instances of the same synth :( (of course you can revert to midi for this)
i think only /t3d/tch and t3d/frm are used e.g. i don't think any of the zone messages are supported yet.
hope this gets you started, Im sure Randy will be along to let you know if Ive got something wrong.
BTW: what are you planning to use it for? and in what?
(Ive done this for the eigenharp, and Im thinking of doing a MaxMsp implementation too for another project... though Im half waiting to see if Randy will be updating to add zone support)
"When Aalto gets t3d messages over OSC, it goes into OSC mode and stops listening to MIDI entirely. If you want to combine both OSC and MIDI I wold recommend converting the MIDI information to OSC somehow"
sorry, my question was badly worded...
automation, is not midi, and Ive tested, it still seems to respond to host control to when in OSC mode - so thats cool :)
i guess really it was two things:
a) if you are thinking of exposing the automation parameters via OSC.
(I'm guessing from your above response - no)
b) as described in my other FR post, I really would like the equivalent of CC , +1 , +2 outputs when in OSC mode.
Im guessing (b) would be useful for the soundplane too, and would perhaps be linked to the work you have done regarding zones on a soundplane.
pattern storage would be nice :)
you can work 'around' it, as the seq values and on/off are automatable - so that provides a way. e.g. you can create a M4L device to store/retrieve patterns.
Edit: even better, I just tried with Numerology 4 (five12) , link up a faderbox, paramod to aalto,
and then you can save as presets, and also have quantised morphing between patterns.
ok, this is more N4 functionality, but is possible due to aalto (& kaivo) exposing sequencer via automation.
N4 + Aalto/Kaivo is a great combination, they sort of have a similar philosophy with their modular aspects.
Randy, when using OSC are the automatation values still available, i.e. is it still listening for midi messages within the audio unit? (which messages are processed and which ignored?)
Ok, more playing yesterday... and some fresh ideas :)
x/y/z and pitchbend curves.
Ive just implemented these in my T3D drivers for the eigenharp, as sometimes you want subtle effects, other times you want more drastic changes.
the reason Im posting here, is perhaps this should also be available per preset rather than at the controller level.
(my current understanding is aalto/kaivo have linear modulation inputs, and I think the soundplane supports a curve on Z, and some quantisation on pitch?)
for 'more' percussive sounds, its useful to have a concave pressure curve,
but on a string/pad sound a more subtle linear/convex curve might be better.
similarly if I'm pitch bending for more 'continuous' type sounds, a linear curve is appropriate, but perhaps on more conventional (say a piano variant) a more concave curve - this becomes very interesting as well when we use larger pitch bend ranges.
of course these are obvious ones, but even when modulating cutoff/q etc curves are useful.
here, i do recognise the differences between the soundplanes ( & continuum) continuous surface, compared to say and eigenharps (& linnstruments) key approach with an offset. ( i think curves may be also useful with midi CC too)
(I wonder even with a soundplane, if often players would on some sounds want a more subtle pitch bend to help stay in pitch, but still allow pb with a more exaggerated move)
I do recognise the danger of introducing complexity in the UI e.g. one could argue for all inputs could have curved response, rather than putting them on the outputs.
so im not sure how/if this is something you think is worth the investment on.
anyway, as I says I've done it in the controller software, so more just a thought, about what is appropriate at 'preset level' vs controller level
Geerts implementation of midi mapping in EigenD is interesting to look at, which you might want to look, might spark some ideas for the soundplane.
basically for every plugin parameter (or midi CC/at etc), you map it to an input (or >1) (e.g. key roll) then you can supply scaling/bounds inc mid points/inversion etc, and now in 2.1 (not in above manual yet) also a curve.
its complex, but its amazing how tuning these parameters can affect the way it feels to play certain vsts/presets... i often fine tune these on instruments I'm really keen on and use frequently.
of course with the soundplane this could be done by using Max, but i thought Id share, as its the same kind of thing I'm doing with the soundplane controller interface.
cool, note per channel will be very useful.
(perhaps also 14 bit midi CC & velocity?)
but I'm happy with t3d due to higher accuracy , would be nice to have support for slider zones though :)
summed outputs, yeah summing is also useful, and I wouldn't change as Im sure many presets depend on it, hence the idea of changing the input 'mode'.
(ok it would be nice to able to do wire1 * wire2 + wire 3, but to be honest, its too complex, so i think either sum(Wire 1..N) or product(Wire 1..N) is fine)
I agree the about the current complement of modules, theres enough for so much flexibility, without being daunting. its hard to see how you can add more to Kaivo/Aalto without sacrificing the UI..... (u-he bazille is a bit daunting at first)
only thing i can think of is having some advanced modules on another tab? perhaps with input / outputs on the sides of the patch bay?... but perhaps a V2 thing, that I'm sure you already have many ideas for :)
anyway, not a big thing, i think theres plenty of opportunities in Aalto and Kaivo, without more complexity.
Im just finalising a new 'agent' for EigenD which I think will be interesting to Soundplane owners, so thought Id post here :) (hope this is ok Randy)
EigenD is flexible and open performance environment with that can host instruments, and contains physical model instruments and things like step sequencers, recorders, etc etc.
from the beginning of June, it was made completely free (its also open source)
(yes, it was developed for the Eigenharp, but actually transcends, and is really device agnostic ... but as an Eigenharp player Im a great fan of EigenD)
my new agent (midi device) supports incoming multi channel midi at 14 bit bit res, and converts those into the native eigenD signal flows (supporting 3d touches, strips, pedals, breath etc) - a must for expressive controllers like the Soundplane.
heres a demo video : http://youtu.be/1VdkDzZaxvw
you may also find the eigenD vst videos interesting, and I hope to add some more,
to introduce people to EigenD features.
anyway just a heads up, Id love to hear how someone gets on with a soundplane and EigenD in the future - I think a powerful combination.
As I said, it may just be my unfamiliarity with Audacity (and its ancient windows like UI :)).
What Ive been trying to do is take samples from my synth, layer them up, and chuck into Kaivo to play with - getting them into Kaivo is the easy bit, its cropping/editing in audacity that is the time consuming bit (for me).
Given, I've little idea what will work well as a sample, Im just trying to streamline this, and see what works :)
perhaps eventually I will grow to love Audacity ;)
Thanks Randy for taking the time to publish some tips, very helpful.
Id also add, that different VST/AU hosts seem to play abit of a part as well, also running in a separate host will allow OSX to do load balancing between your main host/DAW and the host with Kaivo.
Looking forward to 1.1 :)
one thing, I would like to 'streamline' is the importing of samples.
I don't really have a solution... and perhaps its just that I don't get on with Audacity, and none of my DAWs can deal with 4ch wav files :)
Ideally, perhaps it would be nice for kaivo to be able to 'capture' the sample, through audio in,
(it might have to be done in 2 steps to get the 4 channels).
Alternative, being able to specify 2x2ch, which would be easy to create from any daw.
... this has been one reason Ive not been playing with too many of my own samples, as its takes me a bit too long to get them from synth -> kaivo.
Thanks to help from Randy.
Ive managed to get EigenD (the Eigenharp software) talking natively to Kaivo/Aalto using the T3D OSC protocol of the Soundplane.
The expression in this OSC mode is amazing, I imagine, it must be fantastic on a Soundplane too.
Quick demo here: http://youtu.be/wyX1HFCYHfs
Hope to add more features from T3D in the future!
Thanks again Randy for your help, documentation and having your code open source and most of all for producing software instruments that really add something new!
btw... i mentioned it would be useful to have an input into sustain level on the envelopes.
I think perhaps I should have said, one of the reason for this, is existing patches always end up very 'quiet', and have to be modified...
the reason for this seems to be they use x Vel on the envelopes, but there is no velocity from t3d (though of course Kaivo/aalto may be calculating one?)
or have I missed something?
so I thought perhaps route Z to sustain level (currently ive just been mapping to where ever the envelope goes - which is ok, as this means the user controls envelope with pressure)
but perhaps it might be nice to introduce dz (as velocity), and then have a velocity input on envelopes,
or perhaps even better just a multiplier input, could be nice with the LFO/Seq ... and even used between env 1 / 2 and you could remove the x Env1.. as this could be handled by the more generic solution.
anyway just ideas...
BTW, agent has been released, to hopefully a few will be playing with it this weekend :o)