In my project that's a kind of meta-demo you interactively create and rearrange scenes through a creative process, the Rocket integration automatically creates tracks as the scenes are created/removed/reconfigured.
This mostly works already, but as the creative process progresses the tracks just keep accumulating, even those which are no longer needed. When using emoon's RocketEditor it even leads to crashes because the obsoleted tracks never go away and eventually break some finite assumptions. (I've already landed a fix upstream there to mitigate the crashing issue)
I'd like to add something like FORGET_TRACK to the protocol and library, which the Demo would send the Editor. It'd just have the track id as a parameter, as a way of reporting to the Editor "this track I previously performed a GET_TRACK on and we allocated this id for, I'm discarding it and all its rows from my internal state, any keys sent for this ID now I'll be dropping on the floor". If we had no interest in recycling the track id, that would be sufficient already just to get the Editor to reclaim the relevant UI resources/visual space.
Things get more complicated if recycling the track ids of forgotten tracks is desired, due to how the track ids are implicitly allocated via GET_TRACK like an AUTO_INCREMENT mechanism. For recycling I think we'd need an explicit RECYCLE_TRACK which would be like GET_TRACK with the addition of the track id # to be recycled. Then the subsequent SET_KEY storm would come back out with the named track's contents, using the specified track id. So the Demo would initiate the recycle from its side, by knowing it has a forgotten track id to put to use it previously sent FORGET_TRACK for.
I haven't coded up anything in this vein yet, but I already have a substantial project onhand that could serve as a test bed for this functionality without too much effort.
Curious what upstream thinks of this, before I go too far on the implementation side of this.
In my project that's a kind of meta-demo you interactively create and rearrange scenes through a creative process, the Rocket integration automatically creates tracks as the scenes are created/removed/reconfigured.
This mostly works already, but as the creative process progresses the tracks just keep accumulating, even those which are no longer needed. When using emoon's RocketEditor it even leads to crashes because the obsoleted tracks never go away and eventually break some finite assumptions. (I've already landed a fix upstream there to mitigate the crashing issue)
I'd like to add something like FORGET_TRACK to the protocol and library, which the Demo would send the Editor. It'd just have the track id as a parameter, as a way of reporting to the Editor "this track I previously performed a GET_TRACK on and we allocated this id for, I'm discarding it and all its rows from my internal state, any keys sent for this ID now I'll be dropping on the floor". If we had no interest in recycling the track id, that would be sufficient already just to get the Editor to reclaim the relevant UI resources/visual space.
Things get more complicated if recycling the track ids of forgotten tracks is desired, due to how the track ids are implicitly allocated via GET_TRACK like an AUTO_INCREMENT mechanism. For recycling I think we'd need an explicit RECYCLE_TRACK which would be like GET_TRACK with the addition of the track id # to be recycled. Then the subsequent SET_KEY storm would come back out with the named track's contents, using the specified track id. So the Demo would initiate the recycle from its side, by knowing it has a forgotten track id to put to use it previously sent FORGET_TRACK for.
I haven't coded up anything in this vein yet, but I already have a substantial project onhand that could serve as a test bed for this functionality without too much effort.
Curious what upstream thinks of this, before I go too far on the implementation side of this.