@seb-harmonik.ar That's more elegant than what I did yesterday, thanks.

I'm still thinking through the tricky case of:

• Something scheduled near the end of a time slice.
• While waiting for that, a new item is pushed earlier.
  • How to know how much of the time slice has elapsed? [timer] I guess. EDIT: [timer] supports tempo messages!!!
• I guess I'd have to issue another tick to pick up the new item (the push message should probably do that). This invalidates the initial delay for the item near the end of the time slice.

I can almost see how to do it, need to sit down with paper and pencil for awhile.

hjh

With @seb-harmonik.ar 's suggestion, I think I've pretty much got it. I've tested the cases of:

• multiple events within one tick time slice;
• pseudo-recursively scheduling (an event popped out of the scheduler pushes a new event in);
• and that tricky case of scheduling for the future but before the queue's current top priority.

It needs usage testing but if it handles these cases, I think it should be ok. ("Should," of course, is at the top of the list of programmers' famous last words...)

One that I didn't test is scheduling something before the current tick (i.e. late scheduling) -- which is wrong usage but I'd want to be sure it doesn't break the queue. And I haven't tested tempo yet either.

hjh

This actually works:

At the beginning of each bar, it calculates a full bar's worth of hi-hat rhythm and dumps that into the scheduler. The sequence of time values is not sorted in the [pd resched] subpatch! It just naively dumps the events into the queue. Ticking the scheduler once per beat, the events come out in time order and the rhythm is coherent. (Someone might say "but you could just generate deltas and [delay] or [metro]"... but that doesn't enable the use of metrical position as a parameter.)

I'll probably change the interface to get rid of "push" and use one inlet for ticking and one for putting new data in. The logic... I tested the hard cases, seems legit. (Oh, and this also tests tempo, successfully.)

EDIT: And the late-scheduling case didn't break either -- late-scheduled messages come out as soon as possible after scheduling, and later events still happen with correct timing.

hjh

I decided to publish it using pdcontainer for now -- I've saved ingox's abstraction in case pdcontainer disappears at some point.

I haven't found a bad test case yet.

hjh

i wonder in which context you gonna need this.

normally it should be fine to move everything which is time critical into the scheduler queue, and move everything out of it which is not so important.

metro 1 anything is just brutal.

@Obineg said:

i wonder in which context you gonna need this.

Beats and bars.

Pd is a music tool but has no way built in to say, "I clicked on the start button at some arbitrary time, and I want the actual thing to start on the downbeat."

To do that, you need a clock with a time reference (otherwise there is no globally accessible concept of where the downbeat is).

Then you need something to pop out a message on time = a scheduler.

EDIT: I see, after the fact, that you can use timer to figure out elapsed time, round up, subtract and delay -- if Pd is in control of the timing. But if you're using abl_link~ or MIDI clock to sync with other devices, then Pd is not in exclusive control of the timing. In that case, advancing a scheduler by ticks is a good way to proceed (and you can substitute a metro in place of the external clock). So the one solution is "Pd is a solo universe" while the tick-scheduler is more general. (For that matter, in SuperCollider, all scheduling occurs in this type of queue. Implementing Ableton Link support was mainly a matter of replacing the internal beats-vs-seconds calculations with Link's and basically everything else worked for free -- LinkClock is a drop-in replacement for TempoClock. By contrast, a Pd patch based on Pd vanilla timing mechanisms only will be harder to adapt to Link, but a Pd patch based on a scheduler such as this one would be much simpler to adapt.)

hjh

@ingox said:

metro 1 anything is just brutal.

"tempo 84 permin" = 714 ms per tick. That's not brutal.

I realize that Pd convention is to use ms for timing but tempo messages are really really useful (even though makenote and pipe don't support them).

hjh

@ddw_music Ah sorry, i didn't see this.