Couldn’t think of a better name, but the idea would be to have a note stream act as a gate for another note stream, effectively re-triggering the source pitches from stream A using the note-on/off and velocities of stream B
Stream A: chord progressions every bar: I IV V
Stream B: single note staccato pattern with various intensities: x–x--x—x-x—
Output “Pitches” from A combined with “Gate” from B: I–I--I—I-I—IV–IV–IV—IV-IV—V–V--V—V-V—
the core is the same as the arpegiator buffer, but the second stream is triggering the entire buffer. it can get really interesting if the 2nd stream is an euclidean generator, for example.
you can probably decide which midi channel the output notes are written to, with the assumption that if the output channel is the same as input A or B, the original input is suppressed.
I think things like these will become possible once we implement a special output pipe for being able to make use of MIDI mapped parameters with values generated withing Midihub. Then you’d produce messages into the special output, and those messages would control various parameters in other pipes, to achieve these kinds of effects.
Hmm, so could this to-be special pipe be used to implement a more traditional compressor/gate/ducker sidechain?
My use-case is different: I’d want note activity on a given channel to silence/mute activity on another channel, to work around a Pyramid defiency with handling fills.
Basically I’d like to have the main drum beat loop running on channel 10, and place drum fills on channel 11 and whenever fills play, automatically mute the beat on channel 10 for the duration of the fill. Should be applicable for other instrument fills too.
Intelligently handling the “duration of the fill” wrt short, non-overlapping percussion notes would probably need a more integrated effect approach, but then you can always play/program the fill notes to be longer I suppose.
It’s possible to arrange this manually with CC / FX automation on Pyramid, the trick I’m after is automating it. For a simple implementation, a note on message on the side-chain channel (eg 11, which is where the fills are) would start the silence/mute period on the “target” channel (eg 10 where the main beat is), and a note off would end it, unless there’s other overlapping activity. A more elaborate implementation would have some kind of attack/release controls (eg release only on next eight/quarter/half note regardless of side-chain note length), but note length should get the basic job done.
Am I right in thinking that this special output pipe now exists as Virtual Ports A & B?
If so, how would we use those messages?
I’ve been doing variations on this in max, for ten years now. Would love to implement it here, without relying on my failing laptop.
Side note:
My implementation would probably end up with a LOT of chains:
FROM A - send list of pitches to Special Output Pipe.
FROM B - filter down to one specific note. use that as a gate. Dispatch to specific channel out on TO A.
…multiply the FROM B chain times 16 notes, for 16 channels.
…and clone all of that, for the second pair of FROM ports.
So… 34 chains?
One extra complication:
My implementation does two things.
As described, the “pitch” stream is triggered by staccato notes from the “rhythm” string. I use a guitar metaphor – the first stream is one’s left hand, fretting the neck. The second is the right hand, plucking individual strings.
This works great, for staccato notes. If the second stream has longer held notes, they can (and will) overlap notes from one chord into the next. So, maintaining the guitar metaphor, my version also performs hammer-ons and pull-offs. By which I mean “while a note is plucked, moving the fret will change its pitch”.
Again, that’s for more legato rhythm streams. It sounds terrible if the incoming notes are staccato. And thus, that feature need be separate, to be enabled or disabled as needed.
(…so, maybe 50 chains)
Plus, as I said, variations…
…but let’s get the basics down first. Has what Olivier suggested become possible yet?
(worst case, I can port things to PD, and use midihub in conjunction with a Raspberry Pi. it’s just that much harder to share this solution, if it can’t reasonably be contained on one device)
Then you’d produce messages into the special output, and those messages would control various parameters in other pipes, to achieve these kinds of effects.
The Virtual Output ports are for routing data to Virtual Input ports, so stuff can be shared, etc…