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.