I agree with the general design idea that pd should only provide the primitives so you do more useful stuff yourself. The only reason I think freezable delay lines should be implemented is because the data is already there in buffer, so copying it somewhere else is not too efficient, and not too pretty when you then need to use vd~s _and_ tabread4~s (or whatever). Freezing it should be free: you just need to _not_ increment read/write pointers and _not_ copy new data in.
Incidentally I notice that when you switch~ off a subpatch with a delwrite~, the delread~ just outputs some random stuff (I don't know what it actually is, but it isn't anything that was in the delay line). As an alternative, couldn't a switch~ed off delay line just 'freeze'? I think this would be more 'correct' if nothing else.
I promise this is the last time I mention this :). I just think, admittedly as a fairly new user who knows nothing about the inner workings, that there is too much emphasis on making new externals when perhaps the built-in stuff could be improved as well. It was just a suggestion in any case.
Chris I think you might need to look at the t3 objects in IEMlib which go faster than control rate (sort of) if metro is getting you down. Also sample-and-hold (samphold~ I think) is quite good for doing control-type things at audio rate especially with a phasor~. Good luck and keep up the good work everyone!
Stefan
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com