Midihub changing presets by midi message

Hi everyone.
I am trying to get Midihub to change to preset number two. I send midi message program number two and nothing happens.

Exactly, what message do I have to send to midihub to get it to advance to the corresponding preset?


It depends on your settings: Need some help - one CC to change MH preset - #2 by Giedrius

I set up program change 0 for preset one, program change one for preset 2 & program change 2 for preset 3.
It Works as expected ascending in numbers, but descending, prgm 3 changing to 2 goes from preset 3 to 1 !

Separate question: When I try to populate presets 2 & 3 , the inserted [from saved] prest info doesn’t stick. I figured to just put the same saved preset in each and then modify 2 and 3. I renamed them to be unique but that doesnt seem to help…
There must be a body of knowledge I am missing here.Can you refer me somewhere…?
I can’t seem to upload a file, but here is what it looks like
Thanks for any&all response!
ps-to resonattor: am I a “moderator”?-I still can’t upload file…thx!

What do you mean by ‘descending’? Is it some controller that keeps sending Program Change messages each time a button is pressed? Could you verify that the expected Program Change values are sent?

Or otherwise, how are you producing the Program Change messages?

Could you elaborate what you mean by this?

Thanks for getting back to me-
Program change ; 1,2,3= ascending. 3,2,1= descending.

My settings:

-to TriplePlay [FTP] patch contains Program 0


RESULT-MHub goes to Preset A

–to TriplePlay [FTP] patch contains Program 1
RESULT-MHub goes to Preset B

----to TriplePlay [FTP] patch contains Program 2
Nothing recorded in Midi monitor!
RESULT-MHub goes to Preset C

Now Descending:
–to TriplePlay [FTP] patch contains Program 1
AGAIN, no midi activity recorded on A,B, or C

—to TriplePlay [FTP] patch contains Program 0
AGAIN, no midi activity recorded on A,B, or C
RESULT-MHub goes to Preset A

This has been tested many times with the same result
Looking at Midi Monitor, the obvious thing to do is switch MHub prhrm revive Channl to 2. But if I do that I get equally, but different nonsensical results.

I am stumped.

I think I figured this out ok. I wish the name of the saved patch on a given preset could be seen. It would be confirming.
Thanks for your response!

Is there anyway to upload a file that is being discussed so all can see? I only have a hyperlink option.

Giedrius, you had kindly sent me a patch that contained a filter for all but the CC’s I am using. But midi monitor shows it doesn’t work for me. I will show you how I inserted it into my working patch:

where should it go?

The MIDI Program Change messages contain an absolute number for a device to change its preset/program. I couldn’t detect any issues in going between presets in sequences of 1, 2, 3 and then 3, 2, 1. Midihub is only interested in the absolute program change number whenever it receives a PC message on the configured port and channel, and loads that particular preset.

The easiest way to know which preset you’re currently on is to be connected via the Editor and looking at the “Current Preset: n” at the top toolbar. If you don’t have any unsaved changes made to the preset, the Editor will automatically load up the current active preset from Midihub whenever it changes.

One possible point of confusion when dealing with program changes - unlike MIDI things like Channel numbers which are conventionally always 1 - 16, there’s no common base number standard for Program Change messages. Some devices may display the lowest and highest Program Change numbers as being 1 and 128, others 0 and 127. Midihub uses 0 - 127 range for display. So that means that Preset 1 on Midihub gets recalled by PC0, Preset 2 by PC1, and so on until Preset 8 by PC7.

What is the exact connections made to/from Midihub and which device is sending the Program Change messages to Midihub? The messages that Midihub is being provided with should be inspected first, whether they meet the exact expectations. This can be done by temporarily disabling or changing the port & channel that Midihub is using for its Preset changes, and looking at the MIDI Monitor pane in the Editor when the appropriate input pipe is selected.

The preset name is not saved in Midihub’s memory, however, the contents in the Description pane are saved, so this could be used as a help for identification.

Yes, either drag the file into the reply textbox, or use the little ‘upload’ button:


Let us know if this button is not available for you.

It very much depends on the way you’re building up your preset - every time an Input pipe appears, you could think that all of the incoming messages from that port are forwarded directly to the pipe on the right, containing exact copy of the data at each instance that input pipe appears in the preset. Therefore, you either have to place the same filters after every Input port if you want it completely gone, or use a Virtual input & output pipes to share the same preprocessing of data coming in from MIDI A. Or sometimes you want to filter out data only before certain pipes. It really depends on what you want your particular preset to do.

In the screenshot, I see that the 2nd pipeline would sort of duplicate the MIDI events coming from DIN-5 MIDI A sent to USB A output, depending on what its Filter is set to do, and might make the effect of CC Range Filter pipe unnoticeable to USB A output. (preset upload would help confirm if it’s indeed the case)

I’d suggest creating a new topic with a description of what you want your preset to do exactly, in terms of which kinds of MIDI events and their ranges you want to get forwarded to which destinations, list out the MIDI connections made to Midihub’s inputs and outputs, and attach the preset you have so far, then we can help make it achieve the set goals.

Hi Peter,
I thought I’d have a crack at moving you forward.

It took me a while to figure out what was going on in your ‘Live Setup’ post (with who saying what to who), but then I twigged you’re replying by email which seems to make a bit of a mess of the formatting!

I put a little PS about this below :arrow_lower_left:

Can you try replying within the forum website and see if you can upload Monitor screenshots there?

To recap before you try again

  1. set your Midihub so that it doesn’t respond to Preset changes:
    Screen Shot 2023-11-10 at 16.44.15
    (just so we can see what’s being output by FTP)

  2. Then up post a shot of what’s coming in when you do PC± on FTP:
    Screen Shot 2023-11-10 at 17.12.03
    (showing the selected pipe like here is generally useful too)


:arrow_upper_right: PS.

email formatting...

…can easily become cluttered, it seems
But you can introduce so formatting like in this example…

If you reply by email
>this will it appear as a quote in the topic flow

and this will

* appear as
* bullet points

with extra some space from a forward slash

and even a
or some **bold** or *italic* text!

like this

If you reply by email

this will it appear as a quote in the topic flow

and this will

  • appear as
  • bullet points

with extra some space from a forward slash

and even a

or some bold or italic text!

Thanks much for getting back to me and helping.
I see the formatted version to the right of what I type.

So I disabled program changes and Midihub, and changed patches on my MIDI Guitar to a patch that sends program number one in order to get input B.
Here is what it looks like
I don’t know why it is sending on channels one and two.

The behavior has changed. It now goes to a A,B,& C correctly.

However, it won’t go to D with program message three.
why, I wonder.
ps-this message look ok?

Yes very readable!

Notice in your Monitors shots, Peter, that the channel has changed:
First everything is Ch2 then Ch1
As MH Settings only allows you to pick one channel to listen on, only one of them is going to work.

I am not sure why it sends program messages on channel one and channel 2. This has to do with the Fishman triple play software in the FC one floor unit.
But, it doesn’t matter, seeing as that channel 2 is ignored anyway