Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Twitter

BASE II FSR pad sensitivity issue.

Hi to all the midi-maniacs.

I just bought a Base II, and I noticed that the fsr pads sensibility was too low, so I went to the online editor to change it to the "highest" ,but it seems that nothing changed. The pad still needs to be pushed really, and I mean, REALLY hard to get the midi note out.
It's very unplayable... any suggestions?



  • I see you've filled out a support ticket. Thank you. I'll follow up there!

  • Hi, I have the same issue. Is this just how the pads are?

  • Hello, I have the same problem here, have tried various combinations of high/low etc and tried using fixed note velocity but I still have to hit the pads quite hard for them to trigger.

  • Same issue here. Renders it kind of unusable for finger drumming.

    If you are just using it for casual clip launching, mushing down on the pad works, but the percussive sort of motion from playing beats barely registers regardless of what has been set in the livid editor.

    It almost seems like there is a tiny millisecond timer that the pad has to be held for or else a hit doesn't register. For example- hitting it very, very hard super quickly (redrawing my finger immediately) can register -no- note at all, but pressing my finger very gently and keeping it held down does.

    Does something like this "ignore super short inputs" exist as a sort of de-noiser on the inputs? Can this be fixed through firmware?
  • I'm curious about this too. The 'pad sensitivity' setting works as I suppose it was intended, mapping to different velocity curves/scaling nicely. But there is too high threshold before which any hit are registered.

    Hopefully it's addressable; once a hit is registered the pressure modulation seems agile, and I do recall the original BASE model being more responsive to play. It's just that initial hit threshold that makes finger drumming clunkier than it should be (even after years of playing an original Trigger Finger).

  • Hi Moon, thanks.

    I am using the latest firmware and have noticed this behavior across the different firmware versions since receiving my Base.

    I can record a video to demonstrate what I, and I believe all the others in this thread are describing.
  • Here is a video demonstrating the lack of response when quickly hitting even very hard but quick vs a soft touch that stays pressed down-

  • Hi hmbl, can you also check the actual MIDI data is being sent? I reset my Base to its defaults to get the pad highlighting as on your video. Visually it looks the same, with some fast hits not illuminating pads. But, irrespective of the pad lighting, every single MIDI note is getting sent correctly.

  • This exact problem, as described by hmbl, happens to me with a brand new Base II. I don't speak about leds blinking or not, but missed pad playing. This is simply unusable for me in a musical context... I contacted SCV in the UK who sold me this unit and they are ok to send me the last one new Base II they have in stock. But what will happen if I hit the same problem with it ? Do all the Base II owners notice that ?

  • Any word from Livid about this ?

  • Hello,

    I also have problems with the pads sensitivity. I am using the BaseII with the firmware 2.4.4. I tested the controller in Ableton Live and Bitwig and the problem is the same in both DAWs. For playing synth it is still kind of Ok but for finger drumming it gets really annoying because playing 16th notes with so much pressure is very tiresome and you just cannot be very precise if you cannot relax your finger while playing. In the internet I read a lot of positive reviews about the velocity but I totally cannot agree on this. Even my Akai LPD8 works better. What I also dont like is that you have to hit the pads in the very center to make them reliable. I tried resetting to default. Switching the different sensitivities in the Editor seems to have no effect at all somehow. Is there any new firmware coming up to fix these issues? It seems a lot of people here have the same problem!

    Cheers, Ulli
  • Thank you for the fast response. Happy to hear that you take these problems seriously and think about a solution. I really like this piece of hardware and would love to make it work properly.

  • The new unit I got from SCV is a little better in the sense that all the pads can send values from 0 to 127 but I must say that, like other users above, I'm quite disappointed with the playbility of that controller. That, with the unreliability of the scripts (I often get stuck and can't go back to Launch mode for example) makes this brand new device totally unusable for me...

  • Same here with the scripts for Bitwig. I know it must be a bit annoying to update all the scripts to the new API but it would be really nice if that happens at some time. The BaseII sends Polyphonic Aftertouch which is supported by Bitwig, but the script does not make use of it. Changing tracks is buggy and some other aspects of the script do not work any more. I send detailed videos to the support but so far the last update is 3 months ago and did not really fix the problems. I am barely using the controller right now and am only hesitating selling it because I would loose a bunch of money doing that…

    On the other hand I may loose even more if I wait too long as well. I would prefer to just have a working device.
  • edited November 2015

    Maybe have another look, quasimono, as I updated our github repo with some fixes exactly a month ago.  

  • Thanks for pointing that out but I meant the script you are referring to. It is still not working as expected with Bitwig 1.2. Selecting tracks does not work especially if there are some group tracks in the project.

    The step sequencer is broken as well and does not let you select the grid division anymore.
    Polyphonic aftertouch is not supported by the script. The current version of the scrips does not work properly.
  • I can confirm the problems with track selection.  I've opened a dialog with BW about this, they changed some things that don't make sense from my perspective.  I know what the problem is, but I won't have a solution until I'm able to speak with them, as the underlying problem affects several things at once and there isn't a simple fix.   Hopefully we have a solution soon.

    I can also confirm that the grid division selector is broken.  I'll have a look for solutions asap.

    Polyphonic Aftertouch:  That's a feature that wasn't present in the original script, so I wouldn't consider it a bug, it's a feature request.  I can't say if/when it will be implemented, but I will consider it while I'm working on the scripts to fix the aforementioned bugs.

    Please, if you find anything else, feel free to PM me.  I'll try to post something here once we have something new for you. (Or possibly in a new subject that isn't crossposting an unrelated makes it rather hard to dig these out when their orphaned like this).


  • OK no problem I will write you directly. The polyphonic aftertouch is indeed more of a feature request (I was pretty excited when i found out Bitwig finally implemented it). Another thing that bothered me with the existing script is that the automation write ON/OFF switch works for the arrangement rather than the clip launcher. Based on the whole work flow I think it would make more sense to use the launcher instead. Also in clip mode I think it is kind of unintuitive that you need to engage shift mode in order to stop playing clips. Why not just make them stop by hitting them again in the normal view?

    Cheers, Ulli
  • More than any script related issue, the pads trigger inconsistencies seem to be the real problem. Noticed this answer above : "The sensitivities do not adjust the bottom threshold, only the top, that is why the setting does not seem to have an impact in your case." So it seems to get the wider range of velocity values, we should set the lowest sensitivity setting ???

  • Well, that seems to me totally counter intuitive but the lowest sensitivity setting for the pads gave me the best results as far as the velocity range I can play. This is logical given the quote in my above post though...

  • Interesting, i gonna try that.

  • edited November 2015

    Done more tests. It seems the Base can lose settings for velocity sensitivity, at least it happened me once (hence the latest message I let on my other thread about the remote control scripts).
    I've also tested a ridiculously cheap (39€) korg nanopad and the playability is highly better : the nuances are far more precise and I can trig a pad with a very low velocity and be sure it will play, which has never been the case with the Base, no matter how I set it. I can't even be sure a clip will be launched.
    Which leads me to think there is definitively a hardware problem, not only a software one. I'm tired of losing time trying to make a + 400 € controller work correctly. Worst purchase ever for me.

  • And I've owned  (and still do) a wide range of gear...

  • I also think it is an inherent problem of the hardware. As long as this is not solved I would not recommend anyone buying it. I am using it as paperweight currently…

  • Any word from Livid ?

  • I just checked the Base II with the current 1.3.5 version of Bitwig and some of the bugs are gone pointing to problems of Bitwig Api. I will have to look further into it but the biggest problem, the buggy track selection is gone. However I got no response to my mails and did not hear anything about an update to the script. And the threshhold issue continues…

  • edited December 2015

    Thanks for the report. Can you summarize the script bugs that you're still experiencing?  I know of a few feature omissions (crossfader in Ohm, no group support), but I'm not aware of any bugs currently.

    1. When I tried the script the last time the sequencer of the drum machine still did not work (maybe due to the arbitrary changing of Bitwigs API form "DrumMachine" to "Drmmachine"?). This is what happens when you select the sequencer in drum mode:
    One cannot select a quantization value or switch triplet mode on/off, also there is no playhead marker visible.
    However, the instruments step sequencer is fine.

    2. Somehow the touch button#2 in mode#2 is back to device enable instead of automation write. The last time this was fixed by you it was also set to global automation instead of clipautomation. For the whole work flow it would make more sense to use that button for clip automation like the overdub button. I changed this now myself in the script by following the description of changes published in the previous github version. This works but for some reasons the LED does not get switched on which is weird because the code follows exactly the same syntax as the overdub in which the LED works as expected:

    this._overdub = new ToggledParameter('overdub_listener', {javaObj:transport, action:'toggleLauncherOverdub', monitor:'addLauncherOverdubObserver', onValue:colors.RED});

    this._autowrite = new ToggledParameter('autowrite_listener', {javaObj:transport, action:'toggleWriteArrangerAutomation', monitor:'addAutomationWriteModeObserver', onValue:colors.RED});

    this._clipautowrite = new ToggledParameter('clipautowrite_listener', {javaObj:transport, action:'toggleWriteClipLauncherAutomation', monitor:'addAutomationWriteModeObserver', onValue:colors.RED});
    That is more or less it. Although of course there is still the feature request for support of polyphonic aftertouch. Since this is a pretty cool feature it would be a pity not to make use of is especially since the Base cannot send "normal" aftertouch meaning there is no aftertouch at all currently which is pretty weak nowadays…
  • Just realised that I was wrong about the touch button thing. It IS set to autowrite not to device enable. But it should be set to clipautowrite and the problem with the status LED not working is present in both settings.

    I just got informed that there is a new version of the script where the broken master fader is fixed, cool :-)
    Could you verify the bugs with the step sequencer? I just tried the newest version of the script and still do not get the step sequencer running properly in the drum machine mode.

    Happy to hear that a new firmware is on it's way btw! Thank you for your efforts!
  • Ok, I'm very close to spending some time with the Bitwig scripts, so your report is timely and I'll definitely check these out.  Thanks :)


Sign In or Register to comment.