Lots of audio nodes produced where none need be about adhere-lib

[nigelmegitt]

I'm pretty sure I've made a big dent in the overall scale of this in bbc/Adhere#84:

• the end times were being calculated wrongly, which is now fixed by updates to TimingCalculator and by correctly calculating the end time only when an element's descendants have been created. The effect of this bug was that some cues were active for way too long.
• Parser.markSpeech() had a logic error: previously when iterating through an element's children, as soon as any of them reported that they have speech, all the subsequent ones were marked as having speech too, even if they didn't. This has now been fixed. The impact was that too many nodes were created.

There's one further optimisation that we could make, which is, only create a pan node if pan is being modified, and only create a gain node if gain is being modified. Need to make sure we don't make it impossible to implement bbc/Adhere#78 in doing this though. I'm not really sure if it's worthwhile.

@robertbryer do you think the issue you originally raised has now been fixed, or are you still seeing significantly too many nodes?

[robertbryer]

There's one further optimisation that we could make, which is, only create a pan node if pan is being modified, and only create a gain node if gain is being modified. Need to make sure we don't make it impossible to implement bbc/Adhere#78 in doing this though. I'm not really sure if it's worthwhile.

I think that was the original point I was getting at with issue—it's why the nodes refer to this.input/this.output because the original intention was to allow them to just passthrough as an option (i.e., when you ask for a non-audio-modifying node's output, it could just return its parent's output instead). If you wrapped every <span> in their own <p> and then a <div> there would be a lot of unneccessary gain/pans. I haven't seen any performance problems or otherwise, so maybe it's not a problem to get exercised about right now.