MIDI

[librol]

Hello. Midi control does not work properly. I assigned CC commands with a value of 127 to scroll through banks, scroll through presets, and select snapshots. Each command is executed only once and does not work again. I tried combining the values ​​127 and 0 for the commands, but it also didn’t work correctly. 1.3.0
Thank you.

[rerdavies]

Sorry for the slow response. I've been recovering from a system crash on one of my development machines for the last few days.

The current logic appears to do the following: each binding triggers when the control goes from a value of less than 64 to a value that's more than 64 (leading edge, although the threshold value might not be the best choice). But sending 127 followed by a zero value should have worked. That may not be the best implementation. Expect a change here. I'll let you know what the fix is when I publish it. (Leaning toward triggering on a rising edge, regardless of the value, which would prevent floods of rapid program changes if the system bindings ever get bound to a rotary controller).

Also, as currently implemented, the first system midi binding in the list that has a matching control number is the one that is triggered, and subsequent bindings with the same control number are ignored. If, for example, you had previously bound your MIDI control to bank plus or minus, that would prevent you from using the same control number for program changes until you remove the binding for bank selection. Speculating a bit, but I half suspect that you stumbled across that bug.

So you know. Program and bank changes have to be performed off the real-time thread (plugins and media files have to be loaded from disk, and rebuiling the realtime plugin chain is too expensive to perform on the audio thread). It's an unfortunately complicated piece of code that tries to buffer midi commands until the program change takes effect. The code has been tested; but there may be more bugs here.

I'm probably also going to have to do something about system midi bindings preventing plugin control bindings from working. :-/ Unlike system bindings, You CAN use duplicate bindings for plugin controls. But, as currently implemented, binding a MIDI control with a system binding will prevent MIDI bindings to the same control ID from taking effect. Duplicate bindings to more than one plugin controls don't have that restriction; but binding a MIDI control to a system binding will prevent the plugin control bindings from working.

In summary, if you have duplicate control numbers, things may not work as expected. So be careful of that.

In the meantime, I suspect you may have better luck if you can get your midi controller to generate Note events instead. As a temporary workaround, that may produce more predictable results. System bindings should trigger whenever they see a note-on message.

Also worth considering: If you can bind your midi controls to MIDI PROGRAM changes, that would also allow you to change programs as well. (Program zero selects the first preset, program 1 selects the second preset and so forth). Pipedal supports both MIDI program changes and MIDI bank selects, but does not currently support MIDI increment/decrement RPNs.

Expect a fixes and improvements (and more testing) shortly. But in the meantime, you may want to try binding system controls to NOTE-ON midi events instead.

[librol]

Thank you very much for the detailed answer. I will take into account all your explanations. I used midi commands with different numbers, which led to the problem I described. I tried to use PC midi commands, but PiPedal does not see them, does not react to them in any way, there is no way to express them in the settings. I'll try the NOTE midi command. My controller is able to work with such commands, I have M-VAVE CHOCOLATE. Thank you! I'll be waiting for news.

…

20 нояб. 2024 г., в 04:54, Robin Davies ***@***.***> написал(а): Sorry for the slow response. I've been recovering from a system crash on one of my development machines for the last few days. The current logic appears to do the following: each binding triggers when the control goes from a value of less than 64 to a value that's more than 64 (leading edge, although the threshold value might not be the best choice). But sending 127 followed by a zero value should have worked. That may not be the best implementation. Expect a change here. I'll let you know what the fix is when I publish it. (Leaning toward triggering on a rising edge, regardless of the value, which would prevent floods of rapid program changes if the system bindings ever get bound to a rotary controller). Also, as currently implemented, the first system midi binding in the list that has a matching control number is the one that is triggered, and subsequent bindings with the same control number are ignored. If, for example, you had previously bound your MIDI control to bank plus or minus, that would prevent you from using the same control number for program changes until you remove the binding for bank selection. Speculating a bit, but I half suspect that you stumbled across that bug. So you know. Program and bank changes have to be performed off the real-time thread (plugins and media files have to be loaded from disk, and rebuiling the realtime plugin chain is too expensive to perform on the audio thread). It's an unfortunately complicated piece of code that tries to buffer midi commands until the program change takes effect. The code has been tested; but there may be more bugs here. I'm probably also going to have to do something about system midi bindings preventing plugin control bindings from working. :-/ Unlike system bindings, You CAN use duplicate bindings for plugin controls. But, as currently implemented, binding a MIDI control with a system binding will prevent MIDI bindings to the same control ID from taking effect. Duplicate bindings to more than one plugin controls don't have that restriction; but binding a MIDI control to a system binding will prevent the plugin control bindings from working. In summary, if you have duplicate control numbers, things may not work as expected. So be careful of that. In the meantime, I suspect you may have better luck if you can get your midi controller to generate Note events instead. As a temporary workaround, that may produce more predictable results. System bindings should trigger whenever they see a note-on message. Also worth considering: If you can bind your midi controls to MIDI PROGRAM changes, that would also allow you to change programs as well. (Program zero selects the first preset, program 1 selects the second preset and so forth). Pipedal supports both MIDI program changes and MIDI bank selects, but does not currently support MIDI increment/decrement RPNs. Expect a fixes and improvements (and more testing) shortly. But in the meantime, you may want to try binding system controls to NOTE-ON midi events instead. —

[librol]

Midi control via NOTE ON commands works well. Thank you.

…

20 нояб. 2024 г., в 04:54, Robin Davies ***@***.***> написал(а): Sorry for the slow response. I've been recovering from a system crash on one of my development machines for the last few days. The current logic appears to do the following: each binding triggers when the control goes from a value of less than 64 to a value that's more than 64 (leading edge, although the threshold value might not be the best choice). But sending 127 followed by a zero value should have worked. That may not be the best implementation. Expect a change here. I'll let you know what the fix is when I publish it. (Leaning toward triggering on a rising edge, regardless of the value, which would prevent floods of rapid program changes if the system bindings ever get bound to a rotary controller). Also, as currently implemented, the first system midi binding in the list that has a matching control number is the one that is triggered, and subsequent bindings with the same control number are ignored. If, for example, you had previously bound your MIDI control to bank plus or minus, that would prevent you from using the same control number for program changes until you remove the binding for bank selection. Speculating a bit, but I half suspect that you stumbled across that bug. So you know. Program and bank changes have to be performed off the real-time thread (plugins and media files have to be loaded from disk, and rebuiling the realtime plugin chain is too expensive to perform on the audio thread). It's an unfortunately complicated piece of code that tries to buffer midi commands until the program change takes effect. The code has been tested; but there may be more bugs here. I'm probably also going to have to do something about system midi bindings preventing plugin control bindings from working. :-/ Unlike system bindings, You CAN use duplicate bindings for plugin controls. But, as currently implemented, binding a MIDI control with a system binding will prevent MIDI bindings to the same control ID from taking effect. Duplicate bindings to more than one plugin controls don't have that restriction; but binding a MIDI control to a system binding will prevent the plugin control bindings from working. In summary, if you have duplicate control numbers, things may not work as expected. So be careful of that. In the meantime, I suspect you may have better luck if you can get your midi controller to generate Note events instead. As a temporary workaround, that may produce more predictable results. System bindings should trigger whenever they see a note-on message. Also worth considering: If you can bind your midi controls to MIDI PROGRAM changes, that would also allow you to change programs as well. (Program zero selects the first preset, program 1 selects the second preset and so forth). Pipedal supports both MIDI program changes and MIDI bank selects, but does not currently support MIDI increment/decrement RPNs. Expect a fixes and improvements (and more testing) shortly. But in the meantime, you may want to try binding system controls to NOTE-ON midi events instead. — Reply to this email directly, view it on GitHub <#255 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGWJDPDWYDRPMXIP3ZBC2AD2BPTWJAVCNFSM6AAAAABSAIF2QOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMZRGYZDOMI>. You are receiving this because you authored the thread.