Because it would be too slow in large instruments.
First of all, find_zone is too slow, that I never use it in prod. Only as pre-processor) But without zone_name(id) preprocessor starts to be a little bit more unstable and much more complex, including parsing files, within counting which sample is used in the particular instrument.
At the second, find_zone(name) is the operation of linear complexity, based on zones amount, zone_name(id) is the operation of constant complexity, and can be used, at least, to display what the sample is being played, not so unuseful, regarding the fact we can view zone in the waveform.
Remembered
@vosk, told me, "Cubase is only DAW can be used for orchestra, because of Instrument track 2.0"))
No, I agree with you, that it works as it works. But I pointed to the logical conflict of, at least, UX.
Anyway, if 3-4 AHDSR are used as operators of polyphonic value, I think, architecturally it would be cheaper than have a personal group per sample
PS.
any meaningful way apart from concatenation, or compare strings
also can't find any reason not to implement this:
- strings concatenation means they are not using char type, but string type. So strings still can be immutable, but still being dynamically allocated.
- Only ASCII symbols are allowed for strings, it is not too scary to compare them char by char. It's not more scary, than search(<array>, <value>).
- char by char comparison can be optimized not to go up to the worst case within every function call, opposite to search(), which would do it a bit more often