[PD] space and time

jfm3 jfm3 at ouroboros-complex.org
Mon Apr 1 03:17:52 CEST 2002

I have given it some thought, and I recant my previous worries about Pd
extension languages with run time environments that provide automatic
deallocation. To summarize the arguments:

1) You can turn automatic deallocation off (i.e., no deallocation at
all) and on again later. This makes your composition/performance
environment have an additional mode, but no more so than it would if you
were doing hard disk recording of a particular performance, or loading
samples into memory dynamically.

2) With modern GC algorithms, as well as Python's
mostly-reference-counting approach, the bounds on time taken to do an
automatic deallocation is typically still well within the useful range
in a control signal processing system.

3) It is as hard to predict the time cost of a malloc() in most (if not
all) libc implementations as it is to predict how long an allocation
will take in a run time environment that provides garbage collection.
Only special purpose allocators are faster, and having automatic
deallocation in your run time environment does not preclude special
purpose allocators.

We think of moving the slider on the screen as having a deterministic
affect on the audio, and it does, but it is not really
time-deterministic. It so happens that the time it takes for the mouse
motion to affect the audio is fast enough so we don't notice. I'll go
back to not worrying about it now.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 184 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20020331/169e0e85/attachment.pgp>

More information about the Pd-list mailing list