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:
…
[View More]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
[View Less]
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
…
[View More]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_…
[View Less]
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
…
[View More]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_…
[View Less]
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
…
[View More]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_…
[View Less]
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: …
[View More]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_…
[View Less]
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
…
[View More]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_…
[View Less]
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] …
[View More]* -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
[View Less]
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=…
[View More]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
[View Less]
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:…
[View More] 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_…
[View Less]
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
…
[View More]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_…
[View Less]