dvhdr / launchpad-pro

Open source firmware for the Launchpad Pro grid controller
BSD 3-Clause "New" or "Revised" License
444 stars 101 forks source link

Way to adjust minimum pad on and off pressure sensitivities? #6

Open micahscopes opened 9 years ago

micahscopes commented 9 years ago

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.

faroit commented 9 years ago

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.

micahscopes commented 9 years ago

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?

dvhdr commented 9 years ago

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!

micahscopes commented 9 years ago

Hey thanks for being receptive. This thing is cool, I'm hoping to keep it around :)

micahscopes commented 9 years ago

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 :-)

dvhdr commented 9 years ago

Cheers! Chatted it over with the team late last week, a proper response (ie. one not written by me ;) is in the works.

micahscopes commented 9 years ago

Hey there, any news? I need to take the controller back soon if it's not gonna be sensitive.

GuitarAlex commented 9 years ago

Hey no more feedback from DVHDR? I am also very interested in an increased pad sensitivity!

dvhdr commented 9 years ago

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!

whibble commented 9 years ago

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

faroit commented 9 years ago

@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 commented 9 years ago

@faroit, yeah, I'll chat to @dvhdr about this as I don't know where in the code this resides. It might be available to change already - not sure.

Kyran-C commented 9 years ago

@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.

dvhdr commented 9 years ago

@Kyran-C & @faroit - how would you feel about another api call simply sending over the raw ADC data? It sounds like that would allow you to do whatever you wanted, as you say, without complicating things for those who wanted to build an app using the existing method.

Kyran-C commented 9 years ago

Yeah that'd be wonderful!

micahscopes commented 9 years ago

Ooohhh that sounds great!

faroit commented 9 years ago

:+1: 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.

micahscopes commented 8 years ago

Any news on the raw ADC data?

dvhdr commented 8 years ago

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!

Kyran-C commented 8 years ago

Any chance the LP Pro is going to start getting some love again now that a major update to Circuit has been released?

dvhdr commented 8 years ago

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!

Kyran-C commented 8 years ago

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.

faroit commented 8 years ago

@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... 🙏

micahscopes commented 8 years ago

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 https://github.com/dvhdr/launchpad-pro/issues/6#issuecomment-239857215, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXylv00TpfB51aO0C6XEuTA5X17ATgJks5qgJiVgaJpZM4FjBOV .

kindlychung commented 8 years ago

I have bought a launchpad pro today but have to return it. It tires my fingers too quickly. Will check it out later.

kindlychung commented 8 years ago

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.

kindlychung commented 8 years ago

The cover should be made of transparent material, of course. I expect the cones will also have some interesting effects on the optics.

atriantafy commented 8 years ago

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?

micahscopes commented 8 years ago

@dvhdr @whibble any news here? I'm losin' faith :confused: 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

ShekkyVD69 commented 8 years ago

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.

Kyran-C commented 8 years ago

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.

malkomalko commented 7 years ago

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

duffcat commented 7 years ago

Yes please. This is the #1 issue with the LP Pros. Playability. Although better than Push I feel they can be even better.

duffcat commented 7 years ago

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?

kindlychung commented 7 years ago

If you have the money, get an linnstrument, way more playable than both push and LP pro.

JacobiusWrex commented 7 years ago

To whom it may concern

I think there may be (although a little complicated, and as of yet, untraveled territory) a workaround for the Launchpad pressure sensitivities. If you are not familiar with Bome MIDI Translator Pro I would immediately get familiar with it first of all. I imagine that you could pretty easily create a translator in Bome to rescale the values to something else more desireable/playable and then as long as you do it within 1 Preset it will work with the "free version" of their software which could be distributed to all the people getting ready to throw their Launchpad out of the window. The further down the rabbit hole you go with Bome, the better in my opinion, but I can see where this method would scare people away because it involves an additional software program and a virtual MIDI port. It would appear at all like an official fix by Novation and I imagine it might not be super easy to tweak, but hey if you're motivated you find a way... I am not affiliated with Bome or Novation at this time and am also no longer an owner of a Launchpad pro but I feel like I can see at least a band-aid for the problem for those desperate enough to take action.

http://www.bome.com/products/miditranslator

Thanks Jacobius Wrex

On Mon, Dec 26, 2016 at 6:16 AM, Kaiyin Zhong notifications@github.com wrote:

If you have the money, get an linnstrument http://www.rogerlinndesign.com/index.html, way more playable than both push and LP pro.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dvhdr/launchpad-pro/issues/6#issuecomment-269201469, or mute the thread https://github.com/notifications/unsubscribe-auth/ATTzvDH2JXaKDqwc0PLRRixweZROty6bks5rL6HwgaJpZM4FjBOV .

Kyran-C commented 7 years ago

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.

micahscopes commented 7 years ago

I think the main problem is that the pressure change needed for note off events is too small. For example, I don't mind needing to use a little velocity to turn a note on, but I absolutely don't want to have to hold that same pressure continuously just so that the note stays on. I'll catch a case of carpal tunnel after two performances (seriously).

It'd be nice if there was more sensitivity in the first place, but the lack of hysteresis is more glaring to me.

What's the hold up? Can we please get some low level access to the ADC?

On Dec 26, 2016 8:54 AM, "Kyran-C" notifications@github.com wrote:

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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dvhdr/launchpad-pro/issues/6#issuecomment-269217891, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXyluT55naY54UdY6bJAmSdWY-En2geks5rL9UggaJpZM4FjBOV .

dvhdr commented 7 years ago

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!

faroit commented 7 years ago

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.

micahscopes commented 7 years ago

Wow! Wonderful news! Thanks so much for following through with this!

On Jan 10, 2017 7:27 AM, "Dave Hodder" notifications@github.com wrote:

Well, whoops! I was planning to review raw-adc https://github.com/dvhdr/launchpad-pro/blob/raw-adc 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!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dvhdr/launchpad-pro/issues/6#issuecomment-271575058, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXylpyPiz1CNGVFmyTKmRFXGiublYgOks5rQ4c9gaJpZM4FjBOV .

skylarrcaverly commented 7 years ago

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!

faroit commented 7 years ago

@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.

jcurtis commented 7 years ago

Did you mean @jrcurtis

jrcurtis commented 7 years ago

Hello. I'll check this out today. Sounds cool.

mccrabney commented 7 years ago

@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.

http://www7a.biglobe.ne.jp/~mpc1000/128xl/padsens.htm

aedancullen commented 7 years ago

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.

ben-richardson commented 6 years ago

Hi all, just wondering if there was ever any advancement on this issue? Thanks!

faroit commented 6 years ago

@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... ;-)

ben-richardson commented 6 years ago

@faroit many thanks for the update!

@whibble anything further you are able do to help make this possible would be much appreciated.