you could easily convert relative time to absolute time in pd with a few objects around [qlist] for playing. vice versa, it should be quite feasible to convert absolute time to relative time for recording with [qlist]. i don't quite see the need for an external here.

Yes of course the conversion of relative / absolute time is not the issue: I needed to mention it because otherwise the second point (the real issue) couldn't be understood (or I should have phrased it in terms of negative time offsets).

The problem is I need to be able to add (at any time) a scheduled message whose time isn't necessarily "later" than all previoisly scheduled events.

Let's make an example. For the sake of simplicity I will keep using "absolute" times, though indeed I'd like to implement it in such a way that the time is always specified relative to the time when the message is _added_ to the queue (not relative to the time of the last event in the queue) - this would be in order to avoid infinitely growing times. But for now let's not think about time conversions.

It would work like this: (times are in milliseconds)

At time 0 the object is "started" (i.e. it starts counting time). At time 200 I send a message [add 3000 message1( This schedules a message "message1" to be output at time 3000

At time 1000 I send a message [add 2000 message2(

At time 2000 message "message2" is output

At time 3000 message "message1" is output

An easy way of implementing it in pure PD would be by using two [textfile]s or [qlist]s. Every time a new event is to be added to the queue, the existing queue is "scanned" and copied to a dummy queue, where the new event is inserted at the desired point; then the dummy queue is copied back to the nondummy [textfile]/[qlist]. The timimg would be managed with a [delay] or with the builtin timing funcionality of [qlist], whichever is simpler.

But this means that inserting an event takes a time linear with the number of events currently in the queue.

Since I need to accumulate thousands of messages, a part from being very cpu-greedy, this would probably cause audio dropouts when adding events to a queue already populated with thousands of events.

I also thought about an alternative, fast but memory-costly implementation, with thousands of "delay lines" (i.e. instances of an abstraction containing a [delay] and needed stuff), and a [poly] used to distribute incoming events to "free" delays.

But with a few thousands of instances of any object, the patch would take ages to load. I tried that! I dunnow if it would ever complete loading and work!!

Even if I implemented a binary heap in PD, I still need to store a vector of a few thousand lists, and the only way I know of doing this is to use a few thousand instances of [list append], so again I have the problem of load time.

By the way, is perhaps the loading time of a patch greater-than-linear with the number of objects in it? perhaps quadratic?