I have found this same thing independently. No suprise to find a thread already dedicated to this absolute game ending issue. I also gather from this thread this has been a know issue for some time and the developers have yet to address it. It’s really not looking good for the good guys around here. Guess I got my answer about what’s going on, suppose I’m just here to shout down a long dead hallway. “WTF!”
I suppose we all just jumped on the sensel bandwagon too soon. Tally Ho fellow lab rats.
@Matt_from_Sensel Velocity must be 0-127. This is taking too long, what’s going on? You will lose your customers and faith this way. This is really not acceptable anymore.
This is a major issue with your product. I have found the drum pad basically unusable with sticks. At low sensitivity with sticks it’s at 100+ velocity even with a light touch, at high sensitivity it works for hard strikes but anythis soft doesn’t even register. On any setting on any pad I have barely ever been able to play a note with less than a 30 as the velocity and you have to really try to get that, not really possible in a normal playing environment. Without sensitivity curve this product is not what it is presented as. Not flexible or morphable but a constant headache to get to preform in an expressive way. This was not expected or stated by your company. Many controllers have met this standard and have velocity curves, time for you to step up!
No one from sensel has even commented on this thread since July and that was a brush off. Did you hire anyone yet? Can we expect anything to change in the next year or so? This is a very important issue that makes the difference if many of us will continue with your product or not.
Hey @Humdrum and @Just_Pierre,
Yes, we were able to bring on part-time support last month and are currently working on an update. The velocity curve issue will not immediately be addressed since it requires us changing the algorithm, and we need to knock out some quick fixes first.
We are discussing other ways that we could potentially address this issue in the upcoming update and will keep you posted.
I know these kinds of answers are frustrating, especially given the amount of time that has gone by. The fact is, the Morph team at Sensel is like a startup within a startup, and even with the recent hire we have limited technical resources/bandwidth right now. This issue and some of the others that have come up are VERY much on our minds. We want them to be fixed as much as you do. Please don’t mistake the lack of updates of caring. Logistically, we just haven’t been able to address it yet.
We still very much appreciate you following up about it regularly. It’s very helpful for us to know how important this is to you. I completely understand your frustration and apologize that it hasn’t been addressed yet.
Thanks,
Matt
Thank you for your response. I was out in the studio all night working on my set up and trying to figure out where the morph fits. It doesn’t fit. Of all my gear Im down to only really being able to use it with my dsi tempest, and since the drum pads don’t play for ■■■■, it’s really not that fun to play the Tempest either. The pads on my tempest are WAY nicer, I just wanted to be able to play with sticks. I have tried playing with sticks on the drum pad at every threshold level but It either feels unnatural and flat or doesn’t play all the strikes. The keys are just as bad as it either flat full velocity at high sensitivity or I have the to hit the thing so hard it hurts my fingers at low velocity. Setting the velocity in the middle does just that and I can’t play less than 30 or more than 90 on most middle settings, all this effects aftertouch as well which becomes its own issue. The other device I was hoping to play was my op-1. After the major let downs with the connectivity issues it turns out that the keys on the Morph are only marginally better to play than the ones on my op-1(which are horrible).
So yes. You have some work to do. Really disappointed this isn’t in the plans for your next update. What is more important than this issue? Maybe figuring out a bundle with Retro Kits so they can fix your connectivity issues?
You response is helpful however in letting me know this product is still in the beta testing stages and should not have been brought to market in this form. While I may sell my morph I would need to be on the level with the buyer and help them understand where the product is in development. Not really wishing to pass the problems to the next creator. So it looks like I’ve got a 300$ paper weight. Truely, shame on you for wasting others time and money. Artists struggle enough without being tricked out of thier money by faulty products. I will be advising anyone I can to join this forum before buying a Morph. I understand you need sales to fund R/D, however this cannot come at the price of fleecing artist for what little money they have.
I’m sorry this has been your experience with the Morph. It’s certainly not perfect and we try to be transparent about that. We’re grateful that so many others have gotten value out of it and are doing incredibly creative things.
For customer’s who are dissatisfied, the Morph is backed up by a 30-day free return period - no questions asked. You can learn more about that policy here: https://sensel.com/pages/return-policy
Thanks,
Matt
Will you also refund shipping and customs duties? These added about 1/3 more to my costs than the retail price.
We refund the taxes if they were charged at check out. We do not refund shipping costs, but if your order was over $75 there should not be any.
Best,
Matt
My shipping costs were 130% of the item’s cost on one order, and 18% of the item’s costs on another order.
So you’re saying that you do not refund customs duties, you do not refund shipping charges, and you do not refund return shipping charges—right? The return you suggest is cold comfort and comes of more as emotional management and PR, which is far less welcome than any of the device’s shortcomings because it makes it seems as if the company has in fact given up on this issue.
I understand that the MIDI resolution and total zone area have to be managed so that the device will produce a satisfactory response. So if it must be limited to 96 MIDI velocities, you could mitigate the problem by spreading those 96 velocities out in various ways, with the current lopping off of the entire bottom range just one of several options. In other words, a few optional velocity curves even if you can’t provide the user a way to customize the entire velocity response.
I’d need to look at your specific case, so please email support@sensel.com if you want a detailed answer. We do refund taxes which could cover the customs duties you’re describing. Again, I’d need to see your order, where you had it shipped to, etc.
As I stated in my previous response, we very much have NOT given up on this issue. A fix will be coming. We’re having active discussions about it. I just can’t give a solid time estimate right now, which I understand is frustrating.
Thanks for the suggestion. Sharing it with the team now.
Thank you for these responses. I believe you when you say these issues are important to the sensel team. I look forward to the future of this product or whichever new device that utilizes this tech to proper effect. I realize that firmware is a huge part of the development so I will keep it on the shelf(as I am well past any 30 day warrenty). I look forward to the day that I check back in on this forum To find a vibrant community of creators sharing ideas about a vital product. Till then, good luck, I truely wish you the best, for both our sakes.
Always the same quotes, week after week, month after month, year after year. Matt, I do appreciate your replies but nobody can take this serious anymore. There are so many issues.
I really regret buying the Morph. It has so much potential but I still regret buying it. I own it now for 7 weeks, so return it is no option? Or is it?
Messaged you directly, @Just_Pierre.
Hello…Did you attempt to lessen the under-unwinding elements of speed and weight?
In the seggregated solver choices, you can discover “Speed Corrections: Acceptable Velocity Increase Rate”. possibly decrease this rate as well, so as to dodge huge speed greatness hops.
I don’t remember a technique to collaborate with the weight field legitimately.
Hi Matt,
A important question before I (maybe?) will return the Morph. Can I change the Midi channel on the fly while using a overlay?
Kind regards,
Peter Bode
It seems to me that it might be helpful for us to try to better understand what this device really is so that we can perhaps accept the limitations where we must and use it for its strengths if they serve our interests. Really, it is a pretty incredible tool in many ways. But I think we are expecting it to do all things well (that is how it is marketed, after all), and this inevitably leads some of us to disappointment.
I am wondering if it might be problematic to nicely handle velocity, especially low velocity, on these devices. The way velocity is sensed here is different from the way it is sensed in something like a keyboard. In a keyboard, there are two switches, one of which gets triggered before the other as the key comes down. The time difference between activations of these simple on/off switches is used to compute velocity.
Take the following with a grain of salt. I am just speculating based on limited information and understanding.
In the case of the morph, if I understand it correctly, it is an array of tiny pressure sensors and that is all. So the only information you are gathering is the amount of pressure at each sensor at a given time. In order to compute velocity, you have to measure pressure at different times, very quickly, and calculate the rate of change of pressure. So, in order to measure a velocity accurately, you have to measure at least two different pressures within the overall range of pressure that each sensor can register.
I am guessing here, but it seems to me that in order to register a touch, you are looking for a pressure reading above a certain threshold first. Then, you look for a higher reading on another scan. Once you have those two readings, you can calculate the rate of change.
But it probably isn’t quite that simple, since you are looking for the touch of something like a fingertip that spans a number of sensors. And the activation area is spreading as you increase pressure, so more and more sensors become part of the touch. The pressure readings from all the individual sensors must be processed to decide what counts as a single finger touch, what is likely to be multiple touches, and so on. And it probably requires some waiting to see what happens with a number of sensors in order to determine that a single finger touch has been made. If it were a matter only of comparing successive scans of one sensor, it would be simpler, I’m sure.
I find myself imagining that it shouldn’t be that hard to measure a low velocity, as all that seemingly amounts to is a small increase of pressure between successive scans. But there might be real-world issues like noise that have to be dealt with. You might have to reject very small changes because of the magnitude of the noise present. And there are different sensitivities between neighboring sensors since manufacturing is not perfectly consistent. Differences in the circuitry for reading each sensor could be an issue too.
There is probably a lot that has to be done here to reject errors as much as possible, and that might raise the measurable velocity threshold to a point well above the minimum detectable pressure. They could probably lower the threshold, but it might be that other undesired behaviors, like false touches and releases, tend to emerge below a certain point.
This is all very different from the pair of simple on/off switches in a keyboard. There, noise isn’t an issue since you aren’t measuring a range of values. On each scan, it is simply a matter of checking to see whether each switch is on or not.
I would suggest that we shouldn’t hold our breath on this. It might not be possible to deliver accurate low velocities with hardware of this design. I am thinking that Sensel is hesitant to admit any such limitations because in order to survive as a business, they need to market this device as a “does everything” device in order to reach a market of sufficient size.
Perhaps we have some limitations. What are the strengths? Well, we have an array of 20,000 pressure sensors to play with, along with some rather impressive software to work with information from those sensors. Getting that for a couple hundred dollars is pretty impressive! This beats the hell out of an Expressive E Touché, for instance, and is cheaper.
I discovered that I can’t play delicate passages with an acoustic guitar library on this device, while I can using my Komplete Kontrol S61. But, using the morph, I can use pressure instead of velocity in a synth to control something like gain or filter cutoff, which gives me expressive control far superior to the channel pressure aftertouch on my S61. I can make different notes swell in and decay as I wish, by feel, in the moment, not being limited by a stupid ADSR envelope. I hate ADSR envelopes! They make things sound so robotic and overly consistent, which tires the ear and is so unlike the rich variation in a real acoustic instrument.
The morph is also great for such things as XYZ pads to control various parameters with pressure and horizontal and vertical position. There, you don’t need velocity. Touch location and pressure is what the morph is really sensing. Use that! And the ability to design your own controller layouts here is unlike anything else available.
Different tools for different purposes! It seems this isn’t the best device for delicate velocity sensing. It probably isn’t the best device for fine percussion control. To crudely sketch out some ideas rhythmically though, which will be edited to perfection in post, or to trigger simple samples, it works fine. Is it like playing a real hand drum? Not even close. Maybe someday, with technology improvements, we will get a sensor array that can get close to that. In order to get there though, we probably need to support the developers that are innovating in that direction.
Just food for thought! I could be totally wrong about the limitations here! With better software, it might be possible to improve velocity detection. I certainly don’t know!
The problem isnt the devices limitations, but the marketing around it being an all encompasing controller. The ,marketing clearly stated that its a good drum pad, they even created a drum pad template, and it works for ■■■■. I think we have all had to take a step back with this device and figure out what it is actually for and how it MIGHT fit in our scene. Its just a shame one has to buy it before one can relize what it is.
I too have only found it useful as something to audition sounds on software and to create idiosyncratic sound controls. They may work for one thing. Ut id i want to control another sound its back to the drawing board, spending hours creating a template that works in an interesting and useful way. A FAR cry from what was advertised.
Man, Humdrum, I feel I have to agree with you here, and it is aggravating. I bought the morph around a good year ago, got the music production overlay bundle. I’d only really toyed with on occasion until very recently, and using it for drumming is really the 1st major thing I started to try. The velocity scaling just sticks right out. I’m attempting to use it for Superior Drummer 3, hosted by Bitwig.
SD3 has some good midi velocity custom curve making tools, but I don’t know if they’re good enough - tho it might be my own skill deficiency that’s lacking - to smooth out what’s going on with the current state of the morph.
Unaltered, my incoming midi from the morph was in the low to mid 40’s. I was able to remap it to consistently get triggering values in the 1-9 range, but there still seemed to be too many occasional outliers in the teens and low 20’s range. To get this, I had to significantly reduce the horizontal length of the velocity curve graphic in SD3’s tool for curve adjustment. That would seem to squash the range sensitivity - I still have full 0-127 range triggering the drum samples, but it is difficult to consistently control the output velocities values within consistent dynamical musical ranges. Hopefully I said that clearly. It seems too difficult to control with usable musical dynamics. Too jumpy in controlling dynamics.
The Morph has such a range of raw sensitivity, it seems to me like it is a simple scaling problem within the midi part of what I assume would be the Morph’s firmware. Looking at how the visualizer responds the sensors seem smooth - tho that is with direct continuous pressure, and not drumming type interaction. Maybe the sensors have a consistency problem responding to quick hits?
But anyway - it’s definitely seeming too buggy for drumming. Definitely NOT how it was advertised concerning this use.
Wondering if it can be addressed in the API by someone with programming experience? Yargh.
The new firmware, using threshold = 10, offers quite an improvement. It’s easy to get a full spectrum of velocities below 40, but it looks like that’s at the expense of finer resolutions of the higher velocities. For example, I get no velocities from 79-87, 92-97, 99-103, then just 115, 120, and 127. As a trade-off on my particular instrument of choice (percussion controller for BFD and TD-50) it’s a definite improvement. I’m thinking smooth, full-spectrum response might not be possible due to processor limitations, but at least now it’s something I can use. I’m still testing.
Just here to say that I also really miss velocity curves…