[PD] Consistency Problem - OS X[intel] - when modifying Abstractions
Hi List, I notice a bug, thats coming back on OS X PD-extended. The occurs when i change an Abstraction, but not the original, but an active "instance" of a patch. Fpr example i have many instances of the same abstraction encapsulated in other abstractions. While patching i decide to change something - for example add an outlet - i open the instance change it and try to save it. PD seems to update all occurring abstractions and meanwhile the "parent-window" seems to disappear and it is not possible to save the patch anymore... I have to force quit PD after that. Strangely enough the change is saved in the abstraction. but of course it is totally annoying for the workflow. I think i had this issue before and it disappeared in a more recent release of PD-Extended for OS-X Intel I am sorry i cannot post an example patch right now, maybe tonight... For now i would like to ask if anybody is having the same problemand how to fix it, or maybe knows under which "subject" it might have been saved in the archive.. All the Best and a Happy New Year Luigi ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Consistency Problem - OS X[intel] - when modifying Abstractions
Did you ever find an answer to this? Or is there an example patch? I have seen some strange behavior that I am trying to track down. .hc On Jan 5, 2009, at 5:06 AM, Luigi Rensinghoff wrote: > Hi List, > > I notice a bug, thats coming back on OS X PD-extended. The occurs when > i change an Abstraction, but not the original, but an active > "instance" of a patch. > > Fpr example i have many instances of the same abstraction encapsulated > in other abstractions. > > While patching i decide to change something - for example add an > outlet - i open the instance change it and try to save it. > > PD seems to update all occurring abstractions and meanwhile the > "parent-window" seems to disappear and it is not possible to save the > patch anymore... > > I have to force quit PD after that. Strangely enough the change is > saved in the abstraction. but of course it is totally annoying for > the workflow. > > > I think i had this issue before and it disappeared in a more recent > release of PD-Extended for OS-X Intel > > I am sorry i cannot post an example patch right now, maybe tonight... > > For now i would like to ask if anybody is having the same > problemand how to fix it, or maybe knows under which "subject" it > might have been saved in the archive.. > > > All the Best and a Happy New Year > > > Luigi > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Consistency Problem - OS X[intel] - when modifying Abstractions
Ok, I get that too. First thing I notice is that some connections are failing. It looks like perhaps drum_module.pd used to have two outlets, but now it does not. Does this happen for you? Does this trigger the bug? drummer_main.pd 48 0 0 0 (canvas->message) connection failed drummer_main.pd 49 0 42 0 (canvas->message) connection failed drummer_main.pd 50 0 32 0 (canvas->message) connection failed drummer_main.pd 50 1 34 0 (canvas->message) connection failed drummer_main.pd 50 1 22 0 (canvas->unpack) connection failed drummer_main.pd 51 0 31 0 (canvas->message) connection failed drummer_main.pd 52 0 26 0 (canvas->unpack) connection failed drummer_main.pd 52 1 35 0 (canvas->message) connection failed drummer_main.pd 52 1 45 0 (canvas->unpack) connection failed drummer_main.pd 53 0 37 0 (canvas->message) connection failed drummer_main.pd 53 1 36 0 (canvas->message) connection failed But yes, I get the issue that you are talking about, I'll dig deeper. .hc On Feb 7, 2009, at 11:44 AM, Luigi wrote: > Hi Hans Christian... > > All on OSX(INTEL) 10.5.6 > > So lets see if you can reproduce this bug: i have Pd version 0.40.3- > extended > dont know which exact version from the "builds" actually > > so here we go: > > 1) Unzip the Archive > > 2) open "drummer_main" > > 3) with "right-click" go inside of "drum_module" > > 4) with "right-click" go inside "gg_midi_note" > > 5) do any modification > > 6) Type "CTRL-S" for save or choose "Save" from the menu > > > > Hope that helps > > would be great to find that bugger > > Best Luigi > > > > > > > > > > Am 07.02.2009 um 02:15 schrieb Hans-Christoph Steiner: > >> >> Did you ever find an answer to this? Or is there an example >> patch? I have seen some strange behavior that I am trying to track >> down. >> >> .hc >> >> On Jan 5, 2009, at 5:06 AM, Luigi Rensinghoff wrote: >> >>> Hi List, >>> >>> I notice a bug, thats coming back on OS X PD-extended. The occurs >>> when >>> i change an Abstraction, but not the original, but an active >>> "instance" of a patch. >>> >>> Fpr example i have many instances of the same abstraction >>> encapsulated >>> in other abstractions. >>> >>> While patching i decide to change something - for example add an >>> outlet - i open the instance change it and try to save it. >>> >>> PD seems to update all occurring abstractions and meanwhile the >>> "parent-window" seems to disappear and it is not possible to save >>> the >>> patch anymore... >>> >>> I have to force quit PD after that. Strangely enough the change is >>> saved in the abstraction. but of course it is totally annoying >>> for >>> the workflow. >>> >>> >>> I think i had this issue before and it disappeared in a more recent >>> release of PD-Extended for OS-X Intel >>> >>> I am sorry i cannot post an example patch right now, maybe >>> tonight... >>> >>> For now i would like to ask if anybody is having the same >>> problemand how to fix it, or maybe knows under which "subject" >>> it >>> might have been saved in the archive.. >>> >>> >>> All the Best and a Happy New Year >>> >>> >>> Luigi >>> >>> ___ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >> >> >> >> >> >> Man has survived hitherto because he was too ignorant to know how >> to realize his wishes. Now that he can realize them, he must >> either change them, or perish.-William Carlos Williams >> >> >> > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Consistency Problem - OS X[intel] - when modifying Abstractions
So the "consistency check failed: canvas_create_editor" also happens on Pd-vanilla 0.41-4 but seems to be fixed in 0.42-4. I checked this by copying the contents of "extra" into a Pd-0.42-4.app and running your app. If we can track down the fix, I'll backport it if it is not too complicated. "error: .x6cfc80: no such object" seems to be specific to Pd-extended, I think this is related to a bug I've been trying to track down. Basically the canvas seems to disappear on the 'pd' side, while the pd- gui side it is still there... .hc On Feb 7, 2009, at 11:44 AM, Luigi wrote: > Hi Hans Christian... > > All on OSX(INTEL) 10.5.6 > > So lets see if you can reproduce this bug: i have Pd version 0.40.3- > extended > dont know which exact version from the "builds" actually > > so here we go: > > 1) Unzip the Archive > > 2) open "drummer_main" > > 3) with "right-click" go inside of "drum_module" > > 4) with "right-click" go inside "gg_midi_note" > > 5) do any modification > > 6) Type "CTRL-S" for save or choose "Save" from the menu > > > > Hope that helps > > would be great to find that bugger > > Best Luigi > > > > > > > > > > Am 07.02.2009 um 02:15 schrieb Hans-Christoph Steiner: > >> >> Did you ever find an answer to this? Or is there an example >> patch? I have seen some strange behavior that I am trying to track >> down. >> >> .hc >> >> On Jan 5, 2009, at 5:06 AM, Luigi Rensinghoff wrote: >> >>> Hi List, >>> >>> I notice a bug, thats coming back on OS X PD-extended. The occurs >>> when >>> i change an Abstraction, but not the original, but an active >>> "instance" of a patch. >>> >>> Fpr example i have many instances of the same abstraction >>> encapsulated >>> in other abstractions. >>> >>> While patching i decide to change something - for example add an >>> outlet - i open the instance change it and try to save it. >>> >>> PD seems to update all occurring abstractions and meanwhile the >>> "parent-window" seems to disappear and it is not possible to save >>> the >>> patch anymore... >>> >>> I have to force quit PD after that. Strangely enough the change is >>> saved in the abstraction. but of course it is totally annoying >>> for >>> the workflow. >>> >>> >>> I think i had this issue before and it disappeared in a more recent >>> release of PD-Extended for OS-X Intel >>> >>> I am sorry i cannot post an example patch right now, maybe >>> tonight... >>> >>> For now i would like to ask if anybody is having the same >>> problemand how to fix it, or maybe knows under which "subject" >>> it >>> might have been saved in the archive.. >>> >>> >>> All the Best and a Happy New Year >>> >>> >>> Luigi >>> >>> ___ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >> >> >> >> >> >> Man has survived hitherto because he was too ignorant to know how >> to realize his wishes. Now that he can realize them, he must >> either change them, or perish.-William Carlos Williams >> >> >> > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ¡El pueblo unido jamás será vencido! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Consistency Problem - OS X[intel] - when modifying Abstractions
I'm not sure if this is related since I'm running winxp, but I was getting about seventeen of the following errors when closing test.pd on pd-vanilla 0.42-4: error: .xa22a90: no such object if I would: 1) open test.pd 2) right-click and open one of the instances of the ds-tgl 3) click the ds in editmode and delete it 4) save and quickly close the abstraction window (takes about 10 seconds) 5) close test.pd without saving (which takes about 5 seconds) But as you might imagine, putting the ds in its own gop window solved all these problems. -Jonathan --- On Mon, 2/9/09, Hans-Christoph Steiner wrote: > From: Hans-Christoph Steiner > Subject: Re: [PD] Consistency Problem - OS X[intel] - when modifying > Abstractions > To: "Luigi" > Cc: "puredata mailing list" > Date: Monday, February 9, 2009, 4:46 AM > So the "consistency check failed: > canvas_create_editor" also happens > on Pd-vanilla 0.41-4 but seems to be fixed in 0.42-4. I > checked this > by copying the contents of "extra" into a > Pd-0.42-4.app and running > your app. If we can track down the fix, I'll backport > it if it is not > too complicated. > > "error: .x6cfc80: no such object" seems to be > specific to Pd-extended, > I think this is related to a bug I've been trying to > track down. > Basically the canvas seems to disappear on the 'pd' > side, while the pd- > gui side it is still there... > > .hc > > On Feb 7, 2009, at 11:44 AM, Luigi wrote: > > > Hi Hans Christian... > > > > All on OSX(INTEL) 10.5.6 > > > > So lets see if you can reproduce this bug: i have Pd > version 0.40.3- > > extended > > dont know which exact version from the > "builds" actually > > > > so here we go: > > > > 1) Unzip the Archive > > > > 2) open "drummer_main" > > > > 3) with "right-click" go inside of > "drum_module" > > > > 4) with "right-click" go inside > "gg_midi_note" > > > > 5) do any modification > > > > 6) Type "CTRL-S" for save or choose > "Save" from the menu > > > > > > > > Hope that helps > > > > would be great to find that bugger > > > > Best Luigi > > > > > > > > > > > > > > > > > > > > Am 07.02.2009 um 02:15 schrieb Hans-Christoph Steiner: > > > >> > >> Did you ever find an answer to this? Or is there > an example > >> patch? I have seen some strange behavior that I > am trying to track > >> down. > >> > >> .hc > >> > >> On Jan 5, 2009, at 5:06 AM, Luigi Rensinghoff > wrote: > >> > >>> Hi List, > >>> > >>> I notice a bug, thats coming back on OS X > PD-extended. The occurs > >>> when > >>> i change an Abstraction, but not the original, > but an active > >>> "instance" of a patch. > >>> > >>> Fpr example i have many instances of the same > abstraction > >>> encapsulated > >>> in other abstractions. > >>> > >>> While patching i decide to change something - > for example add an > >>> outlet - i open the instance change it and try > to save it. > >>> > >>> PD seems to update all occurring abstractions > and meanwhile the > >>> "parent-window" seems to disappear > and it is not possible to save > >>> the > >>> patch anymore... > >>> > >>> I have to force quit PD after that. Strangely > enough the change is > >>> saved in the abstraction. but of course it > is totally annoying > >>> for > >>> the workflow. > >>> > >>> > >>> I think i had this issue before and it > disappeared in a more recent > >>> release of PD-Extended for OS-X Intel > >>> > >>> I am sorry i cannot post an example patch > right now, maybe > >>> tonight... > >>> > >>> For now i would like to ask if anybody is > having the same > >>> problemand how to fix it, or maybe knows > under which "subject" > >>> it > >>> might have been saved in the archive.. > >>> > >>> > >>> All the Best and a Happy New Year > >>> > >>> > >>> Luigi > >>> > >>> > _
Re: [PD] Consistency Problem - OS X[intel] - when modifying Abstractions
No that doesnt mean anything, i just threw away some garbage lying around. Actually the patch does not work in that version Am 09.02.2009 um 04:13 schrieb Hans-Christoph Steiner: > > Ok, I get that too. First thing I notice is that some connections are > failing. It looks like perhaps drum_module.pd used to have two > outlets, but now it does not. Does this happen for you? Does this > trigger the bug? > > drummer_main.pd 48 0 0 0 (canvas->message) connection failed > drummer_main.pd 49 0 42 0 (canvas->message) connection failed > drummer_main.pd 50 0 32 0 (canvas->message) connection failed > drummer_main.pd 50 1 34 0 (canvas->message) connection failed > drummer_main.pd 50 1 22 0 (canvas->unpack) connection failed > drummer_main.pd 51 0 31 0 (canvas->message) connection failed > drummer_main.pd 52 0 26 0 (canvas->unpack) connection failed > drummer_main.pd 52 1 35 0 (canvas->message) connection failed > drummer_main.pd 52 1 45 0 (canvas->unpack) connection failed > drummer_main.pd 53 0 37 0 (canvas->message) connection failed > drummer_main.pd 53 1 36 0 (canvas->message) connection failed > > But yes, I get the issue that you are talking about, I'll dig deeper. > > .hc > > On Feb 7, 2009, at 11:44 AM, Luigi wrote: > >> Hi Hans Christian... >> >> All on OSX(INTEL) 10.5.6 >> >> So lets see if you can reproduce this bug: i have Pd version 0.40.3- >> extended >> dont know which exact version from the "builds" actually >> >> so here we go: >> >> 1) Unzip the Archive >> >> 2) open "drummer_main" >> >> 3) with "right-click" go inside of "drum_module" >> >> 4) with "right-click" go inside "gg_midi_note" >> >> 5) do any modification >> >> 6) Type "CTRL-S" for save or choose "Save" from the menu >> >> >> >> Hope that helps >> >> would be great to find that bugger >> >> Best Luigi >> >> >> >> >> >> >> >> >> >> Am 07.02.2009 um 02:15 schrieb Hans-Christoph Steiner: >> >>> >>> Did you ever find an answer to this? Or is there an example >>> patch? I have seen some strange behavior that I am trying to track >>> down. >>> >>> .hc >>> >>> On Jan 5, 2009, at 5:06 AM, Luigi Rensinghoff wrote: >>> Hi List, I notice a bug, thats coming back on OS X PD-extended. The occurs when i change an Abstraction, but not the original, but an active "instance" of a patch. Fpr example i have many instances of the same abstraction encapsulated in other abstractions. While patching i decide to change something - for example add an outlet - i open the instance change it and try to save it. PD seems to update all occurring abstractions and meanwhile the "parent-window" seems to disappear and it is not possible to save the patch anymore... I have to force quit PD after that. Strangely enough the change is saved in the abstraction. but of course it is totally annoying for the workflow. I think i had this issue before and it disappeared in a more recent release of PD-Extended for OS-X Intel I am sorry i cannot post an example patch right now, maybe tonight... For now i would like to ask if anybody is having the same problemand how to fix it, or maybe knows under which "subject" it might have been saved in the archive.. All the Best and a Happy New Year Luigi ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >>> >>> >>> >>> >>> >>> Man has survived hitherto because he was too ignorant to know how >>> to realize his wishes. Now that he can realize them, he must >>> either change them, or perish.-William Carlos Williams >>> >>> >>> >> >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > > > > > > Computer science is no more related to the computer than astronomy is > related to the telescope. -Edsger Dykstra > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Consistency Problem - OS X[intel] - when modifying Abstractions
With Pd-0.42-4 vanilla on Mac OS X 10.5.6/Intel, I can't reproduce this. With Pd-0.41-4 vanilla, I can. I get one: error: .x34e4d0: no such object .hc On Feb 9, 2009, at 12:19 AM, Jonathan Wilkes wrote: > I'm not sure if this is related since I'm running winxp, but I was > getting about seventeen of the following errors when closing test.pd > on pd-vanilla 0.42-4: > error: .xa22a90: no such object > > if I would: > 1) open test.pd > 2) right-click and open one of the instances of the ds-tgl > 3) click the ds in editmode and delete it > 4) save and quickly close the abstraction window (takes about 10 > seconds) > 5) close test.pd without saving (which takes about 5 seconds) > > But as you might imagine, putting the ds in its own gop window > solved all these problems. > > -Jonathan > > --- On Mon, 2/9/09, Hans-Christoph Steiner wrote: > >> From: Hans-Christoph Steiner >> Subject: Re: [PD] Consistency Problem - OS X[intel] - when >> modifying Abstractions >> To: "Luigi" >> Cc: "puredata mailing list" >> Date: Monday, February 9, 2009, 4:46 AM >> So the "consistency check failed: >> canvas_create_editor" also happens >> on Pd-vanilla 0.41-4 but seems to be fixed in 0.42-4. I >> checked this >> by copying the contents of "extra" into a >> Pd-0.42-4.app and running >> your app. If we can track down the fix, I'll backport >> it if it is not >> too complicated. >> >> "error: .x6cfc80: no such object" seems to be >> specific to Pd-extended, >> I think this is related to a bug I've been trying to >> track down. >> Basically the canvas seems to disappear on the 'pd' >> side, while the pd- >> gui side it is still there... >> >> .hc >> >> On Feb 7, 2009, at 11:44 AM, Luigi wrote: >> >>> Hi Hans Christian... >>> >>> All on OSX(INTEL) 10.5.6 >>> >>> So lets see if you can reproduce this bug: i have Pd >> version 0.40.3- >>> extended >>> dont know which exact version from the >> "builds" actually >>> >>> so here we go: >>> >>> 1) Unzip the Archive >>> >>> 2) open "drummer_main" >>> >>> 3) with "right-click" go inside of >> "drum_module" >>> >>> 4) with "right-click" go inside >> "gg_midi_note" >>> >>> 5) do any modification >>> >>> 6) Type "CTRL-S" for save or choose >> "Save" from the menu >>> >>> >>> >>> Hope that helps >>> >>> would be great to find that bugger >>> >>> Best Luigi >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Am 07.02.2009 um 02:15 schrieb Hans-Christoph Steiner: >>> >>>> >>>> Did you ever find an answer to this? Or is there >> an example >>>> patch? I have seen some strange behavior that I >> am trying to track >>>> down. >>>> >>>> .hc >>>> >>>> On Jan 5, 2009, at 5:06 AM, Luigi Rensinghoff >> wrote: >>>> >>>>> Hi List, >>>>> >>>>> I notice a bug, thats coming back on OS X >> PD-extended. The occurs >>>>> when >>>>> i change an Abstraction, but not the original, >> but an active >>>>> "instance" of a patch. >>>>> >>>>> Fpr example i have many instances of the same >> abstraction >>>>> encapsulated >>>>> in other abstractions. >>>>> >>>>> While patching i decide to change something - >> for example add an >>>>> outlet - i open the instance change it and try >> to save it. >>>>> >>>>> PD seems to update all occurring abstractions >> and meanwhile the >>>>> "parent-window" seems to disappear >> and it is not possible to save >>>>> the >>>>> patch anymore... >>>>> >>>>> I have to force quit PD after that. Strangely >> enough the change is >>>>> saved in the abstraction. but of course it >> is totally annoying >>>>> for >>>>> the workflow. >>>>> >>>>> >>>>> I think i had this issue before and it >> disappeared in a more r
Re: [PD] Consistency Problem - OS X[intel] - when modifying Abstractions
That means: the only workaround is to use pd-vanilla for now ?? This leads to anoher question: What is the best way then to use pd- vanilla but with the externals and documentation from pd-extended ??? was that discussed before ?? Grüße Luigi Am 10.02.2009 um 03:34 schrieb Hans-Christoph Steiner: > > With Pd-0.42-4 vanilla on Mac OS X 10.5.6/Intel, I can't reproduce > this. With Pd-0.41-4 vanilla, I can. I get one: > > error: .x34e4d0: no such object > > .hc > > On Feb 9, 2009, at 12:19 AM, Jonathan Wilkes wrote: > >> I'm not sure if this is related since I'm running winxp, but I was >> getting about seventeen of the following errors when closing test.pd >> on pd-vanilla 0.42-4: >> error: .xa22a90: no such object >> >> if I would: >> 1) open test.pd >> 2) right-click and open one of the instances of the ds-tgl >> 3) click the ds in editmode and delete it >> 4) save and quickly close the abstraction window (takes about 10 >> seconds) >> 5) close test.pd without saving (which takes about 5 seconds) >> >> But as you might imagine, putting the ds in its own gop window >> solved all these problems. >> >> -Jonathan >> >> --- On Mon, 2/9/09, Hans-Christoph Steiner wrote: >> >>> From: Hans-Christoph Steiner >>> Subject: Re: [PD] Consistency Problem - OS X[intel] - when >>> modifying Abstractions >>> To: "Luigi" >>> Cc: "puredata mailing list" >>> Date: Monday, February 9, 2009, 4:46 AM >>> So the "consistency check failed: >>> canvas_create_editor" also happens >>> on Pd-vanilla 0.41-4 but seems to be fixed in 0.42-4. I >>> checked this >>> by copying the contents of "extra" into a >>> Pd-0.42-4.app and running >>> your app. If we can track down the fix, I'll backport >>> it if it is not >>> too complicated. >>> >>> "error: .x6cfc80: no such object" seems to be >>> specific to Pd-extended, >>> I think this is related to a bug I've been trying to >>> track down. >>> Basically the canvas seems to disappear on the 'pd' >>> side, while the pd- >>> gui side it is still there... >>> >>> .hc >>> >>> On Feb 7, 2009, at 11:44 AM, Luigi wrote: >>> >>>> Hi Hans Christian... >>>> >>>> All on OSX(INTEL) 10.5.6 >>>> >>>> So lets see if you can reproduce this bug: i have Pd >>> version 0.40.3- >>>> extended >>>> dont know which exact version from the >>> "builds" actually >>>> >>>> so here we go: >>>> >>>> 1) Unzip the Archive >>>> >>>> 2) open "drummer_main" >>>> >>>> 3) with "right-click" go inside of >>> "drum_module" >>>> >>>> 4) with "right-click" go inside >>> "gg_midi_note" >>>> >>>> 5) do any modification >>>> >>>> 6) Type "CTRL-S" for save or choose >>> "Save" from the menu >>>> >>>> >>>> >>>> Hope that helps >>>> >>>> would be great to find that bugger >>>> >>>> Best Luigi >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Am 07.02.2009 um 02:15 schrieb Hans-Christoph Steiner: >>>> >>>>> >>>>> Did you ever find an answer to this? Or is there >>> an example >>>>> patch? I have seen some strange behavior that I >>> am trying to track >>>>> down. >>>>> >>>>> .hc >>>>> >>>>> On Jan 5, 2009, at 5:06 AM, Luigi Rensinghoff >>> wrote: >>>>> >>>>>> Hi List, >>>>>> >>>>>> I notice a bug, thats coming back on OS X >>> PD-extended. The occurs >>>>>> when >>>>>> i change an Abstraction, but not the original, >>> but an active >>>>>> "instance" of a patch. >>>>>> >>>>>> Fpr example i have many instances of the same >>> abstraction >>>>>> encapsulated >>>>>> in other abstractions. >>>>>> >>>>>> While patching i decide to change some
Re: [PD] Consistency Problem - OS X[intel] - when modifying Abstractions
If you run into that bug, then yeah, you need to use 0.42. There are vanilla+libs builds of 0.42 for GNU/Linux. You might be able to make one for Mac OS X, I haven't tried. Or you can just copy extra and docs from Pd-extended. .hc On Feb 10, 2009, at 2:57 AM, Luigi wrote: > That means: > > the only workaround is to use pd-vanilla for now ?? > > This leads to anoher question: What is the best way then to use pd- > vanilla but with the externals and documentation from pd-extended ??? > > was that discussed before ?? > > Grüße > > Luigi > > > Am 10.02.2009 um 03:34 schrieb Hans-Christoph Steiner: > >> >> With Pd-0.42-4 vanilla on Mac OS X 10.5.6/Intel, I can't reproduce >> this. With Pd-0.41-4 vanilla, I can. I get one: >> >> error: .x34e4d0: no such object >> >> .hc >> >> On Feb 9, 2009, at 12:19 AM, Jonathan Wilkes wrote: >> >>> I'm not sure if this is related since I'm running winxp, but I was >>> getting about seventeen of the following errors when closing test.pd >>> on pd-vanilla 0.42-4: >>> error: .xa22a90: no such object >>> >>> if I would: >>> 1) open test.pd >>> 2) right-click and open one of the instances of the ds-tgl >>> 3) click the ds in editmode and delete it >>> 4) save and quickly close the abstraction window (takes about 10 >>> seconds) >>> 5) close test.pd without saving (which takes about 5 seconds) >>> >>> But as you might imagine, putting the ds in its own gop window >>> solved all these problems. >>> >>> -Jonathan >>> >>> --- On Mon, 2/9/09, Hans-Christoph Steiner wrote: >>> >>>> From: Hans-Christoph Steiner >>>> Subject: Re: [PD] Consistency Problem - OS X[intel] - when >>>> modifying Abstractions >>>> To: "Luigi" >>>> Cc: "puredata mailing list" >>>> Date: Monday, February 9, 2009, 4:46 AM >>>> So the "consistency check failed: >>>> canvas_create_editor" also happens >>>> on Pd-vanilla 0.41-4 but seems to be fixed in 0.42-4. I >>>> checked this >>>> by copying the contents of "extra" into a >>>> Pd-0.42-4.app and running >>>> your app. If we can track down the fix, I'll backport >>>> it if it is not >>>> too complicated. >>>> >>>> "error: .x6cfc80: no such object" seems to be >>>> specific to Pd-extended, >>>> I think this is related to a bug I've been trying to >>>> track down. >>>> Basically the canvas seems to disappear on the 'pd' >>>> side, while the pd- >>>> gui side it is still there... >>>> >>>> .hc >>>> >>>> On Feb 7, 2009, at 11:44 AM, Luigi wrote: >>>> >>>>> Hi Hans Christian... >>>>> >>>>> All on OSX(INTEL) 10.5.6 >>>>> >>>>> So lets see if you can reproduce this bug: i have Pd >>>> version 0.40.3- >>>>> extended >>>>> dont know which exact version from the >>>> "builds" actually >>>>> >>>>> so here we go: >>>>> >>>>> 1) Unzip the Archive >>>>> >>>>> 2) open "drummer_main" >>>>> >>>>> 3) with "right-click" go inside of >>>> "drum_module" >>>>> >>>>> 4) with "right-click" go inside >>>> "gg_midi_note" >>>>> >>>>> 5) do any modification >>>>> >>>>> 6) Type "CTRL-S" for save or choose >>>> "Save" from the menu >>>>> >>>>> >>>>> >>>>> Hope that helps >>>>> >>>>> would be great to find that bugger >>>>> >>>>> Best Luigi >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Am 07.02.2009 um 02:15 schrieb Hans-Christoph Steiner: >>>>> >>>>>> >>>>>> Did you ever find an answer to this? Or is there >>>> an example >>>>>> patch? I have seen some strange behavior that I >>>> am trying to track >>>>>> down. >>>
