Strange pitchbend behaviour in UFM (Pure Data)

[UncleWayback]

Hello there,

I'm sorry if this would be better off as an 'issue' on github - I can try that if you want, I have an account there but am still learning about it.

I am currently experimenting with User Firmware Mode in Pure Data, and have the following strange behaviour:

No problem with negative/left pitch bends, but positive/right bends show the following behaviour:

If starting from column 1 (0=buttons) can only bend that (1) cell. If starting from column 2 can bend that and the +1 cell (2 cells). And so on. Can bend as many cells negative as I want.

I haven't noticed this before and have been playing around a little while so perhaps it is something wrong on my end, but I wanted to raise the issue here just in case.

*

Also I wanted to start posting here so that when the time comes that I have something to share I will be able to post links and such.

The working title of my project is "Roger This". It will be a Pure Data framework for interfacing with the Linnstrument through User Firmware Mode, although some functions should also be available/usable without engaging UFM (though perhaps requiring one of the preset slots to be put aside).

(On that note, one more question: is there any possibility of sending the Linnstrument a midi message to change which user preset slot is currently selected?)

I hope to provide some expanded functionality and a basic framework for tinkering using the free and open source Max alternative/ancestor Pure Data. It's going quite well and the possibilities are quite exciting but it's a lot of work even getting to a basic stage and I better not say more than "I'm doing my best/working on it" until I have at least a v0.001 to share. I don't have much experience programming but have been playing with Pure Data for a few years now and am very fond of it, that's why I've gone this route as opposed to writing a custom firmware or something (also I only use my Linnstrument connected to my computer so it is no problem for me to go through a layer of Pure Data first, haven't noticed any latency).

If it all works out it should make tinkering with the User Firmware Mode that bit more accessible (if you consider Pure Data more accessible than learning to code the Arduino). I'm taking the approach of staying quite close to the existing functionality but expanding it, such that OCTAVE/TRANSPOSE also gives access to a scale designer, and PRESET will give a basic patch browser as well as program change, etc. The idea is to have a core or standard system/approach, that people could then use as a framework, so for instance we could code a bunch of different arpreggiators and sequencers in Pure Data, and share them as modules for Roger This.

I love my Linnstrument!
All the best,
Sam.

[gbevin]

Hello there,

I'm sorry if this would be better off as an 'issue' on github - I can try that if you want, I have an account there but am still learning about it.

I am currently experimenting with User Firmware Mode in Pure Data, and have the following strange behaviour:

No problem with negative/left pitch bends, but positive/right bends show the following behaviour:

If starting from column 1 (0=buttons) can only bend that (1) cell. If starting from column 2 can bend that and the +1 cell (2 cells). And so on. Can bend as many cells negative as I want.

I haven't noticed this before and have been playing around a little while so perhaps it is something wrong on my end, but I wanted to raise the issue here just in case.

Hi Sam,

I'm not sure I follow what you're describing, user firmware mode doesn't have the concept of pitch bends, only of X-axis data that is sent out as 14-bit MIDI CC messages. I suppose you're translating these to pitch bend in your software, so it seems that the problem you're seeing would be located there too. You can find all the details of LinnStrument user firmware mode here: https://github.com/rogerlinndesign/linn ... e_mode.txt

Take care,

Geert

[UncleWayback]

Hello Geert, thanks for your response - yes I am converting from the cc data myself. I have analysed a little more and can see that there is no problem until I turn the 'slide mode' (cc 119) on. I will copy and paste some print outs, as you know there is the MSB on 0-25 and the LSB on 32-57 with the slide data on 119.

Here is a quick slide from column 1 (all slides positive as negative is working without issue), as you can see as soon as the slide kicks in the ccs sending x data drop out:

49 33 8
0 1 8
43 33 8
0 1 8
37 33 8
0 1 8
32 33 8
0 1 8
26 33 8
0 1 8
20 33 8
0 1 8
8 33 8
0 1 8
4 33 8
0 1 8
1 33 8
0 1 8
0 33 8
0 1 8
1 119 8
2 119 8
3 119 8
4 119 8

(I truncated a bunch of vibrato to make it easier to read).

*

Here I do the same sort of thing, only starting from column 3, as you can see this lets me slide 3 cells before the x data drops out (in fact it just sends a zero, once only)

:

31 35 8
3 3 8
29 35 8
3 3 8
31 35 8
3 3 8
34 35 8
3 3 8
36 35 8
3 3 8
39 35 8
3 3 8
43 35 8
3 3 8
51 35 8
3 3 8
56 35 8
3 3 8
68 35 8
3 3 8
74 35 8
3 3 8
80 35 8
3 3 8
86 35 8
3 3 8
89 35 8
3 3 8
90 35 8
3 3 8
92 35 8
3 3 8
90 35 8
3 3 8
87 35 8
3 3 8
84 35 8
3 3 8
83 35 8
3 3 8
81 35 8
3 3 8
83 35 8
3 3 8
81 35 8
3 3 8
80 35 8
3 3 8
77 35 8
3 3 8
71 35 8
3 3 8
65 35 8
3 3 8
58 35 8
3 3 8
49 35 8
3 3 8
40 35 8
3 3 8
30 35 8
3 3 8
26 35 8
3 3 8
20 35 8
3 3 8
9 35 8
3 3 8
6 35 8
3 3 8
126 35 8
2 3 8
117 35 8
2 3 8
108 35 8
2 3 8
101 35 8
2 3 8
94 35 8
2 3 8
3 119 8
88 36 8
2 4 8
81 36 8
2 4 8
71 36 8
2 4 8
52 36 8
2 4 8
19 36 8
2 4 8
94 36 8
1 4 8
97 36 8
1 4 8
76 36 8
1 4 8
60 36 8
1 4 8
48 36 8
1 4 8
4 119 8
39 37 8
1 5 8
22 37 8
1 5 8
126 37 8
0 5 8
91 37 8
0 5 8
57 37 8
0 5 8
26 37 8
0 5 8
12 37 8
0 5 8
0 37 8
0 5 8
5 119 8
6 119 8
0 39 8
0 7 8
7 119 8
0 40 8
0 8 8
8 119 8
0 41 8
0 9 8
9 119 8
0 42 8
0 10 8
10 119 8
0 43 8
0 11 8

*

I hope that makes things clearer, I'm pretty sure the problem is coming from the Linnstrument and not the program, which is only reading the above. Sorry for the data dump and thanks very much for your time/attention!

[gbevin]

I can't reproduce this, I'm making assumptions about your data format since you didn't specify it, the first number is likely the CC value, then the CC number, then the MIDI channel. I'm using my sendmidi and receivemidi command line tools to check the behavior directly without relying on how PD or Max or anything else interprets MIDI data: https://github.com/gbevin/SendMIDI and https://github.com/gbevin/ReceiveMIDI

I start receivemidi simply with:

Code: Select all

receivemidi dev linnstrument

Then with sendmidi I do:

Code: Select all

sendmidi dev linnstrument nrpn 245 1
sendmidi dev linnstrument ch 8 cc 9 1
sendmidi dev linnstrument ch 8 cc 10 1

Then slide your finger on the topmost row from left to right, starting from any column, the CC data stream is completely continuous.

User firmware mode doesn't track slides, it only transmits the absolute X position, you can easily check that by setting receivemidi to 14-bit CC reception mode as such:

Code: Select all

receivemidi dev linnstrument cc14

You'll see a continuous stream again with changing CC numbers but a continuously increasing value that correlates to the X position of your finger.

[UncleWayback]

Hello, thanks very much for the pointers to your midi utilities - I see you included a linux makefile but I'm afraid I'm still learning - I can compile a program by following instructions like a robot but that's about it.

However I had a hunch: I recently started using the Linnstrument in left hand mode. I just went out of UFM, switched left hand mode off, went back into UFM and it worked - so I reckon that's the bug - does it (not) work for you too?

This is no biggy for me as I can just instantiate left hand mode via UFM, but it might be worth knowing about nonetheless - if of course it is the problem (it does seem a little strange that a setting from outside user firmware mode would make a difference?)

Sorry for the bother!

[gbevin]

Hi Sam,

Left handed mode was indeed the culprit, user firmware mode should in fact completely ignore it. I updated the firmware so that in the next update the handedness setting will have no influence on user firmware mode.

I also updated to readme on my midi utilities with build instructions for Linux, if you're interested.

Take care,

Geert

[UncleWayback]

Hey thanks Geert, that's super cool, will keep an eye out for the next firmware!

I also had a look at the updated readme and will give it a try later as your utility looks really handy - very much appreciated. The instructions are clear and building looks really straightforward, it is only that it is outside of my current experience and the 'make' tutorials are too involved considering how much work I still have to do getting ready for winter

All the best,
Sam.

[UncleWayback]

Greetings Geert - I found one more bug, but I guess it will be fixed by having settings not persist into UFM mode: first set bottom row to X=CC1, now go into UFM and slide from the bottom left, column 1 row 1 (counting from 1 ignoring buttons), right along row 1 - before you are half way the Linnstrument will exit UFM mode!

[UncleWayback]

(concerned a problem of my own, solved)

[UncleWayback]

(I wasn't sure the Linnstrument in UFM was always sending both the LSB/MSB - I did some research and sorted it out. Running Geert's receivemidi programme for comparison proved very useful and enabled me to see that I wasn't handling the 'running status' correctly. I now have a vanilla pure data patch that handles all midi messages properly and with minimal latency. There are reports that the native [notein] object can cause latency, and anyway it doesn't handle note off velocity. If anyone wants the patch let me know and I will attach it. I tried to do so but it gave me 'invalid file extension' for .pd, and the same when I tried changing it to .txt)

[UncleWayback]

The bug "low row being set to x=cc1 prior to entering UFM mode takes Linnstrument out of UFM when sliding from bottom left" still stands.

(Edit: Would these UFM/firmware bugs (if that's what they are) be better off on github? I can research a bit and try to file a proper bug report there? I need to test more later/tomorrow, but it happened once more even without having the low row setting on on the Linnstrument prior to entering UFM mode, this time it seemed random (although it was the bottom row still) and I was sliding negatively - I wasn't sending any MIDI so pretty sure the problem was internal. (I am currently taking it out of left hand mode before going into UFM))

[UncleWayback]

apologies, both for leaving this hanging a few days, and for the fact that this 'bug' was simply caused by the overlap between the 'data entry' CC numbers and the UFM x-data, and my own ignorance. I had been simply listening for CC 38 1/0 in order to check if the user had triggered the UFM mode from the linnstrument itself, whereas now I understand N/RPN a little better I am listening for NRPN 245 on channel 9 as the documentation clearly specifies (thus receiving the NRPN number before the data entry CCs re-routes them, but not otherwise). Learning curves!

[UncleWayback]

(and I have properly clocked the very complete midi implementation now, also, which answers my question regarding sending the linnstrument 'preset change messages'... thanks Roger & Geert for thinking of everything! (of course!))