umbang isep, sangsih polos

I finally finished the wayang samples, which means I need to start getting serious about notation for Balinese-style music.  The most basic level of that is dealing with pengumbang and pengisep, and polos / sangsih pairs.  Namely, I need notation that takes a single part and splits it into parts, whether unison, kempyung, or kotekan.  And of course, every time I think I have a general powerful system that can handle anything, I find out that even the most basic fundamental notation will require adding new features, or further generalizing existing ones.

I initially wanted to implement the "pasang" calls (which is my name for instruments that are actually pairs of instruments) by setting a part=polos or part=sangsih environ val, and letting the default note call apply the appropriate instrument.  But then I ran into the core problem which seems to underlie just about all notation problems: order of evaluation.  Namely, if I want to apply these calls to arbitrary notation rather than just single notes, they have to be postproc calls.  Only then do I have access to the flat stream of notes, and know how fast the concrete tempo is (to know if I can add noltol or not).  But at that point it's too late to ask the note call to emit sangsih or polos or both.

So the note call emits the nonexistent "pasang" instrument (e.g.  ">wayang"), and a postproc later looks at inst-polos and inst-sangsih env vars to split that into, say ">wayang-umbang" and ">wayang-isep", which are real instruments and have allocation.  Now we have yet another order of evaluation problem: by the time the postproc switches the instrument, the pitch is already determined.  Pitches delay evaluation and can continue to be affected by controls, but not environ, and the tuning is environ, not a control, so it's too late to change the tuning.

Notes from the TODO file:

Tuning is incorrect if postproc changes the instrument, because the new instrument doesn't bring its tuning along with it.  I could fix that by having the instrument bring its environ into scope during conversion as well as derivation.

• The easiest way is to move environ to Patch.  But this means Derive needs to look up Patch, or at least get a function for it.
• But Environ is technically code, since it has PitchControl, which has has a pitch signal.  So I can't save it unless I make a RawEnviron out of RawVal.  Hassle and complicated.
• Wait, environ is no good, because pitch doesn't take environ.  It's already baked in by the time the pitch is realized.  So I'd have to represent umbang/isep as a signal, e.g. umbang=0 isep=1.  It's a bit sketchy because umbang-isep is not additive, while PitchSignal.appy assumes all pitch-affecting signals are additive.  Do I want to keep the env var?  Try removing for now.  But for this to work, inst has to be able to introduce signals.  If I added that, it would basically be a one-off for this case.
• Now making pitches take environ looks more attractive: it means I can change the key after the fact too, the environ replaces rather than adds, and possibly even fits better with a mythical future unification of environ and signals.
• On the other hand, letting the instrument introduce signals could be a useful generalization.  Also, it seems like an umbang-isep signal could be a useful generalization, because it lets me explicitly place a pitch in the center.  Actually, %ombak=0 already does that.  So it's actually kind of non-orthogonal.
• Which is better?  I'm going with adding Environ to the pitch.  Who knows if that is the right choice, but I have to choose something.

Goals for today:

• Get this umbang/isep thing sorted out.
• Practice mridangam, lesson on Tuesday!
• Practice kendang for Semara Dahana to get ready for lesson on Friday.
• Sort out samples for mridangam and kendang, and figure out how to automatically infer dynamic levels.