Channel Pressure Behavior: Fixed in Custom Firmware

[ryanpg]

Tommytea, thank you! I'm running bitwig and will try your script. I've actually not used controller scripts in bitwig yet, so this will be a fun way to experiment.

[Ahornberg]

tommytea, how does your Bitwig script deal with polyphonic notes?

[teknico]

Status report: I disabled zero-value Z messages before note-ons and note-offs for simultaneous notes on the same channel. They are still sent before the first and the last note, and when using Polyphonic Aftertouch.

This works well in all modes: one channel, channel per row, and even channel per note (MPE) when you have more notes than available channels. In the latter case you probably want to use Polyphonic Aftertouch, though.

Now working on only sending the maximum Z value for simultaneous notes on the same channel, again except when using Polyphonic Aftertouch.

[Ahornberg]

Status report: I disabled zero-value Z messages before note-ons and note-offs for simultaneous notes on the same channel. They are still sent before the first and the last note, and when using Polyphonic Aftertouch.

This works well in all modes: one channel, channel per row, and even channel per note (MPE) when you have more notes than available channels. In the latter case you probably want to use Polyphonic Aftertouch, though.

Now working on only sending the maximum Z value for simultaneous notes on the same channel, again except when using Polyphonic Aftertouch.

My VCV Rack MPE-module relies on this zero-value Z messages, at least in mode channel per note (MPE). I think there are also some MPE-capable VSTs that rely on this messages. IMO there's a reason why they are implemented.

[teknico]

My VCV Rack MPE-module relies on this zero-value Z messages, at least in mode channel per note (MPE). I think there are also some MPE-capable VSTs that rely on this messages. IMO there's a reason why they are implemented.

Currently, zero-value Z messages are sent before all note-ons and all note-offs. With my change, they are still sent:

- when using Polyphonic Aftertouch;
- before the note-on of the first note on a given channel;
- before the note-off of the last note on a given channel.

In MPE mode, usually there's only one note at a time per channel. In this case, nothing changes: zero-value Z messages are sent exactly as before, irrespective of whether Polyphonic Aftertouch is used or not.

However, these messages can interfere with seamless expression in both One Channel and Channel per Row modes. For this reason I'm disabling them, but only:

- when not using Polyphonic Aftertouch, and
- only for simultaneous notes that are not the first or the last one.

(Another change will be to only send the maximum Z value when there's more than one note on each channel, and Polyphonic Aftertouch is not being used. I will later apply this change to Y values too.)

[tommytea]

tommytea, how does your Bitwig script deal with polyphonic notes?

I just updated the script so that if multiple notes are held, it uses the highest pressure value (the solution described in the original post). With this change, polyphony and pressure should work as ryanpg wanted and surprisingly, mono instruments feel even more intuitive now too

FWIW, I don't find the Linnstrument's current pressure behaviour to be particularly useful or musical. The issues I see with it are:

1. When a new note is played, the pressure starts from 0 before ramping up
2. Even if the first issue is fixed, Linnstrument sends a message to set pressure to 0 before every Note On and Note Off. This is intended though so this can't be fixed if the Linnstrument is to remain compliant with the MPE spec although this can be fixed for One Channel mode (because it's not MPE).
3. As described in the thread, if multiple notes are held, Linnstrument uses the pressure value from the latest note. This causes abrupt changes because of the first two issues and the fact that it is extremely difficult to hit a note with the same pressure as the previous note.

If these issues could somehow be fixed, I think the pressure behaviour would become much more intuitive and would work well with wind and bowed instruments such as the SWAM instruments and Infinite Woodwinds/Brass.

With this thread and this previous thread, there are at least 5 people (including myself) that would benefit from a change to the pressure behaviour

[Ahornberg]

I see, the expectations on the LinnStrument vary from one user to another. One wants to play like on a real flute, trumpet, violin with all the typical articulations provided by these instruments. Others just play piano sounds without any pitch-bend, modulation, and aftertouch. And others like me want to use it as far as possible as a cheaper replacement for the Hakenaudio Continuum.

[teknico]

FWIW, I don't find the Linnstrument's current pressure behaviour to be particularly useful or musical.

Agreed, that is why this thread exists.

The issues I see with it are:

1. When a new note is played, the pressure starts from 0 before ramping up

This is because of #2 below.

2. Even if the first issue is fixed, Linnstrument sends a message to set pressure to 0 before every Note On and Note Off. This is intended though so this can't be fixed if the Linnstrument is to remain compliant with the MPE spec.

Not true. I already fixed this in a way that doesn't interfere with MPE, see the previous messages.

3. As described in the thread, if multiple notes are held, Linnstrument uses the pressure value from the latest note. This causes abrupt changes because of the first two issues and the fact that it is extremely difficult to hit a note with the same pressure as the previous note.

I'm fixing this by only sending the maximum value for all simultaneous notes on each channel, when there is more than one note and PolyAT is not used. This will be changed for both the Y and Z axes.

If these issues could somehow be fixed,

They can and they will, if you're willing to use unofficial firmware.

I think the pressure behaviour would become much more intuitive and would work well with wind and bowed instruments such as the SWAM instruments and Infinite Woodwinds/Brass.

Again, agreed.

With this thread and this previous thread, there are at least 5 people (including myself) that would benefit from a change to the pressure behaviour

Thanks for the reference to the previous thread.

I should emphasize that these changes are unofficial, USE AT YOUR OWN RISK, and come with no pressure (heh) on Roger or Geert to ever integrate them into the official firmware.

And now, back to work.

[teknico]

It's done, and seems to be working.

Developers will find the changes in this branch on Github. Once it's got some more testing I will upload a binary file to be used with the updater.

If you try it, please let me know how it goes.

[ryanpg]

Amazing! Your changes are working beautifully! They are unquestionably a net gain in function and will THRILL any non-MPE players. My non-MPE synths are MUCH more predictable and z-data is now useful for controlling cutoff and other parameters.

Thank you, teknico for your openness to the issue, your knowledge of coding, and the effort you put into implementing this. Having taken a look at the code, this seems a logical and elegant solution to the issue that very closely matches the ethos and style of the existing firmware. I have not tested with an MPE instrument, but will do so soon with the full expectation that it will work beautifully there too.

[Edit] the below proved to be wrong. It's still possible to produce large "jumps" in pressure data between played notes. I.e. lightly hold a note then quickly and firmly tap a second pad. Some synths may respond unpredictably. It's an unavoidable result of that playing style and the custom firmware is a great improvement.


The only "unwelcome surprise" as Roger suggested, is that a minor shortcoming in the way Linnstrument handles velocity (due to the unique challenges presented by pressure pads vs. switches and sensors on keyboards) is made a bit more evident. If you still hear some occasional "pops" in z-data with very quick pad presses, I believe this is the cause. To be clear, the velocity issue pre-existed this change and was not introduced by it, it's just unmasked in trade for the MUCH improved pressure behavior and should not stop anyone interested and willing from trying teknico's modifications.

[teknico]

Thank you, teknico for your openness to the issue, your knowledge of coding, and the effort you put into implementing this. Having taken a look at the code, this seems a logical and elegant solution to the issue that very closely matches the ethos and style of the existing firmware.

Thank you very much for your kind words. I'm happy to be helpful.

I have not tested with an MPE instrument, but will do so soon with the full expectation that it will work beautifully there too.

There should be no change at all in MPE mode (except for the unlikely case of multiple notes on the same channel). If there's any difference, it's a bug.

The only "unwelcome surprise" as Roger suggested, is that a minor shortcoming in the way Linnstrument handles velocity (due to the unique challenges presented by pressure pads vs. switches and sensors on keyboards) is made a bit more evident.

There is no change in the handling of velocity values.

If you still hear some occasional "pops" in z-data with very quick pad presses, I believe this is the cause. To be clear, the velocity issue pre-existed this change and was not introduced by it, it's just unmasked [...]

Are you saying that there's some interaction in the processing of velocity and pressure by the receiving synth, so that the different pressure behavior causes a change in the response to velocity? That would be a problem with the specific synth.

Some more details about the synth, the patch and maybe a recording would be useful.

[John the Savage]

For the record, all of the non-MPE synths that I use do support polypressure, and the rest are legit MPE synths. As such, I have not been burdened by this particular issue.

However, for the sake of integrity, I do think the LinnStrument should support old standards, like channel pressure, as one might expect of any standard MIDI controller.

In this case, the mishandling of channel pressure seems to have been a simple oversight (understandably so, what with the focus being on MPE), and the solution seems easy enough, so... Here's hoping it gets fixed in the official firmware as well.

I will likely have to contend with this at some point. In fact, I'm amazed that I haven't yet.

Good effort, teknico. The community owes you a debt of gratitude.

Cheers!

[ryanpg]

Hi teknico. I'll do some more investigation. Occasionally, there's a very quick "pop" still. It happens on two of the three synths I've tested (Deepmind 12 Desktop, Minilogue XD) but it's:

1) not very significant and infrequent
2) I'm starting to doubt my initial diagnosis so I'll try to make it reproducible.

I'll provide logs and recording.

[teknico]

For the record, all of the non-MPE synths that I use do support polypressure, and the rest are legit MPE synths. As such, I have not been burdened by this particular issue.

However, for the sake of integrity, I do think the LinnStrument should support old standards, like channel pressure, as one might expect of any standard MIDI controller.

Supporting older synths is only part of the story, though. My main use case is monophonic sounds.

When playing sustained, monophonic lines it's useful to have a more uniformly playable behavior on the Y and Z axes, without having to resort to workarounds like the Low Row or pedals.

Another use case is emulating guitar playing in Channel per Row mode. In that case each row models a guitar string, again a monophonic source, and the same considerations as above apply.

In this case, the mishandling of channel pressure seems to have been a simple oversight (understandably so, what with the focus being on MPE), and the solution seems easy enough, so... Here's hoping it gets fixed in the official firmware as well.

I will likely have to contend with this at some point. In fact, I'm amazed that I haven't yet.

Good effort, teknico. The community owes you a debt of gratitude.

Cheers!

Thank you. Once again, this would not have been possible without Roger's wise choice to open the Linnstrument source code. A choice that is unfortunately still rare in the synth world.

[Roger_Linn]

I also must thank you, teknico. It was very kind of you to help ryanpg. I look forward to trying out the code on my mac when you have a build for the Updater app.