ok, (depending on your change), if a static velocity works, then my suspicion about z being too low is likely correctā¦
basically the velocity calculator used was build for the eigenharp which have very different hardware characteristics.
Ive created a branch which you can try, that tidies this up a bit, and also allows the calculator to be āfine tunesā
new github branch
code changes are on a new branch, that Ive pushed
branch = sb_test
new config allow
the new block should allow something like
"soundplane" : {
"voices" : 15,
"velocity count" : 4,
"velocity curve" : 4.0,
"velocity scale" : 4.0,
"throttle" : 0,
"steal voices" : true
}
note: a missing key above, will default to the values shown above.
i.e. you donāt need all / any of keys 
note 2: when using aalto be careful of āvoicesā !
the above is the ādefaultā and what was being used, and not working, asI think it yielded too small values - that said it was clamped to 0.01, so Id have expected a velocity of 1 (midi) which would be ok!
what values?
this is HIGHLY hardware dependent, which is probably why the defaults fail!
velocity count
number of pressure samples to use, should be 2-N.
depends on frequency of dataā¦ more will be sluggish, but should feel more predictable
note: voice does not start until we have N samples.
velocity scale
this is a āgainā on pressure samples.
ideally, this is set with a 'max velocityplayed, thatvel_count` samples will approach 1.0.
i.e. the less samples used, the higher this likey needs to be.
velocity curve
this is a curve used to adjust the computed velocity.
1.0 = linear
< 1.0 = more sensitive
> 1.0 = less sensitive
sensitive is not a good word really, its more how aggressively the samples ramp up on the device. ie. do you get higher value pressure samples faster (for N)
I suspect this could be the main culpritā¦
as the Eigenharp is a LOT more sensitive than the soundplane and with less travel, so Iād not be surprised for velocity if this had to be ādamped a bitā
may be try linear, or even < 1.0
throttle
throttling of messages in microseconds, only used for ātouchContinueā.
only needed for embedded platforms, of when using hardware midi targets, that may not cope with high frequency of messages.
bare in mind āconsoleā is also for testing, youād likely want this off or throttled for ārealā use, as its extra cpu/ioā¦ though I think it shouldnāt affect things too much.
Important Notes
Untested
I did NOT test this, I have no way to do soā¦ it may be bugged
I did add a few comments
note: there is an assumption that its the calculated velocity, but there might be something else going on, as I said, im confused as Id expect the vel calc to yield min 0.01 ā 1 midi.
but could be pow was returning invalid value, which might have screwed it (fixed)
Hardware dependent
these values are very dependent on hardware, and theres no ārightā answer, really you need to play and feel them out.
Id probably start with linear scale, so vel_curve = 1.0, then test.
then adjust vel_scale to see if velocity is too low and max velocity.
you can then adjust vel_curve to get a progressive feel.
adjust vel_count if its feeling way too sluggish.
its a trade off,
vel_count 2, would be faster, but likely much less predictable.
vel_count > 4, would be slower, but (hopefully) more predicable.
Changes
mainly, just allowed velocity calculator to be configurable.
but I also did tidy the calculator code.
- removed some code that felt hardware specific (e.g preloading at zero point on regression)
- check for pow going out of bounds
these do mean the ādefaultā values for vel_curve / vel_scale could be āoffā even for eigenharp, as that preload changes the regression.
but it feels like its now more correct/logical - but as above, untested, so could have broken it completely
testing / logging
uncomment out include for logging
uncomment the line for calculated velocity to see
Soundplane velocity
Im going to be honest, I found velocity (using ML app) not very predictable, though it used as simple algo iirc.
Its partly down to the tech used, generally I found soundplane better for slow/evolving pressures, rather than strikes.
is fixed velocity bad?
NO - the Haken continuum uses fixed velocity, because pressure is MUCH better if you have a sensitive controller - you PLAY the curve.
this is also why I much prefer OSC / T3D with aalto !
ofc, the drawback is most synths are based around velocity, so dont have the subtly of pressure
tl;dr; if you using soundplane, and mainly aalto, stick with fixed velocity, but even better used osc/t3d which is supported in MEC.
and make sure your patches use Z , rather than the aalto envelope and velocity.
the MEC repo contains an osc exampleā¦ you are interested in outputs with āoscā, just copy that block
btw: if you change āmidiā to āamidiā, then the midi block cannot be found and so will not be used, this is how you disable/change outputs
honestly, I rarely used the soundplane with anything other than ML vsts for this reason ā¦ that an Aalto is my favourite VST by far!
Summary
hopefully this will help you get more out of MEC/Soundplane.
sorry, not much more I can do, and im doing this āblindā, as I dont have a Soundplane anymore (I do miss it , its a lovely instrument ! )
also, frankly Ive moved on from MEC for my Eigenharps and Erae, the code is a bit ādatedā, and also as I dont have the Soundplane - my newer solutions are simpler as they dont have to support it.
also, bare in mind, MEC was mainly for other platforms (embedded mainly) i.e. those that didnāt have the ML Soundplane App, really macOS (and the console app) was just there for testing purposes.
anyway, sounds like you are able to adjust code (and/or possibly use AI tools), so feel free to fork it, and see if you can fine tune it to your tastes.
if you just focus on mec_soundplane.h/cpp and the mpe processor its not much code really and there is logging so you can track whats going on.
so its quite a simple code base to work with!
Good Luck,
Mark aka TheTechnobaer
