Re: [PD] "G05.execution.order" issue (bug? just wrong?)

Actually even for one's own patches, Pd is supposed to go into read-only mode when you depend on creation order for deterministic behavior.  That is-- it shouldn't let you save the patch after that.  But there's a long-standing unfixable bug that lets you do it anyway. I make this joke with

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

Alexandre, Looking at your original question, G05.execution.order says the following: "If you're writing to and reading from a delay line, you have to get the write sorted before the read or else you'll never get less than a block's delay." As the others have pointed out, there are basically

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

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

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

On 09/09/2015 03:26 PM, Alexandre Torres Porres wrote: > 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. which is fair enough. (and which is why i actually tried to explain it...in the end). > but it's funny

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

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. 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

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

It might be a bit misleading to call this behaviour 'undefined'. As Alexandre points out, control execution is defined by the order the connections appear in the netlist and so have reliable results each time the patch is run. It's not really the same problem you have in other languages where

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

On 2015-09-08 11:52, Joe White wrote: >> >>> It might be a bit misleading to call this behaviour 'undefined'. >> why? > > > a) for the reasons pointed out previously ??? > b) by virtue of the fact that Alexandre is questioning it (and I would > agree with him) i was under the impression that

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

> > dunno what you mean by "connection order". The order of the "#X connect" statements in the patch netlist. > Pd totally ignores the order > of connections; what is important is the order of creation of the > connected objects. Technically it doesn't. You can remove and re-add an existing

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

not talking about connection order, but rather creation order. If you cut an object, and then paste it, it will jump to the front of the object queue. Say you created a [delwrite~] / [delread~] pair, in that order; if you cut the [delwrite~] and then pasted it back, then it would come after the

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

Oh yeah of course On 8 September 2015 at 11:04, i go bananas wrote: > not talking about connection order, but rather creation order. If you cut > an object, and then paste it, it will jump to the front of the object > queue. > > Say you created a [delwrite~] / [delread~]

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

On 2015-09-08 12:21, Joe White wrote: > Technically it doesn't. You can remove and re-add an existing connection > and it could change the order. > > Re-instantiating objects does the same, I assume the GUI is removing the > object (and connection) and then re-connecting it back up. ah yes,

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

wow, this is quite a technical and theoretical discussion, nice. but, keeping it simple and trying to avoid this nitty gritty completely, all I'm curious about is if I can *rely* on building a patch with order of creation/connection for both data and audio without trigger and subpatches. and by

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

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

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

Apologies for derailing the thread Ive saved the file and it is is now behaving the way I want every time I > open it, can I *rely* that it will always open and work like that if no > one edits the file changing the order of connections and everything? (As far as I know) you can be certain

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

I think that was what I trying to point in my original post. I believe IOhannes is referring to the fact that by looking at the patch it sometimes isn't possible to evaluate the correct order of operations, and therefore is 'undefined'. On 8 September 2015 at 15:29, Alexandre Torres Porres

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

> it's undefined. But how is it "undefined behaviour"? For trigger, for example, I understand the order of connections will define the order of messages being sent, right? I mean, every time I've tested it, it worked. But is it at some level really "undefined" and might not work? and what would

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

On 09/07/2015 07:16 PM, Alexandre Torres Porres wrote: >> it's undefined. > > But how is it "undefined behaviour"? For trigger, for example, I understand > the order of connections will define the order of messages being sent, > right? I mean, every time I've tested it, it worked. But is it at

Re: [PD] "G05.execution.order" issue (bug? just wrong?)

On 09/07/2015 08:01 PM, IOhannes m zmölnig wrote: > i hope this explains it. forgot this. gfmards IOhannes #N canvas 332 210 657 385 10; #N canvas 0 50 450 250 (subpatch) 0; #X array scope1 100 float 4; #X array scope2 100 float 4; #X coords 0 1 100 -1 200 140 1; #X restore 174 229 graph; #X obj

Re: [PD] G05.execution.order issue (bug? just wrong?)

On 2015-08-26 06:25, Alexandre Torres Porres wrote: Yes, you can get 'correct' execution order by just adding your objects in the right order. what is the right order then? it's undefined. (conceptually) it's the very same as using a fan-out without [trigger]: if you are lucky (or know the

Re: [PD] G05.execution.order issue (bug? just wrong?)

so, this is really fishy... here's another patch. Don't know what I did, in which order I connected them, but now the delay won't work for less than an audio block (64 samples) Nevertheless... if I go into edit mode e reinstantiate the [sig~] object, for example, it'll work! Then if I save the

Re: [PD] G05.execution.order issue (bug? just wrong?)

same goes with [send~]/[receive~] as I see it, so [throw~]/[catch~] and [tabsend~]/[tabreceive~] must behave the same way... 2015-08-26 0:46 GMT-03:00 i go bananas hard@gmail.com: Yes, you can get 'correct' execution order by just adding your objects in the right order. But it is unclear

Re: [PD] G05.execution.order issue (bug? just wrong?)

Yes, you can get 'correct' execution order by just adding your objects in the right order. what is the right order then? 2015-08-26 0:46 GMT-03:00 i go bananas hard@gmail.com: Yes, you can get 'correct' execution order by just adding your objects in the right order. But it is unclear

Re: [PD] G05.execution.order issue (bug? just wrong?)

the delwrite~ must come first (which is exactly what happens when you force the order by putting the delread~ into a subpatch. i would also guess that send~ must come before recieve~, etc etc. In all cases , you have to write before you can read. ___

Re: [PD] G05.execution.order issue (bug? just wrong?)

Yes, you can get 'correct' execution order by just adding your objects in the right order. But it is unclear from looking at the patch. Also, if you perform a cut and paste or rename your objects, you risk changing the order. Thus it is always safest to use the subpatch, as it will force the