[PD] [almost OT] need suggestions for an implementation

[matteo sisti sette]

> 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?


-- 
Matteo Sisti Sette
matteosistisette at gmail.com
http://www.matteosistisette.com