crazy idea about group handling

[Levitanus]

I just made an extra track within reaticulate routed to the same destination as main instrument midi, for just usage of reaper autochasing of pr.change for control whether trumpet muted or not:
the first track has normal articulations, the second is used just for "settings" (yep, still the "settings" problem).
And then I thought if reaticulate can use additional CCs like pr change handler. I assume, that there will be problems with moving and displaying the current selection. But, for example, midi text can be used for displaying, and nothing for moving (e.g. if the place is wrong – it's user's fault, just delete the assignment).

What do You think about it?

[jtackaberry]

If I understand you right, you mean to use CC events in addition to the current program changes as a way get around the only-chases-the-most-recent-program-change problem of multiple groups?

I think, as you point out, the risk of having stray CCs lying around is pretty high. Especially since those CCs would have to be otherwise used by VIs on that track, so the user doesn't have much reason to have CC lanes for them. In that case, they're pretty invisible (and they probably should be anyway as it's kind of a kludge), so I can imagine there being all kinds of remnants.

In other words, I'm not really seeing how to make it work cleanly in practice.

[Levitanus]

I understand You now))
Generally, I'm thinking now about splitting pr change events by channels as Your architecture allows. But haven't tested yet...
Generally, I'm bothered much more about this issue. It really confuses the work)

[jtackaberry]

I'm going to close this issue as it's a bit too much of a kludge for comfort. I think perhaps we'd have better luck improving this situation by supporting Reaper notations. Something that will probably come in one form or another in the future.