NORD STAGE 4 officially announced for February 16th 2023

[Hlaalu]

My issue/concern is in incorrectly talking about Triple Sensors and MIDI as if they are connected and that somehow there is some Triple Sensor MIDI implementation or standard which there is not.

I am aware of only one user in this thread who perhaps, I'll grant you, didn't word his thought in the most accurate way, as to imply what you describe above, namely that there is some "triple sensor MIDI standard". Yet I think we all agree that that was poor wording for the following concept:

The problem you are discussing is specifically a MIDI implementation problem and one that maybe/probably should be addressed, but its a general MIDI issue.

...which is the question that, once agreed about all the rest (as I think we have) we can finally talk about.

Multiple "Note On" or lack of "Note Off" is not a new problem and has been around for a long time.

You said it: it has been a "problem" precisely because the generation of multiple note-on messages has always been an unintended and often unwanted consequence of some MIDI loops or other configurations that people have set up to achieve some other goal, not "in order to" have multiple note-on messages per se.

You say: "a triple sensor keybed doesn't have anything to do with multiple MIDI note-on messages". I get it, we agree on this. Yet, it's obvious to everyone that at some point, someone will have to make a decision as to how to make this piece of information (note retriggering, for example, or multicontact for organ) travel over MIDI, and it's highly likely that that will involve multiple note-on messages. So what to do with them in MIDI language? The alternative is to totally lose this piece of information in MIDI, sort of "lost in translation".

All of problems listed below are related to MIDI implementations having problems with MIDI data streams that are somehow missing a "Note Off" command, which conversely means they are getting multiple "Note On" or a single "Note On" followed by a string of "Note" data, or in some cases just receiving MIDI data faster than they can process.

Were those quotes from this forum? Anyway once again: it has been a problem, and what better time than now, with triple sensor keybeds being more and more implemented, to come up with a way to codify it?

You're viewing the world from a narrow perspective.

Not that I want to start an argument over manners, but I guess you meant I am viewing MIDI from a narrow perspective.

[Hlaalu]

With the triple sensor keybed otoh you must generate multiple Note ON, if you want to render in terms of MIDI what's happening mechanically (this is the relationship) or maybe you are suggesting a different way we are not getting?

I guess he means that multiple note-on messages is not necessarily the way of translating into MIDI language what happens mechanically (so it's not that you "must"), because the two things (keybed scanning technology and MIDI) are totally unrelated.

Yet, granted we all agree on that, the problem still remains exactly as it was, as you said, for all the reasons we have been saying.

[dcjams]

Internally Nord Keyboards DO NOT use MIDI for anything. MIDI is only used for external communication with other MIDI equipment.

Nord instruments generate MIDI information AFTER determining what key has been pressed and how fast. That raw sensor data is completely internal to the keyboard. MIDI has NO method to pass raw sensor information between keyboards.

First of all, are you positive about the above? You're implying a parallel processing in which the raw signal from the keybed/sensors is processed internally by the sound engine in a language that has nothing to do with MIDI (so nothing like note-on, note-off, 128 velocity steps, etc...) and is then also converted into MIDI language to then be sent externally.

MIDI is a 27 year old asynchronous, serial (not parallel, so there's a fundamental difference right there) protocol originally specified for transmission at a leisurely baud rate of 31,250Hz (nothing inside any Nord runs this slow apart from the serial interfaces used to spit out/receive MIDI). It typically represents values at 7-bit (the leading bit determines status versus data) giving only a very coarse 128 levels of granularity.

NPRNs enable 14-bit values (16,384 levels of granularity) but they're independent of note on and note off messages, and costly and cumbersome to use.

I can absolutely guarantee no engineer in their right mind would hamstring an instrument by converting the output of a keyboard to MIDI before it reached the operating system.

I can only think of one notable exception that used MIDI internally but it was a very partial implementation only, and unrelated to keyboard sensing (Yamaha Montage/MODX series).

And just to spice things up ... to make the point that nobody really knows what the engineers have implemented without asking the engineers ... a MIDI note on message with a velocity of 0 is often parsed as a MIDI note off message!

[Hlaalu]

Thanks for the info. I removed that part of my post.

In practical terms, does that mean that when you play back a MIDI recording of your own instrument back into the same instrument, what it plays back is based on less information than what the internal sound engine had available in the moment of the original playing?

If so, in which way (if any) does that information loss map onto, ultimately, sonic differences? I can think of velocity being more or less coarse than 127 steps, but other than that, is there anything else?

[dcjams]

Thanks for the info. I removed that part of my post.

In practical terms, does that mean that when you play back a MIDI recording of your own instrument back into the same instrument, what it plays back is based on less information than what the internal sound engine had available in the moment of the original playing?

It can do, it all depends on implementation. In truth, 127 levels is plenty for our perception of loudness, particularly taking into account it's a logarithmic phenomenon. There's a practical limitation anyway of how many velocity layers you can support in terms of sample size and memory. Many supposedly better software pianos have such huge footprints simply because they sample at many, many velocity levels.

Our perception of sound is complex and there's all sorts of smoke and mirrors going on in software; how you cross-fade between layers, interpolation between EQ curves dependent on context, etc, and of course, there are many other factors besides loudness that constitute expressivity in a human performance.

Remember, even though they sound so good, it's easy to forget, they're not actually pianos!

[anotherscott]

I’m sad with this new Stage 4: if you are using (like me) 2 Extern sections on your NS3, you will only have 1 synth layer with the NS4.
...
I owned all previous NS (1, 1 ex, 2, 2 ex,3) and I have to stop upgrade now for a choice of developent that consume almost no CPU (midi is very light). I hope this limitation can be fixed…

The issue is presumably not CPU, but rather interface/control. I don't see how it can be "fixed" in that I don't see an obvious, intuitive way to use 3 sets of control settings to enable 4 sounds.

But regardless, I discussed a workaround at post161973.html#p161973

[Mr_-G-]

It seems to me that there is. Leave the synth engine on and use the range set for the synth layer for sending MIDI out in the desired channel. If you *want* to switch that synth off, that is a different issue.

[DanielD71]

It won’t be the end of Clavia to put the entire external section in a menu. I could live with that.
We could set the external section, set morph, etc. all within a menu.

[maxpiano]

And just to spice things up ... to make the point that nobody really knows what the engineers have implemented without asking the engineers ... a MIDI note on message with a velocity of 0 is often parsed as a MIDI note off message!

If I remember well that was part of the MIDI 1.0 standard, for the reason explained here http://midi.teragonaudio.com/tech/midispec/noteon.htm so it should always be like that (and this can create the problem with piano "silent key" management if velocity 0 and not 1 is used for that instead)

PS: yes, https://archive.org/stream/MIDI_1.0_Det ... 4_djvu.txt , see Note ON and Note OFF sections

[analogika]

It won’t be the end of Clavia to put the entire external section in a menu. I could live with that.
We could set the external section, set morph, etc. all within a menu.

It would absolutely be “the end” of the Nord Stage series, though, as this is the exact opposite of everything it tried to do. The whole point is having the same physical interface, including the split selection, for all engines — whether organ, piano, synth, or external.

Building a completely new interface to achieve the same thing for one single mode is not going to happen, as it breaks the fundamental idea of the product.

There are other manufacturers that do this as part of their product concept, and that’s fine. That’s why they’re other manufacturers.