Way to adjust minimum pad on and off pressure sensitivities?
Opened this issue · 81 comments
Okay, this is a very cool controller. You guys did a great job. It's awesome that it's so customizable too, and that you've made this firmware available.
So I wanted to give honest feedback. As a keyboard player, I'm having trouble with the minimum sensitivities for triggering pads on and off. I've tried playing with the velocity settings but that doesn't solve this.
In the open source firmware, is there a way to adjust with the minimum pressure threshold for triggering pads off and on? The current minimum feels much too high. Ideally I'd be able to rest all ten fingers lightly on the pads and get a "consistent" response from each pad, using less than the weight of the hand alone. Holding my arm stiff, right now I can rest my left hand fingers on five pads and none of them will trigger.
Since the pressure applied from the arm is divided over fingers, playing one or two pads per hand is doable (although still clunky), but each additional note becomes more and more difficult. My arms are having to exert a lot of force with this controller, and my fingers are tired.
So if the right hand is already pressing on four pads, a fifth pad becomes difficult to press without releasing pressure on one of the less advantaged fingers. Playing chords and melodies simultaneously is very hard to do because I'm losing notes every time I shift a little to accommodate new ones.
If the issue here is a hardware issue (too much noise at lower pressures), one thing that could help is to make the 'pad off' minimum pressure lower than the 'pad on' minimum. If someone still has their finger pressing on a pad, after having already pressed it with the minimum 'pad on' sensitivity, it's significantly more likely that they want the note to stay on.
For example, sometimes I will play a chord with my thumb, pointer and middle fingers and the melody with the ring and pinky. The pressure from the thumb might pass below the pressure needed to trigger the pad on in the first place, but I still want the note to to be down. Another case for this is when you're holding pads for a long time. I don't want to have to hold the same pressure required originally required to trigger the pad on on for long periods of time.
Right now, it seems like the minimum "pad on" and "pad off" thesholds are set the same. If I slowly press on a pad, I can find a narrow range of pressures the pad flickers on and off with very little change in pressure. This leads me to believe that the sensors are pretty accurate near the current minimum settings, and that some software changes could make me very happy with the controller.
Without much idea of what's going on inside, my hunch is that this controller is physically capable of performing at least as well as the ableton push, which feels a lot more playable to me, but right now it just doesn't feel tuned like a performance instrument. Even using musical typing on a PC keyboard feels hugely more expressive, regardless of the lack of velocity sensitivity, because my fingers have so much more control at the pressures required to press down on PC keyboard keys. That's not meant as a diss :) I'm just being real with you. Since this is marketed as a professional "performance" instrument, I'd expect it to be more expressive than a PC keyboard, not less expressive. Right now, the controller feels tuned like a drum machine.
Okay this is interesting. I absolutely agree and found this to be a huge issue myself. Actually I had a little conversation with @dvhdr on twitter. I am pretty sure this can be fixed at the firmware level since this this is just the threshold value at which the ADC values are recognised as note-on. For most power users it would be okay to set the threshold by SYSEX msg. I think Livid Instruments does this for some of their products as well.
Yeah, honestly if this isn't fixed, the product isn't going to fail, it's still great, but I don't know any keyboard player who would use this over a cheap midi keyboard. It's not going to live up to the hype. Although, hype can sell a lot of products.
The reason I bought this thing was because I enjoy playing the ableton push more than a lot of keyboards, and thought this might be similar, but at the current minimum threshold the pads are like nice MPC pads. There are big named artists who would want as much access to the minimum pad on and off thresholds as you're willing to give them. They're also going to want velocity and aftertouch response curves that suit lower thresholds.
Like to the point where blowing on the instrument would trigger the pad, or modify the aftertouch, if that's even possible :)
The question is, are you making this for professional DJs or serious artists?
Great feedback, thanks. I'll raise this with the team, it feels like you're really after some changes to the factory firmware rather than hacks here. I wouldn't rule out either, but can't make any commitments other than to evaluate it thoroughly!
Hey thanks for being receptive. This thing is cool, I'm hoping to keep it around :)
Any news here? I'm excited about using the launchpad in new ways!!! (especially for microtonal music and music theory applications)
And let me know if you need any help testing :-)
Cheers! Chatted it over with the team late last week, a proper response (ie. one not written by me ;) is in the works.
Hey there, any news? I need to take the controller back soon if it's not gonna be sensitive.
Hey no more feedback from DVHDR? I am also very interested in an increased pad sensitivity!
Hi all! I was holding on for a proper response from someone in the know. I still am, but I hope to have one for you this week. Thanks for your patience!
Hello all and apologies for the delay. We launched a new beastie yesterday called Circuit which has been taking up all my time: www.novationmusic.com/circuit
We went through quite a journey to get the velocity performance of the Launchpad Pro right. We designed it as a percussive instrument in that you do need to at least tap the pads to trigger them. It is not designed to be played by resting fingers on pads and playing from there even though you might do that on a piano or keyboard. On a keyboard you have the travel of the key whereas on the Launchpad Pro, the pads deflect slightly but remain basically static, of course.
It is fitted with an FSR (Force Sensitive Resistor) sheet which is a custom part with an 8x8 grid of sensors. In the product you press a rubber pad, this applies pressure to the FSR sheet and a voltage is generated and read by the firmware. Turning this into a velocity is not the same as you might do on a keyboard where you read a timing difference between two switches. With an FSR you read the change in pressure over a fixed period of time very early on after a change is detected. The time after that can be read continuously and translated into aftertouch - either channel or polyphonic.
There is a table for each of the velocity curves and this acts on the values read to become the final velocity output. We put in three - low, medium and high to give various respective outputs for the same input ‘hit’. I think these are available for edit in the codebase.
There is another factor though and that’s the point at which the voltage change is first detected. This is a physical hardware limitation due to the mechanical construction. There is a minimum pressure that must be applied for the pad to ‘turn on’, that is move obviously enough out of the noise floor. This change is not continuous so, in firmware, there is an associated low limit that is fixed to correspond to when the voltage has changed enough to definitely be a pad press. There is a low setting for this and it may be possible to fiddle with it but it will not give you the hyper sensitivity you may be looking for.
To achieve this the mechanical construction would have to be different with every pad in a permanent ‘on’ state and the threshold controlled entirely in firmware. We didn’t go this route although we did spend quite a bit of R&D time looking at it. We found in the end that our chosen solution had much greater consistency of performance unit-to-unit and avoided units with stuck pads in mass production.
The different ‘off’ to ‘on’ pressure idea is interesting but I’m not sure if it might fall down on the same physical limitation. That said, the whole point of opening up the firmware is to see what you guys can do with it so I want to see where that minimum threshold is in the firmware and see if it can be exposed for you to play with.
In summary, there is a hard-coded threshold that it may be possible to expose to play with (and we can look into that subject to demand) but I expect that changing it won’t make enough of the difference you are looking for.
Paul Whittington
Senior Product Manager
@whibble, thanks so much for your detailed response.
So just to sum this up: There will no changes regarding the stock firmware in terms of sensitivity, but you will try to expose the threshold value within the API to allow it to be changed for projects built on top of the open source firmware, right?
@whibble @dvhdr
Just wanted to weigh in on this and say there's certainly a demand. Stupidly low threshold settings are one the primary things I look for in a velocity sensitive controller. (Another being poly AT, that's why I got a LP Pro instead of a Push) I think many other people are the same, look at MPCStuff and their pad corx and fat pads. A lot of people voided their warranties trying to squeeze a bit extra sensitivity out of their pads, myself included. I've nearly stripped the screws for my MPK from dismantling it so many times, trying to fine-tune the number of layers of tape under the pads so they're as sensitive as possible without sticking or mis-firing. Complete nightmare.
Luckily I moved on to a Maschine Mk2, which is the benchmark for drum controllers in my opinion. With the sensitivity on max, I can get pads to trigger with a very light touch, comparable to lightly drumming your fingers on a table. Now obviously the Maschine and the Launchpad Pro are different instruments (otherwise I wouldn't have both) but if you can get a bit closer to Maschine's level of sensitivity, it would really increase the playability of the Launchpad.
A couple factors to consider here; The size of the pads makes it more cumbersome to play a single pad with multiple fingers, so all that pressure is typically only being supported by a single finger. Also, the 8x8 grid makes the Launchpad Pro more suited to playing harmonic instruments, which implies multiple fingers playing different notes at the same time. The inclusion of poly aftertouch is fantastic, but it's hard to leverage that by applying individual finger pressure when the response of the pads is a bit stiff. Of course you can put your whole arm/body into it, but that cancels out the finger independence. Note triggering suffers similarly if you're trying to hold down sustained notes and trigger new ones at the same time. Your only option is to use the weaker muscles in your hand. After a while of bashing away a bit harder than I'd like (plus a little extra so I don't have dead notes) I end up with stiff hands and sore knuckles.
Overall, I'd say the LP Pro met my expectations for pad sensitivity, and over time I'll probably acclimatize a bit to the amount of force required. But if things can be improved from "very good" to "excellent", it would really open up more possibilities for expressive playing.
I'd say probably keep the default firmware where it's at, and then allow deeper editing via Sysex or custom firmware. Ideally the threshold would be adjustable to the point of un-useability, and then be able to be inched up slowly until stuck pads and double triggers are eliminated. Likewise for the upper threshold, setting it to the maximum desired pressure to increase precision and fully utilize the midi range. The ability to adjust this independently for note vs aftertouch, as well as separate low thresholds for note on vs note off, would be the icing on the cake.
I know a lot of this is physical limitations of the sensors and pad architecture, but any access you can open up to the low level software side would enable people to tinker and perfect it to their liking. Maybe instead of averaging the ADC signal and comparing it to the threshold, we could use something like a transient detector where the signal feeds two envelopes with slightly different attack times, and the slower one is subtracted from the other to get a signal based on rate of change instead of only magnitude. Then the lowest values wouldn't have to be gated as aggressively to eliminate noise. Of course that's more computationally intensive than a moving average, but being able to experiment within the capabilities of the hardware would be very rewarding I think.
Anyway, thanks for being engaged and opening up the firmware in the first place. I look forward to seeing what the modding community is able to do in the coming months.
Yeah that'd be wonderful!
Ooohhh that sounds great!
👍 yeah this sounds very good to me as well. I guess projects like https://github.com/jrcurtis/subsequencely could then easily make use of it and implement their own velocity readout algorithms.
Any news on the raw ADC data?
Sorry @timbresmith - nothing to report yet. Though it's been fun getting back into this with the flash storage stuff, I hope to make more time in future - but all that is just good intentions at the moment!
Any chance the LP Pro is going to start getting some love again now that a major update to Circuit has been released?
Hey @Kyran-C - fair point, the Circuit stuff has been a big deal for me. I'm still not able to commit to anything, but I hear you!
Hey, just wondering if there's been any discussion recently of exposing the ADC data in the firmware? Recently I've been playing with my LPP again and I'm having issues with soft notes dropping off after the initial attack. It's really hard to play sustained notes at low velocity; once the initial impact vibrations subside, the total pressure on the pad drops below the note off threshold and the pad dies. Hitting the pad harder mitigates this, but then you're overshooting the desired velocity. It'd be great to have some hysteresis so it takes a more abrupt drop in pressure to send a note-off.
I'm going to try to implement a module in my reaper plugin that uses aftertouch data to determine whether a pad was meant to be released. A note-off preceded by a sharp drop in aftertouch would send the note-off as usual, but a slow drop in aftertouch (or a low initial velocity value) will defer note-off for a short period to see if any further aftertouch comes in on that pad.
Of course, that's still just using the midi values being sent to the software; It'd be so much more powerful and easy to implement something like that with the raw ADC data instead.
@dvhdr @whibble The new scales update is great. So, maybe now is a good time to trigger this issue again. Just look at this. Such a video of someone playing those Jazz licks on a Launchpad would be great, right? The thing is, it's really hard to play with the currently set LPP sensitivity level. I really tried. So once again: it would be so great if you could provide us with a workaround here... 🙏
It'd be so wonderful to have that ADC function! I've been using the
Launchpad Pro more lately, and appreciate it as a launcher, but
unfortunately it's just not easy to play. Hysteresis is the word of the
day, @Kyran-C https://github.com/Kyran-C! Thanks for that one! A
different threshold for letting up vs pressing down!
Beautiful video btw... I'm a serious keyboard player, and would love to
consider this thing a serious instrument ;)
Thanks again @dvhdr for even facilitating this discussion... Hope you all
can fit it on the calendar soon!
On Mon, Aug 15, 2016 at 11:49 AM, Fabian-Robert Stöter <
notifications@github.com> wrote:
@dvhdr https://github.com/dvhdr @whibble https://github.com/whibble
The new scales update is great. So, maybe now is a good time to trigger
this issue again. Just look at this http://pic.twitter.com/x3tA8MpUMK.
Such a video of someone playing those Jazz licks on a Launchpad would be
great, right? The thing is, it's really hard to play with the currently set
LPP sensitivity level. I really tried. So once again: it would be so great
if you could provide us with a workaround here... 🙏—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#6 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXylv00TpfB51aO0C6XEuTA5X17ATgJks5qgJiVgaJpZM4FjBOV
.
I have bought a launchpad pro today but have to return it. It tires my fingers too quickly. Will check it out later.
I suggest to work around it by release a accessory pad cover like this:
Only 4 buttons are shown in the pic, and the cones need not to be that sharp, but you get the gist. It's just elementary physics, but should get the job done nicely.
The cover should be made of transparent material, of course. I expect the cones will also have some interesting effects on the optics.
Hello, does anyone have any updates on this issue? I have just bought the LP Pro and I was amazed at its playability overall as a monophonic instrument but when it comes to playing some harmonies this issue ruins it. If we don't have any change in the API is there any other work around for this?
@dvhdr @whibble any news here? I'm losin' faith 😕 Maybe there is some reluctance to this idea at a marketing level or something?
It seems like exposing some existing function(s) should not take very long. From my experience as a programmer in a corporate office, exposing an already written and tested function should take less than 3 days work for one person. Of course, I have no idea what your code looks like internally, or how the low level "closed firmware" is separated out from the "open firmware" part.
If some hacker managed to create an ergonomic legato play mode, using hysteresis or some other method, you'd sell more than enough Launchpads to pay for this programmer's time. There are at least 20 people who would buy a Launchpad for this reason. IMO It'd be a worthwhile investment, simply in terms of selling more Launchpads...
If it didn't work out... well then at least you all gave your users a chance to see what they could do! It would give people a sense of ownership in the project. Not to mention that following through on marketing goes a long way in building confidence.
Aside from that, myself and quite a few others already paid $300 for the thing, expecting some way to get reasonable soft touch playability. Given the initial marketing of the Launchpad Pro as a "pro performance instrument", and the recent marking of the Launchpad Pro as "a hackers dream", those expectations were and still are reasonable. If I wanted a controller for the clip launcher, I'd have just got a used Launchpad from 2009, or something with knobs. If I wanted drum pads, I coulda bought a Maschine or something from AKAI. This was marketed as something different.
Again, I don't mean it as a knock on the design quality or the wonderful efforts you all have already made to open this project up. Please know that I'm still appreciative of this conversation, the efforts that have already been made to open the firmware, the quality design of this machine, etc. Still, I feel the need to give honest feedback about my feelings. As "a consumer" who has been marketed to, who has invested not only money but time and energy into making this thing a part of my work, I'm frustrated and feel misled by the marketing. As a hacker, who's been to Music Hackday twice, I'm feeling locked out of the library. This thing is sitting around waiting, collecting dust. As of right now, it feels like a lingering disappointment. But I'm still holding onto the hope that some more serious low level functions will be added to the open firmware.
Okay! Hope to hear some good news soon!
Micah
Nice synopsis Micah! I agree wholeheartedly and am one of a large number of users waiting/hoping for this change as well. Just wanted to chime in as well.
Yeah, I'd like an update on this issue too. I know things have been busy for you guys lately, but I'm sure you've had the chance to discuss it a bit by now. I'm curious what's impeding things; Software, hardware, or human resource limitations? I see this as the Achilles heel of an otherwise superbly designed box. It would be great to see this sorted out, and the LPP cemented as an indispensable studio/live tool. As it currently stands - from my perspective at least - the LPP's time is numbered until a competing device offers the same form factor but with better velocity response. Ableton's Push series are already a strong competitor, and NI holds the crown for best response with their Maschine series. The new Maschine Jam shows NI's increased attention towards the 8x8 paradigm and session-style control. The #1 complaint about it (aside from a lack of discounts for existing Maschine software owners) is the lack of velocity sensitivity. If NI do manage to fit their excellent pad response into an 8x8 form factor without stepping on their other products, it's game over. I don't care about a screen (computer duh), or other controls (although those touch strips are a tantalizing alternative to knobs), I just want 8x8 velocity pads without being tied to Ableton. The LPP is an obvious first choice but this velocity/threshold issue is a pretty big sticking point once you get your hands on it.
I know there's physical limitations of the hardware, and environmental factors that can't be controlled (vibrations on stage for instance), but it seems like there's still a lot that could be done in software to tailor the response to users' needs. Transient detection using a few windows of different lengths in parallel would gather more precise time-based information, which might help decrease the uncertainty near the noise floor of the sensors. Hysteresis would give us some more flexibility at setting the minimum possible threshold. We could even do some correlation between between pads; stage vibrations would affect most pads uniformly, so that could be filtered out. Any struck pad should produce a small impulse in adjacent pads, so that would help confirm that a pad was actually hit. Conversely, once pad strikes have been identified, these "vibration leaks" can be subtracted from the surrounding pads to avoid false positives.
Obviously all that would be a fair bit more computationally expensive than a more naive implementation of note detection, but it would be worth sacrificing other features if it actually produced better pad response.
I'm still very hopeful that we'll see the sensor data exposed in the API and/or some other means of improving the pads. How viable would it be to modify the pad sheet to close the gap above the sensors? I don't mind voiding my warranty if it means I have a playable instrument that I'll want to keep for life.
Just wanted to put this back on the radar. I've found myself frustrated with notes jumping on and off because of sensitivity issues. Considering as how an update released the scales mode, it makes it even more important that we're allowed access to sensitivity settings.
Cheers
Yes please. This is the #1 issue with the LP Pros. Playability. Although better than Push I feel they can be even better.
Also, not sure why Novation is looking at this primarily as a percussive instrument. With the wealth of pads, scales etc. this is a performance instrument. ...an amazingly promising one too. Love the idea of it but it needs tweaking to truly live up to what it can be. I bet that improving sensitivity for melodic playing is the most relevant feature to most users. Why not tackle it head on?
If you have the money, get an linnstrument, way more playable than both push and LP pro.
Unfortunately, that doesn't help, because the problem is the low threshold on the hardware itself. It just doesn't send anything on light touches. There's no way to rescale the velocity of a note that was never triggered. It does help bring up some of the velocities of notes which do trigger, but that just exaggerates the gating effect. We need a way to adjust sensitivity on the hardware before it's scaled and quantized into the midi range.
Well, whoops! I was planning to review raw-adc with a colleague before pushing it, but my fingers slipped.
I'm really not sure if the API is right (there's a conflict between handling "processed" surface events vs. using the raw ADC data). And I've changed the timer callback interrupt priority to synchronise the ADC data with the callback, which may have unintended consequences.
But, well, you can have a look - feedback on the API would be welcome!
But, well, you can have a look - feedback on the API would be welcome!
@dvhdr dvhdr thats awesome, thanks for keep this thing rolling. I will try the new API asap.
Thanks so much dvhdr for providing a way to modify this threshold. My only issue is I have no idea what I'm doing! I'm fairly experienced with computers but modifying the Launchpad has me pretty intimidated, I can get a gist of what I need to do from the read-me but if someone could just provide me with a quick run-down of how to specifically JUST lower the "on" threshold for my Launchpad w/ the API that would be incredible. Thanks!
@skylarrcaverly this is a dev project, the open firmware does not reflect the stock firmware and it's features. Therefore this API change will not JUST fix anything for end users. Just wait a couple of months for projects like @jrcurtis subsequencely to make use of the new API.
Hello. I'll check this out today. Sounds cool.
@skylarrcaverly this is a dev project, the open firmware does not reflect the stock firmware and it's features. Therefore this API change will not JUST fix anything for end users. Just wait a couple of months for projects like @jrcurtis subsequencely to make use of the new API.
i'm late to this discussion but i'm happy to see it being discussed. is there any way to get a version of the factory firmware with a user-editable NOTE-ON threshold capability?
i refer you to the 3rd party "jjos" system for the MPC series - one of the best implementations of user-editable FSR sensitivities i've seen. i definitely don't need per-pad sensitivity control, but it's worth a look for fun.
The way I understand it, the problem (as described by @whibble), is that the FSRs at the hardware level may be slightly incorrect in their outputs due to variation in mechanical assembly of the product, so having very tightly-set software thresholds that might be inadvertently tripped if the ADC reading happens to waver wouldn't be reliable. As I understand, this is why the thresholds are somewhat 'conservative' - they are set such that we can be 99% sure that when the threshold has been passed, a press is being detected. This is good in terms of reliability, but as others have noted, it might not be so great for precise sensitivity.
I'd like to suggest to that adaptively controlling this threshold might be possible, and might allow the threshold(s) to be automatically set according to real-world measurements of the FSRs in each Launchpad rather than to a hardcoded value. The firmware could gather ADC readings and feed them to an algorithm that would automatically learn the 'on' point of pressure for each pad. Essentially, this would be run when no pads are being touched. For a period of time (say, 1 second or so) ADC readings would be sampled and the mean would be used to determine the known point of 'zero pressure' (of course, which might vary from unit to unit and pad to pad). Then, there would be a 'offset' value which would be added to the mean measured ADC reading in order to determine a 'pad-on' threshold to use. Since this offset would cause the threshold(s) to be set relative to the measured point of zero pressure, we'd ideally be able to use a very small offset that would allow light touches to be easily registered. Assuming that the measured point of zero pressure does not change during the Launchpad's existence (e.g. no shifting or settling of FSRs inside the unit), we'd be able to guarantee that no 'stuck pads' would exist after this calibration procedure even with a relatively small offset value.
So this kind of approach would require the user entering a 'calibration' mode where they wouldn't touch any of the pads for a few seconds or so. Then, the per-pad threshold data would be written to the microcontroller flash. Or (in a perfect world) this could be run on every unit before it leaves the factory and kept away from the user altogether. Possibly this kind of thing isn't feasible or advantageous at all; I just thought I'd mention it since so far this discussion has been focused on the concept of a hardcoded, unchanging threshold.
Hi all, just wondering if there was ever any advancement on this issue? Thanks!
@ben-richardson well, the API to access the raw adc gains is there but I guess none of the community project did have time to pick up the changes or to do extensive experiments. Personally its still on my todo list... ;-)
Any further work on this issue?
Or maybe i should ask, is it even possible to fix this? Because i'm willing to try if it is.
Best regards.
@jorgen1005 the sensor data is exposed in the API now, but there's an aliasing issue which prevents having a very low threshold (which was the whole point of exposing the raw sensor data in the first place)
So, looks like the alias issue-thread is dead. No update in half a year. Such a shame :(
@dvhdr @whibble @joefocusrite -- Can we please get a status update? I get the feeling that this project has been abandoned, but it would be good to know Novation's intentions. I purchased the Launchpad Pro and found it to be totally unusable for my primary requirement as a synth controller due to pad sensitivity and premature note-off events. In hindsight I should have just got my money back immediately, but the open firmware looked promising as a way to workaround such shortcomings, so I waited (beyond the purchase return window). After a ton of playing with the firmware, I'm no longer confident that sensitivity can be meaningfully adjusted, but I won't know for certain until the aliasing issue is fixed (which sounds like the fix has been pending commit since Jan 31). It's going to be really disappointing if this hardware is useless to me, especially with the time invested in experimenting with fixes via the firmware.
Please guys. lol
I have contacted Novation support regarding this issue and this thread, so maybe they can get the technicians to submit some further thoughts.
Hey folks, sorry it's been so long. I'll get this over quickly - I've still not got a good answer for you regarding the ADC aliasing issue. The original firmware engineer has moved on, and the rest of the team are busy working on new things.
I don't consider this project dead - but my expertise is not in low level firmware and electromechanical design, and I can't make any commitments regarding this issue.
We do hear you and consider your feedback. Thanks for all of it.
Hello there, whatever its worth to the product owner, I and a friend have been using the LP Pro for days and we both also experienced this problem.
We are regularly checking this thread/issue gets a fix (or at least has a workaround) to finally purchase the LP Pro, respectively one for each of us. I think it really is a big issue, and im sure we are not the only ones waiting for this to be fixed before making a purchase.
This is not a critic, simply the best feedback I can make to encourage a product I'd love to own.
I must say, this is the biggest dissapointment i have ever had with a music product. And to think of the potential of the LP pro going to waste, i just get sad really, also very dissapointed with novation.
We've made some improvements to the ADC noise and crosstalk. Check out this branch:
https://github.com/dvhdr/launchpad-pro/tree/adc-improvements
A pleasant surprise!
Keep up the good work!
Hi @dvhdr !
Any updates regarding the pad sensitivity issue?
Thanks!
hi there, I wanted to checkout the adc-improvements branch but it looks like the link is dead.
@spacepluk hey - it was merged to master :)
I checked the ADC improvements and played a bit with the code. So, as I see it, the minimum sensitivity cannot be lowered using the raw data.
@dvhdr @whibble are there any plans to further improve on this (e.g. increasing the gain) or do you see any way of a user mod that could be applied to the circuit to increase the ADC gain? In that case it would be great if you could provide any feedback on where to start. Otherwise I would suggest to close this issue.
You're making this too complicated! All you need is your MacGyver hat and ~$3 of Avery 3-ring binder reinforcement stickers. This is a hack I've performed successfully on just about every pad controller I've owned (albeit not with 3-ring binder stickers, but same general principle). And I just did it on the LP Pro and it's fantastic!
Here's what you need:
- A package of Avery reinforcement labels (model 6734)
- About 60-90mins (low-medium skill level)
Here's what you do:
- Turn over the unit and peel off the orange backing. This part's a bit of a pain, but be patient and go slowly.
- Unscrew the back panel and remove it. You can slide your finger nails between the back and side panels to lift the back off.
- Grab the unit (put some pressure on the front panel / pads / pc board so that it doesn't come fully off), and turn it over so you're looking at the front. The Kensington lock metal piece may fall out, you can put it back later.
- Remove the front panel. Easiest way to do it is to push the plastic screw holes from the back, if it's not coming off easily.
- Remove the silicone pad sheet.
- Apply Avery stickers to the bottom of each pad (see notes on sensitivity / how many to use below). The stickers have a hole that the leds will go through. When done with the stickers, give the sheet a little blow to get any dust or dirt out.
- Replace silicone pad sheet. Once the pad sheet is back on the fsr sheet, you can lift each corner to make sure the fsr sensors underneath are aligned, and nudge the fsr sheet if needed.
- Replace top cover.
- Hold unit together (side and front panel), and flip it over.
- Replace Kensington slot metal piece and replace back panel. Screw everything in.
- You may want to hold off on putting the sticky orange backing back on, in case you need to open it back up to adjust anything.
- Power on the unit and give it a test. If you get any crosstalk/stuck pads, you may want to mash the pads around to get things to settle. Also, see note below about screw tightening.
Sensitivity:
I found 2 stickers on each pad gives the best result. 3 and 4 feel incredible, but were causing some crosstalk and pads getting stuck on. 2 seems to be optimal. One pad I downgraded to 1 sticker, since it was getting triggered by adjacent pads. But otherwise, all 2s. Even with 2 stickers, it's very sensitive, even brushing your fingers lightly across the grid will trigger. So if you don't need that much sensitivity, 1 will do you fine. On quick test, pressure sensitivity still works with this hack.
Other notes:
Be careful once you open the unit. I made the mistake of letting the whole pc board underneath the front panel fall out the first time I opened it. It's attached to the small USB board via a surface-mounted pin connector which can be a bit of a pain to align and snap back together. If you follow the instructions above and hold the unit together when you're flipping it over to access the front, then you shouldn't have this problem.
I had some stuck pads which were mitigated by loosening the center screw slightly. This may be something to try if you get any crosstalk/stuck pads when you close it up.
You may need to open up the unit a couple of times to deal with crosstalk, etc. I opened my unit 4-5 times through the course of this project (testing with different sticker thicknesses, etc), all in all it took about 2 hours. It should go quicker for you, since 2 stickers seems to be the max, but you may need to open it a couple of times to adjust pads that may be misbehaving.
Disclaimer:
This is a simple hack and there are not a lot of parts inside the LP Pro to get in trouble with. Still, undertake this at your own risk. And note that it may void your warranty.
@svankov Thanks for the info. I've done a similar thing on my MPK using layers of electrical tape and, while finicky, it did make a huge improvement. I've always thought about doing it with the LPP but didn't want to be the guinea pig. What's interesting in this case, is that we have access to the sensor readings through firmware, so we can mitigate stuck pads and crosstalk by raising the threshold. This whole time we've wanted a way to increase electrical sensitivity, but instead we can increase mechanical sensitivity and then fine tune it through software.
I was working on firmware that had an auto calibration mode where it would take a sensor reading with no pads pushed, and then another reading while the user applies max pressure, and sets the min/max thresholds accordingly. I might revisit that and make it work for each pad individually to compensate for any variation across pads. It could be as simple as doing this mod, and then running through the auto calibration to get max sensitivity, consistently across every pad.
I was working on firmware that had an auto calibration mode where it would take a sensor reading with no pads pushed
@Kyran-C interesting. I thought the adc-improvements was just giving us access to RAW values and the demo in the master now visualizes the lowest ADC readout with mapping it to the LED directly. Is there a way to really see the ADC noise?
That's just truncating the sensor value so it can be used to drive the LEDs. If you poll the ADC values with no pads pressed, you get small, time-varying values (the noise floor of the sensors/ADC). If we were to do this mod to effectively have the pads always slightly pressing against the sensors, you'd push past the noise floor of the ADC so that any slight pressure would register with decent strength. You'd set your pad trigger threshold slightly above that, and then scale the pressure into the 0-127 range. It might even have the effect of making pressure more consistent at low levels. As it stands now, the ADC readings are usually a bit jittery with really light touch, but consistent with more firm presses.
@Kyran-C, Hey glad to see another fan of the tape hack! I’ve had a couple of days playing with the modded LP Pro, and have only run into one pad getting stuck on sometimes, so I’ll probably open up the unit and remove one of the two stickers. Pretty impressed at how well the mod seems to be working, I can even do light double finger taps on pads, and they trigger perfectly.
I was on the verge of returning the LP Pro due to how awkward and inconsistent it was at low activation, but I’m glad I opened it up.
Interested to hear if anyone else attempts this mod.
I did the mod, using 3 layers per pad. It's a huge improvement. There's a few stuck pads when I first power it on, but I run the auto-calibration in my custom firmware and it sets the low threshold just slightly above the noise floor. Sometimes I still get some ghosting from the plastic case flexing, so I can manually bump up the trigger threshold a little bit to eliminate that.
I used to have to push my fingers perpendicular to the pads and use arm/wrist to get to full velocity. Now I can hit full velocity with my fingers parallel to the pad surface, only pushing using my fingers. Which means each finger can apply pressure independently instead of having to remain stiff and depend on arm muscles to do the work. Even my pinkie finger can hit max velocity no problem.
I was worried it would reduce the dynamic range of the pads; in other words they'd be easy to trigger but hit full velocity almost right away. But the pads actually feel more dynamic. It's easy now to play soft notes or loud notes. I'm not sure if 4 layers per pad would be any more sensitive or just start to reduce the dynamic range. I'm not going to bother applying more.
I feel like it should have been designed like this in the first place, but it seems pretty common for pad controllers to have a gap between pads and sensors so maybe manufacturers have their reasons. Perhaps tolerance issues with the pad molds, or extra work to assemble or calibrate them?
Either way, the launchpad is now usable as an instrument for me so I'm pretty happy. I still have to implement more features in my firmware to refine the pad response (curve, hysteresis, smoothing) but the current level of sensitivity is pretty encouraging. I'll upload to github once I get things a bit more polished so people can use it or fork it.
Everyone in this thread should really try this mod out, it's super cheap and easy, and it makes a pretty drastic improvement in pad response. Maybe try just 2 layers if you don't want to write your own firmware that lets you fine tune the trigger threshold. 3 layers would most likely give you stuck pads with the stock firmware.
@Kyran-C that sounds exciting. Would you mind to share your firmware fork on GitHub?
@Kryan-C agreed with above. i have not yet installed custom firmware on my launchpad but this will make me take the plunge.
trigger threshholds should be determined by averaging voltage for x seconds after boot, and possibly again at user command.
Thank you @svankov, I just did this mod and it worked great!! Some randomly triggered pads that loosening their nearby screw(s) resolved. The Launchpad Pro feels like a higher quality instrument now, and I can play it much more lightly. Highly recommended to everyone who wants to improve the sensitivity. It was fast and easy.
That's just truncating the sensor value so it can be used to drive the LEDs. If you poll the ADC values with no pads pressed, you get small, time-varying values (the noise floor of the sensors/ADC). If we were to do this mod to effectively have the pads always slightly pressing against the sensors, you'd push past the noise floor of the ADC so that any slight pressure would register with decent strength. You'd set your pad trigger threshold slightly above that, and then scale the pressure into the 0-127 range. It might even have the effect of making pressure more consistent at low levels. As it stands now, the ADC readings are usually a bit jittery with really light touch, but consistent with more firm presses.
@Kyran-C I had a bit more time trying to get a better impression of the raw ADC values. I couldn't get anything out of the sensors that looked like to be some starting point for some smart algorithm that could detect the pad hit from noise. Maybe some Kalman filtering would do? In any case, could you share your code with the best ADC -> LED mapping that you got to visualize the lower bits of the sensor?