Inconsistent behaviour for empty clip slots

[Coupe70]

If I call /live/clip/get/name on an empty clip slot I get 'NoneType' object has no attribute 'name'.

But if I call /live/song/get/track_data x y clip.name and the queried range contains empty clip slots I don't get an error, but the value NIL for the empty slots.

The same happens for clip color and probably for other properties. I definitly prefer NIL over an error. This might also solve the problem with starting listeners you described here: https://github.com/ideoforms/AbletonOSC/issues/49

One thing to bear in mind is that calling start_listen for (e.g.) name or color on a clip_slot that is not populated does not work — because there is no clip in the clip_slot for Live to listen to. So if you wanted to keep a client updated with the correct colour of the slot contained in a clip, you would need to start listening for the presence of a clip in the slot, and then start listening to changes in that clip... which I appreciate may get a bit complicated...

[ideoforms]

I don't think the two are totally inconsistent; /live/song/get/track_data returns a record for every clip slot on a track, whether populated or not, and nil is the best way to indicate that a clip slot is unpopulated.

That said, I can see the logic in returning nil from queries that fail... as long as that logic ("nil means failure") can hold for every plausible query, so that it can be used as a reliable marker of failure. I've just been looking through the properties of each of the object classes, and I don't think there are any that can be nil...

• Names (etc) can be empty strings, but not nil
• List properties (e.g. /live/track/get/available_output_routing_types) can be empty lists, but not nil
• Int properties that can be "unset" (e.g. /live/track/get/playing_slot_index) tend to use -1 as a magic value

So I think probably returning nil would be a safe indicator of error. Would it make it significantly easier to use in the TouchOSC case?