bending from pitch x and restriking pitch x results in stutter or dropped note in bitwig

[sebastian_blu]

I am in channel per note mode.

lets say I play c3 in this case, then I slide it up to d3 now if I want to play c3 again in a legato fashion the note cuts out completely, or it will quickly stutter between the bent note and the unbent note.

if you bring up the onscreen mpe keyboard it shows the stutter

I have verified that this happens in bitwig but not in logic. So is the bug in the LinnStrumentalist script bitwig uses to handle the input from the linnstrument?

can anyone verify this behavior in bitwig?


I will also reach out to bitwig support. But more heads always help.

cheers

[Roger_Linn]

My guess is that your synth is in one-channel mode. If you haven’t seen the Bitwig page on my site (accessed from the LinnStrument Support page), I recently added new info about how to set it up for MPE sounds.

[sebastian_blu]

My guess is that your synth is in one-channel mode. If you haven’t seen the Bitwig page on my site (accessed from the LinnStrument Support page), I recently added new info about how to set it up for MPE sounds.

Hey! Was using equator with the mpe button pressed for my tests but noticed it first in phase 4 an fm and even looking at the onscreen bitwig grid keyboard the Sutter is visible

in logic when I slide up from note x a whole step and keep it held down and restrike x the resulting sound is a sustained major second and keyboard display in equator shows the two notes fully independent, in bitwig the results of the gesture are a stutter between the two notes and the visual display on the equator keyboard is one glitchy note

quick video of logic performance
https://my.pcloud.com/publink/show?code ... KwsmgJpcLX

quick video of bitwig stutter
https://my.pcloud.com/publink/show?code ... xItkAFPM3X

I sent these to bitwig support too

thanks let me know what you think

[Roger_Linn]

Hi Sebastian,
Now I understand better. The video was very helpful. To fix the problem:
1) In Bitwig, select your Instrument track in the track list.
2) In the Track Inspector at left, set the "To" field to "Same".

Unless you do this, Bitwig doesn't internally store the received MIDI channel with each note, which is a kludgey way that Bitwig originally implemented MPE. Then on playback, each note is reassigned to a new MPE per-note channel before sending it out. This works fine if you never play two notes of the same note number. But if you do, their pitch bend messages won't know what note to bend, which is the problem you're experiencing. Bitwig fixed this in (I think) version 2, by adding the "To" field and allowing it to be set to "Same", which implements MPE correctly by storing the actually received MIDI channel with each MPE note. It seems to me there's no reason to set it any other way, but perhaps this gives Bitwig better backward compatibility with older files. Dunno.

I've just updated the Bitwig page on my site to include this extra step, and sorry I didn't include it before.

[Echoes in the Attic]

... Bitwig fixed this in (I think) version 2, by adding the "To" field and allowing it to be set to "Same", which implements MPE correctly by storing the actually received MIDI channel with each MPE note.

One little caveat to this: Even when "To" is set to "Same", Bitwig will still change the midi channel of any note that comes in that is on the same midi channel of a note that is already playing. It will bump it up by one. And then if another note comes in on the channel it bumped the note to, it will bump that one up and. And so on. So this can affect the linnstrument's channel per row mode where you might actually want to keep the channels as they are. If you are in MPE mode in Bitwig, any two notes played simultaneously on the same row will bump the second one up a channel and then bump all next row's channels as well. Just something to be aware of.

[Reckon104]

"It seems to me there's no reason to set it any other way, but perhaps this gives Bitwig better backward compatibility with older files. Dunno. "

Hey Roger, I have actually found that "feature" helpful (the "to channel 1" thing). If I have a project that I am working on wherein several tracks are using MPE synths, but one or two tracks are not, I can go back and forth between the various tracks while the Linnstrument is in channel per note mode for the MPE tracks and don't have to worry about switching that setting on the linnstrument for the non-MPE tracks, if that makes any sense?

More often though, I forget to change that for MPE tracks and spend hours trying to problem solve until I realize that was the issue

[Echoes in the Attic]

I definitely think To "Same" should be the default though, because it can mess up a lot of people until they realize they have to change that one little thing.

[Roger_Linn]

One little caveat to this: Even when "To" is set to "Same", Bitwig will still change the midi channel of any note that comes in that is on the same midi channel of a note that is already playing. It will bump it up by one. And then if another note comes in on the channel it bumped the note to, it will bump that one up and. And so on. So this can affect the linnstrument's channel per row mode where you might actually want to keep the channels as they are. If you are in MPE mode in Bitwig, any two notes played simultaneously on the same row will bump the second one up a channel and then bump all next row's channels as well. Just something to be aware of.

Thanks for the clarification, Echoes. Then it seems that in adding the "To" field, Bitwig merely put a kludge on top of a kludge, but still doesn't store the received MIDI channel with each note exactly as received.

At least it seems to work fine for MPE play, even if it causes the problem you describe for Channel Per Row play. Even with this problem, I still think Bitwig is best because of its ability to edit pitch bend data in real musical pitches instead of arbitrary bend values as in other DAWs.

[Reckon104]

I definitely think To "Same" should be the default though, because it can mess up a lot of people until they realize they have to change that one little thing.

I certainly agree! I have been one of those people to the point of posting on this board for help and then realizing it was just that I forgot to change that setting, even after having done it hundreds of times before!

[Echoes in the Attic]

One little caveat to this: Even when "To" is set to "Same", Bitwig will still change the midi channel of any note that comes in that is on the same midi channel of a note that is already playing. It will bump it up by one. And then if another note comes in on the channel it bumped the note to, it will bump that one up and. And so on. So this can affect the linnstrument's channel per row mode where you might actually want to keep the channels as they are. If you are in MPE mode in Bitwig, any two notes played simultaneously on the same row will bump the second one up a channel and then bump all next row's channels as well. Just something to be aware of.

Thanks for the clarification, Echoes. Then it seems that in adding the "To" field, Bitwig merely put a kludge on top of a kludge, but still doesn't store the received MIDI channel with each note exactly as received.

At least it seems to work fine for MPE play, even if it causes the problem you describe for Channel Per Row play. Even with this problem, I still think Bitwig is best because of its ability to edit pitch bend data in real musical pitches instead of arbitrary bend values as in other DAWs.

Yes exactly, pitch bend editing in real musical pitches is much better than arbitrary pitch bend automation values! Perhaps now you understand why I so much appreciate monophonic instruments that can play in MPE mode in Bitwig - Because you must turn on mpe mode to use that per note pitch editing! And MPE mode in Bitwig will not allow overlapping notes on the same channel, and it will bump the channels. Therefor the instrument must be able to listen to any midi channels, even though it's mono. And not get the pitch bend data confused between the notes with slight overlap. Like Audio Modeling instruments work correctly! And the Roli synths and one or two others...

[Tj Shredder]

I had an argument with Bitwigs support about that, and they claim its not in the MPE spec to have two notes on the same channel as the LinnStrument would send in channel per row mode. May be we could convince them to add a "keep" setting which would allow this? I think they should simply store the original Midi messages along their translation into expressions. And then I could choose between those for playback...

[Roger_Linn]

Bitwig is actually correct in that MPE only permits one note per channel. I think it’s reasonable that they wouldn’t create a special mode only for LinnStrument’s Channel Per Row mode. However, I agree that it would be better if they would store the received midi channel along with the received message in their sequence.

[Echoes in the Attic]

Yes it certainly doesn’t need to be called “mpe” in that case, it could simply be a multichannel midi mode where mpe is off. In fact the strange thing is, when mpe mode is off for an instrument in bitwig, the micro pitch data per note is still recorded for channels 2 and up. Only channel 1 pitch bend is recorded as normal pitch bend data. And it can already record multiple midi channels of notes with mpe off. So it seems to me that they could just have a mode with mpe off where it records all midi expressions on the midi channels where they are played. Worth a feature request anyways.

[Tj Shredder]

They should just record all Midi including sysex, and give a choice what to play back... Its not always about editing! Sometimes it needs simple solutions for simple demands. If I want to playback what I recorded unaltered, I should be able to do so...
In audio its called non-destructive - I have no idea why this successful concept can’t be translated to Midi. Midi is dead simple, much easier and less demanding as audio...

[Echoes in the Attic]

They should just record all Midi including sysex, and give a choice what to play back... Its not always about editing! Sometimes it needs simple solutions for simple demands. If I want to playback what I recorded unaltered, I should be able to do so...
In audio its called non-destructive - I have no idea why this successful concept can’t be translated to Midi. Midi is dead simple, much easier and less demanding as audio...

There are two potential ways that midi data could be recorded though.

It could be recorded on each channel as midi automation (like normal pitch bend data gets recorded into the pitch bend automation lane, channel aftertouch or cc74). Bitwig records pitch bend on channel 1 to PB automation for for some reason doesn't record the other channels, even though those other channels can be added in automation.

The second way of course is to record the midi data as note expressions which is what happens in MPE mode, but Bitwig doesn't allow multiple midi channels to play at once. I'd like to see a "record what you receive mode" for the expressions, thus allowing multiple notes on the same channel, but perhaps there is a conceptual issue about how to record two different note expressions at once on the same channel, which shouldn't be possible, like how you can't have two different pitch bend automation lanes for one channel. Not sure how other hosts do it, but there would need to be some rules about that. For example if you're using Linnstrument in channel per row mode and two notes play at once on one row where one is pitch bent and then another, how should Bitwig draw the pitch bend data since you can only have one pitch bend per channel? Should Bitwig stop drawing the pitch bend on one note and move that to the second note? Or continue drawing the pitch bend on the first note received and not draw it on the second note until the first is released? Perhaps in this case the only way to do it would indeed be to record to standard midi automation and per note expressions would not be possible. I'm not sure.