Hi Guys,
In channel per row mode did the LS use to send PB when sliding between notes when more than one pad is being played, so on the last pad played. It's sending vibrato PB but when i slide to a new note I am getting another note on. Has it always been like this?
Channel per row - PB, loosing my mind?
-
- KVRAF
- 2484 posts since 8 Jun, 2010
- Roger Linn Design
Hi Bob,
In Channel Per Row mode, LinnStrument has the same Pitch Bend behavior for each row as in One Channel Mode: if you slide one touch only, you get a continuous pitch slide. But if you hold one touch while sliding another touch on the same row, the pitch slide results in a series of new notes as each adjacent note pad is touched. If not for this correction, the Pitch Bend information would bend both notes, because Pitch Bend messages apply to all notes on the channel. It's always been like this.
In Channel Per Row mode, LinnStrument has the same Pitch Bend behavior for each row as in One Channel Mode: if you slide one touch only, you get a continuous pitch slide. But if you hold one touch while sliding another touch on the same row, the pitch slide results in a series of new notes as each adjacent note pad is touched. If not for this correction, the Pitch Bend information would bend both notes, because Pitch Bend messages apply to all notes on the channel. It's always been like this.
-
- KVRAF
- Topic Starter
- 1548 posts since 2 Apr, 2015
Hi Roger,
Thanks for the info, I thought I was probably mis-remembering.
The thing is though it does send PB for the new note which does effect the other note, here is an example :
First play a B3 and slide down and hold
Then play a C3, you can see an initial PB of 0 being send then I jiggle around a bit to send more PB messages.
Now lift of the C3 and you can see it send the original value of -7848 for the slid B3
Thanks for the info, I thought I was probably mis-remembering.
The thing is though it does send PB for the new note which does effect the other note, here is an example :
First play a B3 and slide down and hold
Code: Select all
676.052 From LinnStrument MIDI Pitch Wheel 1 0
676.054 From LinnStrument MIDI Note On 1 B3 28
676.367 From LinnStrument MIDI Pitch Wheel 1 -2
676.380 From LinnStrument MIDI Pitch Wheel 1 -4
676.392 From LinnStrument MIDI Pitch Wheel 1 -8
676.405 From LinnStrument MIDI Pitch Wheel 1 -14
676.418 From LinnStrument MIDI Pitch Wheel 1 -28
676.431 From LinnStrument MIDI Pitch Wheel 1 -38
676.443 From LinnStrument MIDI Pitch Wheel 1 -54
676.457 From LinnStrument MIDI Pitch Wheel 1 -60
676.470 From LinnStrument MIDI Pitch Wheel 1 -272
676.502 From LinnStrument MIDI Pitch Wheel 1 -278
676.515 From LinnStrument MIDI Pitch Wheel 1 -308
676.528 From LinnStrument MIDI Pitch Wheel 1 -338
676.540 From LinnStrument MIDI Pitch Wheel 1 -382
...
678.315 From LinnStrument MIDI Pitch Wheel 1 -7838
678.327 From LinnStrument MIDI Pitch Wheel 1 -7840
678.346 From LinnStrument MIDI Pitch Wheel 1 -7842
678.358 From LinnStrument MIDI Pitch Wheel 1 -7844
678.371 From LinnStrument MIDI Pitch Wheel 1 -7846
678.395 From LinnStrument MIDI Pitch Wheel 1 -7848
Code: Select all
679.179 From LinnStrument MIDI Pitch Wheel 1 0
679.182 From LinnStrument MIDI Note On 1 C3 53
680.569 From LinnStrument MIDI Pitch Wheel 1 -2
680.582 From LinnStrument MIDI Pitch Wheel 1 -4
680.596 From LinnStrument MIDI Pitch Wheel 1 -2
680.616 From LinnStrument MIDI Pitch Wheel 1 0
680.650 From LinnStrument MIDI Pitch Wheel 1 2
680.663 From LinnStrument MIDI Pitch Wheel 1 4
680.684 From LinnStrument MIDI Pitch Wheel 1 6
680.697 From LinnStrument MIDI Pitch Wheel 1 10
680.724 From LinnStrument MIDI Pitch Wheel 1 8
680.744 From LinnStrument MIDI Pitch Wheel 1 6
680.758 From LinnStrument MIDI Pitch Wheel 1 4
680.772 From LinnStrument MIDI Pitch Wheel 1 2
680.778 From LinnStrument MIDI Pitch Wheel 1 0
680.832 From LinnStrument MIDI Pitch Wheel 1 -2
680.846 From LinnStrument MIDI Pitch Wheel 1 -4
680.859 From LinnStrument MIDI Pitch Wheel 1 -6
680.873 From LinnStrument MIDI Pitch Wheel 1 -8
680.900 From LinnStrument MIDI Pitch Wheel 1 -6
680.913 From LinnStrument MIDI Pitch Wheel 1 -4
680.927 From LinnStrument MIDI Pitch Wheel 1 -2
680.940 From LinnStrument MIDI Pitch Wheel 1 0
680.974 From LinnStrument MIDI Pitch Wheel 1 2
680.987 From LinnStrument MIDI Pitch Wheel 1 4
681.028 From LinnStrument MIDI Pitch Wheel 1 2
681.041 From LinnStrument MIDI Pitch Wheel 1 0
681.082 From LinnStrument MIDI Pitch Wheel 1 -2
681.129 From LinnStrument MIDI Pitch Wheel 1 0
681.237 From LinnStrument MIDI Pitch Wheel 1 2
681.244 From LinnStrument MIDI Pitch Wheel 1 0
Code: Select all
681.281 From LinnStrument MIDI Note Off 1 C3 127
681.284 From LinnStrument MIDI Pitch Wheel 1 -7848
Bitwig, against the constitution.
-
- KVRAF
- 2484 posts since 8 Jun, 2010
- Roger Linn Design
Hi Bob,
It's a little tricky for me to understand the technical listings. Can you make a brief video that demonstrates the musical problem?
The issue may be that for both 1) one row of Channel Per Row and also 2) for One Channel play, holding one cell while moving another does not block all sending of Pitch Bend messages. You can still vibrato within the cell and movements of both fingers are averaged so that you can vibrato a chord. However, if one of those touches slides to an adjacent cell, then a new Note On is sent for the sliding touch, because otherwise the pitch of both touches would be changed instead of only one.
It's a little tricky for me to understand the technical listings. Can you make a brief video that demonstrates the musical problem?
The issue may be that for both 1) one row of Channel Per Row and also 2) for One Channel play, holding one cell while moving another does not block all sending of Pitch Bend messages. You can still vibrato within the cell and movements of both fingers are averaged so that you can vibrato a chord. However, if one of those touches slides to an adjacent cell, then a new Note On is sent for the sliding touch, because otherwise the pitch of both touches would be changed instead of only one.
-
- KVRAF
- Topic Starter
- 1548 posts since 2 Apr, 2015
I can explain how you can see what is going on with one of your LS, this is related to my original question but is not the problem but rather an issue with the LS code where if you have slid a note and hold it and then play another note the slid note changes pitch:
First both channel per row and one channel mode work the same, so choose one channel mode.
Now slide one finger and settle on a note and hold it there.
Then press another note.
You will hear the original note change pitch as the pitchbend is set to 0 for the new note which also effects the original note.
Now release the second note and you will hear the original note go back to its correct pitch.
First both channel per row and one channel mode work the same, so choose one channel mode.
Now slide one finger and settle on a note and hold it there.
Then press another note.
You will hear the original note change pitch as the pitchbend is set to 0 for the new note which also effects the original note.
Now release the second note and you will hear the original note go back to its correct pitch.
Bitwig, against the constitution.
-
- KVRAF
- 8823 posts since 6 Jan, 2017 from Outer Space
That sounds like expected behavior, according to roger the pitch bend is averaged (even if it goes back to zero it would average the next moment.)
I like that. Not ideal for turkish makams, but you would still be able to play a vibrato. For makam music channel per row should be avoided, as you cannot make it work anyway...
Edit, I did not recognize that you meant sliding to a complete other note. But there is no way to avoid that, because that note is pitched by the pitch bend - think, think, think - there would be a way, but that would mean to retrigger the old note on the slided note - or even worse, repitch all other played notes according to the slide...
I think its better to live with the way it is...
I also adapted a playing style for one channel mode, by just dealing with how it reacts...
I like that. Not ideal for turkish makams, but you would still be able to play a vibrato. For makam music channel per row should be avoided, as you cannot make it work anyway...
Edit, I did not recognize that you meant sliding to a complete other note. But there is no way to avoid that, because that note is pitched by the pitch bend - think, think, think - there would be a way, but that would mean to retrigger the old note on the slided note - or even worse, repitch all other played notes according to the slide...
I think its better to live with the way it is...
I also adapted a playing style for one channel mode, by just dealing with how it reacts...
-
- KVRAF
- 8823 posts since 6 Jan, 2017 from Outer Space
On a side note, I could imagine a 2-channel per row mode. Just for voice per channel playing (missing the control channel of MPE for each row). I guess its rare that you need more than 2 notes per row, there are enough other rows to move to, in case of conflicts...
-
- KVRAF
- Topic Starter
- 1548 posts since 2 Apr, 2015
It isn't using the average though, it uses the last note pressed for PB, all other notes PB are ignored. Whenever you press a new note PB is set to 0.
If the last note is released it then starts using the previous note pressed and so on.
Another way of doing it is to offset the new note and keep the same PB value.
So for example.
First note is C3 slid down to C2, so now PB is at -12 semitones.
Then when a new note is played say E3 we need to offset that note by +12 semitones (E4) and keep the PB the same.
Now both notes are correct.
When playing virbrato on the last note we alter the PB, when we slide to a new note which is retriggered we set PB back to the original C3->C2 value, the LS already does this.
This would fix this problem.
If the last note is released it then starts using the previous note pressed and so on.
Another way of doing it is to offset the new note and keep the same PB value.
So for example.
First note is C3 slid down to C2, so now PB is at -12 semitones.
Then when a new note is played say E3 we need to offset that note by +12 semitones (E4) and keep the PB the same.
Now both notes are correct.
When playing virbrato on the last note we alter the PB, when we slide to a new note which is retriggered we set PB back to the original C3->C2 value, the LS already does this.
This would fix this problem.
Bitwig, against the constitution.
-
- KVRAF
- 2484 posts since 8 Jun, 2010
- Roger Linn Design
Now I understand and thank you for the clarification, BobDog. That item is a bug and is on our internal bug list:BobDog wrote: ↑Fri Nov 15, 2019 6:12 am I can explain how you can see what is going on with one of your LS, this is related to my original question but is not the problem but rather an issue with the LS code where if you have slid a note and hold it and then play another note the slid note changes pitch:
First both channel per row and one channel mode work the same, so choose one channel mode.
Now slide one finger and settle on a note and hold it there.
Then press another note.
You will hear the original note change pitch as the pitchbend is set to 0 for the new note which also effects the original note.
Now release the second note and you will hear the original note go back to its correct pitch.
Title: One-channel pitch slide is reset when 2nd note pressed.
Detail: In One Channel or Chanel Per Row modes, 1) press a note and slide it in pitch, then 2) also press another note (on the same row if Channel Per Row mode). Notice that the first note’s pitch bend has been reset to the start pitch.
The fix is to, when the second note is pressed, end the first note and immediately send a new note at the pitch slide’s destination pitch with no bend.
-
- KVRAF
- Topic Starter
- 1548 posts since 2 Apr, 2015
Hi Roger,
Yep that's it, the fix I gave in the post previous to yours would be a better solution though as then you wouldn't need to retrigger the bent note which would also sound strange.
So basically instead of retriggering the old bent note by calculating the midi note from the original note and PB you do the calculation for the new note instead and keep the original PB value.
Yep that's it, the fix I gave in the post previous to yours would be a better solution though as then you wouldn't need to retrigger the bent note which would also sound strange.
So basically instead of retriggering the old bent note by calculating the midi note from the original note and PB you do the calculation for the new note instead and keep the original PB value.
Bitwig, against the constitution.
-
- KVRAF
- 2484 posts since 8 Jun, 2010
- Roger Linn Design
Hi BobDog,
I see your reasoning but I fear your implementation would create more problems with subsequent additional notes, require complex code and make the solution bug-prone.
In the example I gave, let's say that the first touch slides 2 semitones, then you add the second non-slid touch. Your suggestion would be to terminate the second, non-slid touch and replace it with a new kludged note 2 semitones lower than the correct pitch so that the slid note's pitch bend of 2 semitones makes it the correct pitch. So what happens if you add a third touch then slide it? Or a fourth? That's a complex solution to keep track of in the code. I think it makes the code unnecessarily bug-prone for such a limited case.
I see your reasoning but I fear your implementation would create more problems with subsequent additional notes, require complex code and make the solution bug-prone.
In the example I gave, let's say that the first touch slides 2 semitones, then you add the second non-slid touch. Your suggestion would be to terminate the second, non-slid touch and replace it with a new kludged note 2 semitones lower than the correct pitch so that the slid note's pitch bend of 2 semitones makes it the correct pitch. So what happens if you add a third touch then slide it? Or a fourth? That's a complex solution to keep track of in the code. I think it makes the code unnecessarily bug-prone for such a limited case.
-
- KVRAF
- Topic Starter
- 1548 posts since 2 Apr, 2015
No, in my solution no note is terminated, all that is needed is to keep hold of the first notes PB value and the Linnstument already does this as it resets PB back to that value when the second note is released. It is no more complex for many notes as the only important thing is that first notes PB value.
If we take these basic premises which are true at the moment:
1. PB slides only work on the first note played and only if no other notes are played.
2. PB can be used to apply vibrato using the last note played.
3. Slides on any note when there is a previous note held trigger new notes.
If we have three variables:
1.NotePBRange : Pitchbend range of a single note, for example 341.33 for a range of +/-24
2.firstNotePB : The last PB value of the first note played
3.lastNotePB : The PB value from the last note playedrelative to this note.
Then the basic algorithm is:
1. Before sending note on message when no notes are already held send PB of 0.
2. Before sending note on message when at least one note is already held offset the note by note offset calculated from round(firstNotePB / NotePBRange) and set lastNotePB=0. We send a midi PB message of (firstNotePB + lastNotePB) before Note on.
3. Any vibrato is applied to lastNotePB and we send PB = (firstNotePB + lastNotePB).
This approach has the advantage of not retriggering any notes which would trigger envelopes on the synth and also of not quantising the original note if quantise is turned off. If quantise is off there is no perfect solution but to give precedence to the first note played we would offset lastNotePB by (firstNotePB modulus NotePBRange). I need to think about this a bit more.
I will have a look at the code and see if I can make these changes then you can try them out and if you like them merge them into your version.
I have also found some more problems, both related to having the first note bent:
1. When first note is bent and held (say -4094 PB), second note played and held sends PB=0, third and subsequent notes held sends PB=-4096 or PB=-2046 depending on the note played. To replicate this play c4 and slide down to c3 and hold, then hold e4, now play B3 and it sends -4096 PB, now release B3 and play E4 and it sends -2046 PB.
2. When first note is bent and held (say -4094 PB), second note played and held sends PB=0, third note is then slid produces strange PB values around -1354 as well as -4096 and -2046.
If we take these basic premises which are true at the moment:
1. PB slides only work on the first note played and only if no other notes are played.
2. PB can be used to apply vibrato using the last note played.
3. Slides on any note when there is a previous note held trigger new notes.
If we have three variables:
1.NotePBRange : Pitchbend range of a single note, for example 341.33 for a range of +/-24
2.firstNotePB : The last PB value of the first note played
3.lastNotePB : The PB value from the last note playedrelative to this note.
Then the basic algorithm is:
1. Before sending note on message when no notes are already held send PB of 0.
2. Before sending note on message when at least one note is already held offset the note by note offset calculated from round(firstNotePB / NotePBRange) and set lastNotePB=0. We send a midi PB message of (firstNotePB + lastNotePB) before Note on.
3. Any vibrato is applied to lastNotePB and we send PB = (firstNotePB + lastNotePB).
This approach has the advantage of not retriggering any notes which would trigger envelopes on the synth and also of not quantising the original note if quantise is turned off. If quantise is off there is no perfect solution but to give precedence to the first note played we would offset lastNotePB by (firstNotePB modulus NotePBRange). I need to think about this a bit more.
I will have a look at the code and see if I can make these changes then you can try them out and if you like them merge them into your version.
I have also found some more problems, both related to having the first note bent:
1. When first note is bent and held (say -4094 PB), second note played and held sends PB=0, third and subsequent notes held sends PB=-4096 or PB=-2046 depending on the note played. To replicate this play c4 and slide down to c3 and hold, then hold e4, now play B3 and it sends -4096 PB, now release B3 and play E4 and it sends -2046 PB.
2. When first note is bent and held (say -4094 PB), second note played and held sends PB=0, third note is then slid produces strange PB values around -1354 as well as -4096 and -2046.
Bitwig, against the constitution.
-
- KVRAF
- 2484 posts since 8 Jun, 2010
- Roger Linn Design
Hi BobDog,
I understand your logic but I'm uncomfortable with the added complexity of starting all subsequent simultaneous new notes with a pitch bend bias, because it opens up new edge cases to consider, and all for a relative little-used edge case of simultaneously bends in One Channel Mode, an edge case that so far one person has noticed. I'm afraid that if and when Geert has time to do work on this, I must let the implementation method be his decision, but I do appreciate your taking the time to detail your idea. By the way, you're welcome to code your implementation if you're feeling adventurous.
I understand your logic but I'm uncomfortable with the added complexity of starting all subsequent simultaneous new notes with a pitch bend bias, because it opens up new edge cases to consider, and all for a relative little-used edge case of simultaneously bends in One Channel Mode, an edge case that so far one person has noticed. I'm afraid that if and when Geert has time to do work on this, I must let the implementation method be his decision, but I do appreciate your taking the time to detail your idea. By the way, you're welcome to code your implementation if you're feeling adventurous.
-
- KVRAF
- Topic Starter
- 1548 posts since 2 Apr, 2015
Hi Roger,
No problem I fully understand.
What I might do is code up three different ways, two covering this issue and one covering the original thing I wanted.
1. Retrigger existing bent note with offset as per your preference and fix the PB sending bugs for > 2 notes.
2. Trigger all subsequent notes offset.
3. Allow new notes to be fully bent without note quantisation (for channel per row mode really)
I will have a look at the weekend if I get some time...
No problem I fully understand.
What I might do is code up three different ways, two covering this issue and one covering the original thing I wanted.
1. Retrigger existing bent note with offset as per your preference and fix the PB sending bugs for > 2 notes.
2. Trigger all subsequent notes offset.
3. Allow new notes to be fully bent without note quantisation (for channel per row mode really)
I will have a look at the weekend if I get some time...
Bitwig, against the constitution.
-
- KVRAF
- 2484 posts since 8 Jun, 2010
- Roger Linn Design
Sorry BobDog, I don't understand #3. If you code #2, the tricky part will be changing Geert's code for averaging in-cell x-axis movement of all touches--intended for vibrating chords entirely within the original cell--when one of them is bent outside the cell.
