randy's Recent Posts
For the last few months I've been working on a brand new way of extracting touches from the Soundplane pressure data. I'm very happy to send out the first public demo of that work today, as Soundplane 1.5.0b1.
The new touch tracker algorithm is a fundamentally new approach, and fixes small but annoying inconsistencies that players had to work around with the old one. Some of these showed up as stuck notes, or lingering phantom notes that would follow a touch.
I've been playing my Soundplane a lot while working on this. Now, when the sounds aren't right, I'm finding more often it's a problem with where my fingers are and not the software. So I'm very happy to switch my focus a bit more from algorithm development to practising!
Soft touches are no longer subject to a time-varying rejection filter, and should feel much more stable and less spongy. Positions of touches should be more accurate and consistent. Adjacent touches should maintain their positions better over a range of pressure.
Generally speaking, the new algorithm uses spatial filtering in a lot of places where the old one used temporal filtering. So latency should be much better, and in general it should reflect whatever your fingers are doing right now, which is kinds the point. Read on for details.
Version 1.5 changes
- new touch tracker algorithm
- attempted fix for Kyma connection
I'm sending out this version and any other upcoming betas simply as a compressed file containing the application. You can move it to wherever you currently keep your Soundplane application and run the new one alongside the current one. All data files have the same format, so you can use old zone presets with the new version.
On installing, I recommend that you go to the Expert page of the application and choose "restore defaults." This will set the default parameters for the new tracker and pick carriers.
If you have a carefully made calibration for the old tracker, you may want to back that up. I believe that it will be preserved if you switch to the new version and back, but better safe than sorry. The calibration file is in Library/Application Suppport/Madrona Labs/Soundplane/SoundplaneAppState.txt.
This new tracker runs on a new, more robust principle and so a calibration procedure is no longer needed at all. In the future, I may add some form of positional fine tuning to allow for differences between instruments, but for now I think this should perform well without any calibration, and we'll have a more consistent baseline so I can get feedback on how it's working for the beta.
A couple of levels might need to be adjusted, as follows. Run the app and go to the "Touches" page, and pick the "xy" view mode from the view mode menu. If you raise the view scale dial to around 10, you can probably see some gray flickering. This is the sensor background noise. If you touch the surface now, you will see some green pixels, and probably a touch. If you see green pixels when you are not touching the surface, the "lo thresh" dial needs adjustment. To do this, go to the Expert page.
Back on the Touches page the "thresh" dial functions basically as before. The default here is 0.01. If you make this lower, lighter pressure will create touches, but touches will not be as consistent. Please use the default value for now when reporting issues.
Let me know if the new tracker seems like an improvement. If there are some cases where it isn't, the most effective communication to me would be a short written statement about what doesn't work well. I may be seeing the issue too, and already aware of it. After that, screen shots and movies are probably the best way to communicate about issues with tracking.
If you have a Kyma, please get in touch and let me know if this fix solves the connection issue with 1.4. If it does not, I will be sorry, but not too surprised, because I don't have a Kyma for testing. Now that the new tracker is done, and we are in the testing phase for this release, I can work frequently with you to find a fix.
New tracker notes
The new tracker runs in multiple phases, which you can see visualizations of using the various view modes on the Touches page. In short, these are:
- raw data: as before, raw Soundplane data
- calibrated: data after calibration and spatial smoothing
- pings: touch candidates obtained by curvature method
- pings horiz: horizontal pings only with pressure graphs
- pings vert: vertical pings only with pressure graphs
- key states: where a touch may be over each key
- raw touches: touch candidates derived from key states
- touches: filtered and matched touches
- xy: finished touches with position histories, also sensor data
Sustaining touches on adjacent keys should now be possible, with careful playing, as long as the touches are more than a key width apart. In other words,
While single touches can be played very softly, groups of touches may take more pressure.
Touches on the bottom row suffer from positional inaccuracy because the palm of the hand is often close by providing a sink for electrical charge. This is a Soundplane hardware issue, not a tracker thing as such. To see an example, try pushing the lower row keys with a nonconductive pen or pencil instead of a finger. You may see that the positions go more easily to their limits. I have found keeping the bulk of my hand away from the surface, by curling the finger underneath and playing with my nail, to be a useful technique.
Touches never go all the way to the edge of the outer keys. If you think about it, you would have to be poking into the corner with something pointy-shaped in order for the center of a touch to be truly on the edge of the surface. The Soundplane is designed for fingers, which all have some thickness.
If you look on the Soundplane issue tracker on Github, you can see the problems I know about or improvements I would like to make. If you have a problem with the software or a feature suggestion that's not on this list, please let me know.
The current state of the software archive is a bit messy, and it's not too clear what versions of libraries to grab to compile your own version. I'll be cleaning things up as I work on the 1.5 release. Meanwhile feel free let me know if you have any questions.
I also look forward to finally updating the manual, now that the software is settling down. I'm having a lot of fun playing now, and I plan to do some more video demonstrations soon.
Finally, all this work sets the stage for the soundplane-to-CV module, and the next model of the Soundplane itself. Stay tuned for developments.
I have only been building for 64-bit. Adding 32-bit doubles the size of the app and I wouldn't have thought anyone wanted it. If this is a need you will be having regularly and not just a lark, I can look at adding a 32-bit version.
Looks like I have been building for 10.9 and up. I'll see what I can do to support 10.8.
This is fixed, I'm working on the scale issue now and will send out an update shortly.
Did you try the beta 1? It should still be linked above. Another person had the same issue with the beta 2 but not #1.
Hi @walker I'm sorry I missed your post.
I actually found this thread through a search just now because I'm working on this issue. so I hope to have a fix for you very soon.
There's not yet a global transpose. It would be useful, I realize!
In the release phase the granulator and resonator of the voice still need to be working to make sound, just as hard as in any phase. If another voice tries to use the resonator at a different pitch, you will hear this stealing.
The body is a bit different because it is shared by all voices. It is very much like the setup you are talking about with a reverberation plug-in.
Hi Joseph, I don't test on XP anymore, but I haven't heard of any changes that would break it so I won't be surprised if it still works. Make sure to save your old installer or plugin and try the demo.
I'm still interested in doing this. Now that AU version3 is supported it makes more sense.
Thanks for the thoughts, all.
Aalto has been around for quite a while, and a lot of people have patches they are attached to. I have a lot of additions in mind, and I think all of them can be accomplished while maintaining good compatibility with previous versions.
I think if a Kaivo 2 were to offer improved smoothness across a larger range for certain sounds, then compatibility can come second. This thread is supposedly about Aalto so I'll probably write more about that elsewhere.
It sounds to me like having only 8 voices is the problem here. At some point a voice must be stolen for a new note to sound, and with a long sustain there's no way to do this without hearing it.
At some point, maybe when Kaivo gains multicore support, then it will probably make sense to allow more voices.
Thanks for the feedback.
OK, I'll look into this. To recreate the problem I need to lean more.
What version of Reason are you using when you get the problem?
What OS and version?
What input do you send to the plugin? It could depend on pitch.
Finally, if you are able to try the same patch in a different host on your system, please do and let me know if you can reproduce the same issues.
It's not really complicated. The value signals can be any number within the range set by the range dial. The pulse signals can only be a 1 or a 0, because the UI is just a toggle switch. That is the difference.
All the UI for the value signals, including range dial, glide dial and 16 sliders, takes a lot of room. So instead of two sets of values one set is just triggers. This kind of interface comes from hardware sequencers and drum machines.
Thanks a lot for the feedback, I appreciate it. I might add a gate output to Aalto 2 if I can do it and maintain compatibility with existing patches. It seems doable. I know the gate adds a lot of flexibility.
I hear you about Kaivo's resonators being too wild at times. If anything I try to err on the side of allowing too much dynamics. But I think with some more work it would be possible to make things a little smoother.
The pulse and value signals are really the same thing, except the value signals can only be turned to 0 or 1 by the UI. Every signal in Aalto is just a floating point number, which in a hardware modular would be a voltage. I hope that makes sense.
Now I have Aalto !! I can keep my stereo, my bassoon, my sofa, etc.
One of my favorite testimonials ever :-) Thanks for the good words.
@jeffreypierce Latency should be a bit lower for the new software.
My guess is you are describing a problem I've seen where OSC communication gets "stuck" at a very high latency sometimes. The trigger seems to be high CPU load. I would try rebooting or using MIDI to see if this is the issue.
Future versions of the app will be optimized, so hopefully you can do whatever you were trying to and the CPU load won't be such an issue.
Hi there, glad you're digging into Kaivo!
The resonator gets its patch only from the pitch signal inputs and the setting of the pitch dial. There's no scale reading or quantizing happening inside it. So, if you send it signals from the KEY module for a pitch sequence it will use them.
You could try some really different scale from 12-equal like Japanese/hirajoshi with a simple patch to really hear the difference. If you don't send pitch to the granulator, just have it produce a constant noise, you can hear only what the resonators are doing.
Everything is there and would theoretically compile. I'm checking in all the changes to the embedded branch currently, and will merge it back into master and clean up compilation instructions / dependencies when the software is out of beta.
I'm going to be changing the API around the TouchTracker module before that release, again for better compatibility with the embedded code.
Then there's note-on velocity, which happens in the tracker and really isn't done yet.
All this is to say, if I were you I'd wait a bit more until I send out something with proper velocity and a new API.
I haven't done any work on optimizing yet. So the new code may even be slower. But due to the new algorithm I know it has the potential to be much faster.
Right now I'm mostly working on a much-needed update to Kaivo. I appreciate your patience.
A new beta: Soundplane 1.5.0b2.
The only changes from b1 are attempts to get Kyma working. So, if you don't have a Kyma you probably don't want to bother with this.
MIDI filtering by channel is up to the DAW, in general. In most programs there is a channel setting in the track somewhere for each MIDI instrument.
Ableton Live has a different approach. It chooses to basically ignore the concept of a MIDI channel and (I think) merges all channels of MIDI data onto the current track. So if you're using Live you may have to filter the data somehow before it reaches the program.
Working on it!
Good to hear. I'll be working to make adjacent touches easier. They really need to be on the outermost edges of the adjacent keys.
I heard that Kyma communication is still broken. I'll be sending out another beta to try very soon.
It's hard to say from here— it could be either that a new source of radio interference appeared, or that a mechanical shift took place. Once in a while I see a variation I think is from radio noise here but it tends to be more minor.
When the new detector is deployed I could think about some kind of auto-calibration again.
Yes, I think your experience with the green patches is just the surface not going back to its rest state completely. This shouldn't be a problem. The tracker is designed to ignore those little blips if they don't correspond to a touch. If you have the main page "thresh" set very low to respond to the softest touches possible, it could be more of an issue.
The areas where they appear most may be due to both the long-term compression and the fact that certain carriers have more background noise.
Overall, much more playable and musically stable. I just got lost playing for an hour or so and didn't hear a single ghost note or something that made me stop and move into diagnostic mode. On to practicing more!
I'm very very glad to hear this.
This is just the first version of a tracker using this new technique. Improvements will follow, including some way to calibrate or correct for the wobbly y boundaries.
Adjacent touches should be possible now but only on the opposite sides of keys, and only with care and extra pressure. The centers of the touches must be > 1.5 key widths apart. So, if key edges are at (0, 1, 2), the touches must be within the range (0, 0.25) and (1.75, 2). I'll work on reducing the pressure required in the future. If you look at the "pings" display you can see what might be possible.
I am thinking of adding a "join" mode where a touch directly on the edge triggers both keys. There are some details to work out, but I think this could be a useful option. It breaks the "continuous" use of moving touches but could allow more chords to be played.
Thanks Mark. I'm glad you were excited to check this out and get back to me. Your feedback is very encouraging, and confirms that my new picture, both in improvements and a few remaining problems, reflects reality! After so much work on one thing it's a relief.
I also found that MIDI velocity is not working well. This should be a quick fix. I'll continue to adjust the "slide" distance for a good feel and possibly add this as an expert setting.
I am thinking about a new calibration routine that will work just as you suggest. I wanted to confirm that the underlying layer was working well first.
My next step is to clean up the repo and make the tracker module compile in our embedded world, which means giving up on a few C++11 niceties I'd gotten used to and removing some dependencies.
Glad to hear it. Enjoy!
Sorry I didn't see this post... You can start your own topics for a new question.
I have never heard of Snoopy, except the cartoon dog!