Hi gvfarns, like I said I am not too electronics-savvy, but here is a link to the Pianoteq news/updates:

http://www.pianoteq.com/pianoteq3_changes

Look under version 3.6.6

Unless I am misreading this, it looks like if you have a Vax77 or the 'fabled DIY keyboard with similar sensors'(haha), you will be able to utilize the extra resolution inside these piano programs.

As I understand it, the MIDI standard is 7 bit 0-127 for velocity like dewster stated before. I don't know how the software developers magically tap into the unused higher resolution values, while still sending standard MIDI data (if you don't have a Vax77), but like you said - it would be great if everything worked this way, or MIDI upped their standards.

I don't understand. How does HD MIDI help in this area?

8 bit JPEG?

Hall-effect devices measure magnetic field strength, and are fairly linear in this regard. But the field strength of a magnet is inversely proportional to the square of the distance. So a magnet embedded in the key interacting with the sensor will tell you non-linear position, and you will have to linearize these readings before using them to calculate energy. Software can do this, as can dedicated hardware in an FPGA. The linearized positional info can be used directly for damping.

If you know how much energy it takes to accelerate (change the velocity) of your key (something you can calculate based on the mass of the key, the distribution of the mass, and the spring force) then you can take the instantaneous positional information from the sensor and through further calculation find the energy being imparted to the key. Integrating (summing) this over time gives the work done on the key to move it.

An alternative to Hall-effect sensors and magnets might be infra-red LEDs. If you can shield them well enough from ambient light, it's pretty easy to use LEDs as both emitter and detector - you would need two LEDs per key. If you modulate the emitter and measure both lit and dark at the detector you might be able to tolerate a fair amount ambient light.

Yes, and it appears that the VAX actually does something along these lines. Quote from http://www.infiniteresponse.com/expr.html :


Unforunately though, the VAX doesn't feel much like a real piano.

Greg.

Velocity curves on the software side are a mapping from 1-127 into a function that is not those values, so it necessarily causes some rarification in areas where a few values are mapped into a larger number of values.

It's not as serious as the problem with the jpegs (which are all 8 bits per channel). If you edit a jpeg and adjust the colors, then save, then open it, make changes, open, make changes, etc., the quality goes down and you start to see the levels of the colors. Irrecoverable information loss. Not such a problem with higher color resolution formats.

There are other people who can explain both phenomena better than I can, but that's the general idea.

I believe the degradation in quality experienced with repeated saving of JPEGs is due to lossy compression, not colour depth.

Cheers,
James
x

Both cause problems (completely different ones).

The lossy compression issue causes characteristic jpeg artifacts (blocks, a certain kind of noise, etc) similar to the look if the compression was set to very aggressive.

The bit depth thing causes a different problem where relatively large areas have the exact same color, similar to the way it would look if you had downgraded it to a 256 color image or something. They call this posterization. It happens on lossless files as well if the bit depth is not high enough and the file is edited.

Actually I guess it always happens when you do certain types of edits (adjusting the white balance, for example) but with a large number of colors in a deeper palette to choose from, it's not typically visible.

The latter effect is the visual equivalent of what happens with MIDI when it is remapped. Not a problem if you start with thousands of MIDI levels.

Funny how a topic of discussion can shift from installing an optical sensor into a grand piano action, to visual artifacts in compression of digital photos :P

I'm afraid I still don't follow how this relates to JPEG compression.
I skimmed through the Wikipedia entry about JPEG to refresh my knowledge, but could not find any mention of posterisation or colour banding.

Are you perhaps comparing JPG to RAW (12/14/16-bit per channel)? Or possibly moving in the other direction and comparing to GIF (8-bit colour, 256 indexed values)?

Apologies to everyone else for the off-topic - gvfarns, you can PM if preferable.

Cheers,
James
x

It doesn't. Compression is a separate issue. The JPEG standard happens to be limited to 8 bits per channel, which is the part that's similar to MIDI. When you have that many or fewer colors to choose from, image enhancements start to cause posterization. It happens with all formats with low bit depth, but JPEG is the most common case.

Modifying the MIDI touch response curve is similar to adjusting the color balance or something in an image, and can lead to the MIDI equivalent of posterization.

The phenomenon is not mentioned on the wikipedia page because it's not actually JPEG specific. Photography forums or photoshop forums are the place to look, where they discuss bit depth issues associated with editing. I first ran into this while discussing the gimp. The gimp can only do 8 bit color (and has for years), which causes many people to say it's not the right software to use for image enhancement. For that reason, people who edit photos seriously start with high bit depth images when they can, and edit them in photoshop.

Notice that RAW files contain more information than can be displayed in any single image, but that's a separate issue as well. Even if you first render the RAW to an image, and then take that image into an editor and tweak it like crazy, you want the image to be a higher color depth than JPEG allows or the editing will start to make it look bad.

Okay, I see where you're coming from now.

So this is really a discussion about the limitations of using 8-bits per channel when performing image manipulation.

Cheers,
James
x