A Choke Group In An Instrument Rack?

[otalgia99]

Hello once again.

Today's question: Is it possible to create a "choke group" type behavior for chains in an Instrument Rack?

Does anyone have suggestions on how this might be accomplished?

The choke group works great in Drum Racks, and I've taken it so much for granted that I don't even know how Drum Racks actually "do that."

I suppose that since Drum Racks link their chains to specific notes more directly than Instrument Rack chains do, it might be more programmatically feasible to say "these 2 notes may not sound at the same time."

But you can also assign note restrictions to chains in an Instrument Rack, and I wonder if perhaps some kind of MIDI device placed in the chain before the sound generator could say "This chain may not produce output at the same time as [note of other chain(s)] does."

...Or something.

My own current usage example is Solid Sounds' Kit Maker.adg -- it's providing some very useful sauce for me in a current set, but I can't choke them hi-hats!

o99

[maja-k]

I also have this question. In my case I have nested drum racks in an instrument rack. And I would like to choke on the instrument level.

But you can also assign note restrictions to chains in an Instrument Rack, and I wonder if perhaps some kind of MIDI device placed in the chain before the sound generator could say "This chain may not produce output at the same time as [note of other chain(s)] does."

Perhaps a chain selector? Mapping incoming note to activate only one chain?

[otalgia99]

I also have this question. In my case I have nested drum racks in an instrument rack. And I would like to choke on the instrument level.

Perhaps a chain selector? Mapping incoming note to activate only one chain?

I had this idea -- or something along that line -- as well. Now I might not understand your suggestion correctly, but the way I had considered such an approach, it then seemed to me to be potentially deeply labor intensive.

Imagine needing to draw in chain selector data for every single hi-hat sound tradeoff, for example. In shorter clips that get repeated, maybe that's not such a big deal... but sometimes one needs to break out of that paradigm just to shake things up.

A Note Range solution doesn't really cut it either I think, because while it could separate two related sounds, triggering the successive articulation of a sound won't suppress or mute the preceding one (such as with a closed hi-hat sound following an open one). Nothing about Note Range tells a sound NOT to happen...

Anyway, all of this is why I was hoping for a more programmatic approach -- something like a MIDI effect? But I'm probably dreaming...

o99

[otalgia99]

all of this is why I was hoping for a more programmatic approach -- something like a MIDI effect? But I'm probably dreaming...

o99

Considering further:
I wonder how difficult it would be to create an M4L "Note Off Generator." It could work a couple of different ways (any of which would be way beyond my Max skills!)

Example A: ("The Brute Force Approach") -- Create a device that gets placed on a chain (before the audio device of course) which "sees" its incoming Note On and sends a note Note Off message to a different note.

Example A In Usage:

- A closed hi-hat sound on its own chain
- With the chain's note range restricted to D1, let's say.
- On another chain, you have an open hi-hat
- With the chain's note range restricted to E1.
- Instantiate our imaginary device on the (D1) closed chain, before the audio device with the closed hat sound
- Set the Note Off Destination set to E1.
- When the D1 closed hat chain sees an incoming Note On message, its (imaginary) Note Off Device sends a Note Off message to E1.

Example B: ("Oh! The Subtlety!") Rather than designating the destination by MIDI Note Value, the device sees all other chains currently present in the Instrument Rack and allows you to select the note Off destination chain from a dropdown list of the other chains -- similar to the options that open up on a track's automation dropdowns.

In this approach, the note-designated destination functionality is shifted to chain-designated. I'm not sure why that's any more desirable than note value assignment, but in this example at least you'd get to name the device "Choke Chain," which kinda makes me chuckle.

Anyway -- you'd place one of these on any chain that needs to choke another one, and set them up to send Note Off messages when they receive Note On's.

All of this said however, I believe I have read that Note Off isn't universally recognized by devices. So it might be that some may not know what to do with the incoming Note Off!

Returning to actual work now,
o99