On 2/26/21 10:51 AM, Winfried Ritsch wrote:
@Dan: The numbering for order is a nice idea,
honestly, i really dislike it (i also don't really like the [gemhead] priorities; but i can't change that now).
priorities just make it *much* harder to reason about what is going on, as you don't easily spot them (they might be scattered in multiple parallel subpatches).
similarily [gemhead] priorities (or it's more general form of "receive"-priorities in [gemreceive]) are a very bad substitute for explicit ordering via [t a a a].
anyway editing a declare object is as fast (or faster) than open an dialog and settings some things somewhere. Maybe as an option -P <n> (priority from 1 to 32768
at least this is a thing that [gemhead]'s priorities got right: the values are floats. if you (as a user) prefer to use integers 1..32768, then of course you can do so (as this is a subset of the valid numbers), but you are not limited to it.
with priorities it's easy to get into a tight spot. pathA is 7 and pathB is 8, and you cannot change those priorities but need to insert pathC inbetween? "7.5" to the rescue. ah yes, and pathD needs to be squeezed right in there as well, so "7.4" is is. my old (locomotive) BASIC interpreter (but i guess this is true for all line-based BASIC interpreters) had this nifty 'RENUM' command that would tremendously help with that.
shudder.
gfdsmr IOhannes