Channel per row - PB, loosing my mind?

[BobDog]

Hi Roger,

As far as I can see there is no code to average x-axis movement of all touches, only the cell for the last note played allows x axis (PB) movement on my LS anyway! Maybe I have some setting wrong somewhere?

Could you try it out on one you have and check, for example in one channel mode:

1. Play a note and hold it, wiggle and PB is sent for that note.
2. Play another note with the original still held, now wiggle the original and no PB is sent. Wiggle the second and PB is sent.
3. Now slide the original note to a new note this will trigger a new note on, now wiggle and this note is sending PB, wiggle the note from step 2 and no PB is sent.

Thanks.

[Roger_Linn]

Sorry, I was mistaken and you are correct. It's been a long time since that code was written. The vibratoing of chords occurs because all notes are being wiggled, but the x-axis movement is taken only from the last-pressed note of the chord.

[BobDog]

No problem, to be honest I thought it worked exactly how you said until I started looking at the midi messages being produced.

I will have a look at the code anyway when I get some time, I did set it all up again recently with a new fork and started looking at doing the code for maybe doing the curves on the Z and Y axis, got it to the point where it was building and I could get debug messages coming back and then stalled, so at least I have a starting point.

What we really need is a 36 hour day.

[BobDog]

Hi Roger,

You weren't mistaken there is code in there for multiple notes PB being averaged:

Code: Select all

        // if there are several touches for the same MIDI channel (for instance in one channel mode)
        // we average the X values to have only one global X value for those touches
        if (countTouchesForMidiChannel(sensorSplit, sensorCol, sensorRow) > 2) {
...

It only comes into play when 3 notes are held and is not working correctly as far as I can see, this is what is causing the strange PB messages when playing more than 3 notes when the first was bent.

Maybe something was changed latter that messed this code up, I am investigating...

[BobDog]

Hi Roger,

Concerning the fix:

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.

Do you want the new re-triggered note to have the original velocity, or the velocity of the new second note being played?

[Roger_Linn]

Hi BobDog,
My current opinion is that the alternate method is better and not bug-prone: when the second note is played, start a new note that has a different note number than the pressed pad, such that the first note's pitch bend makes the second note the correct pitch. On reflection, this isn't problematic because its state will be the same as if the second note had been played from a different pad then slid up to the target pitch. So if you agree, I think it's OK to focus only on this implementation. And if you agree, then it makes sense that the second note's velocity should be the velocity at which the second note was played.

[BobDog]

Ah good, I think from looking at the code today this is the also the easiest implementation as it is only dealing with current/future events rather than going back in time and altering past events; so we don't need to alter the stored state of the sensor and also there is a lot of code in there dealing with storing events ordered in time to do with the arpeggiator and I was worried about how going back in time to alter events would mess this up!

The averaging code for > 2 notes will need to change a bit, also maybe change it to > 1 note?

I also need to think a bit about the way it should all work when quantise is turned off.

I will have a bit more time on Saturday to look at it...

[Roger_Linn]

Ah good, I think from looking at the code today this is the also the easiest implementation as it is only dealing with current/future events rather than going back in time and altering past events; so we don't need to alter the stored state of the sensor and also there is a lot of code in there dealing with storing events ordered in time to do with the arpeggiator and I was worried about how going back in time to alter events would mess this up!

Yes, if changing some code looks like it might break something, best not to touch it.

The averaging code for > 2 notes will need to change a bit, also maybe change it to > 1 note?

That sounds reasonable. I'll ask Geert if he had a reason for doing the averaging only on 3+ notes.

I also need to think a bit about the way it should all work when quantise is turned off.

I'd say keep it simple. Just pick the corrected note number for the new note that's closest to the one suggested by current pitch bend amount. I think that will be fine.

Thanks for your help!

[rsavell]

Hello all,
Just got my new Linnstrument and it's fantastic. I play guitar as well as keyboard and have been exploring the channel per row implementation. I saw old posts about Bitwig not handling this mode properly, and as far as I can tell that is fixed in 4.0 so that's great! I still have a question about this particular issue, because it seems the new Linnstrument implements the original method where a 2nd pressed note pops a bent note back to its original value. Then releasing snaps it back to the bent value. This seems somewhat unintuitive to me. And I'm wondering if the fix you discussed in this thread was ever implemented. If so is there a software version available with that fix. I could foresee a problem resetting the original bent note's velocity, so perhaps you nixed the solution for that reason. At any rate. Fantastic instrument. It's gotten me back to making music after a long drought. Thanks so much!!!

[Roger_Linn]

Hi rsavell,
Thanks for buying a LinnStrument. I'm sorry to say that the required fix for this has not yet been implemented, but it's a priority for a next update.

[rsavell]

It occurred to me while playing the instrument and scanning back thru this thread that what the stringed instrument players might be expecting in the per row mode is actually more of a mono per row mode, which would be closer to the way a string player intuits the string interactions. I understand the value of the current channel per row instantiation as it allows directing your notes explicitly to different instruments via the midi mapping as opposed to round-robining, and one wouldn't want to lose that. So I think to satisfy the string player's intuition (and probably horn, woodwind and other instruments) would probably indicate a fourth mode. It seems at least superficially it would be simpler to implement than the problems you discussed here, as you would just need to maintain the current bend state of held notes and privilege the highest note for the mono output. I think that handles multi finger bends, hammers and pulloffs on a single row- but will need to think about the cases more.

At this point I guess the proper response is probably- It's open-source code Rob, give it a go! Sigh... Gonna break out that ide any second now... You know, on second thought, this channel per row mode is great the way it is. :-] :-] :-]
Cheers!

[Roger_Linn]

Hi rsavell,

That’s easy. Just set each row’s synth to mono mode. Mono mode is normally a feature of the synth, not the keyboard, regardless of whether the keyboard is a traditional midi piano keyboard or LinnStrument. So there’s no need to change the LinnStrument code.

[rsavell]

Duh. Of course. I usually mull something over longer before I start typing, but not today. Thanks!