Add a track index track-info extension

[roelofvkr]

I've added a track index field to the track info extension. This should be entirely compatible with the current version of the extension, as long as plugins don't access the track_index field when CLAP_TRACK_INFO_HAS_TRACK_INDEX isn't set in flags.

[CLAassistant]

All committers have signed the CLA.

[abique]

Hi,

You can't extend the struct size like that, it'll break the ABI.

You have to extend this extension by making a complementary one.

Cheers,
Alex

[abique]

Extending the struct will break the ABI.

[roelofvkr]

Ohh of course, my bad, sorry. What do you mean exactly by making a complementary extension? Would you want to see an entirely separate extension for this, rather than appending it to this extension (and incrementing its version)?

In either case I think it'd be a good idea to make it possible to extend the track-info (or I guess the, would be, extended-track-info) without breaking the ABI like this. Maybe by passing in a set of flags, describing which fields the host can fill or adding a get_string/get_int getter by key (so new values can be added without breaking).

[roelofvkr]

Alright. I've added an extended track-info extension, which would allow plugins to read/write instance metadata in a more generic way.
This way of retrieving track info should be easily extensible to include more properties without breaking anything or bumping version numbers.

[abique]

This PR opens a few questions:

• should we have a generic key/value object in clap that could be re-used by other extension, so you'd implement this only once
• it is missing invalidation of the data
• index is simple, but what if you had the plugin path within the project instead?

I think there are two overlapping things here:

• a short term solution for being able to order multiple plugin instances
• a long term solution for understanding the project structure (tracks, tracks group, parallel containers, device chain, ...)
  If that is correct maybe we just go with a simple solution for the track index without a dictionary and then someone may need to start thinking about a more complex solution for the long term one. Maybe it could be receiving a stripped down version of DAW project (without plugin states, ...)

What do you think?

[baconpaul]

I think a key value approach here is smart, but think the host sho have a way to provide the available keys.

Interrsting question on if we want a generic key value extension Alex. Then this could just be the get the track info key value provider. It wouldn’t change the code much but would solve the next version of this problem

pond thought: hierarchical keys?

[roelofvkr]

Interesting thoughts. I think making a shared key/value extension, that can be reused by other extensions makes sense. It would also "solve" the invalidation, as you can say "when any of the track-info values are updated, the host must call clap_plugin_track_info->changed" (this is basically also what my thought was for invalidation in the current state, as it makes sense to me to reuse that same callback).

index is simple, but what if you had the plugin path within the project instead?

I'm not sure if having a path would make sense. I feel like you'd always end up trying to split the path into these components (sorting key/index for the track, sorting key/index for the instance on the track, name of the instance, possibly the name of the track). You wouldn't want to display a path directly I don't think, so unless the path is designed in such a way that it can be used as a sorting key, there wouldn't really be any gains over just using indices.

I don't think having a generic key/val store necessarily overlaps with having a bigger "project layout" extension, but they can complement each other. Let's say the project layout extension would return the project in a simplified DAWProject, you could then use the values provided like the track/instance index to look up information about a specific instance in the project. This way the project layout doesn't need to contain any instance-specific information and could theoretically be shared between instances.