/name and /color clip listeners breaking

[Coupe70]

It seems like in common situations the newly fixed listeners are breaking. I'll describe examples for /name, but it's the same with /color (and maybe others?).

a) /live/clip/start_listen/name, 0, 0 on empty clip slot: Error handling OSC message: 'NoneType' object has no attribute 'add_name_listener' no clip present = no listener for clip name possible. So far, so good. b) /live/clip/stop_listen/name, 0, 0 on empty clip slot: No error. Deleting a non-existing listener is tolerated. So far, so good.

c) /live/clip/start_listen/name, 0, 0 on filled clip slot: Clip name is returned. Ok. d) /live/clip/stop_listen/name, 0, 0 on filled clip slot: Listener is stopped. Ok.

e) /live/clip/start_listen/name, 0, 0 on filled clip slot again: Clip name is returned. Ok. f) delete clip while listener is active: No message, no error. Ok. g) create new clip in slot: No message, listener seems to be gone. Would be logical, but: h) trying to stop the non-existing listener (which worked in b): Error handling OSC message: Observer not connected i) trying to start a new listener on newly filled slot: Error handling OSC message: Observer not connected

So it seems I'm losing listener access to the slot and I can't avoid it as when /has_clip indicates the clip was deleted, the listener access did already break. Functionality can be restored with /api/reload, but causing the problems described in issue #104 "/api/reload messes up listeners". So the only way to restore it is to de- and reselect AbletonOSC in Live.

[ideoforms]

I think the solution here is that the clip listeners need to be torn down whenever the corresponding clip is deleted, and then there should be no problem recreating them again. Will look now!

[ideoforms]

I've just made some tweaks and (g), (h), (i) should now work as expected and I've added a unit test accordingly. Let me know how you get on!

[Coupe70]

Seems to work, can't reproduce the problem anymore. Cool!

[ideoforms]

Great, closing 👍