A bunch of the core objects (sp.onsetframe~, sp.descriptors~, etc…) all let you specify what kind of mics/setup you are using, so you can use the @input attribute to say what kind of mic you’re using, and if you’re using more than one input:
The different input modes are as follows:
0 = SP sensor
1 = drum trigger (contact mic)
2 = air microphone
3 = SP sensor + air microphone
4 = drum trigger + air microphone
This handles routing and stuff, but also applies some EQ/filtering that I’ve found useful for each of the types of mics (mainly for the Sensory Percussion sensor and piezo discs).
For most of my purposes I use @input 3 as it gives me the “best of both worlds” with the super fast onset detection from the Sensory Percussion hardware, but better descriptors from a DPA 4099. That being said, I have found that I get the best results from classification with just the Sensory Percussion sensor on its own.
So in short, it should all work, but your mileage will vary with some of the fussier processes (mainly classification really). With something like the KeyTam (ooh, what are your thoughts on it so far?), you can get a really wide range of sounds just from the open tuning, so that would really confuse the classifier anyways. It would work wonders for the vanilla descriptors and corpus matching stuff though.
On my list of things I’m eyeballing is eventually trying to come up with a DIY version of the Sensory Percussion hardware. Or rather, something inspired by that approach (hall sensor-based), so it will be easier to make some, and mount them on existing drums permanently (like in a KeyTam). My hardware/engineer chops are such that this is a really slow investigation from me as even though I’ve taken my sensor apart and taking pics of everything, I can’t easily draw a schematic or know how to make one from scratch. If this overlaps with your knowledge/interest, I can ping you an email with the info/pics I have and we can chat from there further.
