I don’t see the need to have the 0-15 in the MIDI Channel Outgoing section. It just creates confusion.
How many times have I selected the wrong MIDI channel because of the number on the left???.
hehe there is no win one way or the other. I much prefer 0 based indexing especially as midi is a hexadecimal language and doing deeper stuff usually favours that
BUT
maybe a good compromise would be a display toggle to use 1-16 display and default to 0 based?
I beg to differ.
If people are into the “deeper stuff” then they will probably know that 0=1 or first.
I understand @Jesse.B no problem…
When you have been programming midi for 34 years…its pretty hard to not think of 0-15 in programming context but I totally get the frustration of 1-16 etc. I would prefer the rules didnt write back decimal when I specifically input hex…but I just go with the flow hehe.
0x00 - 0x10 = 1-16
On top of that most arrays are 0 based eg python, java etc
Why not just use a window preference so everyone is happy? I thought that was the most diplomatic way
Yes, I’m not sure of the right answer here. Even with my knowledge of MIDI channel number, I often mess this up. No matter what you do, I fear someone will get confused.
I’ll note the request however.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Yeah, when you’re working in BMTP everything is numbered down the left, except this. So it comes down to muscle memory I suppose.
Hi Jesse, I fully understand your issue! As you know, the reason for the mess is that channel numbers are usually referred to as 1…16, but in the actual MIDI message, they are 0…15 (a 4-bit nibble).
Why won’t we just always treat channels as 1…16 in the program? The issue is with variables. If you set a variable to the channel number, or set the channel to the value of a variable, it would cause much more confusion if the variable was in the range 1…16. So we tried to make clear that the program operates with 0…15, but in the ‘human display’, it is 1…16.
So here, you’re really setting the channel to 3 (because MT Pro operates on 0…15), but the display is ‘Channel 4’.
Now I understand that this way is not ideal. I also think that making it an option how to display channels will not solve much, because we cannot change the fact that MT Pro expects channel variables in the range 0…15. Only displaying channels in the range 1…16 will just ask for confusion when a user starts using variables for channels.
I am very open for a new way to let the user select e.g. ‘Channel 4’, but at the same time making sure the user can see that internally, this is the number 3.
Any suggestions?
@mwesse, I fully agree!! With the current project file format, this cannot be changed (Rules are saved in a tokenized format), but the next major version of MT Pro will have a new file format anyway. It will just save the Rules sections as plain text as typed – with all formatting.
See also: Keep number representation in hexadecimal format
Agree with all of that…I think the dialogs are a good compromise
Re Logging: Maybe just a bracket showing the “English” version or even a standardised bracketing so its a global reminder of translated info that can be switched on as a pref
eg
MIDI OUT [MCU_Control_DAW In]: 90 29 7F {- Ch1: Note 41: Val 127 -}
or something similar; that way whenever you see bracketing {- ??? -}, you know its the translated version…
Nice!
yes, that’s a good idea. To somehow mark the ‘Human’ representation so that it’s easily recognized as such.
Thats funny…
I thought you meant reading debug info in the outgoing section…not the UI dropdown.
I don’t even notice the first number…im auto just seeing the human second column
Yeah sure…its trivial but if it helps new users then great…i get you now
Thanks, to both of you! I have a good understanding now of how this can be improved.
Great!
If I was working in BMTP only, this would not be an issue. But jumping from a synth or a DAW (1-16) back to BMTP, has caught me out many times.
Hi, this has been improved in version 1.9.1:
Funny, without knowing this was improved I selected the correct channel first go. But then had to do a double take because it looked different.