Scheduler queue object?
How would one implement a standard scheduling queue in Pd?
You only need access to the earliest scheduled event.
I'm thinking in connection with [abl_link~]: You want something to happen at beat counter 52.0, and something else at 52.25. Something has to remember that.
hjh
@ddw_music
Or you could interrogate [text]
Or if Pd is originating the sequence then [qlist]
David.
[text] looks potentially useful for this. It seems, if Pd is running its own timing, then the ms timing is probably sufficient.
But ms are not sufficient for [abl_link~]. You need a waiting point to be triggered externally. As far as I can see, we're receiving the time point from [abl_link~], and we need to compare it to the current time index. [text] doesn't tell you that -- so, OK, the patch needs to maintain the current time point externally.
Ahh... so I sort of see the outlines of the approach. I don't have bandwidth right now to develop it, but I guess you would have to maintain a counter outside of [text]. When abl_link~ timepoint >= counter, then a/ fire the next batch from text and b/ counter = counter + time_delta.
hjh
@ddw_music Not sure if it is what you are looking for, but this might be interesting: https://www.chnry.net/ch/spip.php?article94
@ddw_music With [abl_link~] you are syncing Pd to the other programs at the audio rate.... the audio "is" the time.
I don't see how you need to compare indexes. They have to be the same, or the same +/- any offset you want to apply.
If Pd is not originating time you only need to process messages received from [abl_link~] at each dsp tick. If Pd is originating time then you need to send the messages at least once into [abl_link~].
Only one of the linked programs is controlling the audio.
I imagine that the "resolution" setting determines that messages are sent every dsp tick.
But maybe it is the [abl_link~] object that generates the control data from the audio rate sync?
Looking at the C code that looks to be the case. It seems to be calculating in microseconds with double precision floats.
I guess from the [abl_link~] help patch (I have not read the Ableton doc) that you can receive the beat index and the phase at every dsp tick.
The phase will be 0-1 I imagine, so a control rate equivalent of the output you would get from a [phasor~] object in Pd running at the same tempo and starting on the beat.
The updates are at block boundaries, but you have also received the tempo, so you can calculate to sub-sample accuracy within Pd and schedule events across boundaries.
You can do a [text] lookup every tick, but it would be cheaper I think just to accept the data or not when it arrives........ some method such as using [==] as above to trigger events.
The events triggered by the bangs would run completely before the next tick, unless you have a delay programmed...... but a delay programmed is a delay that you want to apply.
You could distribute the values to the [==] objects from storage arrays to use "presets".
@EEight Cyrille again!..... brilliant as ever.
David.
With [abl_link~] you are syncing Pd to the other programs at the audio rate.... the audio "is" the time.
I'm quite sure this is not the point of Ableton Link at all.
Link, AFAICS, does not follow a master/slave clock model. It's a cooperative negotiation among equal peers to maintain best-possible (or, musically useful) sync. There is no concept of Pd originating time, or not originating time.
When you use Link, you voluntarily sacrifice sample accuracy in exchange for a coherent musical pulse shared across multiple machines. Samples run according to the machine's local soundcard (and soundcards are famously inaccurate -- in SuperCollider, if I do s.actualSampleRate, I get numbers like 44099.234426884 or 44099.40771005, but never 44100.0). So a "beat" at, say, 120 bpm is not necessarily exactly 22050 samples -- but it doesn't matter because everyone is slightly inaccurate, together. (If typical musical events are at least 80 ms apart, inaccuracy within 1-2 ms will be undetectable to the ear.)
Here (connected to a SuperCollider client running a LinkClock at 60 bpm), the time between beat ticks varies between 998 and 1001.36. Most of the time it's 999.909 but occasionally it "adjusts" for the inevitable time variance between clocks.
The point of Link is, if I have a musical event that is supposed to happen on the "and of 2," then Link determines that time point to coordinate with the other machines, within an acceptable margin of error. Pd's sample clock is totally irrelevant to this. (Corollary: If you need sample accuracy, don't use Link.)
The phase will be 0-1 I imagine
Nope, it's 0 - (quantum-1). "Quantum" is a Link property corresponding to the number of beats in the bar. So my "and of 2" example should happen at phase = 1.5.
You can do a [text] lookup every tick
That seems wasteful. I would rather calculate the beat index for the next event and store it in a [float] box -- because this value is likely to be stable for hundreds or thousands of audio ticks.
@EEight The cue system seems a bit heavyweight for note sequences, but I might be able to steal some code design ideas from it 
hjh
@ddw_music The time variance is because the event was triggered within the last audio block and arrives before the next block is processed. So as the beat clock is not a perfect division of the audio clock it has to skip to compensate.
You are right that event inaccuracy at that scale is not important, so Link is quite accurate enough for events.
But for the audio it is vital that the programs are in sync because our brains are wired to detect phase, but more importantly the program hasn't got a clue what to do with data that doesn't match its expectations.
It doesn't matter what the sample rate is.
The point is that it is the same for all the programs that are linked by the audio, and so they have to be in sync.
They are using that common distributed clock, with a natural sync every 64 samples, if that is the block size chosen for the audio..... so every 1.45ms roughly at 44.1 with a 64 sample buffer.
They all have to process those chunks and spit them out in sync.
It is not difficult for a modern computer to calculate time at every sample, or we would not be blessed with ASIO, DAW's and all. My DAW will show me the calculated time stamp of every sample within the 64 sample window.
Every block must pass or there would be dropouts somewhere.
The soundcard also uses the same clock as it counts it's way inexorably through the blocks.
The computer doesn't make mistakes as it counts through the blocks, unless another process blocks the calculations for too long because of a deferred procedure call. DPC latency is something to look out for when running audio applications and there are some tools available for analysis.
But the answer is no, in that there is no inaccuracy in a computer until you reach the limits of its bit depth.
David.
I think that it doesn't matter what the sample rate is. The point is that it is the same for all the programs that are linked, and so they have to be in sync.
https://ableton.github.io/link/
Ableton documents no strict requirement that all connected applications must share the same sample rate. Reading this document, it seems to me that such a requirement would be contrary to what they are trying to achieve.
They are using that common distributed clock
The Link session state is defined in terms of tempo, beat and phase -- not samples. I believe it's up to each application to translate the session state into its own timing.
But the answer is no, in that there is no inaccuracy in a computer.
When two computers, or even two sound cards, are involved, there is no guarantee of the clocks running at exactly the same rate. If you set up two PD sequences on two different computers and start them in sync, within a few minutes, you will notice sync problems. To make them play together, it's necessary for one or the other or both to adjust timing periodically. If the adjustments are frequent enough and small enough, then they are undetectable to the ear (but they would be detectable if you record pulses to an audio file and count the samples between pulses).
So there may be no inaccuracy within one computer by itself. When you involve a second machine, then machine B is inaccurate from A's perspective and vice versa.
FWIW, I tried to hack up a quick beat sync but quickly ran into trouble (it was firing on every tick, instead of waiting for the next tick). Perhaps it's just that I'm not familiar enough with the Pure Data way of thinking, but I often find that things are unnecessarily difficult in PD. Maybe I'll try again later today.
hjh
@ddw_music Even with 2 computers, for audio to work they have to be synced.
That is how we can watch digital television or a podcast on our phone.
Of course the buffer sizes are then enormous, but they are synced and time is offset.
You are right of course that the clock rate will not be exactly the same in that case.
That is not a problem unless increased latency is a problem.
The answer is the same for the use of [abl_link~]
If you are running live audio and need low latency then you need a small buffer.
If not then everything can be in sync 3 weeks later, although that would be annoying.
You are conflating the calculations done in control messages with the clock of the audio thread.
Can [abl_link~] communicate between programs on different computers?
It would surprise me if it could, because as you say the clock will not be the same.
But it is possible. After all an external soundcard is "another computer".
Sample accurate flows are achieved across IP networks in systems such as Dante, by Audinate.....
so of course it can be done.
If you are looking for the next change in the beat value then [change] will filter the incoming data.
David.
Can [abl_link~] communicate between programs on different computers?
It would surprise me if it could, because as you say the clock will not be the same.
Erm... synchronizing multiple computers' musical timing over a LAN is precisely the primary use case for Ableton Link!
From the beginning, it's designed for groups of computer musicians to be able to play on a shared, synchronized, metrical timebase. If it can't communicate between programs on different computers, then Link has failed in what it set out to do.
For successful ensemble performance, sample accuracy is not necessary. So, Link does not enforce sample accurate sync. It may be possible for some applications to achieve sample accurate sync under some conditions, but this isn't a requirement for successful use of Link, and it isn't the primary purpose.
It might be the case in this conversation that your interests or priorities are very different from what Ableton Link is trying to do, so it's leading you to misinterpret the purpose of this component...?
hjh
@ddw_music Ok, you are right, I have not looked at using [abl_link~] so I don't know enough about it.
I wonder why they didn't go the extra mile then. Maybe they were blocked by a patent?
I am sorry to have got into the wrong argument as the thread developed.
David.
This lecture at Linux Audio Conference 18 explains it in detail:
https://media.ccc.de/v/lac2018-42-ableton_link_a_technology_to_synchronize_music_software
@whale-av "I wonder why they didn't go the extra mile then."
I think it's because that's not the use case. They weren't trying to copy ReWire.
I did get my patch to work. Sync is disappointing -- SuperCollider <--> Ableton Live is fairly tight, while SC <--> abl_link~ is not quite there.
hjh
FWIW I filed an issue at https://github.com/libpd/abl_link/issues/20 -- sync by Link's phase is not really up to it in Pd yet.
hjh
Oops! Looks like something went wrong!
