DIfference between programs number in pgm file and programs loaded by Program Change MIDI event

[brunetton]

Hi,

Steps to reproduce:

• define this program file:

  1 {
     name="All off",
     drawbars="000 0000 000",
    }
  
  2 {
     name="All on",
     drawbars="888 8888 888",
    }

• lunch setbfree with this program file

• connect new setBfree output MIDI channel to any MIDI logger

• send to setBfree MIDI in: Program Change 1

• -> it loads the "All on" program, not "All off" program

Version: setBfree 9309bd4f9df02e99f7dee5841afc0b13c33d36ec (command line version)

[x42]

By default the CCs values for drawbars are inverted to work with motorized faders.

So drawbar "0" = Drawbar all the way to the top = Fader all the way to the top = CC value 127. while Drawbar "8" = Drawbar pulled out all the way = Fader at the bottom = CC value 0.

Try with a slight modification, that makes things more obvious:

1 {
  name="Almost All off",
  drawbars="000 0008 000",
  }

2 {
  name="Almost All on",
  drawbars="787 8888 888",
  }

And while you can configure this (suffix a minus (-) in the controller map, it seems to be a bug when sending feedback. I'll look into it.

[x42]

Since you do get feedback, I'll close #49 now.

PS. to test, try the following .cfg

midi.controller.reset=1                                                                                                                                                                        
midi.controller.upper.80=upper.drawbar16
midi.controller.upper.81=upper.drawbar16-

When you change the program, CC 81 will have the "inverted" (drawbar "0" (top) ~ MIDI 0) and CC 81 the normal (drawbar "0" (top) ~ MIDI 128) value.

[brunetton]

Thanks for your answer, and your reactivity ! But I'm afraid you miss my point on this one :s I'm using MIDI instruments for a while, and I totaly understand that drawbars are encoded in 7 bits so to encode 9 possible positions, you took regular intervals to encode different drawbars positions (I noticed those numbers in zynthian_engine_setbfree.py too). I also understand in your commit that you give a way to ask setBfree to "invert" value (127-value).

But ... I wasn't talking about that :)

I realize now that the example I took (drawbars) was not a good one. I initially choose drawbars to have a great visual feedback on program changes (since I'm using Open Stage Control for control, 9 faders moving from 0 to 127 at the same time are a clear feedback).

Let me try to say it in another way: I think that there is a shift between the program change MIDI in command and the program actually loaded.

Let's take another example:

1 {
   name="Perc On",
   perc=on,
  }

2 {
   name="Perc Off",
   perc=off,
  }

I think I'm right saying that the knob encodes its positions in that way:

• Off = 0
• On = 127

Given that configuration, here is the MIDI communication between setBfree and the controller (IN means: "controller -> setBfree" and OUT means "setBfree -> controller"):

IN: Program Change 0
OUT: CC 80 127   <= This is the program "Perc On", ie number 1, not 0 as asked by controller
IN: Program Change 1
OUT: CC 80 0     <= This is the program "Perc Off", ie number 2, not 1 as asked by controller

The problem here is that to load program n, we have to send Program Change n-1

Hope this is more clear this time ! And sorry for that :s

[brunetton]

PS: I always close the issues I open ;) But I take some time to test before closing !

[x42]

Is it the off-by-one that is confusing you?

There is no "Program/Patch Change 0" MIDI program/patches are numbered 1..128 (encoded as 0x00..0x7f) - Same for MIDI-channels: Channel 1..16 are encoded as 0..15 (There's no channel zero, although this can be vendor specific).

PS. so yes to load program "N" (1 <= N <= 128) You send a message 0xc0(N-1) on the wire.

[brunetton]

Answering to myself:

I just seen the default offset in config file ! Didn't seen it before !

## MIDI controller program number offset
## The value of this parameter should be equal to the number of the
## lowest program number on your MIDI controller. Some use 0 others 1.
##
#pgm.controller.offset=1

Setting it to 0 solve my offset problem :+1:

=> maybe this should be 0 by default ? I was surprised seeing this activated by default.

Thanks again, and sorry for the time you spent reading this !

[x42]

I forgot that that was there. and yes it's to follow some vendor-preferences. It's been a while since I've seen a device that starts counting at zero.

[brunetton]

Is it the off-by-one that is confusing you?

It was, yes

PS. so yes to load program "N" (1 <= N <= 128) You send a message 0xc0(N-1) on the wire.

Exactly. And I thought program number was [0-127] coded, not the "human friendly" value. Minor little thing that finally confused me.

Thanks again ... (I'll definitely have to pay you tons of beers !) :beers:

[brunetton]

I forgot that that was there. and yes it's to follow some vendor-preferences. It's been a while since I've seen a device that starts counting at zero.

Probably I have no chance on this point: my MK-361 starts counting from 0, and jack-keyboard (that I use for testing) too :s

[x42]

NIce, I have not seen a device that starts counting at zero in a long time. The 361 even has "000 Grand Piano" printed on it -- and I guess the 7seg LEDs also shows "000".

Anyway, there was indeed a bug about inverted CCs values (fixed now), so that's progress either way.