Feature Request: Optional metadata field with musical key support

[tomglynch]

I'm happy to create a PR for this feature if it aligns with Link's vision. This request outlines the concept for your feedback before I start implementation work.

Overview

I'd like to propose adding an optional metadata field to Link that would allow applications to share musical information beyond timing, with an initial focus on musical key data. This extension is designed with strict backward compatibility as the primary requirement, ensuring no disruption to existing Link integrations.

Use Case

I currently use Link when connecting DJay Pro with Ableton Live and custom software. While the tempo, beat, and phase synchronization works wonderfully, I'd like to also share the musical key of songs between applications. This would be particularly valuable for:

1. DJs mixing between applications
2. Live performers who want to stay in the same key during a jam
3. Generative music apps that need to know the current key to produce complementary sounds

Proposed Implementation

I envision this as an optional field that:

1. Is 100% backward compatible with all existing Link clients
2. Uses the extensible protocol design to ensure older clients can safely ignore it
3. Contains a flexible metadata structure with key/value pairs
4. Includes specific support for musical key information (e.g., "C", "Am")
5. Has a "follow strength" parameter for how strictly to adhere to the key

Backward Compatibility Guarantees

The implementation would ensure:

• Zero impact on existing clients: Applications using older versions of Link would continue to function exactly as before
• No protocol breakage: The extension would use the existing payload mechanism that allows clients to ignore unknown fields
• Opt-in functionality: New API methods would be separate from the core timing functions
• Graceful degradation: In mixed environments with new and old clients, timing sync would work for all while metadata would be available only to clients that support it

Technical Considerations

• The implementation would follow the existing serialization patterns in the codebase
• The API would provide straightforward methods to get/set metadata values
• Performance impact would be minimal as the data is small and changes infrequently
• All changes would be made with the utmost attention to preserving the robust nature of Link

Next Steps

I'm willing to implement this feature and submit a PR if there's interest. Before proceeding, I'd like feedback on:

1. Is this kind of extension in line with the Link roadmap?
2. Are there any architectural concerns I should be aware of?
3. Any specific design requirements or constraints to consider?

Thank you for considering this proposal!

[vizzie]

I love this and have often thought about how this would be a nice addition to Link.

[fgo-ableton]

Hey @tomglynch,

Thanks a lot for the detailed proposal! I really appreciate it!

We have had this feature in our backlog for quite a while. Adding the required information to Link in the way you describe would surely be possible. However, the reason why we have never prioritised this is, that we could not come up with proposed client integrations that would make sense for a reasonable number of applications.
The concepts used to describe key and scale between softwares vary a lot. Also the benefit of sharing the information between peers in realtime is questionable. Even if a software has transposing capabilities and a global setting, the content usually is not automatically altered or something similar. Anything related usually requires manual user actions.
So my current guess is, that there is not much value in having this parameter in Link vs. just communicating it between jam participants in case it is relevant.

[tomglynch]

Hi @fgo-ableton

Thanks for your thoughtful response! I completely agree with your assessment regarding automatic alterations.
Based on your feedback, I think a more valuable approach would be implementing a general metadata communication field rather than one specifically for musical keys. This would allow jam participants to share information like:

• Musical key data
• Track/file details
• Artist information
• Other relevant session metadata

The key difference is that this would be purely informational - nothing would be automatically altered, just communicated between participants. This addresses the limitation you mentioned where there's currently no built-in method for jam participants to exchange information beyond timing data.

Would this broader communication layer align better with Link's vision? I'm still happy to work on a PR if this direction makes more sense.

Cheers

[fgo-ableton]

Hey Tom,

Thanks for offering to work on a PR! However, I don't think adding such generic communication capabilities to Link makes much sense. Link really aims at sharing information in a way that is meaningful for different kinds of peers. So the challenge is more about the specific data to share, and how to build an API around it that makes it reasonably easy to use for different kinds of apps.

If you want to share information that is somehow specific for one of your projects, I would recommend to add a different communication channel for your particular purpose. I.e. using multicast UDP in combination with OSC should get you close to what you are proposing.

Best, Florian