Frank Barknecht escribió:
Attached is a very stupid example, which should show what I mean: Here various abstractions are layed out in a way, that they execute in order. Only one connection is used for order forcing, but still many s~/r~ are active, all properly ordered.
Oh, I see, thank you. At least that reduces the number of necessary wires to one, but I'm not sure that is viable in "real life". I'll try to think of some example. You still have to enclose receives within a subpatch, and if you need to connect it to the "outside" of the main patch, you are again facing the same original problem.... i think.
I will think of some simple-but-near-to-real-life example and post it.
In any case, at the very least, if order matters and you're building some complex patch, I think it soon becomes quite awkward and unmantainable.
I think it would be a great improvement to be able to impose (when one needs it) some precedence restrictions, i.e. dsp dependencies, between non-wired objects. For example, having a second optional creation argument in send~ and receive~ indicating a priority - or something. Pd would simply have to treat them the same way it treats dependencies forced by wire connections - and in case a loop is detected it would give the "loop detected" error (or a warning and ignore the restriction).
Without that, if I think of some of the complex architectures I built, if I had to modify them so as to guarantee sample accuracy, I'm afraid i would just have to port everything to something other than Pd....
By the way a similar improvement in the message domain would be the possibility to force an order among [r]s of a given [s]. In this case the interface would be simpler: just a numeric argument for the [r], for example: [s xxx], [r xxx 0], [r xxx 1], etc. where receives with the same number would be executed in unpredictable order.