Output events that relate to articulations in different groups should activate the articulation in the other group

[jtackaberry]

Suppose we have:

//! c=long i=note-whole o=note:12/note:22,1/note:23,1
1 all-in-one long

//! c=legato i=legato g=2 o=note:22,65
20 legato on
//! c=legato i=note-whole g=2 o=note:22,1
19 legato off
//! c=long-light i=con-sord g=3 o=note:23,65
7 con sordino
//! c=long-light i=note-whole g=3 o=note:23,1
2 senza sordino
//! c=long i=note-whole o=note:12
3 sustain

If we activate program 1, it should also recognize that programs 19 and 2 in groups 2 and 3 will be triggered, and should activate these articulations in the other groups as if the user had triggered the keyswitch manually.

[jtackaberry]

This turns out to be awkward because articulations_by_output_event can only map an output event to a single articulation. We can see in the above example that notes 12, 22, and 23 actually map to 2 output events. If the all-in-one long program is moved below the others, then as the articulations_by_output_event map is constructed, it'll overwrite the other programs which we really want to find.

One alternative idea is to introduce a new art output type, which would simply invoke the referenced articulation by program on the given channel:

//! c=long i=note-whole o=art:3/art:19/art:2
1 all-in-one long

//! c=legato i=legato g=2 o=note:22,65
20 legato on
//! c=legato i=note-whole g=2 o=note:22,1
19 legato off
//! c=long-light i=con-sord g=3 o=note:23,65
7 con sordino
//! c=long-light i=note-whole g=3 o=note:23,1
2 senza sordino
//! c=long i=note-whole o=note:12
3 sustain

Then we can fully process the referenced articulations as if they were activated by program. Some care will need to be taken not to fall into infinite loops (program 1 invokes art:2 while program 2 invokes art:1) but that shouldn't be too hard.