Pd-dev February 2010

pd-dev@lists.iem.at

22 participants
71 discussions

changes in atom_getsymbol between pd 0.40-3 and 0.42.4?
by B. Bogart 18 Feb '10

18 Feb '10

Hello all, I noticed a bug testing my gphoto code. It was written for 40-3 but does no longer work in 42.4. The problem is passing the A_GIMME arguments from a wrapper function to a function that runs in a separate thread. This is done by populating a structure mimicking the A_GIMME args: typedef struct gphoto_gimme_struct { gphoto_struct *gphoto; t_symbol *s; int argc; t_atom *argv; } gphoto_gimme_struct; This struct is populated like so in the function that spawns the thread: static void wrapCaptureImage(gphoto_struct *gphoto, t_symbol *s, int argc, t_atom *argv) { int ret; pthread_t thread1; t_symbol *filename; if (!gphoto->busy) { // instance of structure gphoto_gimme_struct *threadArgs = (gphoto_gimme_struct *)malloc(sizeof(gphoto_gimme_struct)); // packaging arguments into structure threadArgs->gphoto = gphoto; threadArgs->s = s; threadArgs->argc = argc; threadArgs->argv = argv; // We're busy gphoto->busy = 1; // Create thread ret = pthread_create( &thread1, &gphoto->threadAttr, captureImage, threadArgs); } else { error("gphoto: ERROR: Already executing a command, try again later."); } } When I print out the value of argv in the above function all is well. In 42.4 the function that runs in the thread sees argv differently than the spawning function. For example: post("out: argv: %s", atom_getsymbol(argv)->s_name); In the spawning function properly prints out the argument supplied in PD (for example input.jpg) In the function that runs in the thread the argument is printed as follows: post("in: argv: %s", atom_getsymbol(((gphoto_gimme_struct *)threadArgs)->argv)->s_name); "Float" is printed to the console, not "input.jpg" as supplied in PD. In PD <.0.40.3 the proper argument is printed from both the thread and in the spawning function. I'm at a loss here. How does the symbol "input.jpg" end up turning into "float" in 0.42.4? Any ideas for solutions? All the code is in svn/externals/bbogart/gphoto Thanks, B. Bogart

4 9

[ pure-data-Bugs-2953383 ] GEM cannot be loaded / MACOSX 10.6 / nightly build 20100216
by SourceForge.net 17 Feb '10

17 Feb '10

Bugs item #2953383, was opened at 2010-02-17 10:24 Message generated for change (Tracker Item Submitted) made by r33p You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2953383&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mersadier Pierre (r33p) Assigned to: Hans-Christoph Steiner (eighthave) Summary: GEM cannot be loaded / MACOSX 10.6 / nightly build 20100216 Initial Comment: /Applications/Pd-0.42.5-extended-20100216.app/Contents/Resources/extra/Gem/Gem.pd_darwin: dlopen(/Applications/Pd-0.42.5-extended-20100216.app/Contents/Resources/extra/Gem/Gem.pd_darwin, 10): Library not loaded: /sw/lib/libfaad.0.dylib Referenced from: /Applications/Pd-0.42.5-extended-20100216.app/Contents/Resources/Scripts/../bin/../../lib/libgmerlin_avdec.1.dylib Reason: image not found Gem: can't load library ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2953383&group_…

1 0

[ pure-data-Patches-2952880 ] a partial float fix
by SourceForge.net 16 Feb '10

16 Feb '10

Patches item #2952880, was opened at 2010-02-16 11:33 Message generated for change (Settings changed) made by mrpeach You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2952880&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata >Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Peach (mrpeach) Assigned to: Miller Puckette (millerpuckette) Summary: a partial float fix Initial Comment: Pd currently doesn't store floats to their full precision because atom_string uses the %g format specifier to print them into the binbuf. As a result 24-bit numbers lose precision. This patch changes the format specifier to %f and also adds a routine to chop off trailing zeros and the decimal point if nothing is to the right of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2952880&group_…

1 0

[ pure-data-Patches-2952880 ] a partial float fix
by SourceForge.net 16 Feb '10

16 Feb '10

Patches item #2952880, was opened at 2010-02-16 11:33 Message generated for change (Tracker Item Submitted) made by mrpeach You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2952880&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Peach (mrpeach) Assigned to: Miller Puckette (millerpuckette) Summary: a partial float fix Initial Comment: Pd currently doesn't store floats to their full precision because atom_string uses the %g format specifier to print them into the binbuf. As a result 24-bit numbers lose precision. This patch changes the format specifier to %f and also adds a routine to chop off trailing zeros and the decimal point if nothing is to the right of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2952880&group_…

1 0

[ pure-data-Bugs-2952825 ] pd hangs in windows Vista and won't work until system reboot
by SourceForge.net 16 Feb '10

16 Feb '10

Bugs item #2952825, was opened at 2010-02-16 16:10 Message generated for change (Comment added) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2952825&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pd hangs in windows Vista and won't work until system reboot Initial Comment: Sometimes (unfortunately I haven't observed any apparent cause that triggers the problem), I open PD and it won't create a new patch (file/new) nor open any patch (file/open). It won't even quit untill I kill the process, and clicking on "DIO errors" doesn't produce any printout. Furthermore, all menus of the menu bar are empty (only a "--" item) except the File menu. Even if I kill and restart PD, it won't ever work, untill I reboot the operating system, then everything is fine. This is PD Vanilla 0.42.5 on Windows Vista. When it gets "frozen" like this, if I launch it with -lib Gem (I have Gem installed), it won't print the usual Gem output on the console (no output at all). After reboot, everything usually works. This happens every once in a while, and it is NOT necessary after some crash or anything. ---------------------------------------------------------------------- >Comment By: Matteo Sisti Sette (sistisette) Date: 2010-02-16 16:16 Message: I've just found out that killing the "acrotray.exe" process seems to fix the problem: after doing that, PD works fine. Acrotray is something related to Adobe Acrobat or Acrobat Reader. What relation it can have with PD is beyond my understanding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2952825&group_…

1 0

[ pure-data-Bugs-2952825 ] pd hangs in windows Vista and won't work until system reboot
by SourceForge.net 16 Feb '10

16 Feb '10

Bugs item #2952825, was opened at 2010-02-16 16:10 Message generated for change (Tracker Item Submitted) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2952825&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pd hangs in windows Vista and won't work until system reboot Initial Comment: Sometimes (unfortunately I haven't observed any apparent cause that triggers the problem), I open PD and it won't create a new patch (file/new) nor open any patch (file/open). It won't even quit untill I kill the process, and clicking on "DIO errors" doesn't produce any printout. Furthermore, all menus of the menu bar are empty (only a "--" item) except the File menu. Even if I kill and restart PD, it won't ever work, untill I reboot the operating system, then everything is fine. This is PD Vanilla 0.42.5 on Windows Vista. When it gets "frozen" like this, if I launch it with -lib Gem (I have Gem installed), it won't print the usual Gem output on the console (no output at all). After reboot, everything usually works. This happens every once in a while, and it is NOT necessary after some crash or anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2952825&group_…

1 0

pd file format: color settings
by Robert Schwarz 16 Feb '10

16 Feb '10

Hi all, I recently tried writing patches in a text editor (or from scripts) and had problems getting the color settings right, for bang elements. There is some documentation at http://puredata.info/docs/developer/fileformat with the explanation: > > Color: Some graphical elements have color attributes. Per color only > one signed integer value is stored that contains the three 8-bit > color components (RGB). Formula to calculate color attribute values: > > color = ( [red] * -65536) + ( [green] * -256) + ( [blue] * -1) > > Where [red], [green], [blue] obviously represent the three color > components, their values range from 0 to 255. They apply to the > attributes [background color], [front color], [label color] of > various elements. I tried that, but it didn't work. Instead of showing the whole spectrum I just got different shades of blue. Also, when I opened one of my handwritten patches in PureData, looked at the color settings and saved, the resulting numbers changed. I assume that some kind of rounding is happening, and colors are actually saved in lower resolution. Do you have any ideas? Also, my application is a 13x13 button matrix, each triggering different chords via MIDI. The buttons should be color coded. Obviously, it's too much work setting all colors individually and I might want to create several of these patches with different colors. Maybe there is another obvious solution I didn't see. Any help is appreciated! (I'm using standard pd 0.42_5 on Arch Linux, but this shouldn't make a difference.) -- Robert Schwarz <mail(a)rschwarz.net> Get my public key at http://rschwarz.net/key.asc

4 7

Re: [PD-dev] pd file format: color settings
by Patrick Boivin 16 Feb '10

16 Feb '10

Hi, there's also [#to_iem] in gridflow 0.9.7 (svn) that does rgb to iemgui color conversion. > Date: Sun, 14 Feb 2010 12:26:51 -0500 > From: Hans-Christoph Steiner <hans(a)at.or.at> > Subject: Re: [PD-dev] pd file format: color settings > To: reduzierer(a)yahoo.de > Cc: Martin Peach <martin.peach(a)sympatico.ca>, pd-dev(a)iem.at > Message-ID: <425FDA03-43CB-40C8-8F0E-68E55236E13D(a)at.or.at> > Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; > delsp=yes > > > Also, there are some conversion objects around, I think in pdmtl for > example. > > .hc > > On Feb 14, 2010, at 12:15 PM, Roman Haefeli wrote: > >> I assume, this is because a 24bit integer cannot be saved with full >> precision with Pd, since Pd seems to strip off some bits when saving a >> floating point value (or when printing or displaying it). If the color >> would be encoded as RGB 8bpp, it would look different after saving and >> restoring it. So a smaller range had to be used. >> >> When sending 'color' messages to the iemguis directly, the full 24bit >> resolution can be used. >> >> Roman >> >> >> >> On Sat, 2010-02-13 at 18:32 -0500, Martin Peach wrote: >>> Ah yes, in g_all_guis.c line 281: >>> >>> void iemgui_all_colfromload(t_iemgui *iemgui, int *bflcol) >>> { >>> if(bflcol[0] < 0) >>> { >>> bflcol[0] = -1 - bflcol[0]; >>> iemgui->x_bcol = ((bflcol[0] & 0x3f000) << 6)|((bflcol[0] & >>> 0xfc0) << 4)| >>> ((bflcol[0] & 0x3f) << 2); >>> } >>> else >>> { >>> bflcol[0] = iemgui_modulo_color(bflcol[0]); >>> iemgui->x_bcol = iemgui_color_hex[bflcol[0]]; >>> } >>> >>> ...so if the colour is negative it's a negated (all bits flipped) >>> 18-bit >>> rgb value and if it's positive it's an indexed colour from the iemgui >>> palette. >>> 111111RRRRRRGGGGGGBBBBBB >>> is bit-flipped to get: >>> 000000rrrrrrggggggbbbbbb >>> which is shifted into this: >>> rrrrrr00gggggg00bbbbbb00 >>> so the 2 LSBs of each colour are set to 0. I don't know why. >>> >>> Martin >>> >>> Robert Schwarz wrote: >>>> Thanks for the quick answer. >>>> >>>> The concept of embedding three 8 bit components in one integer was >>>> clear >>>> to me, but I think that pd doesn't really use all 8 bits for the >>>> colors. >>>> Or maybe there is some issue with 2-complements or something. >>>> >>>> For example, if I want to create three bang objects, in red >>>> (#ff0000), >>>> green (#00ff00) and blue (#0000ff), your formula gives values of: >>>> 16711680, 65280, 255 for the three colors. >>>> >>>> But I insert them in a patch, like: >>>> >>>> #N canvas 825 10 450 300 10; >>>> #X obj 0 0 bng 15 200 50 0 target empty empty 0 0 0 8 16711680 0 0 ; >>>> #X obj 0 15 bng 15 200 50 0 target empty empty 0 0 0 8 65280 0 0 ; >>>> #X obj 0 30 bng 15 200 50 0 target empty empty 0 0 0 8 255 0 0 ; >>>> >>>> I see the colors white, white, yellow. >>>> >>>> Now, when I change the colors by hand, to really get red, blue and >>>> green >>>> on the bang objects and save the file, it reads: >>>> >>>> #N canvas 825 10 450 300 10; >>>> #X obj 0 0 bng 15 200 50 0 target empty empty 0 0 0 8 -258049 -1 >>>> -1 ; >>>> #X obj 0 15 bng 15 200 50 0 target empty empty 0 0 0 8 -4033 -1 -1 ; >>>> #X obj 0 30 bng 15 200 50 0 target empty empty 0 0 0 8 -64 -1 -1 ; >>>> >>>> So it uses negative numbers, and -64 means "full blue". >>>> Now, when I re-open the same file and look at the properties of >>>> the blue >>>> bang object, the color now reads: #0000fc instead of the #0000ff I >>>> entered just before saving. >>>> >>>> That's why I suspect some lower resolution going on. I tried to >>>> browse >>>> this part in the sources, but all the GUI code confuses me. >>>> >>>> For your interest, this patch results for colors of #040000, >>>> #000400 and >>>> #000004 set by hand in the properties window: >>>> >>>> #X obj 0 0 bng 15 200 50 0 target empty empty 0 0 0 8 -4097 -1 -1; >>>> #X obj 0 15 bng 15 200 50 0 target empty empty 0 0 0 8 -65 -1 -1; >>>> #X obj 0 30 bng 15 200 50 0 target empty empty 0 0 0 8 -2 -1 -1; >>>> >>>> Setting colors to lower values, like #010000 results in getting them >>>> rounded down to #000000. >>>> >>>> So, the resolution is apparently 256/4 = 64 values, or 6 bits. >>>> >>>> Indeed, if I replace the formula with: >>>> >>>> color = (-([red]+1)/4*64*64) - (([green]+1)/4*64) - ([blue]+1)/4 >>>> >>>> I get the same values that Pure Data produces. >>>> Hm, I might just have solved my problem. >>>> >>>> It's still weird and some developer could check this our or change >>>> the >>>> documentation. >>>> >>>> Cheers, Robert >>>> >>>> On 02/13/2010 11:08 PM, Martin Peach wrote: >>>>> That formula should read: >>>>> color = ([red] * 65536) + ([green] * 256) + ([blue]) >>>>> In binary the idea is to shift the 8 'red' bits 16 to the left, >>>>> then add >>>>> 8 'green' bits shifted 8 bits, and finally 8 'blue' bits, so in >>>>> all 24 >>>>> bits are occupied. >>>>> Multiplying the blue value by -1 in the original formula has the >>>>> effect >>>>> of setting the 16 bits to the left of it to 1, so you get different >>>>> shades of pure blue. >>>>> >>>>> Martin >>>>> >>>>> Robert Schwarz wrote: >>>>>> Hi all, >>>>>> >>>>>> I recently tried writing patches in a text editor (or from >>>>>> scripts) and >>>>>> had problems getting the color settings right, for bang elements. >>>>>> >>>>>> There is some documentation at >>>>>> http://puredata.info/docs/developer/fileformat >>>>>> with the explanation: >>>>>> >>>>>>> Color: Some graphical elements have color attributes. Per color >>>>>>> only >>>>>>> one signed integer value is stored that contains the three 8-bit >>>>>>> color components (RGB). Formula to calculate color attribute >>>>>>> values: >>>>>>> >>>>>>> color = ( [red] * -65536) + ( [green] * -256) + ( [blue] * -1) >>>>>>> >>>>>>> Where [red], [green], [blue] obviously represent the three color >>>>>>> components, their values range from 0 to 255. They apply to the >>>>>>> attributes [background color], [front color], [label color] of >>>>>>> various elements. >>>>>> I tried that, but it didn't work. Instead of showing the whole >>>>>> spectrum >>>>>> I just got different shades of blue. Also, when I opened one of my >>>>>> handwritten patches in PureData, looked at the color settings >>>>>> and saved, >>>>>> the resulting numbers changed. I assume that some kind of >>>>>> rounding is >>>>>> happening, and colors are actually saved in lower resolution. >>>>>> >>>>>> Do you have any ideas? >>>>>> >>>>>> Also, my application is a 13x13 button matrix, each triggering >>>>>> different >>>>>> chords via MIDI. The buttons should be color coded. Obviously, >>>>>> it's too >>>>>> much work setting all colors individually and I might want to >>>>>> create >>>>>> several of these patches with different colors. >>>>>> Maybe there is another obvious solution I didn't see. >>>>>> >>>>>> Any help is appreciated! >>>>>> >>>>>> (I'm using standard pd 0.42_5 on Arch Linux, but this shouldn't >>>>>> make a >>>>>> difference.) >>>>>> >>>> >>> >>> >>> _______________________________________________ >>> Pd-dev mailing list >>> Pd-dev(a)iem.at >>> http://lists.puredata.info/listinfo/pd-dev >> >> >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev(a)iem.at >> http://lists.puredata.info/listinfo/pd-dev > > > > > > ---------------------------------------------------------------------------- > > 'You people have such restrictive dress for women,? she said, hobbling > away in three inch heels and panty hose to finish out another pink- > collar temp pool day. - ?Hijab Scene #2", by Mohja Kahf

1 0

[ pure-data-Patches-2929284 ] bang to switch~ while dsp off: Pd exits
by SourceForge.net 15 Feb '10

15 Feb '10

Patches item #2929284, was opened at 2010-01-10 14:36 Message generated for change (Comment added) made by katjav You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2929284&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: None Status: Open Resolution: Fixed Priority: 7 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Miller Puckette (millerpuckette) Summary: bang to switch~ while dsp off: Pd exits Initial Comment: When a bang is sent to the switch~ object while dsp is turned off (after having been on at least once since start up of Pd), Pd will exit with segmentation fault. This was tested with Pd extended 0.41.4 on OSX 10.5 and on Linux Ubuntu. I guess the bug could be fixed by extending the conditional check in the bang method for block~/switch~: if(x->x_switched && !x->x_switchon && canvas_dspstate) (reported anonymously by Katja Vetter) ---------------------------------------------------------------------- Comment By: Katja (katjav) Date: 2010-02-15 13:24 Message: Hans, I suggested a check on canvas_dspstate because it seems to be a global variable reflecting the dsp status of all root canvases. glob_dsp uses it as well. This suggestion was tested in Pd 0.41 on a Kubuntu system. With the modification, the switch~ object in an encapsulated subpatch switches dsp from off to on for one signal block, like it should do, and without Pd crashing. Apparently I overlooked conditions where it does not work, since it did not work for you. Anyway, a check on dsp_chain does the job. Thanks. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-02-15 07:45 Message: I added a patch to add a warning error when switch~ is banged and the DSP is off, instead of crashing. It is also checked into Pd-extended 0.42.5: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=131… ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-02-14 01:35 Message: It seems that dsp_chain is the issue, so the code should be perhaps something like if (x->x_switched && !x->x_switchon && dsp_chain) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-02-14 01:25 Message: Reproduced using Pd-extended 0.42.5-20100120 pd-gui-rewrite/0.43 on Mac OS X 10.5.8/Intel. Here's the stacktrace: 0 pd 0x0006b3e3 block_bang + 78 (d_ugen.c:227) 1 pd 0x00056eb4 outlet_bang + 56 (m_obj.c:370) 2 pd 0x0003e79c bng_newclick + 153 (g_bang.c:299) 3 pd 0x000378c8 canvas_doclick + 594 (g_editor.c:110) 4 pd 0x00038572 canvas_mousedown + 61 (g_editor.c:1440) 5 pd 0x00054e09 pd_typedmess + 1141 (m_class.c:792) 6 pd 0x00054ccf pd_typedmess + 827 (m_class.c:818) 7 pd 0x00058f5c binbuf_eval + 1224 (m_binbuf.c:726) 8 pd 0x00063232 socketreceiver_read + 1734 (s_inter.c:558) 9 pd 0x00061df2 sys_domicrosleep + 381 (s_inter.c:196) 10 pd 0x00061e7e sys_microsleep + 19 (s_inter.c:219) 11 pd 0x0005f004 m_mainloop + 1030 (m_sched.c:587) 12 pd 0x00061b21 sys_main + 2909 (s_main.c:304) 13 pd 0x00002852 _start + 216 14 pd 0x00002779 start + 41 Can you explain the addition of canvas_dspstate? For me, this change just makes it so bang never turns on the canvas-local DSP. ---------------------------------------------------------------------- Comment By: Katja (katjav) Date: 2010-02-14 00:37 Message: Above-mentioned bug exists in Pd 0.42-4 as well. I have checked that the problem is indeed solved with the following (where d_ugen_old.c is the original file and d_ugen.c the modified version): diff d_ugen_old.c d_ugen.c 222c222 < if (x->x_switched && !x->x_switchon) --- > if (x->x_switched && !x->x_switchon && canvas_dspstate) Hope this bug will be fixed soon cause I want to share a patch including the switch~ object. Katja ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2929284&group_…

1 0

[ pure-data-Patches-2929284 ] bang to switch~ while dsp off: Pd exits
by SourceForge.net 15 Feb '10

15 Feb '10

Patches item #2929284, was opened at 2010-01-10 08:36 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2929284&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: pd-extended >Group: None Status: Open >Resolution: Fixed >Priority: 7 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Miller Puckette (millerpuckette) Summary: bang to switch~ while dsp off: Pd exits Initial Comment: When a bang is sent to the switch~ object while dsp is turned off (after having been on at least once since start up of Pd), Pd will exit with segmentation fault. This was tested with Pd extended 0.41.4 on OSX 10.5 and on Linux Ubuntu. I guess the bug could be fixed by extending the conditional check in the bang method for block~/switch~: if(x->x_switched && !x->x_switchon && canvas_dspstate) (reported anonymously by Katja Vetter) ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-02-15 01:45 Message: I added a patch to add a warning error when switch~ is banged and the DSP is off, instead of crashing. It is also checked into Pd-extended 0.42.5: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=131… ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-02-13 19:35 Message: It seems that dsp_chain is the issue, so the code should be perhaps something like if (x->x_switched && !x->x_switchon && dsp_chain) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-02-13 19:25 Message: Reproduced using Pd-extended 0.42.5-20100120 pd-gui-rewrite/0.43 on Mac OS X 10.5.8/Intel. Here's the stacktrace: 0 pd 0x0006b3e3 block_bang + 78 (d_ugen.c:227) 1 pd 0x00056eb4 outlet_bang + 56 (m_obj.c:370) 2 pd 0x0003e79c bng_newclick + 153 (g_bang.c:299) 3 pd 0x000378c8 canvas_doclick + 594 (g_editor.c:110) 4 pd 0x00038572 canvas_mousedown + 61 (g_editor.c:1440) 5 pd 0x00054e09 pd_typedmess + 1141 (m_class.c:792) 6 pd 0x00054ccf pd_typedmess + 827 (m_class.c:818) 7 pd 0x00058f5c binbuf_eval + 1224 (m_binbuf.c:726) 8 pd 0x00063232 socketreceiver_read + 1734 (s_inter.c:558) 9 pd 0x00061df2 sys_domicrosleep + 381 (s_inter.c:196) 10 pd 0x00061e7e sys_microsleep + 19 (s_inter.c:219) 11 pd 0x0005f004 m_mainloop + 1030 (m_sched.c:587) 12 pd 0x00061b21 sys_main + 2909 (s_main.c:304) 13 pd 0x00002852 _start + 216 14 pd 0x00002779 start + 41 Can you explain the addition of canvas_dspstate? For me, this change just makes it so bang never turns on the canvas-local DSP. ---------------------------------------------------------------------- Comment By: Katja (katjav) Date: 2010-02-13 18:37 Message: Above-mentioned bug exists in Pd 0.42-4 as well. I have checked that the problem is indeed solved with the following (where d_ugen_old.c is the original file and d_ugen.c the modified version): diff d_ugen_old.c d_ugen.c 222c222 < if (x->x_switched && !x->x_switchon) --- > if (x->x_switched && !x->x_switchon && canvas_dspstate) Hope this bug will be fixed soon cause I want to share a patch including the switch~ object. Katja ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2929284&group_…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev February 2010