Release logic (multiple notes for release=trigger + rt_dead handling)

[paulfd]

Closes: #299

[paulfd]

At this point maybe it would be more "logical" to let the Region object be purely a data storage, and handle all the changes of the "status" of each regions within the Synth (i.e. instead of having the registerNoteOn and co. change the internal private status of the regions, all status variable are public and handled by the synth). What do you think?

[jpcima]

change the internal private status of the regions, all status variable are public and handled by the synth). What do you think?

Without a doubt yes. This helps to manage the complexity a bit as the software grows.
As source organization is concerned, there is an increasing number of sources at the root level which are purely utility, I would like these to be placed in a subdirectory preferably.

[paulfd]

change the internal private status of the regions, all status variable are public and handled by the synth). What do you think?

Without a doubt yes. This helps to manage the complexity a bit as the software grows.
As source organization is concerned, there is an increasing number of sources at the root level which are purely utility, I would like these to be placed in a subdirectory preferably.

Sure and sure. I'll defer the passive region in another pull request, and feel free to reorganize the sources 🙂

[paulfd]

I added tests and support for the rt_dead opcode. The behavior now matches sforzando/dimension, and the trigger=release regions will only sound if there is a corresponding attack sample, corresponding meaning compatible in the key and velocity range.

The architecture is not entirely satisfactory but I will defer overhauling the activations/dispatching in another PR. The tests added in this one will help ensure nothing breaks, and I will add a more comprehensive set in the upcoming PR as this is relatively easy to test programmatically.