I guess this is a hack, but for keyOn and keyOff coming from the polyphony
code (which I traced from looking for `freq` references) I'm thinking
changing these in `poly-dsp.h` to further filter by channel at compile time
would be key?

        // MIDI API
        MapUI* keyOn(int channel, int pitch, int velocity)
        {
            if (checkPolyphony()) {
                int voice = getFreeVoice();
                fVoiceTable[voice]->keyOn(pitch, velocity,
fVoiceTable[voice]->fCurNote == kLegatoVoice);
                return fVoiceTable[voice];
            } else {
                return 0;
            }
        }

        void keyOff(int channel, int pitch, int velocity = 127)
        {
            if (checkPolyphony()) {
                int voice = getPlayingVoice(pitch);
                if (voice != kNoVoice) {
                    fVoiceTable[voice]->keyOff();
                } else {
                    fprintf(stderr, "Playing pitch = %d not found\n",
pitch);
                }
            }
        }

Change to:

        // MIDI API
        MapUI* keyOn(int channel, int pitch, int velocity)
        {
            if (checkPolyphony() & (channel == 1)) {  // to respond only to
MIDI channel 2, actual number is MIDI channel - 1
                int voice = getFreeVoice();
                fVoiceTable[voice]->keyOn(pitch, velocity,
fVoiceTable[voice]->fCurNote == kLegatoVoice);
                return fVoiceTable[voice];
            } else {
                return 0;
            }
        }

        void keyOff(int channel, int pitch, int velocity = 127)
        {
            if (checkPolyphony() & (channel == 1)) {  // to respond only to
MIDI channel 2, actual number is MIDI channel - 1
                int voice = getPlayingVoice(pitch);
                if (voice != kNoVoice) {
                    fVoiceTable[voice]->keyOff();
                } else {
                    fprintf(stderr, "Playing pitch = %d not found\n",
pitch);
                }
            }
        }

But yes, would be better to allow the polyphony/voice-table architecture to
be more standards compliant about channels, I'm thinking. I'll test this,
for now it will do if it works.

Aaron Krister Johnson
Music, etc.:
https://soundcloud.com/aaron-krister-johnson
https://soundcloud.com/filtercreed
https://www.youtube.com/channel/UC_utjGYbSizWE0dNyr0Vdmg
https://aaronkristerjohnson.bandcamp.com/
http://www.untwelve.org
Code:
https://github.com/akjmicro <http://www.untwelve.org>


On Sun, Sep 21, 2025 at 8:26 AM Aaron Krister Johnson <[email protected]>
wrote:

> Is this MIDI channel filtering option being considered? If not, would the
> dev team welcome a patch if I tried my hand at it?
>
> ~AKJ
>
> Aaron Krister Johnson
> Music, etc.:
> https://soundcloud.com/aaron-krister-johnson
> https://soundcloud.com/filtercreed
> https://www.youtube.com/channel/UC_utjGYbSizWE0dNyr0Vdmg
> https://aaronkristerjohnson.bandcamp.com/
> http://www.untwelve.org
> Code:
> https://github.com/akjmicro <http://www.untwelve.org>
>
> On Fri, Sep 12, 2025, 13:31 Aaron Krister Johnson <[email protected]>
> wrote:
>
>> Ah, so it seems others have bumped into this limitation.
>>
>> Please, Faust devs, implement this! :D
>>
>> Aaron Krister Johnson
>> Music, etc.:
>> https://soundcloud.com/aaron-krister-johnson
>> https://soundcloud.com/filtercreed
>> https://www.youtube.com/channel/UC_utjGYbSizWE0dNyr0Vdmg
>> https://aaronkristerjohnson.bandcamp.com/
>> http://www.untwelve.org
>> Code:
>> https://github.com/akjmicro <http://www.untwelve.org>
>>
>>
>> On Thu, Sep 11, 2025 at 2:17 AM <[email protected]> wrote:
>>
>>> Additional reading here:
>>> https://github.com/grame-cncm/faust/discussions/696
>>>
>>> All of this must be carefully considered...
>>>
>>> Stéphane
>>>
>>> > Le 10 sept. 2025 à 19:26, Aaron Krister Johnson <[email protected]>
>>> a écrit :
>>> >
>>> > P.S. -- and if this is implemented, covering key/vel/velocity, too :D
>>> >
>>> > Aaron Krister Johnson
>>> > Music, etc.:
>>> > https://soundcloud.com/aaron-krister-johnson
>>> > https://soundcloud.com/filtercreed
>>> > https://www.youtube.com/channel/UC_utjGYbSizWE0dNyr0Vdmg
>>> > https://aaronkristerjohnson.bandcamp.com/
>>> > http://www.untwelve.org
>>> > Code:
>>> > https://github.com/akjmicro
>>> >
>>> >
>>> > On Wed, Sep 10, 2025 at 10:23 AM Aaron Krister Johnson <
>>> [email protected]> wrote:
>>> > Thanks, Stephane, yes, it would be most useful to have a Faust synth
>>> only respond on a declared channel, and `0` (or no specification) being
>>> "listen on all channels".
>>> >
>>> > Would this be in the "options" header, then?
>>> >
>>> > Aaron Krister Johnson
>>> > Music, etc.:
>>> > https://soundcloud.com/aaron-krister-johnson
>>> > https://soundcloud.com/filtercreed
>>> > https://www.youtube.com/channel/UC_utjGYbSizWE0dNyr0Vdmg
>>> > https://aaronkristerjohnson.bandcamp.com/
>>> > http://www.untwelve.org
>>> > Code:
>>> > https://github.com/akjmicro
>>> >
>>> >
>>> > On Wed, Sep 10, 2025 at 9:00 AM Stéphane Letz <[email protected]> wrote:
>>> > Hi Aaron,
>>> >
>>> > MIDI metadata for standard MIDI control can use MIDI channel:
>>> https://faustdoc.grame.fr/manual/midi/#configuring-midi-in-faust
>>> >
>>> > But it is currently not possible to set a given channel for polyphony,
>>> you can see that the channel info is not used in the polyphonic code for
>>> now:
>>> >
>>> >
>>> https://github.com/grame-cncm/faust/blob/f5c23da4fe6e09fa55667ae588f4b6ef9c226cae/architecture/faust/dsp/poly-dsp.h#L900
>>> >
>>> > Should we extend/revisit the syntax of freq/gate/gain convention for
>>> something like [freq: chan],  [gate: chan],  [gain: chan], with the
>>> convention chan = 0 would mean « receive on all channels», like for other
>>> MIDI messages ?
>>> >
>>> > Stéphane
>>> >
>>> > > Le 10 sept. 2025 à 17:35, Aaron Krister Johnson <[email protected]>
>>> a écrit :
>>> > >
>>> > > I notice in the manual, certain MIDI slider metadata operations can
>>> be filtered by a certain MIDI channel, like `keyon` uses the velocity of a
>>> given key on a given channel.
>>> > >
>>> > > But IMO, these kinds of operations seem geared towards a
>>> non-standard way of using a MIDI signal. Most useful mono- or poly- synths
>>> would want to use the general
>>> > > keywords with special meaning: `freq/key`, `gain/vel`, and `gate` to
>>> drive the usually needed MIDI parameters in, for instance, a synthesizer
>>> signal chain.
>>> > >
>>> > > The problem I am having is: I'd like to pair a custom Faust synth
>>> with an outboard analog monosynth. Ideally, I could assign Faust to listen
>>> only on a certain MIDI channel.
>>> > > As it is, it seems like I have to do the opposite: Faust will
>>> respond to _all_ channels (not ideal) and I make the hardware synth respond
>>> to MIDI channel 2. They are isolated only
>>> > > by the fact that they are listening on different MIDI ports
>>> (otherwise, the Faust synth would be "hearing" both channels and trying to
>>> respond to both). What I have works for now,
>>> > > but let's say I want 2 Faust synths -- they'd both be responding to
>>> all channels that particular virtual port is listening on.
>>> > >
>>> > > So, in short: is there an easy way to make a running Faust synth
>>> instance listen only to a particular MIDI channel when it's designed to use
>>> the keywords `freq`, `gain`, and `gate`,
>>> > > per the docs? How easy would it be to hack Faust or add a feature
>>> for users for this if not?
>>> > >
>>> > > Aaron Krister Johnson
>>> > > Music, etc.:
>>> > > https://soundcloud.com/aaron-krister-johnson
>>> > > https://soundcloud.com/filtercreed
>>> > > https://www.youtube.com/channel/UC_utjGYbSizWE0dNyr0Vdmg
>>> > > https://aaronkristerjohnson.bandcamp.com/
>>> > > http://www.untwelve.org
>>> > > Code:
>>> > > https://github.com/akjmicro
>>> > > _______________________________________________
>>> > > Faudiostream-users mailing list
>>> > > [email protected]
>>> > > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>> >
>>>
>>>
_______________________________________________
Faudiostream-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Reply via email to