[Rey_a]

- In MIDI listening mode, the displayed MIDI channel is 1 below the actual channel.
So "(Channel 0) is dispayed, when actually the data was received over channel 1.

- The MIDI Actions defined in MSP only seem to respond to data send over MIDI channel 1.
I configured actions on both channel 10 and channel 1 in MSP.
When sending the corresponding MIDI data to MSP over channel 10 no actions were triggered in MSP.
When sending the data over channel 1, both the actions defined on channel 1 and 10 were triggered in MSP.
(MIDI channel 1 is also currently my default MIDI channel in the MSP settings)

- After checking the option "Allow Multiple MIDI channels", a quit from the Settings screens is required before the channel parameter actually appears in the Midi Action settings.

[Zubersoft]

When it comes to the channel, in code, it's all 0-based, so it's 0-15. This doesn't match the channel settings in the application that I display to the user, so I agree that the listen dialog should be updated to display channel + 1, so I've made that change.

MobileSheetsPro is set up right now to do processing on received messages on one channel - the channel configured in the settings for MIDI channel. The fact that I allow channel to be selected for MIDI actions is a mistake. If you look at the "Allow Multiple MIDI Channels" setting description, it states that it "Allows MIDI messages to be sent to multiple devices on different channels", but it isn't intended to be used to filter on channel on the receiving end. This limitation of receiving only on one channel is not a limitation of what I can support with MIDI - it's just an extra check in the code to allow messages from other MIDI channels to be ignored.

So this really brings up some larger issues:

1) Having a default MIDI Channel makes sense for sending messages, as you should be able to quickly change what channel you are sending all of your messages to. For users with a more complex setup, they can enable multiple channels and send their messages to multiple devices as required. When it comes to receiving messages, I'm not sure the setting really makes sense, or it doesn't make sense to use one setting for both. So I think I really should either not have a setting for the receive channel or separate this setting into two options: Send Channel and Receive channel.

2) If I do have a receive channel setting, I think I should add an "all" or "omni" setting, and that this should be the default so that you can receive on all connected channels. Do you think that should that be the default, or is it better to only receive on one channel by default? I'd like to hear feedback on whether filtering on the receiving end is useful to people.

3) When setting up the channel for MIDI commands, this was always intended to be just for sending. Is that sufficient, or do people also want this to apply to the receiving end so that you can only process certain MIDI messages on certain channels? This will drive whether I remove the ability to set channel for MIDI actions or leave it and change the way channel is processed.

I'll be curious to hear feedback on how people want this to work. As for the setting not taking affect, that is true, I'll need to add specific handling for changing that setting so it takes effect immediately instead of only after you leave the settings screen.

Thanks,
Mike

[NeoCZ]

1)I would prefer separate settings for Receive channel. I'm going to use MIDI channel that I don't use for anything else just to be sure I don't sent any wrong or unwanted command.
2) Also IMHO default setting for send and recieve channel should be the same - channel 1. It seems to be the safest setting when you start using MIDI and you can always change it to what you need.
3)I would keep the possibility to specify MIDI channel also for MIDI actions, but if recieve channel is not set to all or omni, MS should not respond to MIDI messages on other channel than specified one in recieve channel setting.

[Zubersoft]

Thanks for the feedback. Question on #3: are you basically saying that you should be able to provide both a channel setting for a MIDI action, and a receive channel, and if those two don't happen to be the same, I would not trigger the MIDI action? Is the thought process behind that that you can set up MIDI actions for a specific device, and then switch which MIDI actions are triggered based upon the receive channel?

[Rey_a]

The fact that the current default channel for sending is simply called 'MIDI channel' is allready somewhat confusing to me. In my opinion, it should better be called 'Default MIDI Channel', which reflects better what it is. (I know it is explained in the text, but I sometimes 'forget' to read that .)

1) For basic MIDI usage, I would prefer separate defaults for sending and receiving so:
a 'Default send MIDI channel' and a 'Default receive MIDI channel' or something like that.
Initially (factory settings of MSP) they could both be set to 1.

2) I am not in favor of a "all" or "omni" setting. It feels to me as an "easy" solution that will sooner or later lead to unwanted surprises when suddenly something gets triggered unwillingly. (A feeling even strenghtened by the fact that MSP now provides a 'MIDI Echo' setting...)
It is my personal opinion that if people use MSP for receiving MIDI and are capable of setting up control change or program change parameters they will also be capable of specifying a default MIDI channel for reception without any problems.


3) For more advanced MIDI usage, keeping the posibility for using multiple midi channels for receiving will allow for the most flexiple setup. So I would prefer it.
In my opinion, when multiple channels are activated, the default MIDI channel then should only be used to provide a default channel value when adding new MIDI commands, nothing else.

[NeoCZ]

Thanks for the feedback. Question on #3: are you basically saying that you should be able to provide both a channel setting for a MIDI action, and a receive channel, and if those two don't happen to be the same, I would not trigger the MIDI action?  Is the thought process behind that that you can set up MIDI actions for a specific device, and then switch which MIDI actions are triggered based upon the receive channel?

Yes, this is exactly why I would set it so. You can make a sets of MIDI actions based on MIDI channel and if it's needed, you can "filter" all channels but one out. Also if you need in some case to make quick MIDI action settings for new keyboard (yours is broken, you need to use different one, etc.), you can set them in minute or two without messing with your current actions.

[Rey_a]

I know 'Midi Actions' is not finished at this time, but  I just wanted to report that the up and down arrows (collapse / expand) are not showing on one of my devices (MSP 1.8.5)
See attached screenshot.

It is on Android 4.4.4 but I have another device also on 4.4.4 where the arrows are showing .

So probably not a MSP issue ...

[Rey_a]

[1.8.5] When restoring from a backup, the Midi Action settings get restored even with the 'restore settings' option unchecked

[Zubersoft]

Midi actions are stored in the database, not in separate settings files. Midi actions are too complex for me to store in standard Android preference files (or rather, I don't want to try to come up with some complex scheme to get that to work). Due to that, I can't really separate them out like the other settings. If this is really a major issue for you, let me know. In that case, I can add specific code to cache the MidiActions before the backup file is restored, and after the database is restored from the backup, I'll just overwrite the Midi actions with the previously cached actions.

Mike

[Rey_a]

Hi Mike'
Not an issue at all for me.
In fact it suits me rather well, the way it currently is working.☺

Just reported it because it does not follow the general logic regarding settings related backup/restore, so I thought it was a bug.
Wonder how other people would prefer this to work though?

Rudy