Filter to virtual streams depending on polyphony

I want to be able to detect the number of notes held at one given moment so that I can have different streams for single notes and for chords.
So I want to make a filter that passes notes only if more than one note is held and I want another filter that passes notes only if less than two notes are held at the same time.
Is this doable?
What objects could I use for this?

Hello there,

Maybe the ARP pipe can be of use? Given an ARP will only return/output notes when it receives a chord, you could then transform these notes to what you are looking for.

But does it really split the signal?
Most arpeggiators I have used will “arpeggio” only one note as well by just repeating it at the given tempo, or move it up and down octaves if it is set to that.
And even if it does not do anything with the single note, I still have all the notes in the same pipeline, so there is no splitting of notes being done?

When the pipeline plays the arpeggio, you could dispatch the notes to different channels with the DISPATCHER pipe, then bring them all back on the same channel with a CH REMAP pipe, then with SUSTAIN pipe make it a chord again?

1 Like

Features like this seem easy to describe what you’d like to do, but very difficult to implement in a way that would feel natural and wouldn’t interfere with playing style, like you’d have to have some sort of delay windows in order to know whether the player is about to play a chord or whether just a single note. Also there’s a chance for a player to unintentionally play 3 notes instead of 2 for a very short time that could produce un unintended result.

It could be more intuitive to control and without delay side effects to dedicate certain octaves of the keyboard using Note Remap to send notes to the “<= 2 notes” section and another part (or entire keyboard?) to the polyphony section.

I don’t think any delay is needed?
As soon as you press more than one or maybe two notes it would select a different pipe and be routed to a different instrument.
So you would need to adjust you playing style and/or set a higher note number to avoid accidents, so maybe you would require three notes for the chord pipe because two would trigger too easily.
But I guess one problem would be to keep track of the note on messages?
So if one note is held and therefore routed to the monosynth pipeline, but then two additional notes are pressed so that it should switch to the chord pipe, then the original note should be re-triggered along with the other notes.
Is there any sort of memory or register that can hold the last played notes, keep track of witch ones are still held and then output all of them with a trigger?
I think that sort of functionality could be good in various situations.

So you want the very first two notes played to go one way, and the rest another? Then once all of them were released and there’s no note held down, send the next two notes one way, and the rest another? Is this how you’d intend to play the keyboard?

This could be possible, but would require very particular way of playing the instrument. However, dedicating note ranges for each instrument gives much more freedom for the player on note ordering and timing.

If I’m off in my thinking, could you describe what sort of effect you’re trying to achieve in terms of how you’d operate the keyboard and the expected resulting notes?

No I want all notes to go down one of two pipes at the same time.
So if I play single notes those notes go down one pipe, but as soon as I press more than one note I want all those notes to go down a different pipe.
So the two synths are never played at the same time.

Ill play with this a bit and see whats what. I have a few ideas. The routing part is easy, the question is how to send 1 trigger when only one note is pressed and a different trigger when more than one is pressed. There’s a problem I see though. If you are doing this playing live, when you press a chord all the notes are not going to come in at the same time so effectively making a input likely a single note. There would need to be some wiggle room to allow for more notes to come in to form a chord before switching but if you are playing live you wouldnt to wait for the note to sound.

I think its possible in a very constricted way but I don’t see how you could play live and get consistent expected results because there would be so much variation in timing that would be very difficult to account for. If it were a quantized midi file very possible, for live playing is iffy.

@JoeyButters I keep looking at this and every time I think I know what’s to be solved I look at another statement which casts doubt.

So the two synths are never played at the same time


if I play single notes those notes go down one pipe, but as soon as I press more than one note I want all those notes to go down a different pipe

Counterexample: when holding one note then, after a pause, playing a chord (whilst still holding the first), B contradicts A
… unless there’s an added stipulation of either ‘blocking new’ or ‘dropping old’ or ‘never play that way’. (or a myriad other things that would stop a given approach being appropriate…)

So, in the absence of a 2 channel .mid file showing the playing input and expected output (cf. @Giedrius very last comment), I’m forced back to saying to myself: Can’t solve a problem when you don’t know what it is.

Yeah, it’s sooooo many variables. I can see most of the problems and have ideas to solve all but the most important one. Switching a single note vs switching multiple note routing is easy. In my failures from working on a different patch, I ran into this issue/solution unintentionally.

For me it was a problem, but for op would solve 1 aspect of the bigger problem. I have a few ideas on solving how to switch if timing of a chord is not quantized. The only issue I have left to solve is… in my method, the first note is always going to go to the first synth, then any other notes that come in while the first notes pipeline is open will go to its own pipeline.

One solution I think may work is note 1 will go to pipeline 1 and pipeline 2 but when pipeline 2 is open, note 1 will quickly fade out. This is also a solution I ran into accidentally trying to solve my own problems.

The way I’m headed now is splitting the notes as in my strum patch with the dispatcher. 1st note will always go to channel 1 and channel 2. If a note is received on channel 3, it will trigger bypass of channel 1 and enable channel 2-10. . What’s left to work out is timing of all the switching.