<div dir="ltr">I just wanna know how it works... I'm not really making a case that I'd like to do it, I just want to understand the behaviour of Pd.<br><br>but it's funny how everyone emphatically insists to advice it shouldn't be done and stuff. Well, to calm everyone down, I'll come out and say I'll never do such a thing :)<div><br></div><div>thanks folks <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-09-09 9:17 GMT-03:00 IOhannes m zmoelnig <span dir="ltr"><<a href="mailto:zmoelnig@iem.at" target="_blank">zmoelnig@iem.at</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2015-09-08 16:29, Alexandre Torres Porres wrote:<br>
> cause if so, as I understant it, it is "defined", but not to get into the<br>
> technical discussion about programming languages. It's just a synonym to<br>
> "reliable", and I think it is important to note that, because otherwise you<br>
> can give the idea to people that it'll be chaotic and all, when it isn't<br>
> (that happened to me).<br>
<br>
</span>it won't be chaotic.<br>
it also won't change - at least it won't change if you are using the<br>
same Pd-runtime.<br>
<br>
i would put it that way: Pd currently has a way to explicitely enforce<br>
the order of execution of a DSP graph. this behaviour is documented<br>
*explicitely*, eg. in G05.execution.order.pd<br>
if your patch needs to rely on a certain execution order, you should use<br>
the documented way to enforce this execution order.<br>
<br>
Pd has a long history of not breaking patches. this is one of its<br>
biggest strengths (and one of it's weaknesses, as it prevents fast<br>
addition of new features).<br>
so if you are using an undocumented way¹ of ensuring that objects are<br>
scheduled in order (e.g. by connecting A before B in order to have Pd<br>
schedule C before D), chances are high that your patch will still work<br>
next year. and the year after.<br>
<br>
however, if a major bug was discovered and the only (sane) way to fix<br>
this bug would involve invalidating your assumption (that connecting A<br>
before B will schedule C before D), then i would argue that breking the<br>
current behaviour is *not* a regression (as long as the explicit way to<br>
enforce order still works).<br>
and then your patch will stop working (when used with Pd-0.63.<br>
and when you come complaining i will tell you that you should not have<br>
relied on undefined behaviour in the first place.<br>
<br>
<br>
gfmasdr<br>
IOhannes<br>
<br>
<br>
¹ and no: the fact that G05.execution.order exploits the undocumented<br>
behaviour to guarantee that the "wrong" flanger is indeed "wrong", does<br>
not count as documentation.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</div></div></blockquote></div><br></div>