High Resolution Midi?

[AB9]

Does Sonar do high resolution midi?  (Such as velocity)  If not yet, are there plans for it?
Thank you!

[Bristol_Jonesey]

There are only 128 addressable "steps" in parameters like velocity. How would you propose to increase this?

And what would the benefit be?

I would struggle to hear a difference of a velocity of, say, 100 to 101

 

Edited Tuesday at 07:45 AM by Bristol_Jonesey

[Wookiee]

@AB9 Cakewalk has been fully compliant with all the standard MIDI CC, RPN, NRPN instructions, since its inception in the late 1980's. 

I assume you are asking if it recognises CC 88, which the MIDI association defines as the CC to use when the standard is not sufficient requiring 14 bits of velocity instead of the defaul 7.

There is no blocking filter in the MIDI configuration that I can find to stop CC 88 being passed by Cakewalk.

Having read a little about CC 88 it seems to me you are asking the wrong question. Your question should be, does plugin XYZ or hardware synth respond to CC 88. You can most definitely add CC 88 MIDI messages to Cakewalk either manually or via a envelope, or of course if you have a MIDI controller that can be set to transmit MIDI CC 88.

[Promidi]

7 hours ago, AB9 said:

Does Sonar do high resolution midi?  (Such as velocity)  If not yet, are there plans for it?
Thank you!

Note CC, Channel Aftertouch, polyphonic Aftertouch, velocity, patch events are 7 bit

Wheel,  RPN, NRPN Bank, and I think Note Durations, are 14 bit.

If your definition of high resolution midi differs from this then no, Sonar does not do high resolution midi.

As to are there plans for it, that would be a question for the devs?

It really depends on what your specific definition of high resolution midi actually is.

Edited Tuesday at 10:34 AM by Promidi

[Promidi]

.

Edited Tuesday at 10:34 AM by Promidi

[Promidi]

2 hours ago, Bristol_Jonesey said:

There are only 128 addressable "steps" in parameters like velocity. How would you propose to increase this?

And what would the benefit be?

I would struggle to hear a difference of a velocity of, say, 100 to 101

Me too (with velocity).

However, there have been times when, even with the 14 bit step available for Wheel Events, the step change is discernible. - especially when the Pitch bend range is 1200 cents or greater.

[Starship Krupa]

I think that this question can't be answered without first clarifying the term "high definition MIDI."

Sonar records and plays MIDI events. I've always assumed that it records and plays back whatever types of events are defined in the MIDI specification. I don't know why it wouldn't. Compared to recording and playing back audio, MIDI is (pardon the expression) a snap.

[Max Arwood]

He might be  talking about MPE. I think that is the correct letters. Or possibly midi  2.0 

[David Baay]

I have experimented with high-resolution velocity, using Pianoteq which can respond to it in theory with microtonal and loudness changes. Putting aside whether the variation it produces is musically meaningful, I think the main obstacle to working with the CC88 implmentation in a DAW is that the controller messages are not tied to the note events so special care needs to be taken to keep them together when editing.

Edited Tuesday at 10:57 PM by David Baay

[AB9]

Here is an example of a piano controller that uses high resolution midi:
https://playvidal.com/products/vidal

Here is quote from it: "Our electronics capture hi-res MIDI, with over 16,000 velocity values where most keyboards only support 127."

And my underrstanding is that Cubase allows for high resolution midi.  This is from AI about Cubase:
High-Resolution MIDI Velocity (MIDI 2.0):
While standard MIDI 1.0 uses a 7-bit velocity value (0-127), MIDI 2.0 introduces a 16-bit velocity value, offering much finer control over dynamic expression. 
This means you can have 16,384 possible velocity values instead of 128, providing a much wider range for dynamic expression. 
Cubase 13 supports MIDI 2.0, allowing you to take advantage of this higher resolution velocity. 

NOTE:  This seems like it would be a pain in the editing process.  But maybe it is better in the capturing process.

Edited Tuesday at 03:53 PM by AB9

[David Baay]

7 hours ago, AB9 said:

High-Resolution MIDI Velocity (MIDI 2.0):
While standard MIDI 1.0 uses a 7-bit velocity value (0-127), MIDI 2.0 introduces a 16-bit velocity value, offering much finer control over dynamic expression. 
This means you can have 16,384 possible velocity values instead of 128, providing a much wider range for dynamic expression. 

Just to clariify, MIDI 2.0 Velocity offers 65,536 (16-bit) possible values with the value encoded in the the Note On/Off messages as it is in MIDI 1.0.

What's commonly referred to as "Hi-Res Velocity" (what Vidal is offering) is just a MIDI 1.0 convention for using a CC88 message sent immediately before a Note On/Off message that can be interpreted by the receiving instrument as dividing the velocity value by another 128, yielding 16,384 (14-bit) possible  values.

[Amberwolf]

Hmm...I'd never heard of it till now, but:

https://forum.modartt.com/viewtopic.php?id=5897

Quote

High Resolution MIDI Velocity CC#88 was adopted by the MMA around 2010, giving controllers and instruments a velocity range of 0-16,000+, instead of the basic MIDI 0-127. Pianoteq is one of the few software instruments that respond to it, and I am fortunate enough to have a controller (VAX77) that transmits it.

Are there any other controllers out there (especially 88 key with piano touch) that can transmit it?

Do you feel it actually makes a real-world difference vs 0-127? More subtleties in playing nuance, or you really can't tell?

 

[AB9]

9 minutes ago, David Baay said:

Just to clariify, MIDI 2.0 Velocity offers 65,536 (16-bit) possible values with the value encoded in the the Note On/Off messages as it is in MIDI 1.0.

What's commonly referred to as "Hi-Res Velocity" (what Vidal is offering) is just a MIDI 1.0 convention for using a CC88 message sent immediately before a Note On/Off message that can be interpreted by the receiving instrument as dividing the velocity value by another 128, yielding 16,384 (14-bit) possible  values.

Thank you.    Does Sonar then have the current capability of taking advantage of the the possible values of the Vidal example?

[User 905133]

7 minutes ago, David Baay said:

Just to clarify, MIDI 2.0 Velocity offers 65,536 (16-bit) possible values with the value encoded in the the Note On/Off messages as it is in MIDI 1.0.

What's commonly referred to as "Hi-Res Velocity" (what Vidal is offering) is just a MIDI 1.0 convention for using a CC88 message sent immediately before a Note On/Off message that can be interpreted by the receiving instrument as dividing the velocity value by another 128, yielding 16,384 (14-bit) possible  values.

Thanks for confirming this.  I assumed this was the case based on your prior reference to "the CC88 implementation" but the clarification is good to know. 

[User 905133]

20 minutes ago, AB9 said:

Thank you.    Does Sonar then have the current capability of taking advantage of the the possible values of the Vidal example?

Interesting question.  I have no idea, but I can only assume if you have a controller that sends out CC88 data and a synth that interprets it as extended range velocity information, playing back the recorded MIDI data should allow the synth to do what you want. Again, I have no idea, but I like the question. [EDIT OUT based on David Baay's explanation of the CC88 data.] 

If you (or anyone else), has some note data that has the CC88 velocity extended range, I'd be interested to see what it looks like and play around with it to see what I might want to map the CC88 data to (purely as a hobbyist).

Edited Tuesday at 11:56 PM by User 905133

[David Baay]

4 minutes ago, AB9 said:

Does Sonar then have the current capability of taking advantage of the the possible values of the Vidal example?

Yes, for the most part. You just end up with an Event List that shows a CC88 message right before every Note event. But Sonar currently ignores Note Off velocity and always sends a neutral value of 64, so it will record the CC88 controllers that a Hi-Res-capable keyboard sends right before a Note Off and show them in the Event List even though it doesn't show separate Note Off messages or allow editing them other than indirectly by changing the duration of a Note event.

[David Baay]

5 minutes ago, User 905133 said:

If you (or anyone else), has some note data that has the CC88 velocity extended range, I'd be interested to see what it looks like and play around with it to see what I might want to map the CC88 data to (purely as a hobbyist).

At the time I was investigating this, I was unable to find a hi-res MIDI file to play with so I created my own by copying the velocity lane in the controllers pane of the PRV to a CC88 lane and sliding the resulting controllers 1 tick earlier. If the original MIDI perfromance was played live, the velocities will be variable so the CC88 values will as well.

Without getting too far into the weeds, my conclusiion was that hi-res velocity was of no value when playing Pianoteq in particular because the inherently variable response it produces as a phycially modeled instrument swamped the much smaller level of variability due to the finer gradations of velocity.

Moreover, I'm not convinced that any keyboard player on the planet has the level of control and repeatability necessary to take advantage of higher velocity resolution. There's an argument to be made that even uncontrolled/random variation at a fine level might add some "life" to a piano or synth patch that might otherwise sound mechanical due to producing the exact same response to the same velocity every time, but some instruments already address that by "round-robin" samples or physically modeled randomness as in the case of Pianoteq, and if they don't, they probably won't repond to hi-res MIDI anyway!

[mettelus]

12 hours ago, David Baay said:

Moreover, I'm not convinced that any keyboard player on the planet has the level of control and repeatability necessary to take advantage of higher velocity resolution.

This also only addresses the input side, not any follow on FX (especially compression) that collapses the dynamic range back down anyway (or the hearing capability of the listener if you want to take it to the end point). I used to joke with engineers that most calculations only need 3 significant digits and an order of magnitude to be used, and many would get the deer in the headlights look when I asked if they carried measurement tolerance errors (+/-) through calculations to the final value (almost never the case). Engineers often get more excited with a crapload of numbers than their real-world application.

Then again, guitarists need to not only worry about attack pressure, but also pick angle and distance from the bridge. We need more MIDI parameters for those 😆

[Wookiee]

There appears to be two main MIDI controllers that support hi-resolution velocity, there may be others but these were the most often shown.

The Studiologic VMK188 around £557.29

The Casio PX-5S, which is a digital piano, around £700.00.

They both support MIDI 2.0 which whilst MIDI CC 88 is part of MIDI 1.0, from what I am reading MIDI 2.0 support is preferred. 

The developers of Cakewalk have said that they are looking at MIDI 2.0, whilst it is not fully compliant with MIDI 2.0 it does support features like MPE, which is a MIDI 2.0 requirement, along with other MIDI 2.0 function. 

There is one question, how many plugins and hardware synths are MIDI 2.0 compliant? It is not something I see mentioned in the stats of such.