On 2015-09-08 16:29, Alexandre Torres Porres wrote:
cause if so, as I understant it, it is "defined", but not to get into the technical discussion about programming languages. It's just a synonym to "reliable", and I think it is important to note that, because otherwise you can give the idea to people that it'll be chaotic and all, when it isn't (that happened to me).
it won't be chaotic. it also won't change - at least it won't change if you are using the same Pd-runtime.
i would put it that way: Pd currently has a way to explicitely enforce the order of execution of a DSP graph. this behaviour is documented *explicitely*, eg. in G05.execution.order.pd if your patch needs to rely on a certain execution order, you should use the documented way to enforce this execution order.
Pd has a long history of not breaking patches. this is one of its biggest strengths (and one of it's weaknesses, as it prevents fast addition of new features). so if you are using an undocumented way¹ of ensuring that objects are scheduled in order (e.g. by connecting A before B in order to have Pd schedule C before D), chances are high that your patch will still work next year. and the year after.
however, if a major bug was discovered and the only (sane) way to fix this bug would involve invalidating your assumption (that connecting A before B will schedule C before D), then i would argue that breking the current behaviour is *not* a regression (as long as the explicit way to enforce order still works). and then your patch will stop working (when used with Pd-0.63. and when you come complaining i will tell you that you should not have relied on undefined behaviour in the first place.
gfmasdr IOhannes
¹ and no: the fact that G05.execution.order exploits the undocumented behaviour to guarantee that the "wrong" flanger is indeed "wrong", does not count as documentation.