Pd-dev October 2004

pd-dev@lists.iem.at

32 participants
58 discussions

memory locking policy
by Tim Blechmann 20 Oct '04

20 Oct '04

hi developers ... currently pd in -rt mode tries to lock the memory to the physical memory ... this is done using the MCL_FUTURE policy, which implies that all the memory that will be allocated in future will be placed in the physical memory ... at the moment this is working fine, but when hunting random segfaults in the threaded soundfiler, i found this note in the mlockall man-page: > If MCL_FUTURE has been specified and the number of locked > pages exceeds the upper limit of allowed locked pages, then the > system call which caused the new mapping will fail with ENOMEM. > If these new pages have been mapped by the the growing stack, > then the kernel will deny stack expansion and send a SIGSEGV. to me this seems to be the reason for the soundfiler problems, but it can reduce the stability of a working patch, so i'd suggest to find ways to solve this problem ... possible ideas: -run mlockall(MCL_CURRENT) every once in a while ... maybe after a new object has been created or each second, 10 seconds, 1e+(add a number here) a seconds ... -lock the specific memory region while allocating in getbytes or getalignedbytes -on linux it might be possible to switch of overcommitment of memory in the kernel via /proc/sys/vm/overcommit_memory (don't know if this really does, what i think it's doing) imo, MCL_FUTURE shouldn't be used to avoid this source of error ... although i'm not sure how to deal with it best, i'd prefer mlock instructions during memory allocation ... cheers ... tim -- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

2 8

Re: RRADicaled drum abstractions...
by chun lee 20 Oct '04

20 Oct '04

Hi there: Thanks for all your advices on Vim. Looks like there is another thing to learn now... Am trying to sort out a dual display problem on my laptop at the moment, its a bit frustrating.... Thanks again CHUN

1 0

popup - more weirdness
by B. Bogart 19 Oct '04

19 Oct '04

Hey all, I'm still puzzeling over this one, but I get the impression it has a lot to do with what is happening in PD than in my own external. I'm hoping someone may have already come accross this and could save me some time. If not I'll keep puzzeling. So it seems that in certain circumstances (see patch attached from Oliver) popup will leak some of its data out into the patch. The patch has number of comment objects and a few message boxes: comment: blah blah blah name is: example message: name changed message: name example message: name another The name of the popup is "example" by default. When you change the name of the popup via "name changed" everything seems fine, until you save the patch and see that somehow the messagebox "name example" has magically changed into "name changed" Also odd is that the last atom in the first comment changes "example" also to "changed". It is as if setting the atom in popup to change the name is also setting data elseware in PD. I don't think I'm doing anything special in popup... This happens on OSX and linux. I've put the patches that result from each step of the popup-bug.pd patch popup-bug-1.pd first then popup-bug-2.pd next at the bottom of this email for reference. Here is the structure: typedef struct _popup { t_object x_obj; t_glist * x_glist; t_outlet* out2; int x_rect_width; int x_rect_height; t_symbol* x_sym; int x_height; int x_width; int x_num_options; t_symbol* x_popup_colour; t_symbol* x_popup_name; t_symbol* x_popup_options[MAX_OPTIONS]; } t_popup; Where x_popup_name is the variable the "name" selector is setting. The method that sets the name is: static void popup_name(t_popup* x, t_symbol *name) { DEBUG(post("name start");) DEBUG(post("x_popup_name: %s, name: %s", x->x_popup_name->s_name, name->s_name);) x->x_popup_name->s_name = name->s_name; sys_vgui(".x%x.c.s%x configure -text \"%s\"\n", x->x_glist, x, name->s_name); } Here is the function to save the patch is: static void popup_save(t_gobj *z, t_binbuf *b) { DEBUG(post("save start");) int i; t_popup *x = (t_popup *)z; binbuf_addv(b, "ssiisiiss", gensym("#X"),gensym("obj"), x->x_obj.te_xpix, x->x_obj.te_ypix , gensym("popup"), x->x_width, x->x_height, x->x_popup_colour, x->x_popup_name); /* Loop for menu items */ for(i=0 ; i<x->x_num_options ; i++) { binbuf_addv(b, "s", x->x_popup_options[i]); } binbuf_addv(b, ";"); DEBUG(post("save end");) } And finally my setup looks like: void popup_setup(void) { DEBUG(post("setup start");) popup_class = class_new(gensym("popup"), (t_newmethod)popup_new, 0, sizeof(t_popup),0,A_GIMME,0); class_addmethod(popup_class, (t_method)popup_output, gensym("output"), A_DEFFLOAT, 0); class_addmethod(popup_class, (t_method)popup_name, gensym("name"), A_DEFSYMBOL, 0); class_addmethod(popup_class, (t_method)popup_options, gensym("options"), A_GIMME, 0); class_addmethod(popup_class, (t_method)popup_bgcolour, gensym("bgcolour"), A_DEFSYMBOL, 0); class_doaddfloat(popup_class, (t_method)popup_iselect); class_setwidget(popup_class,&popup_widgetbehavior); #if PD_MINOR_VERSION >= 37 class_setsavefn(popup_class,&popup_save); #endif post("Popup v0.1(test) Ben Bogart."); } I'm really lost as to how I could be setting values outside of my external code. Am I missing any keywords? Am I using any reserved variables? am I simply doing things I should not be??? Thanks all. Ben Bogart popup-bug-1.pd: #N canvas 390 543 625 324 12; #X obj 112 254 popup 124 25 #ffffff changed option; #X msg 112 148 name changed; #X msg 131 178 name changed; #X text 40 46 3.) try to change it back to "example" -> doesn't work ; #X text 40 61 4.) save the patch \, close it and re-open it.; #X msg 150 211 name another; #X text 40 78 5.) do the same with "another"; #X text 41 106 6.) have a look at the changing of the last word in comment; #X text 522 106 1.); #X text 40 30 2.) click the message "name changed"; #X text 40 13 1.) the popup's original name is: changed; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 5 0 0 0; popup-bug-2.pd: #N canvas 390 543 629 328 12; #X obj 112 254 popup 124 25 #ffffff another option; #X msg 112 148 name another; #X msg 131 178 name another; #X text 40 46 3.) try to change it back to "example" -> doesn't work ; #X text 40 61 4.) save the patch \, close it and re-open it.; #X msg 150 211 name another; #X text 40 78 5.) do the same with "another"; #X text 41 106 6.) have a look at the changing of the last word in comment; #X text 522 106 1.); #X text 40 30 2.) click the message "name changed"; #X text 40 13 1.) the popup's original name is: another; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 5 0 0 0; -------- Original Message -------- Subject: Re: [PD] Re: [PD-dev] crashes with "popup" when using inside GOP Date: Sun, 17 Oct 2004 23:41:39 +0200 From: oliver <oliver(a)klingt.org> Reply-To: oliver(a)klingt.org To: B. Bogart <ben(a)ekran.org> References: <49719.132.208.20.8.1096387413.squirrel(a)132.208.20.8> <4162C2FE.9000005(a)klingt.org> <4162F10A.4040303(a)ekran.org> <4163040F.20208(a)klingt.org> <4171C75F.60509(a)ekran.org> hi, ben indeed a very strange bug i found with popup v.0.1 when a popup is created, you give it a name, like "example". now you have the possibility to give it a [name( message and change the name which is then displayed on the popup. now let's say you change it to "changed". works ok. but it's not possible to change it back to "example". thus, saving the patch also changes the popup's name what's even more weirder, is that message boxes that had the term "example" in them, display the term "changed" instead when the patch is re-opened (the same goes for comments, except if the term is quoted!) BTW: this demonstration patch works only once, because with every new saving it gets more and more messed up ;-) ciao oliver B. Bogart wrote: > Hey Oliver, > > Can you possibly get gdb or some kind of debugger do I know why things > are > crashing when you use popup in a gop? (since it works on the other > platforms) > > Also I just commited changes to popup that fix a bug and there is also > an extra > agrument for height. This will break patched using the old popup. > > that's ok, since i always edited the width by hand... > > > I've called > this one v0.1 (I think the other was called v0) > > Lemme know how it works for you. > > Ben > > oliver wrote: > | > | > | B. Bogart wrote: > | > |> Hey Oliver, > |> > |> Hmmm, I've been using popup in GOPs since it was written on OSX and > |> linux without delete problems. You're not, by any chance, trying to > |> send a message to popup via a loadbang when the abstraction loads? Try > |> putting just popup w/out anything else in a gop and see if that still > |> crashes on delete. If that works you can try copying the cutting and > |> pasting the popup to put it on the top and then reconnect it. I did > |> have some issues with deletion order with entry (which shares a lot of > |> code w/ popup). > |> > |> I'm using pd 0.37.1 on OSX and 0.37.1 TEST6 on linux... what are your > |> minor version numbers? "Help" -> "About PD" > | > | > | mine is pd 0.37.2, for whatever reason (don't like to change things too > | often) > | the only thing i needed the GOP for was the height thing. i hoped that > | with the boundaries of a GOP i could reduce it like it does with other > | GUIs. unfortunately it doesn't work, as "popup" seems to be on top of > | all other GUI restrictions ;-) > | > | so, the GOP thing just isn't that important for my request. besides: > the > | GOP using "popup" didn't have anything else but send/receive objects > | connected to its in-/outlets. no loadbang used. > | > |> > |> As for feature requests I can put it on the list of things to do, but > |> saving the height as a creation argument causes the issue of patch > |> compatibility. The arguments are saved in the patch, so the argument > |> list would be compatible with the new popup but not the old one. A > |> possibility is a message that sets the height via message, but when > |> reopening the patch the new height would be lost. > | > | > | wouldn't be that bad, as far as i'm concerned. i understand your > concern > | compatibility problems. (but then: popup is quite a new external, > and as > | far as i reserached, it wasn't ever published on PD-announce...) > | > |> > |> How many pixels high is the popup on windows? Looks about the same on > |> OSX and Linux. (24 pixels high on linux) > | > | > | can't quite tell. i personally use to make my patches with font size > 10, > | which is quite small as i like to put many things (GUIs) inside it. > | therefore my need to save visual space > | > |> > |> As for the widget coming up on top, this is just how tcl/tk draws > |> widgets on canvases. > | > | > | mmh, i think i didn't quite understand that part. what is a "widget" ? > | the thing is: if "popup" behaved like the IEM-GUIs (the GUI that's > | created last covers all the things created before) it would also be > fine > | for me. the problem is that "popup" always stays topmost... > | > | anyway, a cool external, and in general, it's working perfect ! > | > | a great contribution to the PD externals family > | > | ciao > | > | oliver > | > |> > |> Thanks for the feedback, please get back to me when you try what I > |> suggest. > |> > |> Ben > |> > |> oliver wrote: > |> > |>> hi, list, ben > |>> > |>> i discovered, that the popup- menu crashes PD when used inside a GOP > |>> and the GOP is closed (or deleted). so, if you close a patch using a > |>> GOP with "popup" PD will also quit. > |>> > |>> (WinXP with PD 0.37) > |>> > |>> another thing about "popup": > |>> > |>> it would be very cool to give it a vertical size argument. at the > |>> moment you can only define the width of it, but for my needs it's > |>> very often too big in height. > |>> another small "problem" is that it stays on top of all other GUI > |>> elements of PD, no matter when it's created > |>> > |>> just some suggestions for a possible update ;-) > |>> > |>> oliver > |>> > |> > |> _______________________________________________ > |> PD-list(a)iem.at mailing list > |> UNSUBSCRIBE and account-management -> > |> http://iem.at/cgi-bin/mailman/listinfo/pd-list > |> > |> > | -- //////////////////////////////////////////////////////// \\\\\\\\\\\\\ http://klingt.org/ground/lift \\\\\\\\\\\\ ///////// http://klingt.org/executive-ensemble ///////// \\\\\\\\\\\\\ http://klingt.org/~oliver/prb \\\\\\\\\\\\ //////////////////////////////////////////////////////// \\\\\\\\ LIVE-BUILDER (music improvisation tool): \\\\\\ /////// http://klingt.org/~oliver/pd/live-builder ////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ #N canvas 390 543 621 320 12; #X obj 112 254 popup 124 #ffffff example option; #X msg 112 148 name changed; #X msg 131 178 name example; #X text 40 46 3.) try to change it back to "example" -> doesn't work ; #X text 40 61 4.) save the patch \, close it and re-open it.; #X msg 150 211 name another; #X text 40 78 5.) do the same with "another"; #X text 41 106 6.) have a look at the changing of the last word in comment; #X text 522 106 1.); #X text 40 30 2.) click the message "name changed"; #X text 40 13 1.) the popup's original name is: example; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 5 0 0 0;

1 1

Updated documentation for CVS
by guenter geiger 19 Oct '04

19 Oct '04

Hi there ! I have updated the documentation for CVS usage according to the discussions we had in Graz. Please take a look at the bug report, patches and feature request page: http://pure-data.sourceforge.net/bug-report.php As always, feedback and suggestions welcome. Later if we agree (or noone complains) I will send out an announcement to the users list. Guenter

2 1

Re: [PD] Devel_0_37 Compile: undefined reference to `copyvec'
by Tim Blechmann 19 Oct '04

19 Oct '04

> in order to get CVS compiling, i had to uncomment stuff in m_pd.h and > also add some || (__x86_64__) stuff to m_simd.h and maybe > m_simd_gcc.c... or so i thought, the Assembler started whining about > stuff, even though a cat /proc/cpuinfo clearly mentioned sse2 and all it depends on the compiler flags if gcc is able to generate code containing registers, that might not be available on older systems ... btw ... since sse2 is for double precision floating point numbers, pd can't make use of if ... the only sse2 feature is hardware DAZ and FTZ, that's set in the beginning, if available ... > the other stuff, i guess some of it isnt 64bit clean.. anyways what im > getting at is if you have an athlon-XP, you have sse support, but a the size of t_int is hardcoded for the gcc implementation ... so it's not 64bit compatible ... i'm not shure if there is a way to tell gcc the size of a type (if there is, please let me know *g*) but i'm curious ... could you run the simd-optimized gcc code on an amd64? or where you using the c code? cheers .... tim -- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

1 0

Re: RRADicaled drum abstractions...
by chun lee 19 Oct '04

19 Oct '04

Hi Frank: Ok, my RRADical drum abstractions are up in the CVS. Took me a little time to work out how CVS works (roughly) and I think they are up and I hope they are ok. Man, was in a bit of a panic when Vim came up after I did "cvs commit" for the log thing. Not having used Vim before, I was hitting keys almost randomly trying to get it to quit. Had to resort to a quick search on Vim tutorial to get out of it. So, for now, I did not do any log for the entries as I don't know how to use Vim yet. I tried browse the cvs online right after I uploaded the abstraction and could not see them, I guess it might take a little time for it to be updated. Am I correct? Thanks again for your help:) Peace CHUN

4 3

Re: [PD] Re: RRADicaled drum abstractions...
by Frank Barknecht 18 Oct '04

18 Oct '04

Hallo Chun, we should better carry this discussion over to pd-dev now. chun lee hat gesagt: // chun lee wrote: > Thanks for adding me onto the cvs. before I proceed to check stuff in, can I > just check with you that I have understood the things I read in the > documentations? > > The following are the command to import files: > > % export CVS_RSH=ssh > % cvs -z3 -d:ext:chunlee@cvs.sourceforge.net:/cvsroot/pure-data \ > import abstractions/rradical/instruments chunlee source-dist > > When I do this, does it mean that all the files (and sub folders) in the > directory where this command is issued will all be checked into /instruments > at once? Yes, and that's why you should not bother with "import" for now. The command to add a couple of files is "cvs add [filenames]". Let's say I want to add rrad.blabla~.pd to /abs.../rradical/effects I chdir to my local cvs tree: $ cd mycvs/abs.../rradical/effects Copy over rrad.blabla~.pd: $ cp /somewhere/rrad.blabla~.pd . Then "add" it to the cvs: $ cvs add rrad.blabla~.pd This yet has to be committed: $ cvs commit Now I can remove it again and get a fresh version from the CVS: $ rm rrad.blabla~.pd $ cvs update Future "cvs update"s will also download e.g. your changes to that file. > In addition, I will create .cvsrc and .cvswrappers in my home directory as > you pointed out. One question, in the .cvsrc, you have "cvs -z3 -q", does > this mean when you give the command "cvs" in the terminal, it will execute > with the -z3 -q options as default? Yes. > If so, can I add all this "-z3 -q > -d:ext:chunlee@cvs.sourceforge.net:/cvsroot/pure-data" in the .cvsrc > if I am only working on Pd in sf.net? I think, you can, but it's not necessary, and it might mess up if you want to check out something else as anonymous user from Sourceforge. Anyway: when you do your first checkout from CVS using your username/password combo with: $ cvs -z3 -d:ext:chunlee@cvs.sourceforge.net:/cvsroot/pure-data \ co externals then this information gets saved into your local repository in the "CVS" subdirs. You will never need to specify full paths again, only "cvs commit" or "cvs update", if you are in a directory containing the correct CVS subdir. ("cvs import" however needs to know the full path.) Ciao -- Frank Barknecht _ ______footils.org__

1 0

right inlet for s, f and l ?
by Georg Holzmann 17 Oct '04

17 Oct '04

Hallo! Is it possible to handle with a right inlet symbols, floats and lists? Because the External-Howto by IOhannes says, that a right inlet can handle only one selector. If yes, does anyone knows an object, which has this behaviour, so that I can look through the code ? Otherwise a have to make a message to the first inlet with an selector, but then I would need an additional prepend and I want to avoid this (if it's possible). Thanks in advance, LG Georg -- GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++

2 4

popup bug with minimization
by B. Bogart 17 Oct '04

17 Oct '04

Hey all, Upon extending popup to include an argument to specify the vertical size I realized an anoying bug requiring advice. The bug is that when the patch window is minimized the popup (and entry) objects all disapear! Then can still be selected when the window is un-minimized but the widgets themselves are gone. PD returns a string like: windowname already exists in parent. I've put debug messages in all my PD functions and I can't find what function is trying to do the improper thing. The message just seems to come up after the getrectfn completes. I'm looking to gcanvas for inspiration but I can't quite figure out what function gets called when a window is unminimized. Any suggestions of where to look? I used Guenter's "button" as an example and built from there. Looking back it would be really nice to have a standard example of a gui external. Of course this does bring up issues when/if the g_canvas interface changes, but I also think it would be valuable to encourage the development of GUI externals. Of course I'd rather use toxy to make gui externals but have had issues that keep toxy from being able to do what I need (specifically GOP support and the ability to specify the exact pixel size of the widget container in the patch.) It also occured to me looking at the code again that I should change the displace function so that rather than re-creating the widget it simply moves the widget in the canvas via canvas coords. Anyone see any issues caused by this? It may also help with the movement of other gui externals if they are not already using this function. Thanks all for help. PS: I'm now again in a situation where I'll be able to play with toxy more, and I would really love to be able to recreate "popup" and "entry" as a patch & widget file if I was able to use it in the same way I currently am (sized precisely and used in a GOP abstraction) Not to put any cogs in the gears but I think I would be most happy if I could put something like the following into a .wid file and use the widget in toxy: # Define widget variables: set wid #provided by toxy set wid_struc($wid.container) # provided by toxy set wid_struc($wid.alias) popup # name of object to call set wid_struc($wid.tag) "popup1" set wid_struc($wid.width) 100 set wid_struc($wid.height) 25 set wid_struc($wid.relief) raised set wid_struc($wid.bgcolour) black set wid_struc($wid.name) "my popup" set wid_struc($wid.num_options) 5 # Create the Widget menubutton $wid_struc($wid.container).w -relief $wid_struc($wid.relief) -background $wid_struc($wid.bgcolour) -text $wid_struc($wid.name) -direction flush -menu $wid_struc($wid.container).w.menu menu $wid_struc($wid.container).w.menu -tearoff 0 for {set i 0} {$i < $wid_struc($wid.num_options)} {incr i} { $wid_struc($wid.container).w.menu add command -label "test" -command {outlet_symbol(test)} } Where toxy provides: The uniqe $wid value A parent to bind the widget to with: .c create window x_pos y_pos -width $wid_struc(width) -height $wid_struc(height) -anchor $wid_struc(anchor) -window $wid_struc(container) -tags {something-from-toxy $wid_struc(alias)} Perhaps some of the wid_struc variables could be accessible with via properties dialog. Anyhow I'm a very familar tcl/tk programmer and found toxy a little difficult to get my head around. I think it could be a lot easier to use it to build widgets. I do think toxy is the future of GUI design for PD! Enough of me. Ben

2 2

exporting simd functions
by Tim Blechmann 15 Oct '04

15 Oct '04

hi all ... i'm currently thinking of a way to export simd-optimized functions ... at the moment they are implemented in the pd way of passing a pointer to the arguments ... some functions (plus/zero/copy_perform) are already exported this way, so i'd suggest to export the functions this way to make them available for external programmers ... anyway, it would be possible to write wrapper functions like: plus_perf(t_int*); plus_perf_wrap(t_float* in1, t_float* in2, t_float* out, int n); i'm curious, what other developers consider as being more elegant or efficient to use ... cheers... tim -- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev October 2004