Feature Requests: 1) support for compound time signatures/beat subdivision; 2) support for non-sound tick feedback

[Magwitch2]

Some initial comments:

• Thank you for everything you have done so far, in terms of building and maintaining this package!
• If either/both of these features fit your desired scope, I'm happy to contribute effort where I can.

1. Support for compound time signatures/beat subdivision.
   a) Motivation:
   Metronomes with beat subdivisions can provide helpful feedback for musicians trying to improve their ability to play a specific note in time, as well as overall time-keeping. For example, practicing triplets in e.g. 6/8 time; or explicitly not staying synced with eight-notes in a 4/4 swing tempo.
   b) Current experience:
   Currently, in order to expose tick feedback for subdivisions (e.g. six triplets in 6/8 time), a developer would need to e.g. initialize time signature: 6, which keeps the measure feedback (accented sound every sixth tick), but loses the beat feedback (e.g. in 6/8: 2 beats per measure, on triplet 1/6 and 4/6).
   c) An example new experience:
   Although the default behavior is unchanged, an optional subdivision property can be initialized and queried (e.g. int? beatSubdivision), along with an accompanying audio file.
   d) implementation considerations:
   Are there logical defaults which preserve API simplicity (e.g. the subdivision audio file doesn't need to be specified, and is by-default a modulated version of e.g. the already-specified main file?; Does the tick call-back value change to include subdivision data, e.g. for the second subdivision of the first beat, a tuple (1, 2) or a double 1.2?

2. Support for non-audio feedback.
   a) Motivation:
   There are scenarios where audio feedback is not as helpful (or even possible) as e.g. visual (a pulsing graphic), sensory (e.g. vibration), etc. While some types of feedback (e.g. vibration) may violate e.g. cross-platform or other (performance, battery, etc) goals, I'm curious (with limited native mobile client experience) if some sort of visual feedback would be practical.
   b) implementation considerations
   [I have very little native mobile experience, so I don't have good instincts of what is reasonably possible and performant, what the user experience and level of customization should be, etc.]

Thanks again for all your contributions!