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
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_…
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_…
Bugs item #1984672, was opened at 2008-06-04 19:21
Message generated for change (Comment added) made by stffn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1984672&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: v0.42
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: stffn (stffn)
Assigned to: Nobody/Anonymous (nobody)
Summary: numbers in comments are not kept as literals
Initial Comment:
...but only if it's followed by a number unless it's 0's then one 0 is kept. Try to open this patch (also attached):
#N canvas 50 50 200 370 missing_0s.pd 10;
#X text 50 10 011;
#X text 50 40 foo;
#X text 50 70 0ff;
#X text 50 100 0 ff;
#X text 50 130 0;
#X text 50 160 01;
#X text 50 190 0 1;
#X text 50 220 0 ;
#X text 50 250 00;
#X text 50 280 02;
#X text 50 310 000;
#X text 50 340 0000;
It's in Pd-0.41-4 and Pd-extended-0.40.3-RC1 on Intel powered Mac OS X
----------------------------------------------------------------------
>Comment By: stffn (stffn)
Date: 2010-02-15 07:37
Message:
This seams to be a feature. Miller writes:
"It's unfortunate, but it's in fact a 'feature' - 1. is a number and all
numbers are printed in their 'simplest' form :)"
Cf. http://lists.puredata.info/pipermail/pd-list/2010-02/076005.html
----------------------------------------------------------------------
Comment By: stffn (stffn)
Date: 2009-02-05 08:26
Message:
Still there in 0.42-3
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-08-21 09:49
Message:
Logged In: YES
user_id=564396
Originator: NO
the problem is,that numbers in comments are not kept as literals (strings,
symbols) but are really interpreted as numbers, thus "019" is equivalent to
"19".
the same problem occurs if you have large numbers 8000000001 which will be
stripped to 8e09 (like everywhere else in Pd)
the workaround for this is to make sure that these numbers are really read
as symbols, e.g. by adding quotes (or other non-numerical characters):
#X text 50 310 "000";
i changed the name from "0 in start of comment gets stripped off..."
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1984672&group_…
Bugs item #2949009, was opened at 2010-02-10 06:06
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2949009&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-devel
>Group: v0.43
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: IOhannes m zmlnig (zmoelnig)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: pd-gui-rewrite unusable with NumLock
Initial Comment:
when i have NumLock enabled, pd-gui-rewrite is unusable:
when creating an object, i cannot leave the creation (and thus trigger the instantiation) unless i resort to shortcuts like Ctrl-1.
i cannot connect objects
(trying to connect a messagebox will "click" it; trying to connect a numberbox will shift-drag it)
releasing NumLock fixes all problems
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-02-14 14:08
Message:
I don't know why its a mask, but its in the C code, so I just left it as
is. Here's my attempt at a fix, I don't really have numlock on my laptop,
so I can't really test it. Let me know if it works for you.
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=131…
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-02-10 06:32
Message:
and whatever the good reasons behind adding alt/option press to the mouse
bindings, the "key-modifier" value sent to Pd is a _mask_.
since alt/option press uses the value "3", this means that the
key-modifier is actually "Shift+Alt" rather than a separate key.
is this by intention?
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-02-10 06:26
Message:
the bug stems from binding the mouse to "Option-Buttonpress-1" in
pd_bindings.tcl:134, which was added with revision 12849:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=128…
probably on OSX the "Option-Click" has a meaning, on linux it should be
disabled.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2949009&group_…
Bugs 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=478070&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: v0.43
Status: Open
Resolution: None
Priority: 8
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-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=478070&aid=2929284&group_…
Bugs 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=478070&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: v0.43
Status: Open
Resolution: None
>Priority: 8
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-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=478070&aid=2929284&group_…
Bugs 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=478070&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: v0.41
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Christoph Steiner (eighthave)
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-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=478070&aid=2929284&group_…
Bugs item #2950978, was opened at 2010-02-13 01:06
Message generated for change (Tracker Item Submitted) made by reduzent
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2950978&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: Nobody/Anonymous (nobody)
Summary: iemlib/[soundfile_info]: does not load certain wav files
Initial Comment:
an example file showing described behaviour can be downloaded here:
http://www.romanhaefeli.net/test8kanal_interleaved_www.wav
when loading such a file with [soundfile_info], it prints the following error:
soundfile_info_read-error: /home/roman/projekte/liestal/soundfiles/test8kanal_interleaved_www.wav has a format-chunk not equal to 16
this and other files generated with the nuendo software have this problem. the files though seem to be compliant wav-files. [readsf~] loads and plays them fine.
'mplayer -identify test8kanal_interleaved_www.wav' prints:
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 44100 Hz, 8 ch, s16le, 5644.8 kbit/100.00% (ratio: 705600->705600)
Only [soundfile_info] seems to have troubles with those files.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2950978&group_…
Bugs item #2949009, was opened at 2010-02-10 12:06
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2949009&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-devel
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmlnig (zmoelnig)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: pd-gui-rewrite unusable with NumLock
Initial Comment:
when i have NumLock enabled, pd-gui-rewrite is unusable:
when creating an object, i cannot leave the creation (and thus trigger the instantiation) unless i resort to shortcuts like Ctrl-1.
i cannot connect objects
(trying to connect a messagebox will "click" it; trying to connect a numberbox will shift-drag it)
releasing NumLock fixes all problems
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-02-10 12:32
Message:
and whatever the good reasons behind adding alt/option press to the mouse
bindings, the "key-modifier" value sent to Pd is a _mask_.
since alt/option press uses the value "3", this means that the
key-modifier is actually "Shift+Alt" rather than a separate key.
is this by intention?
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-02-10 12:26
Message:
the bug stems from binding the mouse to "Option-Buttonpress-1" in
pd_bindings.tcl:134, which was added with revision 12849:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=128…
probably on OSX the "Option-Click" has a meaning, on linux it should be
disabled.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2949009&group_…