Suggestions welcome #2
Replies: 5 comments 13 replies
-
|
Do you plan to support extended velocities? I know it's a controversial topic and many people think it's just a gimmick, and even a few people I respect say that 7 bits are more than enough to get all the velocity levels you need. I don't have enough experience to confirm or disprove this claim. But even it it is correct, more velocities can be a good choice to future-proof the project and most importantly to ease the calibration: with only 127 levels one must be careful on where to set the minimum, maximum and perhaps intermediate values (probably linearly, but are we sure?). With 16-bit velocities one can get away with more "sloppy" adjustments and not lose resolution. Anyway, this is just a thought and a question about what you are planning, not really a suggestion... |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I think I'll put in support. I doubt the additional velocities are valuable with a keyboard, but it can't hurt. They're largely orthogonal to calibration, though. My procedure outline isn't complete ( https://github.com/jkominek/piano-conversion/wiki/Calibration-Procedure ), but I plan on the device presenting itself as both a USB MIDI and USB serial port, with calibration occurring over the serial port. The host PC will get a very high data rate stream of ADC readings via the serial port, and determine that the MIDI velocity will be some function of the time between readings X and Y. Those values go back to the individual ADC boards, and when they detect X and Y have been crossed, they'll send that amount of time to the main board. (If the ~0.1ms time resolution isn't enough, they'll be able to use the ADC readings and perform interpolation to get a bit more time resolution.) The main board will do whatever it needs, and send out a MIDI velocity. That final step on the main board will probably produce >7 bits (with some missing codewords), so sending them along will just be a matter of producing the appropriate MIDI message(s). |
Beta Was this translation helpful? Give feedback.
-
|
People want higher velocity responses. And yet, I almost never see any concrete measurements regarding velocity response consistency. There is a thread on the pianoworld forums about the VPC-1 and one commenter shows that the velocity responses are all over the place. You could reduce velocity to 32 levels for the VPC-1 and people would most likely not recognize any difference. We all assume optical sensors are good for this type of business. But are they? I haven't seen any measurements from optical sensor solutions. Before going the expensive optical route, I suggest verifying that this is actually sensible in any regard. Or do I miss something? Currently thinking about building some form of mechanism to measure response velocity curves (Teensy MIDI input vs speed signals from a rotating mechanism triggering the key presses - or you just use the speed at which MIDI events are coming in). What if we just need a proper calibration mechanism that's easy to use in order to have a more proper response from the rubber contact solutions out there? Hell, you could just put rubber contacts on your self-crafted silencing bar, and let the hammers hit the rubber instead. Don't take this as offense, please :). I'm trying to get a properly behaving MIDI controller (one which I will be able to repair and calibrate in 30 years still) and am thinking about this optics business, too. But the more I think about the calibration, the more I think that calibrating a MP11 SE could be much wiser. (I know, you have a different goal) |
Beta Was this translation helpful? Give feedback.
-
I'm interpreting that as "people want more bits of velocity data", to which I can only say "people want all sorts of weird things".
I think you could reduce every MIDI keyboard to 32 levels of velocity and few people would notice a difference.
I'm not assuming that, nor is their "goodness" relevant. On the basis of CyberGene's Cybrid, I know that they satisfy the engineering requirements. That is all.
Measurements of what, exactly? The data sheet for the CNY70 has got measurements. I've played with one and watched it on my oscilloscope. stemPianist on the forum has some video of his scope measuring the sensor, and it looks like what I'd expect to see. http://forum.pianoworld.com/ubbthreads.php/topics/3061851/re-cybrid-cybergenes-hybrid-midi-controller-is-open-source.html#Post3061851
It isn't clear to me that the total cost of 88 or ~176 optical sensors significantly exceeds that of a solution containing 176 or ~352 mechanical switches. The switches will be subject to repeated, sudden mechanical force, which complicates their mounting, physical alignment, etc. The optical sensors are non-contact, so their mounting is simplified.
I'm trying to design something which can be installed easily into arbitrary already existing pianos with existing mechanics. I'm not trying to design the electronics for a single mass production item. I will not consider this project successful unless there is an automated calibration routine which is either insensitive to sensor positioning, or can at least tell you "sensor is too close / too far, move it slightly". I don't see how that can possibly be accomplished with pairs of mechanical switches; they provide significantly less data than a sensor which can produce continuous measurements.
A MIDI controller or VST's "velocity curve" is, IMO, a distinct issue from measuring the velocities of single keys. You can apply any curve you like to a properly function controller, and I fully expect users to do so. I don't think there's necessarily a "right" curve.
Probably anything is wiser than trying to do this from scratch. :)
Though if you want something you can keep working for 30 years, an off the shelf keyboard probably isn't it. |
Beta Was this translation helpful? Give feedback.
-
Actual, final MIDI velocity response curves (MIDI note on/off velocity vs physical key press speed, compared across all keys).
Me neither. I want consistency across keys.
Yes. And that's the main reason I like projects like yours: being able to repair and replace stuff. But not unless I'm certain that the technical end result will be on par. |
Beta Was this translation helpful? Give feedback.
-
|
Another point: putting one sensor below the key and one sensor at the hammer might be sub-optimal. Just think about it: there is no way to properly relate the CNY70 sensor output to any actual distance. I don't even know how I'd calibrate that. Maybe take some shortcut by defining "virtual sensors" at min+10% and max-10% intensities after putting the voltages through some averaging filter. But will that provide any consistency across different keys? Probably enough so that noone really cares. But IMHO it somewhat defies the optical ansatz. Most producers seem to use optical sensors in a binary way to measure time difference - a more complicated version of the rubber contact solution. Using both sensors in that way on the hammer head would be something I'd prefer. If one does it correctly, it's also always clear in which direction the hammer is going. There is also potentially another issue with this sort (see also "Cybrid") of continuous sensor solution: vibrations and distortions from playing. |
Beta Was this translation helpful? Give feedback.
-
Well, if you really wanted to calibrate that, you'd get calipers and hold the key/hammer at a known distance, and take the reading. I don't think that's necessary though.
The Cybrid design has manually tuned (with tiny little potentiometers!) "virtual sensors" and measures the time between the two being tripped. It doesn't even have any smoothing! It's my intention to duplicate that, but in software. And I'll probably add a simple low pass filter, for starters. The somewhat vague calibration procedure document has a few details along these lines.
I think you're hand waving over the complexities of the mechanical switches, which I've alluded to above (mounting), or on the Pianoworld post (switch debounce is a fucking pain in the ass).
To the extent that mechanical motion of the action moves the sensors around, switches could also have that problem. It is easier to low pass filter a continuous signal than the discrete changes of a switch being depressed. In general, I think you're comparing realized (or mostly realized) optical solutions to under-specified, unclear mechanical switch solutions, and declaring the switch to be free of perceived problems in the optical solution, while leaving unaddressed problems that a mechanical switch solution would have to address. And to make a constructive suggestion: if you wanted to use mechanical switches much of what I've designed and will write will still be applicable to you. You'd just need to design/fabricate alternative sensor boards, and replace the ADC boards with ones that maintained the same interface/protocol to the main board, but instead take timings off of the pairs of switches being depressed. I think I'd be willing to make/support any variations necessary to the main board's firmware. |
Beta Was this translation helpful? Give feedback.
-
Switch debounce? Can't find much about that in relation to DPs.
Haha, ty a lot, but I like to play around with such stuff, too. Setting up that many processors and making them communicate with each other must be fun. What I'd prefer much more, that is a somewhat technical measurement of velocity precision, how stable calibration is with regards to consistency across keys, minimum and maximum levels etc. |
Beta Was this translation helpful? Give feedback.
-
The engineers at Roland, Kawai, etc have already done the work to make it not a problem. But it is on the list of things you have to deal with if you want to make DP yourself and use mechanical switches.
There'd be plenty of work to do in the ADC board replacement. I'm not making that. :)
Once I've got electronics installed in an action/piano, I'll have a lot more information (including raw sensor recordings) and will be happily posting it. |
Beta Was this translation helpful? Give feedback.
-
|
That'd be superb. |
Beta Was this translation helpful? Give feedback.
-
|
@jkominek I totally agree with you. My only comment/addition is about the reduce "MIDI keyboard to 32 levels". I briefly mentioned this to you already in another issue, but let me elaborate on it here. I think that 32 levels are not enough for nice, smooth and gradual crescendos/decrescendos, but it would be ok as number of levels for casual play, provided that you have enough "headroom" to place the lowest and highest level to the "right" amount (and then with a curve in between, which as you said should be no problem). For example, on my NU1 I find that getting a velocity more than 80 is almost impossible in normal play, even with ff (on the other hand, velocities of single digit are easy for pp). So that is almost a 40% loss of number of levels. Still the total number of usable levels becomes around 80, that is still sufficient, so this is not a problem. On the other hand, should a 40% loss of number of level occur on a 32-level Hence my "nudge" to you (which I wrote to you earlier but did not elaborate much) to use as many levels as practically possible, and making them "wide" enough to make sure the slowest and fastest velocities the system is able to easily detect are as much slow and fast as possible. Even though these speed will be well out of the range of the pianistically useful ones. Being the system targeted at "random" action, that is a nice feature to have and to be able to calibrate electronically rather than mechanically. From what you said in that other conversation I think we are on the same page with this, but wanted it to be clear also here in case others read this issue and wonder... |
Beta Was this translation helpful? Give feedback.
-
|
This project looks fantastic. I have an old action from a Pleyel that I would love to turn digital. |
Beta Was this translation helpful? Give feedback.
-
|
Electrically, it was designed to allow that. You can put between 88 and 176 sensors wherever you please. That board will have plenty of storage space for various extra modes and such, so it will just be a matter of writing the firmware. I'm working on a first version of the note on/note off routines right now, and... it must be possible to do with just the keys, as pianodisc and some other pianos manage it, but the signal may be trickier to work with. I'll think about the key-only case when everything else works; (as I would like to believe that) it should be easier when I can collect a bunch of data from working key/hammer interactions. As a general note, sensor positioning on the key sticks might be trickier than the hammers. They've got less travel, so your sensors have to be closer, and they've got more surface area, so they reflect a bit more. I'm seeing higher "dark" signals from the key sensors than the hammers. |
Beta Was this translation helpful? Give feedback.
-
Using designs from an open source project like this results in the potential for modifying firmware and customization. I had actually got as far as ordering some parts and starting on some code for a simple hammer simulation (arduino + CNY70), but I'm a complete beginner when it comes to electronics so designing a set up for 88 keys looked to be a long road for me. My use case for something like piano scan is this: I'm working on a CNC routed / 3d printed set of key sticks that are 7/8 width of the usual octave. I plan on putting a weight where the capstan would sit. There wouldn't be the same leverage/inertia provided by the hammer mechanism, and I have no idea what it would feel like to play, but perhaps it could still be an expressive enough instrument. The non standard width rules out pianoscan, I'm not sure about pianodisc (but even if it did work with non standard widths, I would still opt for a diy/open source solution). I saw this, where someone had set up a CNY70 on a key and a simple physics simulation to model hammers, producing midi: |
Beta Was this translation helpful? Give feedback.
-
Interesting, Davide and I had discussed the possibility of making / buying entire key frames / actions / etc. I think we'd reached a consensus that at least if you want a full size mechanism, the most reasonable thing to do is pull from a donor piano. But if you want a 7/8ths, and don't mind the lack of mechanics, things become simpler, cheaper, and harder to find elsewhere. I'd be very interested in hearing/seeing more as your work progresses. I'd very much like to see complete DIY/open source keyboards/pianos produced, which don't involve parts sourced from the existing piano industry, but as it stands I think I'm going to limit my scope to the electronics. You'll have an easier time positioning sensors on something like that, as you won't have a back check (or anything else) in your way. With some clever design and positioning (and appropriate firmware), you might be able to mimic the force-sensitivity of a Clavichord by sending MIDI after touch. I was going to say that I doubted there was a clavichord VST that would implement that, but apparently Pianoteq's does. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, quite interesting. This makes complete sense then. As Jay said, I am interested in a smaller keyboard too, but not so much to build everything from scratch, and I do want hammer sensors for a variety of reasons. Probably too long and too OT for this context but as Jay mentioned I've researched quite a bit the topic of building the keys. In short, it's not as easy as it seems. In fact, you can buy a keyboard and a keyframe from a variety of sources (all hard to find, but they are out there) and it cost thousands and thousands of $$$. You can find some information in this great book (just a little on the website, but quite a lot on the excellent print edition). I recommend that you purchase or 3D print yourself one model to test the fit with your hand. I've done it and I've found it that the space between sharps is uncomfortable so I still have to decide if I want to try that route more seriously. If you do decide to do this smaller keyboard, let me know because if we make more than one it will be cheaper to CNC. I ruled out 3D printing because plastics are too heavy, unless we can make a honeycomb pattern which is stiff and light enough -- but I have not the time and patience to do that. Enough for an OT, feel free to continue via email (my address is like my github username but with gmail). |
Beta Was this translation helpful? Give feedback.
-
Yes that is something I would like to see too. Especially for alternative key sizes, which aren't readily available (especially not in New Zealand, where I'm located). If the key sticks work, then I was planning on releasing designs open source. My hope is that although they might noticeably miss some traits of a piano action it would still be a very playable instrument, more playable than digital pianos with short pivot and repetition issues. And customizable in other aspects, like key dip and key weight. A company in the Netherlands is developing a digital piano with customized key sizes, I've emailed them about the action and they are using the same approach - key sticks with counter weights, and a software simulated piano action. That they would use this approach gives me hope that it is possible to make a playable instrument using it. They said they are using hall effect sensors, as they are more accurate for the short distances the key sticks move. See here:
I've been thinking a lot about this same issue. To maximize the space between the sharps I'm keeping the black keys very narrow, and with quite a steep angle. Yes I'll send you an email. |
Beta Was this translation helpful? Give feedback.
-
I'm open to suggestions and feature requests. Here's probably as good a spot as any for them.
Beta Was this translation helpful? Give feedback.
All reactions