hi *!
first of all, thanks for all your helpful replies to my earlier question about messages and abstraction - i'm still trying to understand some of the comments, but i'm going with claude's suggestion for now to keep the ID knowledge outside of all related objects and not use $0. so far, that seems to do the job, and the code is a lot cleaner now. will post asap.
quick question: is it legal to (ab)use creation parameters to inlets and outlets for documentation, or does that lead to unwanted side effects?
i'd like to do something like this:
[inlet Set level in dB] [inlet Set Fader position in mm]
[outlet Current level in dB] [outlet Current Fader position in mm] [outlet~ Gain coefficient]
of course i could use comments, but i don't like the way they don't line-wrap in a controlled way, plus their association to what they are annotating is a bit weak for my taste...
best,
jörn
Hi Jörn
Neat idea. And why not? The restricted words are "hold", "lin", and "linear". The code in g_io.c has the creation methods for voutlet and vinlet. The creation argument is for deciding what type of interpolation method to use during upsampling. In the code below, you can see some if/then/else statements that cover what to do with the creation argument. It defaults to the same thing as no argument when the symbol does not match.
I'm curious to know what happens (in code) when you provide extra arguments to objects--because from experience this does nothing. I think that's a safe practice, but I don't know for sure.
Chuck
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/pd/src/g_io.c?re...
248 static void *vinlet_newsig(t_symbol *s) 249 { 250 t_vinlet *x = (t_vinlet *)pd_new(vinlet_class); 251 x->x_canvas = canvas_getcurrent(); 252 x->x_inlet = canvas_addinlet(x->x_canvas, &x->x_obj.ob_pd, &s_signal); 253 x->x_endbuf = x->x_buf = (t_float *)getbytes(0); 254 x->x_bufsize = 0; 255 x->x_directsignal = 0; 256 outlet_new(&x->x_obj, &s_signal); 257 258 resample_init(&x->x_updown); 259 260 /* this should be though over: 261 * it might prove hard to provide consistency between labeled up- & downsampling methods 262 * maybe indeces would be better... 263 * 264 * up till now we provide several upsampling methods and 1 single downsampling method (no filtering !) 265 */ 266 if (s == gensym("hold"))x->x_updown.method=1; /* up: sample and hold */ 267 else if (s == gensym("lin"))x->x_updown.method=2; /* up: linear interpolation */ 268 else x->x_updown.method=0; /* up: zero-padding */ 269 270 return (x); 271 } 272 273 static void vinlet_setup(void) 274 { 275 vinlet_class = class_new(gensym("inlet"), (t_newmethod)vinlet_new, 276 (t_method)vinlet_free, sizeof(t_vinlet), CLASS_NOINLET, A_DEFSYM, 0); 277 class_addcreator((t_newmethod)vinlet_newsig, gensym("inlet~"), A_DEFSYM, 0); 278 class_addbang(vinlet_class, vinlet_bang); 279 class_addpointer(vinlet_class, vinlet_pointer); 280 class_addfloat(vinlet_class, vinlet_float); 281 class_addsymbol(vinlet_class, vinlet_symbol); 282 class_addlist(vinlet_class, vinlet_list); 283 class_addanything(vinlet_class, vinlet_anything); 284 class_addmethod(vinlet_class, (t_method)vinlet_dsp, gensym("dsp"), 0); 285 class_sethelpsymbol(vinlet_class, gensym("pd")); 286 } ... 558 static void *voutlet_newsig(t_symbol *s) 559 { 560 t_voutlet *x = (t_voutlet *)pd_new(voutlet_class); 561 x->x_canvas = canvas_getcurrent(); 562 x->x_parentoutlet = canvas_addoutlet(x->x_canvas, 563 &x->x_obj.ob_pd, &s_signal); 564 inlet_new(&x->x_obj, &x->x_obj.ob_pd, &s_signal, &s_signal); 565 x->x_endbuf = x->x_buf = (t_sample *)getbytes(0); 566 x->x_bufsize = 0; 567 568 resample_init(&x->x_updown); 569 570 /* this should be though over: 571 * it might prove hard to provide consistency between labeled up- & downsampling methods 572 * maybe indeces would be better... 573 * 574 * up till now we provide several upsampling methods and 1 single downsampling method (no filtering !) 575 */ 576 if (s == gensym("hold"))x->x_updown.method=1; /* up: sample and hold */ 577 else if (s == gensym("lin"))x->x_updown.method=2; /* up: linear interpolation */ 578 else if (s == gensym("linear"))x->x_updown.method=2; /* up: linear interpolation */ 579 else x->x_updown.method=0; /* up: zero-padding; down: ignore samples inbetween */ 580 581 return (x); 582 } 583 584 585 static void voutlet_setup(void) 586 { 587 voutlet_class = class_new(gensym("outlet"), (t_newmethod)voutlet_new, 588 (t_method)voutlet_free, sizeof(t_voutlet), CLASS_NOINLET, A_DEFSYM, 0); 589 class_addcreator((t_newmethod)voutlet_newsig, gensym("outlet~"), A_DEFSYM, 0); 590 class_addbang(voutlet_class, voutlet_bang); 591 class_addpointer(voutlet_class, voutlet_pointer); 592 class_addfloat(voutlet_class, (t_method)voutlet_float); 593 class_addsymbol(voutlet_class, voutlet_symbol); 594 class_addlist(voutlet_class, voutlet_list); 595 class_addanything(voutlet_class, voutlet_anything); 596 class_addmethod(voutlet_class, (t_method)voutlet_dsp, gensym("dsp"), 0); 597 class_sethelpsymbol(voutlet_class, gensym("pd")); 598 }
On Tue, Jun 19, 2012 at 2:41 PM, Jörn Nettingsmeier nettings@stackingdwarves.net wrote:
hi *!
first of all, thanks for all your helpful replies to my earlier question about messages and abstraction - i'm still trying to understand some of the comments, but i'm going with claude's suggestion for now to keep the ID knowledge outside of all related objects and not use $0. so far, that seems to do the job, and the code is a lot cleaner now. will post asap.
quick question: is it legal to (ab)use creation parameters to inlets and outlets for documentation, or does that lead to unwanted side effects?
i'd like to do something like this:
[inlet Set level in dB] [inlet Set Fader position in mm]
[outlet Current level in dB] [outlet Current Fader position in mm] [outlet~ Gain coefficient]
of course i could use comments, but i don't like the way they don't line-wrap in a controlled way, plus their association to what they are annotating is a bit weak for my taste...
best,
jörn
-- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
One potentially nasty drawback to this practice (I found) was that if you change the pseudo-argument in any way, you lose whatever connections were made to that inlet or outlet in the outer patch. I agree with you that comments are a pain in the neck, but at least they don't exhibit this often hard-to-find side effect.
Phil www.pkstonemusic.com
On 6/19/12 12:41 PM, Jörn Nettingsmeier wrote:
quick question: is it legal to (ab)use creation parameters to inlets and outlets for documentation, or does that lead to unwanted side effects?
i'd like to do something like this:
[inlet Set level in dB] [inlet Set Fader position in mm]
[outlet Current level in dB] [outlet Current Fader position in mm] [outlet~ Gain coefficient]
of course i could use comments, but i don't like the way they don't line-wrap in a controlled way, plus their association to what they are annotating is a bit weak for my taste...
best,
jörn
...and it would be lovely to have the text appear in a tooltip when mousing over the inlet/outlet in the parent patch! The drawback mentioned by Phil could be pretty annoying though. Question 1.: What's up with tooltips in pd right now? I couldn't find it out from the list archives. Question 2.: What if the parser would explicitly stop parsing elements when it finds ";#" and would use the remaining part as a comment/tooltip/whatever? Could this change break anything in real life?
András
On Tue, Jun 19, 2012 at 10:22 PM, Phil Stone pkstone@ucdavis.edu wrote:
One potentially nasty drawback to this practice (I found) was that if you change the pseudo-argument in any way, you lose whatever connections were made to that inlet or outlet in the outer patch. I agree with you that comments are a pain in the neck, but at least they don't exhibit this often hard-to-find side effect.
Phil www.pkstonemusic.com
On 6/19/12 12:41 PM, Jörn Nettingsmeier wrote:
quick question: is it legal to (ab)use creation parameters to inlets and outlets for documentation, or does that lead to unwanted side effects?
i'd like to do something like this:
[inlet Set level in dB] [inlet Set Fader position in mm]
[outlet Current level in dB] [outlet Current Fader position in mm] [outlet~ Gain coefficient]
of course i could use comments, but i don't like the way they don't line-wrap in a controlled way, plus their association to what they are annotating is a bit weak for my taste...
best,
jörn
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
From: András Murányi muranyia@gmail.com To: pd-list@iem.at Sent: Tuesday, June 19, 2012 4:47 PM Subject: Re: [PD] creation parameters to inlets/outlets for documentation?
...and it would be lovely to have the text appear in a tooltip when mousing over the inlet/outlet in the parent patch! The drawback mentioned by Phil could be pretty annoying though. Question 1.: What's up with tooltips in pd right now? I couldn't find it out from the list archives.
They will display for the object text, based on the description of the object inside the META subpatch of its help patch. They will display for xlets, showing the types of messages accepted, based on the META subpatch of its help patch.
Question 2.: What if the parser would explicitly stop parsing elements when it finds ";#" and would use the remaining part as a comment/tooltip/whatever? Could this change break anything in real life?
[;# obscure example; but i think matju's #V is a better, more readable solution that could also be used for lots of other graphical properties, and would safely be ignored by older versions(
[receive #] | [print]
[receive but] | [print]
András
On Tue, Jun 19, 2012 at 10:22 PM, Phil Stone pkstone@ucdavis.edu wrote:
One potentially nasty drawback to this practice (I found) was that if you change the pseudo-argument in any way, you lose whatever connections were made to that inlet or outlet in the outer patch. I agree with you that comments are a pain in the neck, but at least they don't exhibit this often hard-to-find side effect.
Phil www.pkstonemusic.com
On 6/19/12 12:41 PM, Jörn Nettingsmeier wrote:
quick question: is it legal to (ab)use creation parameters to inlets and outlets for documentation, or does that lead to unwanted side effects?
i'd like to do something like this:
[inlet Set level in dB] [inlet Set Fader position in mm]
[outlet Current level in dB] [outlet Current Fader position in mm] [outlet~ Gain coefficient]
of course i could use comments, but i don't like the way they don't line-wrap in a controlled way, plus their association to what they are annotating is a bit weak for my taste...
best,
jörn
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 06/20/2012 02:42 AM, Jonathan Wilkes wrote:
________________________________ From: András Murányi ...and it would be lovely to have the text appear in a tooltip when mousing over the inlet/outlet in the parent patch! The drawback mentioned by Phil could be pretty annoying though. Question 1.: What's up with tooltips in pd right now? I couldn't find it out from the list archives.
They will display for the object text, based on the description of the object inside the META subpatch of its help patch. They will display for xlets, showing the types of messages accepted, based on the META subpatch of its help patch.
Question 2.: What if the parser would explicitly stop parsing elements when it finds ";#" and would use the remaining part as a comment/tooltip/whatever? Could this change break anything in real life?
[;# obscure example; but i think matju's #V is a better, more readable solution that could also be used for lots of other graphical properties, and would safely be ignored by older versions(
[receive #] | [print]
[receive but] | [print]
:-D took me a while to understand that one, but yeah, thanks for pointing out the pitfalls...
I should clarify this by adding that the side-effect won't happen if you edit an abstraction's inlets/outlets without any objects that include that abstraction being open at the time. Apparently, the change causes a re-instantiation of the abstraction in the parent, breaking the inlet/outlet connections.
On 6/19/12 1:22 PM, Phil Stone wrote:
One potentially nasty drawback to this practice (I found) was that if you change the pseudo-argument in any way, you lose whatever connections were made to that inlet or outlet in the outer patch. I agree with you that comments are a pain in the neck, but at least they don't exhibit this often hard-to-find side effect.
Phil www.pkstonemusic.com
On 6/19/12 12:41 PM, Jörn Nettingsmeier wrote:
quick question: is it legal to (ab)use creation parameters to inlets and outlets for documentation, or does that lead to unwanted side effects?
i'd like to do something like this:
[inlet Set level in dB] [inlet Set Fader position in mm]
[outlet Current level in dB] [outlet Current Fader position in mm] [outlet~ Gain coefficient]
of course i could use comments, but i don't like the way they don't line-wrap in a controlled way, plus their association to what they are annotating is a bit weak for my taste...
best,
jörn
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
András Murányi -
Charles Henry -
Jonathan Wilkes -
Jörn Nettingsmeier -
Phil Stone