Convert looping playback engine to event-based approach #90
Description
Notes from Slack
Framework updates:
having a bit struggles with framework and progress is bit slow, because the code getting too complicated. currently the structure is class based which was good earlier when we didn’t had these new features. but now the is difficult to wire functions here and there.
i think we could restructure the speaker engine to have some event based structure. it would be clean and easy to understand. so modules just emit events and other can listen to events.
for example, if some speaker is in range, then emit the event “inRange” and frontend can easily listen to this to update polygons ui. and framework engine other modules can know when to start playing it accordingly. same for “loop”, “loaded” and other updates. this is also helpful to pass updates in react, because currently framework cannot initiate messages to template, only template can read framework state (unless callback functions are set).
this would also mean rewriting for other modes too and would take more time to test them. if urgent i can keep it as it is and try continue, but would not be very easy to understand and support new features. also might be difficult for any other person to continue later.
- option 1: rewrite with mixins, event emitter approach, but for now only progressive mode. for other modes, one would need to use older framework version until the modes are completed and tested throughly. drawback: updates to existing modes (prefetch and stream) not easy.
- option 2: work with same code structure, make another engine class, and mark current as _legacy , add an factory class to switch the engines for other modes which are yet supported in new one. drawback: need to add some checks in frontend for legacy or new when accessing engine properties. (edited)
halsey
Thanks for all this thinking and explanation. I like your idea of moving to an event-based approach as that does seem much more sensible at this point and easier to maintain…and perhaps more flexible as well?
If I understand it correctly, your Option 1 is basically saying we move to the proposed event-based approach, but initially only for the new progressive playback mode, which is what we are using for Invisible Choir. Eventually, we can “convert” all other playback modes to this same approach, but until we do that, we will have to use the old framework version.
I don’t mind using different framework versions for a little while and I think the benefits of the event-based approach are significant enough to merit going this way and not struggling with the class based approach we currently have t=for the progressive stuff.
It sounds like this is the direction you would prefer? LMK and we’ll take it from there. If I’m misunderstanding anything, I may change my mind, but you’ll let me know!