openAVproductions / openAV-Luppp

Luppp is a live performance tool, created by OpenAV productions.
http://openavproductions.com/luppp
GNU General Public License v3.0
256 stars 43 forks source link

Ableton Link support #303

Closed grammoboy2 closed 1 year ago

grammoboy2 commented 4 years ago

Feature request / thinking...

https://github.com/Ableton/link

For looping applications on Linux it might be more flexible then Jack Transport. Also looping with Jack Transport is not possible. I was thinking about this when I experimented with Luppp together with Non-Daw. Syncing with non-sequencer comes to mind, but also the possibility of applying automation to the output of Luppp (via non-mixer, non-timeline or a other tool). All these tools use Jack Tranport which is nice, cause the applications are synced, but it's also limited in some way. They've to join together from the start. Applications can't join in at a later point. When I was thinking about this, I found out that Ableton Link might do, what I had in mind. I'm not done thinking, but I post it here already. ;)

Bit related to: https://github.com/openAVproductions/openAV-Luppp/issues/302

More info: LAC2018 talk https://media.ccc.de/v/lac2018-42-ableton_link_a_technology_to_synchronize_music_software JACK link https://github.com/rncbc/jack_link Carla has Ableton Link support https://git.open-music-kontrollers.ch/lv2/link.lv2

grammoboy2 commented 4 years ago

FYI: Short discussion with the author of Jack Transport on IRC:

is Ableton Link a better alternative for Jack Transport when dealing with loops?

link is utterly different from jack transport, and they are barely comparable more than that. link's concept of "sync" is totally different it's not about absolute position as much as relative musical position (though absolute position is a thing too) anyway, the simple answer is "jack transport has no concept of loops, so ..."

there's already an implementation for JACK so in theory they just have to support JACK transport the problems are deeper than that though JACK Transport has 1 rather sophisticated concept that Link does not have that concept may not be useful for any app that keeps all of its data in memory but is essential for those that do not looping apps probably keep it all in memory

jack transport has the concept of a "slow start" client i.e. a DAW that needs to reload 64 tracks into memory to reflect the new position the actual transport mechanism won't start till all clients are ready (within limits) this makes it much easier to write such a client like a DAW

So for a DAW it needs that rather sophisticated feature, cause it needs to write from disk to memory, whereas a looping app might have it all in memory already, so it could live without that rather sophisticated feature. Do I understand it correct?

right

Your statement that in theory they just have to support JACK transport sounds rather... promising.

not sure what the status of rui's Link support code is at this time https://github.com/rncbc/jack_link

grammoboy2 commented 4 years ago

In the LAC talk, also osc sync is mentioned, but I can't find much info about it, other then this maybe

https://www.semanticscholar.org/paper/Simple-Synchronisation-for-Open-Sound-Control-Madgwick-Mitchell/fa139d63858ed49698153486191a29f181ce2e43

harryhaaren commented 1 year ago

Closing due to inactivity - its still a good idea, but unlikely to ever happen, unless some new dev shows up, sorry.