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.
Thanks for CCing me on the note to VEP. I'm very interested in what they come up with.
My parameter code is still mostly based on the JUCE framework. If you want to try another JUCE-based plugin like one of the Valhalla reverbs, it might be interesting to see if it has the same problem. (I'm not suggesting you ought to do my work for me here, but I have other things on my plate for the rest of the week, so thought I'd pass the idea along)
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.