New thru mode: "UnmutedChannels"

[hyperbolist]

Thru::UnmutedChannels

What is this?

A new Thru Mode UnmutedChannels, where only the messages on channels that are not muted will be sent back.

You may indicate (un)muted channels with an array of bool via setThruMutedChannels(), where true at index 0 means "all channels are muted".

NoteOff messages are always sent, even on muted channels in this mode, because otherwise any presently-ringing NoteOn events will ring out forever while the channel is muted.

Why does this exist?

This new Thru Mode allows for an Arduino-powered MIDI Thru box with dedicated hardware toggles for each channel, which may be placed directly after any sequencer to provide control over global track mute state regardless of the sequencer's own track mute functionality.

Why would that be desirable?

The Alesis MMT-8 sequencer allowed for a very fluid performance workflow, where global track mute state was independent of the patterns and was not saved or recalled when switching patterns. Every modern sequencer I've encountered violates the MMT-8 behavior, and insists on being clever about saving and recalling track mute state whenever switching patterns.

This new Thru Mode provides a somewhat elaborate way to replicate the MMT-8 behavior independent of any particular sequencer.

Note: The Sequentix Cirklon provides a "mute hold" feature which would do the same thing, but the Cirklon is unobtainium.

But, does this really belong here?

Given the niche use case, the potentially surprising NoteOff behavior, and the reasonably easy-to-imagine desire to allow all messages other than NoteOn pass through a muted channel in this mode, this kind of thing may be better implemented via a custom thru filter function as discussed in issue #40 here.

[franky47]

Thanks for the high-quality work, but as you say yourself, this is kind of application-specific, unless the MIDI specification has a concept of muted channels that I'm unaware of.

I'm more in favour of an implementation on the application side with the filter function proposed in #40.

Would you be interested in giving that implementation a shot ?

[hyperbolist]

Yes, I'll implement your proposal.

[hyperbolist]

Closing in favor of #232