About protocols aside Ableton link we have few standards to look like OSC, MidiHD...
I think the easiest could be OSC and it has interesting options already avairable (since midiHD still seems in development) and also yesterday read some about Ableton Sync (TouchDesigner propietary protocol) which could be useful too almost as reference. This last combine some OSC messaging with audio over net and specific Ableton scripts to syncronice transport and useful data between them.
http://opensoundcontrol.org/introduction-osc
http://www.derivative.ca/wiki099/index.php?title=Ableton_Live_and_TouchDesigner
Sharing my personal thoughts I will start from my usual "simplify as most" since even Artist like Plastikman, Beardyman or _Any_man have lots of resources (including coders) to fill their needs but maybe us have some more limitations :____V
But, if someone wants to push itself into the run or talking about improvements in these areas related to GTL (and/or iOS devices) maybe we can find some workarounds.
With the actual tools and without updating nothing (to start working today) we could:
* sync few GTL transport instanced devices with Ableton Link.
* link not AbLink supported destination clock with Link to midi & Midi sync Link apps.
* syncronize song parts with midi messaging as someone pointed.
* for style arranging/harmonization it could be possible use Midi Band and Midiflow in iOS and Hardware Arranger (or maxforlive devices like Schwarzonattor/Max7 standalone since it has m4l support and transport AbLink enabled) and the ubercool BomeBox.
Then,
As possible updates/improvements (and taking in consideration AB3 near update which could bring some sort of this crazy magic) my bet will be for OSC to avoid extra coding. It can handle most of the request and even has a better transport features (multicast with Master/Slave) than AbLink but few developers know about it and Ableton did an amazing work "hitting the focus nail" and releasing it as opensource.
From the OSC link above:
Features:
* Open-ended, dynamic, URL-style symbolic naming scheme
* Symbolic and high-resolution numeric argument data
* Pattern matching language to specify multiple recipients of a single message
* High resolution time tags
* "Bundles" of messages whose effects must occur simultaneously
* Query system to dynamically find out the capabilities of an OSC server and get documentation
Application Areas
* Sensor/Gesture-Based Electronic Musical Instruments
* Mapping nonmusical data to sound <-----------------
* Multiple-User Shared Musical Control <-------------
* Web interfaces
* Networked LAN Musical Performance <-------------
* WAN performance and Telepresence
* Virtual Reality
* Wrapping Other Protocols Inside OSC<-------------
So making the GTL core function library compatible with OSC could make possible "enhanced" syncro of transport and metadata letting users to build their own wrappers/translators in between or endpoint with max7 or pd. Time ago even was a dedicated hardware device to translate OSC to midi called "the missing link" but nowadays it should be trivial with a Raspi3/teensy2 and some "glue".
I left you some interesting links in this field for the brave nextlevelchamps ;)
http://opensoundcontrol.org/networked-lan-musical-performance
http://forum.cockos.com/archive/index.php/t-131257.html
http://propulseart.sat.qc.ca/en/Scenic
http://www.intact01.net/blog/2011/12/residencia-hangar/ |_____>
http://puredata.sergilario.com/patches/osc2midi2osc/melocoton/
https://www.bome.com/products/bomebox
http://www.synthtopia.com/content/2012/05/04/the-missing-link-wireless-oscmidi-translator-review/
Sorry if all of this is redundant to some of you or totally unrelated but I hope it helps someone searching for solutions and writting this made me feel a bit young (in the competitive mode) once again. It's strange how life goes back and forth sometimes.
Cheers.