Re: [PD] A_DEFSYM/A_SYMBOL A_DEFFLOAT/A_FLOAT differences?

[IOhannes m zmölnig]

On 05/02/2016 02:30 AM, Derek Kwan wrote:
> 
> 
> Hello list,
> 
> What are the differences between A_DEFSYM and A_SYMBOL and also
> A_DEFFLOAT and A_FLOAT?

they fallback to default values if no value is present.
e.g. the [float] object has a single A_DEFFLOAT argument.
if you forget to provide it, [float] will use a default value of 0
instead (you cannot change the default value).
otoh, zexy's [repack] object used a single A_FLOAT argument (iirc). if
you forgot to provide it, Pd's object instantiation mechanism would
complain about "Bad arguments for message 'repack' to object
'objectmaker'" and refuse to create the object.

> 
> In my situation, I'm updating an object that used to take A_DEFSYM as a
> first argt and A_FLOAT as a second argt,

which does't make sense.
since you require the 2nd argument, you obviously always need a
firstargument to be present. it should therefore be (A_SYMBOL, A_FLOAT),
(A_DFSYMBOL, A_DEFFLOAT) or (A_SYMBOL, A_DEFFLOAT).

 but I want to take a variable
> number of arguments now so I'm just replacing those with A_GIMME in

which is usually the sanest way to have default values of your own
liking (e.g. non-null and non-'')

> class_new (and then passing t_symbol *s, int argc, t_atom *argv instead
> of t_symbol *s, t_floatarg f into the class's _new). Then I'm
> type-checking each argt of the t_atom by A_SYMBOL and A_FLOAT and
> getting their contents with atom_getsymbolarg and atom_getfloatarg
> respectively. However, things seem not to work the same... It could be
> other bugs I've introduced but could this be also due to going from A_DEFSYM
> to A_SYMBOL (and perhaps the same for float)? If so, is there a way to
> typecast to the DEF versions?
> 

there is no need. the callbacks will always be called with real floats
resp. symbols. the bug is somewhere else.

gfmadsr
IOhannes




signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Oops, test3 bad, test4 up now

[Alexandre Torres Porres]

I guess you sent this update as soon as I started writing an email about
this delay bug :)

anyway, trying the object on this release confirms that the bug i pointed (
https://sourceforge.net/p/pure-data/bugs/1217/ ) still exists.

I'm now trying delread~ and finding that it has similar issues, i added an
example patch to that issue thread - also attached here

moreover, i guess you can update the help file of delread~ too, so you
refer to the new [delread4~] object name instead of the now "old" [vd~] in
the "see also".

cheers

2016-05-02 2:04 GMT-03:00 Miller Puckette :

> Sorry for the noise -
>
> I broke the variable delay reader in 0.47-0test3 - I've uploaded test4
> to replace it... http://msp.ucsd.edu/software.htm etc. as usual.
>
> cheers
> Miller
>
> ___
> Pd-announce mailing list
> pd-annou...@lists.iem.at
> https://lists.puredata.info/listinfo/pd-announce
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>


deltest.pd
Description: Binary data
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Pd 0.47-0 test3 released

[Alexandre Torres Porres]

> here's my old report about this.
>
>
sorry, here it is

https://sourceforge.net/p/pure-data/bugs/1217/
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Pd 0.47-0 test3 released

[Alexandre Torres Porres]

Howdy Miller, I see you updated [vd~] (now "delread4~") and its help file,
cool.

But... the object doesn't seem to be working. I'm on the 64 bit version, on
a mac, and I get the errors

"*signal outlet connect to nonsignal inlet (ignored)*
*signal outlet connect to nonsignal inlet (ignored)*
*object with signal outlets but no DSP method?*"

while we're at it, I see the new help file states (as it did before) that
the delay time is "*at most the length of the delay line (specified by a
corresponding delwrite~)*".

This wasn't true before, as I already pointed once. We can go at most to
the length of the delay line minus something like a block size - so I
consider it a bug. Not sure if you were attacking this issue now for this
update or not, but I thought I'd stress it out. I find this bug really
annoying and it ruins some of my patches - here's my old report about this.

I figure is not that a hard fix though, so I hope you can sneak this fix in
this new upcomming release.

cheers

2016-05-01 13:50 GMT-03:00 Miller Puckette :

> Hi all -
>
> Pd 0.47-0 test 3 is up on the usual:
>
> http://msp.ucsd.edu/software.htm
>
> or via: git clone git://git.code.sf.net/p/pure-data/pure-data
>
> This seems to fix all the major problems in test2.  Thanks for all the
> feedback so far - it has helped immensely.
>
> cheers
> Miller
>
> ___
> Pd-announce mailing list
> pd-annou...@lists.iem.at
> https://lists.puredata.info/listinfo/pd-announce
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] Oops, test3 bad, test4 up now

[Miller Puckette]

Sorry for the noise -

I broke the variable delay reader in 0.47-0test3 - I've uploaded test4
to replace it... http://msp.ucsd.edu/software.htm etc. as usual.

cheers
Miller

___
Pd-announce mailing list
pd-annou...@lists.iem.at
https://lists.puredata.info/listinfo/pd-announce
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] A_DEFSYM/A_SYMBOL A_DEFFLOAT/A_FLOAT differences?

[Derek Kwan]

Hello list,

What are the differences between A_DEFSYM and A_SYMBOL and also
A_DEFFLOAT and A_FLOAT?

In my situation, I'm updating an object that used to take A_DEFSYM as a
first argt and A_FLOAT as a second argt, but I want to take a variable
number of arguments now so I'm just replacing those with A_GIMME in
class_new (and then passing t_symbol *s, int argc, t_atom *argv instead
of t_symbol *s, t_floatarg f into the class's _new). Then I'm
type-checking each argt of the t_atom by A_SYMBOL and A_FLOAT and
getting their contents with atom_getsymbolarg and atom_getfloatarg
respectively. However, things seem not to work the same... It could be
other bugs I've introduced but could this be also due to going from A_DEFSYM
to A_SYMBOL (and perhaps the same for float)? If so, is there a way to
typecast to the DEF versions?

Thanks!

Derek

=
Derek Kwan
www.derekxkwan.com

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] Pd 0.47-0 test3 released

[Miller Puckette]

Hi all -

Pd 0.47-0 test 3 is up on the usual:

http://msp.ucsd.edu/software.htm

or via: git clone git://git.code.sf.net/p/pure-data/pure-data

This seems to fix all the major problems in test2.  Thanks for all the
feedback so far - it has helped immensely.

cheers
Miller

___
Pd-announce mailing list
pd-annou...@lists.iem.at
https://lists.puredata.info/listinfo/pd-announce
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] pd 0.47-0test2 released

[Dan Wilcox]

Yeah. Conceptually is makes sense since it’s usually the key marked + which is 
right next to -, but of course the internal logic is related to shift...


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On May 1, 2016, at 9:35 AM, Miller Puckette  wrote:
> 
> Aha.. this explains why I can sometimes not find the ctrl-+ binding in
> other programs - you actually have NOT to hit 'shift'.  confusing
> 
> I'll go on and change it if that's 'normal' usage :)
> 
> M
> On Sat, Apr 30, 2016 at 10:38:52PM -0600, Dan Wilcox wrote:
>> Actually, I checked and Safari shows CMD+ as the zoom in binding in the 
>> menu, so here’s the same patch with the previous + accelerator string but 
>> with the actual equals binding.
>> 
>> 
>> 
>> 
>> Also, I noticed Safari will zoom whether you do CMD= or CMD+, so I guess 
>> they are covering both uses of the key…
>> 
>> 
>> Dan Wilcox
>> @danomatika 
>> danomatika.com 
>> robotcowboy.com 
>>> On Apr 30, 2016, at 10:31 PM, Dan Wilcox  wrote:
>>> 
>>> Never mind, I was wrong. It *is* working, but I’d suggest binding to minus 
>>> and equals instead of minus and plus so Shift is not required. This is how 
>>> most web browsers provide zoom controls, with the addition of Mod+0 as a 
>>> reset to default zoom level.
>>> 
>>> Also, I noticed the accelerator strings in pd_menus.tcl were not showing 
>>> the key bindings in the menu. The chars don’t need to be quoted to work so 
>>> the following works on OSX (at least): -accelerator "$accelerator+=“.
>>> 
>>> In any case, here’s a small patch that fixes the accelerators and changes 
>>> the + to =.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Dan Wilcox
>>> @danomatika 
>>> danomatika.com 
>>> robotcowboy.com 
 On Apr 30, 2016, at 3:21 PM, Dan Wilcox >>> > wrote:
 
 I’ll give it a try. I’m also testing with my builds in the 
 autotools_update branch so my problem could be more of a Tk 8.5 issue on 
 Mac. There are a number of things to fix that break a little between 8.4 & 
 8.5 on mac as far as my testing goes.
 
 
 Dan Wilcox
 @danomatika 
 danomatika.com 
 robotcowboy.com 
> On Apr 30, 2016, at 1:56 PM, Miller Puckette  > wrote:
> 
> Baffling... the line in pd_bindings.tcl that ought to work is this:
> 
>   bind all <$::modifier-Key-plus>{menu_send_float %W zoom 2}
> 
> ... and I can't get this not to work, either on 2 linux boxes (one a 
> laptop)
> nor on a MAC OSX 6.x desktop... what can I be missing???
> 
> thanks
> M
> 
> On Sat, Apr 30, 2016 at 01:10:47PM -0600, Dan Wilcox wrote:
>> Doesn’t work for me on OSX either.
>> 
>> 
>> Dan Wilcox
>> @danomatika > >
>> danomatika.com  > >
>> robotcowboy.com  > >
>>> On Apr 30, 2016, at 1:06 PM, pd-list-requ...@lists.iem.at 
>>>  wrote:
>>> 
>>> From: Miller Puckette mailto:m...@ucsd.edu> 
>>> >>
>>> Subject: Re: [PD] [PD-announce] pd 0.47-0test2 released
>>> Date: April 30, 2016 at 12:25:58 PM MDT
>>> To: Liam Goodacre mailto:liamg...@hotmail.com> 
>>> >>
>>> Cc: "pd-list@lists.iem.at  
>>> >" 
>>> mailto:pd-list@lists.iem.at> 
>>> >>
>>> 
>>> 
>>> I still can't reproduce this... you're indeed hitting the shift key 
>>> along
>>> with control so taht it's ctrl-+ and not ctrl-=, right?  Just tried on a
>>> Fedora laptop with no problem.
>>> 
>>> cheers
>>> Miller
>> 
> 
>> ___
>> Pd-list@lists.iem.at  mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list 
>> 
> 
 
>>> 
>> 
> 
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and accou

Re: [PD] [PD-announce] pd 0.47-0test2 released

[Miller Puckette]

Aha.. this explains why I can sometimes not find the ctrl-+ binding in
other programs - you actually have NOT to hit 'shift'.  confusing

I'll go on and change it if that's 'normal' usage :)

M
On Sat, Apr 30, 2016 at 10:38:52PM -0600, Dan Wilcox wrote:
> Actually, I checked and Safari shows CMD+ as the zoom in binding in the menu, 
> so here’s the same patch with the previous + accelerator string but with the 
> actual equals binding.
> 
> 
> 
> 
> Also, I noticed Safari will zoom whether you do CMD= or CMD+, so I guess they 
> are covering both uses of the key…
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> > On Apr 30, 2016, at 10:31 PM, Dan Wilcox  wrote:
> > 
> > Never mind, I was wrong. It *is* working, but I’d suggest binding to minus 
> > and equals instead of minus and plus so Shift is not required. This is how 
> > most web browsers provide zoom controls, with the addition of Mod+0 as a 
> > reset to default zoom level.
> > 
> > Also, I noticed the accelerator strings in pd_menus.tcl were not showing 
> > the key bindings in the menu. The chars don’t need to be quoted to work so 
> > the following works on OSX (at least): -accelerator "$accelerator+=“.
> > 
> > In any case, here’s a small patch that fixes the accelerators and changes 
> > the + to =.
> > 
> > 
> > 
> > 
> > 
> > Dan Wilcox
> > @danomatika 
> > danomatika.com 
> > robotcowboy.com 
> >> On Apr 30, 2016, at 3:21 PM, Dan Wilcox  >> > wrote:
> >> 
> >> I’ll give it a try. I’m also testing with my builds in the 
> >> autotools_update branch so my problem could be more of a Tk 8.5 issue on 
> >> Mac. There are a number of things to fix that break a little between 8.4 & 
> >> 8.5 on mac as far as my testing goes.
> >> 
> >> 
> >> Dan Wilcox
> >> @danomatika 
> >> danomatika.com 
> >> robotcowboy.com 
> >>> On Apr 30, 2016, at 1:56 PM, Miller Puckette  >>> > wrote:
> >>> 
> >>> Baffling... the line in pd_bindings.tcl that ought to work is this:
> >>> 
> >>>bind all <$::modifier-Key-plus>{menu_send_float %W zoom 2}
> >>> 
> >>> ... and I can't get this not to work, either on 2 linux boxes (one a 
> >>> laptop)
> >>> nor on a MAC OSX 6.x desktop... what can I be missing???
> >>> 
> >>> thanks
> >>> M
> >>> 
> >>> On Sat, Apr 30, 2016 at 01:10:47PM -0600, Dan Wilcox wrote:
>  Doesn’t work for me on OSX either.
>  
>  
>  Dan Wilcox
>  @danomatika   >
>  danomatika.com    >
>  robotcowboy.com    >
> > On Apr 30, 2016, at 1:06 PM, pd-list-requ...@lists.iem.at 
> >  wrote:
> > 
> > From: Miller Puckette mailto:m...@ucsd.edu> 
> > >>
> > Subject: Re: [PD] [PD-announce] pd 0.47-0test2 released
> > Date: April 30, 2016 at 12:25:58 PM MDT
> > To: Liam Goodacre mailto:liamg...@hotmail.com> 
> > >>
> > Cc: "pd-list@lists.iem.at  
> > >" 
> > mailto:pd-list@lists.iem.at> 
> > >>
> > 
> > 
> > I still can't reproduce this... you're indeed hitting the shift key 
> > along
> > with control so taht it's ctrl-+ and not ctrl-=, right?  Just tried on a
> > Fedora laptop with no problem.
> > 
> > cheers
> > Miller
>  
> >>> 
>  ___
>  Pd-list@lists.iem.at  mailing list
>  UNSUBSCRIBE and account-management -> 
>  https://lists.puredata.info/listinfo/pd-list 
>  
> >>> 
> >> 
> > 
> 

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] pd 0.47-0test2 released

[Miller Puckette]

Sorry - I hadn't pushed my local git repo yet, now I have.  I edited the
help file too (with a bit more detail :)

Miller

On Sun, May 01, 2016 at 11:42:45AM +0200, Roman Haefeli wrote:
> On Sat, 2016-04-30 at 12:08 -0700, Miller Puckette wrote:
> > OK.. I added a 0.46 compatibility mode to get the old, strange behavior :)
> 
> I don't see anything regarding this in the logs. Did you push? The most
> recent commit I see is adcdcede.
> 
> Now I feel somewhat guilty for another compatibility mode ;-) 
> Probably more important than supporting the 'strange' behavior would be
> to reflect the current behavior in the documentation. See attached
> my_canvas-help.pd
> 
> Roman
> 
> 
> > On Sat, Apr 30, 2016 at 05:42:55PM +0200, Roman Haefeli wrote:
> > > On Fri, 2016-04-29 at 15:49 -0700, Miller Puckette wrote:
> > > > It looks like the new color handling has made teh "color" message work
> > > > more coherently.  In the past, if "color" had two arguments they were
> > > > interpreted as background, foreground, and label color, but if only
> > > > two were supplied theyt were the foreground and label colors (without
> > > > setting background color). 
> > > 
> > > Actually, a color message with two arguments sets background and label,
> > > leaving foreground color unchanged (in Pd <= 0.46).
> > > 
> > > >  I think the old behavior is horribly confusing.
> > > 
> > > Until now, I wasn't aware that all iemguis behave the same regarding
> > > colors. The new behavior would have worked for old versions of Pd, but
> > > it never occurred to me, since the documentation for  [cnv] clearly
> > > suggests using only two arguments (background, label), while all other
> > > iemguis require three arguments. Thus, I used only two arguments
> > > whenever setting the label color for [cnv]s dynamically. The change of
> > > behavior breaks quite a few patches of mine. This doesn't mean I'm
> > > opposed to introducing sanity in that matter (it's quite easy to fix),
> > > but I'm wondering how many other patches with non-trivial GUI designs
> > > would be affected.
> > > 
> > > > I'm not sure whether to consider it a bug or a 'feature' - and whether
> > > > back compatibility is more important than making the color-settings 
> > > > sane.
> > > 
> > > I'm not even sure what is more sane. The new behavior forces the use of
> > > a redundant middle argument when setting the label of a [cnv].
> > > 
> > > Roman
> > > 
> > > 
> > >  
> > > > On Mon, Apr 25, 2016 at 10:47:38PM +0200, Roman Haefeli wrote:
> > > > > I'm glad to see the release that includes deken is out now.
> > > > > 
> > > > > One minor thing still apparent in the test2 release: The second 
> > > > > argument
> > > > > of the 'color' message to a [cnv] object does not change the text 
> > > > > color
> > > > > anymore in Pd 0.47. Text color can be changed by providing a _third_
> > > > > argument, though. 
> > > > > 
> > > > > See attached patch.
> > > > > 
> > > > > Cheers and thanks for all the work gone into that release,
> > > > > Roman
> > > > > 
> > > 
> > 
> > 
> > 
> > > ___
> > > Pd-list@lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management -> 
> > > https://lists.puredata.info/listinfo/pd-list
> > 
> 

> #N canvas 0 44 500 292 10;
> #X obj 1 1 cnv 15 300 60 foo10_snd foo10_rcv my_canvas=cnv 63 37 0
> 17 -257472 -355 0;
> #X text 4 232 (c) mu...@iem.kug.ac.at;
> #X text 46 245 IEM KUG;
> #N canvas 219 100 699 530 edit 0;
> #X obj 39 226 f;
> #X msg 17 205 bang;
> #X floatatom 55 204 3 63 88 0 - - -, f 3;
> #X floatatom 90 226 3 0 37 0 - - -, f 3;
> #X obj 39 249 pack 0 0;
> #X text 117 226 y-label;
> #X text 83 204 x-label;
> #X obj 297 281 f;
> #X msg 275 260 bang;
> #X floatatom 313 259 3 -10 10 0 - - -, f 3;
> #X floatatom 348 281 3 -10 10 0 - - -, f 3;
> #X obj 297 304 pack 0 0;
> #X obj 309 396 f;
> #X msg 287 375 bang;
> #X floatatom 325 374 3 20 60 0 - - -, f 3;
> #X floatatom 360 396 3 150 200 0 - - -, f 3;
> #X obj 309 419 pack 0 0;
> #X text 341 259 x-delta;
> #X text 375 281 y-delta;
> #X text 353 374 x-position;
> #X text 387 396 y-position;
> #X obj 59 341 f;
> #X msg 37 320 bang;
> #X floatatom 75 319 3 0 2 0 - - -, f 3;
> #X floatatom 110 341 3 4 36 0 - - -, f 3;
> #X obj 59 364 pack 0 0;
> #X text 103 319 font;
> #X text 139 341 height;
> #X floatatom 275 183 3 2 20 0 - - -, f 3;
> #X msg 39 274 \; foo10_rcv label_pos \$1 \$2;
> #X msg 59 390 \; foo10_rcv label_font \$1 \$2;
> #X msg 36 430 \; foo10_rcv label blabla;
> #X msg 36 466 \; foo10_rcv label my_canvas;
> #X msg 309 444 \; foo10_rcv pos \$1 \$2;
> #X msg 297 329 \; foo10_rcv delta \$1 \$2;
> #X obj 505 234 f;
> #X msg 483 213 bang;
> #X floatatom 521 212 5 100 1000 0 - - -, f 5;
> #X floatatom 556 234 4 50 500 0 - - -, f 4;
> #X obj 505 257 pack 0 0;
> #X text 566 212 width;
> #X text 594 236 height;
> #X msg 505 282 \; foo10_rcv vis_size \$1 \$2;
> #X msg 275 211 \; foo10_rcv size \$1;
> #X text 305 183 selectable size;
> #X m

[PD] clock sync problem with ableton live

[ray Y]

>i'm using the iac driver to send controller data from ableton live to pd
>but for some reason the midi response has a serious delay. the weird thing is
>that the atom boxes show the correct score but the instrument
>responce does not. how can i fix this problem. regards  r.y


o.k, i discover that when the values are sent imediately, like square

shapes there is no respose delay. only with triangles or ramps.

the longer the increasing or decreasing line in the score the longer

the delay response of the instrument. i'm actually

routing the data to comport at 115200 baud rate from an external

synth control instrument source in live. thanks for any help on this, r.y
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] pd 0.47-0test2 released

[Roman Haefeli]

On Sat, 2016-04-30 at 12:08 -0700, Miller Puckette wrote:
> OK.. I added a 0.46 compatibility mode to get the old, strange behavior :)

I don't see anything regarding this in the logs. Did you push? The most
recent commit I see is adcdcede.

Now I feel somewhat guilty for another compatibility mode ;-) 
Probably more important than supporting the 'strange' behavior would be
to reflect the current behavior in the documentation. See attached
my_canvas-help.pd

Roman


> On Sat, Apr 30, 2016 at 05:42:55PM +0200, Roman Haefeli wrote:
> > On Fri, 2016-04-29 at 15:49 -0700, Miller Puckette wrote:
> > > It looks like the new color handling has made teh "color" message work
> > > more coherently.  In the past, if "color" had two arguments they were
> > > interpreted as background, foreground, and label color, but if only
> > > two were supplied theyt were the foreground and label colors (without
> > > setting background color). 
> > 
> > Actually, a color message with two arguments sets background and label,
> > leaving foreground color unchanged (in Pd <= 0.46).
> > 
> > >  I think the old behavior is horribly confusing.
> > 
> > Until now, I wasn't aware that all iemguis behave the same regarding
> > colors. The new behavior would have worked for old versions of Pd, but
> > it never occurred to me, since the documentation for  [cnv] clearly
> > suggests using only two arguments (background, label), while all other
> > iemguis require three arguments. Thus, I used only two arguments
> > whenever setting the label color for [cnv]s dynamically. The change of
> > behavior breaks quite a few patches of mine. This doesn't mean I'm
> > opposed to introducing sanity in that matter (it's quite easy to fix),
> > but I'm wondering how many other patches with non-trivial GUI designs
> > would be affected.
> > 
> > > I'm not sure whether to consider it a bug or a 'feature' - and whether
> > > back compatibility is more important than making the color-settings sane.
> > 
> > I'm not even sure what is more sane. The new behavior forces the use of
> > a redundant middle argument when setting the label of a [cnv].
> > 
> > Roman
> > 
> > 
> >  
> > > On Mon, Apr 25, 2016 at 10:47:38PM +0200, Roman Haefeli wrote:
> > > > I'm glad to see the release that includes deken is out now.
> > > > 
> > > > One minor thing still apparent in the test2 release: The second argument
> > > > of the 'color' message to a [cnv] object does not change the text color
> > > > anymore in Pd 0.47. Text color can be changed by providing a _third_
> > > > argument, though. 
> > > > 
> > > > See attached patch.
> > > > 
> > > > Cheers and thanks for all the work gone into that release,
> > > > Roman
> > > > 
> > 
> 
> 
> 
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> 
> > https://lists.puredata.info/listinfo/pd-list
> 

#N canvas 0 44 500 292 10;
#X obj 1 1 cnv 15 300 60 foo10_snd foo10_rcv my_canvas=cnv 63 37 0
17 -257472 -355 0;
#X text 4 232 (c) mu...@iem.kug.ac.at;
#X text 46 245 IEM KUG;
#N canvas 219 100 699 530 edit 0;
#X obj 39 226 f;
#X msg 17 205 bang;
#X floatatom 55 204 3 63 88 0 - - -, f 3;
#X floatatom 90 226 3 0 37 0 - - -, f 3;
#X obj 39 249 pack 0 0;
#X text 117 226 y-label;
#X text 83 204 x-label;
#X obj 297 281 f;
#X msg 275 260 bang;
#X floatatom 313 259 3 -10 10 0 - - -, f 3;
#X floatatom 348 281 3 -10 10 0 - - -, f 3;
#X obj 297 304 pack 0 0;
#X obj 309 396 f;
#X msg 287 375 bang;
#X floatatom 325 374 3 20 60 0 - - -, f 3;
#X floatatom 360 396 3 150 200 0 - - -, f 3;
#X obj 309 419 pack 0 0;
#X text 341 259 x-delta;
#X text 375 281 y-delta;
#X text 353 374 x-position;
#X text 387 396 y-position;
#X obj 59 341 f;
#X msg 37 320 bang;
#X floatatom 75 319 3 0 2 0 - - -, f 3;
#X floatatom 110 341 3 4 36 0 - - -, f 3;
#X obj 59 364 pack 0 0;
#X text 103 319 font;
#X text 139 341 height;
#X floatatom 275 183 3 2 20 0 - - -, f 3;
#X msg 39 274 \; foo10_rcv label_pos \$1 \$2;
#X msg 59 390 \; foo10_rcv label_font \$1 \$2;
#X msg 36 430 \; foo10_rcv label blabla;
#X msg 36 466 \; foo10_rcv label my_canvas;
#X msg 309 444 \; foo10_rcv pos \$1 \$2;
#X msg 297 329 \; foo10_rcv delta \$1 \$2;
#X obj 505 234 f;
#X msg 483 213 bang;
#X floatatom 521 212 5 100 1000 0 - - -, f 5;
#X floatatom 556 234 4 50 500 0 - - -, f 4;
#X obj 505 257 pack 0 0;
#X text 566 212 width;
#X text 594 236 height;
#X msg 505 282 \; foo10_rcv vis_size \$1 \$2;
#X msg 275 211 \; foo10_rcv size \$1;
#X text 305 183 selectable size;
#X msg 483 156 \; foo10a_rcv receive foo10_rcv;
#X msg 483 119 \; foo10_rcv receive foo10a_rcv;
#X msg 482 29 \; foo10_rcv send foo10a_snd;
#X msg 482 67 \; foo10_rcv send foo10_snd;
#X msg 509 372 \; foo10_rcv get_pos;
#X obj 510 407 r foo10_snd;
#X obj 510 428 unpack 0 0;
#X floatatom 510 453 4 0 0 0 - - -, f 4;
#X floatatom 575 452 4 0 0 0 - - -, f 4;
#X text 490 452 x=;
#X text 557 452 y=;
#X obj 52 79 f;
#X msg 29 31 bang;
#X floatatom 68 29 3 0 29 0 - - -, f