NOTE: this will require Mac OS X version 10.7 or later to run.
Changes since 1.2.4:
- Kyma listener off by default to fix collisions on port 3124. Use 'kyma' toggle on Expert page to turn on.
- fixed automatic connection to selected OSC service on startup.
- restored some values from 1.1.2 to improve touch tracking.
- add automatic saving of window dimensions. This is saved in /Application Support/SoundplaneViewState.txt.
- fixed a problem resolving OSC services
- fixed wrong MIDI note offsets in default Zone setups
For those few of you compiling your own version, note that I've moved to using the C++11 compiler provided by XCode. This will enable me to simplify my work with some modern C++ features, and is the reason for the new OS 10.7 requirement.
On 10.10 I'm getting a bug when the Application Support/Madrona Labs folder is empty. After the app finishes selecting the carriers it crashes the moment I hit okay. Got around this by running 1.2.4 first before opening 1.2.5.
Whoops, I'll look into that, thanks for the report.
Fixed and changed the above link to version 1.2.5.1.
cool, will test it :)
Im a bit surprised you have moved the offsets, I know the labelling of the notes was wrong, but I would have thought most, would have got used to note positions, so changing the offset might cause some confusion. (I know you can transpose)
I thought you would probably just change the note names, I know inconsistent with guitar tuning, but id assume its what most users have got used to?
played now for a couple of sessions, does feel better...
there appears to be a new bug (1.2.5.1), now if you do "select carriers" ... the SP will initially not do anything, until you also hit 'recalibrate' - not a biggie, but might catch a few out.
now if you do "select carriers" ... the SP will initially not do anything, until you also hit 'recalibrate'
I can't reproduce this one.
I thought you would probably just change the note names, I know inconsistent with guitar tuning, but id assume its what most users have got used to?
If people want to they can make their own setups that transpose to what they are used to. It's important to me to have nice sensible defaults going forward.
Just posted a 1.2.5.2 with improved touch tracking (existing algorithm). Should be less prone to problems at edges and ghost touches between other touches.
This is the last tweak I'm doing on the 1.2 line, and now I can start in earnest on the new algorithm.
select carriers - I can't reproduce this one.
hmm, odd, I tried this a few times, and it happened each time. Im now wondering perhaps if it was all 'in the same session' , perhaps a restart of the app would have fixed it, i.e. a quirk, if I get it again, I'll try to get some more info on what is going on.
It's important to me to have nice sensible defaults going forward.
fair enough, more an observation... always tricky, with these kind of things, but as you say better to have it 'correct' going forward.
1.2.5.2
cool, will give it a go tomorrow
now I can start in earnest on the new algorithm.
exciting news
okay, when you said 'the SP will initially not do anything' I thought you meant would not select carriers! Now I have seen the problem with no data afterwards until a recalibrate. That is fixed in the repo now.
my two cents: the tracking for the top and bottom rows is way worse in the new version. tends to think the press is in the next row inward. tried reselecting carriers to no avail.
the tracking for the top and bottom rows is way worse in the new version.
Strange, should be the opposite.
Did you try normalizing with the new version? I bet that will fix it. Just go to the expert page and click "normalize" and follow the instructions in the text box.
Selecting carriers will not have any effect on touch detection except to minimize any radio frequency noise present.
yeah normalizing helped after a few attempts...i think i need to practice my normalization skills. is there a video of you going through the normalization routine?
There actually is a video here:
https://www.youtube.com/watch?v=Qckvsc2Gzjo
But it is not super useful any more because I changed the normalization routine to include another step. The ida in the "blue" step is to press with a firm palm just pressing down evenly everywhere. Really it's not too fussy. This is what controls the edge behavior.
Here's a capture of my normal map generated in the "blue" step:
Select view mode "test2" to see this. Note that the view scale is set to 3.0 so you can see better. After you normalize it should look something like this with bigger blobs near the edges over some areas. This compensates for the fact that the surface moves less near the edges where it is clamped.
Good news: I'm currently working on the next rev. of the touch detection and it's going well. It should be much better at close touches and the edge stuff. After this rev. I'm confident the code will settle down and I can take the time to document everything much better. It's hard to document a moving target! thanks for your understanding.
cool, thanks.
very excited about the possibility of being able to distinguish adjacent notes with the new algorithm.
in midi mode , it appears fast slides are generating 2 touches. (1.2.5.2)
( I say midi, its probably unrelated to midi, as you will see below - but its where its easiest to see/hear)
e.g. say you fast slide across the entire surface, you will see (correctly) one slide for the whole slide, but you will see (incorrectly) additional small slides (which look almost independent)
params: quantize on, glissando off, note lock off (everything else default)
replication: easy use 1.2.5.2 midi mode, aalto, patch default, sustain=max, rel=0 and voice = 1 (important) , then slide fast. you will hear the note stop before you reach the end.
ive not fully debugged, I can see in midi monitor 'additional' touches are on different midi channels - this seems to indicate msg->mData[0] is different, as this is used for channel i.e. different touches.
this is also 'confirmed' by the fact if you set max touches = 1, then the problem goes away... presumably as the rogues additional touches are being ignored by the touch tracker.
but oddly only one touch shows on the graph,
not a big problem, but seeing as you are looking at touch tracking, perhaps something to test