search

muellmusik / Utopia

This is an attempt at a generic library of tools for making Network Music Apps in SuperCollider
43 stars 8 forks source link

BeaconClock: Add 'numPeers' (from Ableton spec) for future SCClockMeterSync #25

Open jamshark70 opened 4 years ago

jamshark70 commented 4 years ago

Just throwing this out there while I'm thinking about it.

If you add the single-line method proposed here, then BeaconClock will be able to use a class that will be introduced in an upcoming SC release, to ensure that barlines and beatsPerBar match across the network. (The new class[1] is originally for LinkClock, but except for numPeers from LinkClock, it only uses standard TempoClock methods, so in principle it should be compatible with other beat-syncing clocks that follow TempoClock's interface. I tested, and BeaconClock actually passed! So, +1 for object-oriented decoupling.)

Scott, I remember I had asked you about barlines once before. This might actually take care of that.

a = AddrBook.new;
h = Hail(a, me: \peer1);
c = BeaconClock(a);
m = SCClockMeterSync(c);

[1] https://github.com/supercollider/supercollider/blob/343d4300746b218dab3e0e792cb787ecf10737dd/SCClassLibrary/External/Ableton/SCClockMeterSync.sc

muellmusik commented 4 years ago

Hey James! In principle this seems fine with me, and if you've tested it I don't see any issues? Does this mean that the Ableton integration has been reworked to a more generic sync interface? That would be very nice!

jamshark70 commented 4 years ago

In principle this seems fine with me, and if you've tested it I don't see any issues?

Seems harmless enough. Semantically, Ableton's numPeers includes only those that are reachable online at the moment, so I think this is correct (or maybe count the online ones is more efficient?).

Does this mean that the Ableton integration has been reworked to a more generic sync interface?

In short, no. This new class does nothing to sync beats, and Ableton has an advantage here over anything we can do in the class library because its network activity takes place on its own thread and can't be blocked by other sclang code.

The reason for the new class is that the relationship between our beatsPerBar and their quantum is not an exact match. The currently available version of LinkClock in fact doesn't behave correctly when changing meter midstream. The new approach follows Ableton's recommendation and adds a SC-only layer to keep at least our clocks' barlines together.

It just happened that refactoring it into a separate class opened up the possibility of applying it to other beat-syncing clocks.

It's true that Link is Ableton-branded (thus not generic) but it's also not SC-specific, so in that sense it's more generic. Tricky word ;)