@ingox said:
Now my probably final approach to the topic: This version has all the benefits of the previous, but also the patch opens quickly now.
Cool! I can have a look at it later.
In my mixing abstractions, it's basically a simple substitution (and change some messages -- Spacechild's dcatch~ and dsend~ need "set xyz" while I recall msend~ / mreceive~ take "symbol xyz").
Incidentally, I finally decided about the block delay just to accept it and document it. The primary use case of a send is reverb, where an extra couple milliseconds of pre-delay isn't so bad.
I'm half thinking of proposing a feature request for "priority (float)" messages to DSP chains. That is, part of the reason for the [t] object is that a patch shouldn't depend on invisible information for ordering -- but, the DSP scheduler does handle delays and throw~/catch~ based on the order in which objects were created, and it's impossible to read in the patch, and quite obscure to control, and very easy to break accidentally. That's really unfortunate... but, in context of my mixing abstractions, I just decided that this is a design flaw in Pd and I'm not going to try to fix it. DSP chains would benefit from something like the way that [gemhead] uses float input. (SuperCollider has an edge here -- DSP order is completely under user control.)
hjh