Re: [PD] Pd-GUI-Rewrite 0.43 status: usable
I downloaded 0.43.0-devel-20100119 (windows) and found a few things: 1) A patch like the one I attached used to have no scrollbars (all the way up to the dev version I downloaded on the 11th). Now it has scrollbars. 2) In the attached patch right-clicking and getting "Properties" or "Help" doesn't work properly. For instance, if I right-click on [bag] in the upper right-hand corner and choose "Help", it gives me intro-help.pd. If I right-click the message box with the selector "clear" in it and choose help, it gives me text-help.pd. 3) For menu->Window: is the tree structure represented solely by indentation? There was some problem I was running into with the previous build where selected text in a msg box sticks until you force a refresh by minimizing/maximizing, but it looks you fixed it. -Jonathan #N canvas 0 0 555 619 10; #X obj 0 595 cnv 15 550 21 empty \$0-pddp.cnv.footer empty 20 12 0 14 -228856 -66577 0; #X obj 0 0 cnv 15 550 40 empty \$0-pddp.cnv.header bag 3 12 0 18 -204280 -1 0; #X obj -1 287 cnv 3 550 3 empty \$0-pddp.cnv.inlets inlets 15 12 0 13 -228856 -1 0; #N canvas 46 242 494 344 META 0; #X text 12 65 TEMPLATE template-help.pd v0.1; #X text 12 85 PLATFORM windows macosx gnulinux; #X text 12 125 LIBRARY internal; #X text 12 165 WEBSITE http://crca.ucsd.edu/~msp/; #X text 12 205 RELEASE_VERSION 0.41.4; #X text 12 185 RELEASE_DATE 2009-06-12; #X text 12 45 LICENSE SIBSD; #X text 12 145 AUTHOR Miller Puckette; #X text 12 105 DATATYPE float list; #X text 12 225 HELP_PATCH_AUTHORS Updated for Pd v0.41. Revised by Jonathan Wilkes to conform to the PDDP template for Pd version 0.42. ; #X text 12 5 GENRE control; #X text 12 25 KEYWORDS storage lists; #X restore 500 597 pd META; #X obj -1 495 cnv 3 550 3 empty \$0-pddp.cnv.outlets outlets 15 12 0 13 -228856 -1 0; #X obj -1 538 cnv 3 550 3 empty \$0-pddp.cnv.argument arguments 15 12 0 13 -228856 -1 0; #X obj -1 566 cnv 3 550 3 empty \$0-pddp.cnv.more_info more_info 15 12 0 13 -228856 -1 0; #X text 98 542 (none); #N canvas 54 478 428 109 Related_objects 0; #X obj 61 42 makenote; #X obj 21 42 poly; #X obj 122 42 list; #X obj 1 1 cnv 15 425 20 empty \$0-pddp.cnv.header empty 3 12 0 14 -204280 -1 0; #X text 7 1 [bag] Related Objects; #X restore 102 598 pd Related_objects; #X obj 78 296 cnv 17 3 125 empty \$0-pddp.cnv.let.0 0 5 9 0 16 -228856 -162280 0; #X text 98 295 float; #X text 98 352 list; #X text 98 503 float; #X obj 78 504 cnv 17 3 30 empty \$0-pddp.cnv.let.0 0 5 9 0 16 -228856 -162280 0; #X obj 78 440 cnv 17 3 45 empty \$0-pddp.cnv.let.1 1 5 9 0 16 -228856 -162280 0; #X text 98 439 float; #X text 98 383 flush; #X text 98 413 clear; #X text 148 383 - output all values one by one \, in the order they were received \, and clear the collection.; #X text 148 503 - upon sending the "flush" message to the left inlet \, [bag] will output each value in the order it was received.; #X text 99 570 You can use [bag] to mimic a sustain pedal \, for example. ; #X msg 162 88 60 64; #X msg 213 88 60 0; #X msg 257 88 62 64; #X msg 304 88 62 0; #X obj 162 215 print; #X text 207 216 Output is in the printout window.; #X msg 304 134 clear; #X msg 303 111 flush; #X obj 162 185 bag; #X text 148 352 - a (value \, flag) pair is distributed to the two inlets. Lists with more than two elements will be truncated.; #X text 11 23 collection of numbers; #X obj 493 3 bag; #X obj 465 20 pddp/pddplink http://wiki.puredata.info/en/bag -text pdpedia: bag; #X text 148 413 - clear the collection.; #X text 147 439 - a float to the right inlet sets the "flag": if zero \, values to the left inlet will not be added to the collection. If nonzero \, values to the right inlet will be added to the collection. ; #X text 148 295 - a float to the left inlet will be added to the collection if the last value the right inlet received was nonzero. If the last value the right inlet received was zero \, the float sent to the right inlet will be removed from the collection.; #X connect 21 0 29 0; #X connect 22 0 29 0; #X connect 23 0 29 0; #X connect 24 0 29 0; #X connect 27 0 29 0; #X connect 28 0 29 0; #X connect 29 0 25 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Problem with Snow Leopard and Flext
Hey all, i've got some news on that issue. For me, flext-based externals crash when flext is built with gcc 4.2.1 and the -Os option (optimize for space). This setting is defined in buildsys/config-pd-mac.txt. It doesn't crash with any other optimization flag (e.g. -O2 or -O3). That seems to be a compiler bug, but i'm thankful for any observations on that issue. I consequently changed the default optimization scheme for OSX to -O2 in the current svn. gr~~~ Am 17.01.2010 um 13:01 schrieb Thomas Grill: > Hey all, > the current flext svn version should fix all compilation issues on > Snow Leopard / gcc 4.2. > However, i can confirm that flext crashes also for me when pd is > launched. I'll be able to look into in about a week, so until then, > any hints/solutions/backtraces are welcome. > gr~~~ > > 2010/1/16 Rich E : >> I have been working with a flext external in Snow Leopard, but I did not >> have any success getting it to work with Pd Extended (long story, it is a >> wacom external that is dealing with all the Carbon/Cocoa problems that >> currently exist). >> I compile everything with CFLAGS="-arch i386". No seg faults related to >> flext. I think, from this post and the one below, that flext is linked as >> 64bit. I just today had to reinstall all my pd stuff because of a hard >> drive crash and after making sure everything is cleanly built as 32bit, no >> problems (again, in Snow Leopard). >> >> 2010/1/14 Cécile Picard-Limpens >>> >>> Dear List, >>> >>> I'm encountering the same problem as Miguel.. (message on Sat Dec 12). I'm >>> using Apple Snow Leopard (10.6.2) on my macbook (2.26 GHz Intel Core Duo). >>> As anyone succeeded building and launching flext objects using OSX Snow >>> Leopard? >>> It compiles but crashes at launching without error messages... >>> >>> Does it mean that the Pd-extended version compiled with x86_64 is needed? >>> >>> Thanks for your help! >>> >>> Cecile. >>> >>> >>> >>> ___ >>> 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 >> >> > > > > -- > Thomas Grill > http://g.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] 'relocate' message
On Jan 6, 2010, at 4:02 PM, Jonathan Wilkes wrote: --- On Sun, 1/3/10, Hans-Christoph Steiner wrote: From: Hans-Christoph Steiner Subject: Re: [PD] 'relocate' message To: "Jonathan Wilkes" Cc: "Pd List" Date: Sunday, January 3, 2010, 7:14 AM [...] Hmm, that makes sense. I wonder if this should just have the same syntax as 'canvas', so: relocate x1 y1 x2 y2 Where x is the upper left corner, and y is the lower right corner. .hc That's not right. The syntax of 'canvas' is: canvas topLeftX topLeftY Width Height (not including the menu/title bar) -Jonathan Hmm, you are indeed right. That's how the internal canvas_setbounds() function specs the coords and how t_glist stores them, unfortunately... .hc "[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity."-John Gilmore ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] trunk in svn
On Jan 19, 2010, at 5:51 PM, András Murányi wrote: 2010/1/19 Hans-Christoph Steiner On Jan 19, 2010, at 1:47 PM, András Murányi wrote: 2010/1/19 Hans-Christoph Steiner On Jan 19, 2010, at 1:13 PM, András Murányi wrote: I've been trying to check out the current trunk form svn but i keep getting an error (upon deletion of the checkout folder as well): 'puredata/externals/gridflow' is already a working copy for a different URL Where shall i get the sources of the newest non-rewrite pd- extended from? http://puredata.info/docs/developer/GettingPdSource .hc Well it seems I'm knocking on the right door (svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk pd-extended). But this is the one that gives me the above error. Andras Try rsync. Or try the updated svn instructions on the GettingPdSource page. .hc Cool, thanks. + Gem was needed too. and... it seems "make clean" gets into an endless loop with zexy and iemlib. Please add the Gem checkout instructions to that wiki page :-) .hc You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] trunk in svn
2010/1/19 Hans-Christoph Steiner > > On Jan 19, 2010, at 1:47 PM, András Murányi wrote: > > > > 2010/1/19 Hans-Christoph Steiner > >> >> On Jan 19, 2010, at 1:13 PM, András Murányi wrote: >> >> I've been trying to check out the current trunk form svn but i keep >> getting an error (upon deletion of the checkout folder as well): >> >> 'puredata/externals/gridflow' is already a working copy for a different >>> URL >>> >> >> Where shall i get the sources of the newest non-rewrite pd-extended from? >> >> >> http://puredata.info/docs/developer/GettingPdSource >> >> .hc >> > > Well it seems I'm knocking on the right door (svn co > https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunkpd-extended). > But this is the one that gives me the above error. > > Andras > >> > Try rsync. Or try the updated svn instructions on the GettingPdSource > page. > > .hc > > Cool, thanks. + Gem was needed too. and... it seems "make clean" gets into an endless loop with zexy and iemlib. Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] recording to array in loop mode?
thanks for all the replies. and yes, something similar you posted, frank, is what i had in mind. i couldn't remember the block-quantisation, but it makes sense now. in G05.execution.order it says: "DSP sorting in Pd follows the hierarchy of subpatches" hierarchy of subpatches means top to bottom or simply outlet to inlet? thanks, volker. On 19.01.2010, at 13:05, Frank Barknecht wrote: Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: Mike Moser-Booth hat gesagt: // Mike Moser-Booth wrote: If I'm not mistaken, I believe the trick to getting this to work is to make sure the array size is a multiple of the block size. [tabwrite~] conforms to block boundaries, to if you bang it in the middle of a block, it won't begin writing until the end of the block. That's probably where the clicks are coming from. The actual size of the array doesn't matter: If you have for example an array of size 300, you could record and playback only the first 256 samples (4*64) with block-quantized objects. Just ignore the last 44 samples. Anyway, attached is a tabwrite~-based looping recorder. I use a [bang~] based metro to start recording there, and some DSP order forcing to make sure, the table is written before it is read to be able to get a delay time of zero as well. Ciao -- Frank ___ 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
Re: [PD] Graph-on-Parent GUI debugging - please test and report!
On Mon, Jan 18, 2010 at 10:22 PM, Hans-Christoph Steiner wrote: > > Hey all, > > Since I've seen a lot of people put a lot of effort into making pretty > elaborate GUIs with the Graph-on-Parent, things like netpd and MetaStudio, I > want to try to nail down the last GOP bugs in both Pd-extended 0.42.5 and > pd-gui-rewrite 0.43. > > So I am asking for lots of testing and reporting of problems, and I'm going > through all of the bug reports and emails that I have on the topic now. > > .hc > > Well i have a problemmatic patch but not necessarily because of GOP. - it works well with an i386 build, - pretty slow with an amd64 build, but works, - freezes the box with the rewrite (on amd64). cpu doesn't go so high but the wm stops responding and ctrl-alt-backspace doesn't work either. it uses some moonlib which is not essential, and the glorious sssad. looks complicated at the first sight, actually it's just that i prefer hand-wiring sssad (as opposed to autopatching). btw its a 32 step drum pattern with the "backlight" running with the position - those interested check it out ;o) Andras #N canvas 97 124 1299 871 10; #X obj 101 101 cnv 15 668 60 empty empty empty 20 12 0 14 -128992 -66577 0; #X obj -48 379 i; #X obj 157 150 tgl 12 0 empty empty empty 0 -6 0 10 -241291 -262144 -262144 0 1; #X floatatom 770 467 5 0 0 0 - - -; #X obj 169 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 1 1; #X obj 3 379 i; #X obj 181 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 1 1; #X obj 28 379 i; #X obj 193 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 1 1; #X obj 59 379 i; #X obj 208 150 tgl 12 0 empty empty empty 0 -6 0 10 -260818 -262144 -262144 1 1; #X obj 84 379 i; #X obj 220 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 1 1; #X obj 111 379 i; #X obj 232 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 0 1; #X obj 135 379 i; #X obj 244 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 1 1; #X obj 167 379 i; #X obj 259 150 tgl 12 0 empty empty empty 0 -6 0 10 -260818 -262144 -262144 1 1; #X obj 192 379 i; #X obj 271 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 0 1; #X obj 218 379 i; #X obj 283 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 1 1; #X obj 243 379 i; #X obj 295 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 1 1; #X obj 273 379 i; #X obj 310 150 tgl 12 0 empty empty empty 0 -6 0 10 -260818 -262144 -262144 0 1; #X obj 298 379 i; #X obj 322 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 0 1; #X obj 324 379 i; #X obj 334 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 0 1; #X obj 349 379 i; #X obj 346 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 0 1; #X obj 770 551 outlet; #X obj 45 284 sel 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31; #X obj 383 379 i; #X obj 408 379 i; #X obj 434 379 i; #X obj 459 379 i; #X obj 490 379 i; #X obj 515 379 i; #X obj 541 379 i; #X obj 566 379 i; #X obj 597 379 i; #X obj 622 379 i; #X obj 648 379 i; #X obj 672 379 i; #X obj 702 379 i; #X obj 727 379 i; #X obj 754 379 i; #X obj 361 150 tgl 12 0 empty empty empty 0 -6 0 10 -241291 -262144 -262144 0 1; #X obj 373 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 1 1; #X obj 385 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 0 1; #X obj 397 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 1 1; #X obj 412 150 tgl 12 0 empty empty empty 0 -6 0 10 -260818 -262144 -262144 1 1; #X obj 424 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 0 1; #X obj 436 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 1 1; #X obj 448 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 1 1; #X obj 463 150 tgl 12 0 empty empty empty 0 -6 0 10 -260818 -262144 -262144 0 1; #X obj 475 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 0 1; #X obj 487 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 0 1; #X obj 499 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 1 1; #X obj 514 150 tgl 12 0 empty empty empty 0 -6 0 10 -260818 -262144 -262144 0 1; #X obj 526 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 0 1; #X obj 538 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 1 1; #X obj 550 150 tgl 12 0 empty empty empty 0 -6 0 10 -258699 -262144 -262144 1 1; #X obj 770 500 sel 1; #X obj 210 -107 inlet; #X obj 298 -107 inlet; #X obj 562 150 bng 12 250 50 0 empty empty x 3 5 1 10 -228856 -1 -258113 ; #X msg 562 175 0; #X obj 600 150 bng 12 250 50 0 empty empty 4 4 6 1 10 -128992 -1 -262144 ; #X msg 607 262 0 \, 4 \, 8 \, 12 \, 16 \, 20 \, 24 \, 28; #X obj 587 150 bng 12 250 50 0 empty empty 2 4 6 1 10 -128992 -1 -262144 ; #X msg 594 239 0 \, 2 \, 4 \, 6 \, 8 \, 10 \, 12 \, 14 \, 16 \, 18 \, 20 \, 22 \, 24 \, 26 \, 28 \, 30; #X obj 613 150 bng 12 250 5
Re: [PD] trunk in svn
On Jan 19, 2010, at 1:47 PM, András Murányi wrote: 2010/1/19 Hans-Christoph Steiner On Jan 19, 2010, at 1:13 PM, András Murányi wrote: I've been trying to check out the current trunk form svn but i keep getting an error (upon deletion of the checkout folder as well): 'puredata/externals/gridflow' is already a working copy for a different URL Where shall i get the sources of the newest non-rewrite pd-extended from? http://puredata.info/docs/developer/GettingPdSource .hc Well it seems I'm knocking on the right door (svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk pd-extended). But this is the one that gives me the above error. Andras Try rsync. Or try the updated svn instructions on the GettingPdSource page. .hc "[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] trunk in svn
2010/1/19 Hans-Christoph Steiner > > On Jan 19, 2010, at 1:13 PM, András Murányi wrote: > > I've been trying to check out the current trunk form svn but i keep getting > an error (upon deletion of the checkout folder as well): > > 'puredata/externals/gridflow' is already a working copy for a different URL >> > > Where shall i get the sources of the newest non-rewrite pd-extended from? > > > http://puredata.info/docs/developer/GettingPdSource > > .hc > Well it seems I'm knocking on the right door (svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk pd-extended). But this is the one that gives me the above error. Andras > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] trunk in svn
On Jan 19, 2010, at 1:13 PM, András Murányi wrote: I've been trying to check out the current trunk form svn but i keep getting an error (upon deletion of the checkout folder as well): 'puredata/externals/gridflow' is already a working copy for a different URL Where shall i get the sources of the newest non-rewrite pd-extended from? http://puredata.info/docs/developer/GettingPdSource .hc Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] trunk in svn
I've been trying to check out the current trunk form svn but i keep getting an error (upon deletion of the checkout folder as well): 'puredata/externals/gridflow' is already a working copy for a different URL > Where shall i get the sources of the newest non-rewrite pd-extended from? Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-GUI-Rewrite 0.43 status: usable
2010/1/19 Hans-Christoph Steiner > > On Jan 19, 2010, at 12:13 PM, András Murányi wrote: > > >> finally: this is surely time for a tooltip lingering over the "DSP" >> button, explaining, that this is the button to press if you want to hear >> something. >> >> >> I think a tooltip is a very good idea for the Pd window. >> >> .hc >> >> >> I'm afraid there is no universal method in Tk for tooltips - is there? >> >> Andras >> > > There is no included method called "tooltips", but you can easily make your > own. Here are some examples: > > http://wiki.tcl.tk/3060 > > .hc > Andras > Yes I did try some of those but they were not so perfect or reliable. If you find a good one, however, you're there. Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] abs~ on 64-bit and 0.42.3
Miller Puckette wrote: > Hi all, > > I juect checked and abs~ and exp~ are indeed broken in 0.42-3 (and 0.42-4) - > that got fixed in my source a few months ago but I haven't been releasing > anything since there's a huge GUI re-write underway. > > Here's the damage... > > [...@slash src]$ diff d_math.c ~/pd/src/d_math.c > 630c630 > < *out = exp(*in1); > --- >> *out++ = exp(*in1++); > 723c723 > < *out = (f >= 0 ? f : -f); > --- >> *out++ = (f >= 0 ? f : -f); > > I think I have to try the latest GUI rewrite code (Hans-Christophe and Hannes > are working on it and I'm basically just waiting for it to stabilize) -- and > if it's not at least stable enough for me to put out as a "test" version, I > should probably go back and apply all the applicable bug fixes I can find to > 0.42 (a dangerous prospect since that process often seems to _introduce_ > bugs as well as fix them!) > in this very case, i can confirm that the bugs are already fixed in Pd 0.42-5 (which - according to the SVN logs - was released in may 2009) in this case i would consider upgrading Pd to the newest stable release. apart from that i found that the SSE-code in zexy used for the zexy implementation of [abs~] is buggy as well. for whatever reasons, (recent versions(?) of) gcc always imply SSE, which makes the broken code somewhat mandatory. since Pd>=0.42 will allow libraries to override its built-ins, you might eventually come across the [abs~] of zexy as well. in this case, please update zexy to the latest SVN as well. mfgasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-GUI-Rewrite 0.43 status: usable
On Jan 19, 2010, at 1:33 AM, Jonathan Wilkes wrote: --- On Tue, 1/19/10, Hans-Christoph Steiner wrote: From: Hans-Christoph Steiner Subject: Re: [PD] Pd-GUI-Rewrite 0.43 status: usable To: "Jonathan Wilkes" Cc: "PD list" Date: Tuesday, January 19, 2010, 5:26 AM On Jan 18, 2010, at 7:09 PM, Jonathan Wilkes wrote: [Kind of picky...] In the console, there's a checkbox with the clickable text "DSP." I know acronyms are normally capitalized, but in this case if the text read "dsp", the tk label/checkbox would accurately reflect the message one sends to pd to turn audio on and off (with the checkbox fulfilling the 0/1 argument). I think someone complained recently that DSP would be less clear to a beginner than "compute audio." I think that's true, so if the beginner has to read a help file to figure out what it means, they might as well learn the message "dsp 0" and "dsp 1" at the same time (and be reminded of the _exact_ selector everytime they look at the console). "compute audio" is easier to understand, but it then doesn't match the 'pd dsp' message or the Media menu items. I think overall, its easier if people learn that DSP means computing audio as well as other things, and the term DSP is used consistently throughout. I don't have a strong feeling on upper vs lower case on DSP tho. Well it's definitely a minor distinction-- I just think that the lower case reflects what's going on under the hood more closely, which is a good thing. Something else I've been wondering about...is there any reason the top of the console couldn't be a pd canvas or a gop? As it is, it's just two [tgl]s, two [vu]s, and maybe a [bng]. Other than the DIO button it's just a [dac~], [adc~], and [s pd], right? It could be a GOP, I think all of the properties, about, etc. should be Pd patches. But before doing that, I think we need better support for standard Tk widgets within Pd. .hc -Jonathan In a similar vein: what about "audiostatus" instead of "DIO"? -Jonathan I never use the DIO button and don't really know what it is, so I left it as is ;-) As far as I can gather its an error light for if there are communications troubles with the audio interface. .hc "We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-GUI-Rewrite 0.43 status: usable
On Jan 19, 2010, at 12:13 PM, András Murányi wrote: finally: this is surely time for a tooltip lingering over the "DSP" button, explaining, that this is the button to press if you want to hear something. I think a tooltip is a very good idea for the Pd window. .hc I'm afraid there is no universal method in Tk for tooltips - is there? Andras There is no included method called "tooltips", but you can easily make your own. Here are some examples: http://wiki.tcl.tk/3060 .hc kill your television ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-GUI-Rewrite 0.43 status: usable
> finally: this is surely time for a tooltip lingering over the "DSP" >> button, explaining, that this is the button to press if you want to hear >> something. >> > > > I think a tooltip is a very good idea for the Pd window. > > .hc > > I'm afraid there is no universal method in Tk for tooltips - is there? Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] abs~ on 64-bit and 0.42.3
Hi all, I juect checked and abs~ and exp~ are indeed broken in 0.42-3 (and 0.42-4) - that got fixed in my source a few months ago but I haven't been releasing anything since there's a huge GUI re-write underway. Here's the damage... [...@slash src]$ diff d_math.c ~/pd/src/d_math.c 630c630 < *out = exp(*in1); --- > *out++ = exp(*in1++); 723c723 < *out = (f >= 0 ? f : -f); --- > *out++ = (f >= 0 ? f : -f); I think I have to try the latest GUI rewrite code (Hans-Christophe and Hannes are working on it and I'm basically just waiting for it to stabilize) -- and if it's not at least stable enough for me to put out as a "test" version, I should probably go back and apply all the applicable bug fixes I can find to 0.42 (a dangerous prospect since that process often seems to _introduce_ bugs as well as fix them!) cheers Miller On Tue, Jan 19, 2010 at 11:34:01AM +0100, IOhannes m zmoelnig wrote: > Orm Finnendahl wrote: > > Hi all, > > > > sorry, forgot the attachement. Here it is again... > > > > Hi all, > > > > abs~ seems to be broken on my machine with 64-bit linux and pd 0.42.3 > > > > Clicking in the bang in the attached patch should result in a straight > > line at +0.5 (at least that's what I think it should do). > > > > Instead the result is a straight line at -0.5 with only two points at > > arrayindex 0 and 64 set to +0.5 > > > > I checked the sources which were used to compile the program and they > > look ok. > > > > It feels like a 64-bit problem somehow (maybe some compiler flags I > > didn't set up correctly), but then again I shouldn't rely too much on > > feelings even though it is a computer. > > there is a bugreport that might be related to this: > https://sourceforge.net/tracker/index.php?func=detail&aid=2658537&group_id=55736&atid=478070 > > > mfadr > IOhannes > ___ > 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
Re: [PD] Pd-GUI-Rewrite 0.43 status: usable
On Jan 19, 2010, at 3:35 AM, IOhannes m zmoelnig wrote: Hans-Christoph Steiner wrote: "compute audio" is easier to understand, but it then doesn't match the 'pd dsp' message or the Media menu items. häh? the media menu items in Pd <=0.42 reads "audio ON" and "audio OFF". these do not match the "pd dsp" message, but kind of relate to "compute audio". indeed in pd-gui-rewrite, the "audio ON" is renamed to "DSP An" and "DSP Aus" (seems like the former is a demand for a de_AT localization :-)) but that doesn't really help the argument. I think overall, its easier if people learn that DSP means computing audio as well as other things, and the term DSP is used consistently throughout. makes sense. otoh, most newbies (those who probably won't start using [; pd dsp 1() will want to turn on audio rather than learn what "dsp" means. on the third hand, they will probaby wonder why they have to turn on anything, so it won't matter whether it's audio or dsp. finally: this is surely time for a tooltip lingering over the "DSP" button, explaining, that this is the button to press if you want to hear something. I think a tooltip is a very good idea for the Pd window. .hc Access to computers should be unlimited and total. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sys_gui outlet WAS: create folder implementation
On Jan 18, 2010, at 12:44 PM, colet.patr...@free.fr wrote: Selon Hans-Christoph Steiner : sys_gui.c. That code is pretty simple. I think you could do it by appending something like "; pdsend "#sys_gui-receiver bang" to every command sent, then bind to the receiver name "#sys_gui-receiver" to get that bang. attached diff should be this binding method but it doesn't work, the bang is sent before tcl is done; why attached patch works? (it bangs after tcl command is done), the only difference is that the send command is trigged. pc Ah, the error came from [textfile] not wanting to write an empty file. This works for me with your unchanged C code: createDir.pd Description: Binary data For the outlet, I would bind to a unique receive symbol generated from the pointer to the instance of the sys_gui object, then use that receive to send the bang in Tcl, receive it in C, then output it out the outlet: sprintf(buf,"#%lx", (long unsigned int)x); .hc News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sys_gui outlet WAS: create folder implementation
On Jan 18, 2010, at 12:44 PM, colet.patr...@free.fr wrote: Selon Hans-Christoph Steiner : sys_gui.c. That code is pretty simple. I think you could do it by appending something like "; pdsend "#sys_gui-receiver bang" to every command sent, then bind to the receiver name "#sys_gui-receiver" to get that bang. attached diff should be this binding method but it doesn't work, the bang is sent before tcl is done; why attached patch works? (it bangs after tcl command is done), the only difference is that the send command is trigged. pc Sending this bit of Tcl from the Tcl entry in the 0.43 Pd window worked for me with your test patch, it is odd that it wouldn't work when send from Pd. file delete -force /tmp/test-folder; file mkdir /tmp/test-folder; pdsend "test bang" .hc Information wants to be free.-Stewart Brand ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] recording to array in loop mode?
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: > Mike Moser-Booth hat gesagt: // Mike Moser-Booth wrote: > > > If I'm not mistaken, I believe the trick to getting this to work is to > > make sure the array size is a multiple of the block size. [tabwrite~] > > conforms to block boundaries, to if you bang it in the middle of a > > block, it won't begin writing until the end of the block. That's > > probably where the clicks are coming from. > > The actual size of the array doesn't matter: If you have for example an array > of size 300, you could record and playback only the first 256 samples (4*64) > with block-quantized objects. Just ignore the last 44 samples. Anyway, attached is a tabwrite~-based looping recorder. I use a [bang~] based metro to start recording there, and some DSP order forcing to make sure, the table is written before it is read to be able to get a delay time of zero as well. Ciao -- Frank #N canvas 173 114 659 491 10; #X floatatom 228 81 5 0 0 0 - - -; #X obj 228 295 dac~; #X obj 228 272 *~ 0; #X obj 270 270 hsl 128 15 0 1 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 6600 1; #X obj 445 141 table \$0-x 6400; #X floatatom 348 71 5 0 0 1 blocks - -; #X obj 368 139 timer; #X obj 368 120 t b b; #X obj 368 163 change; #X floatatom 368 186 5 0 0 0 - - -; #N canvas 0 0 453 361 blockmetro 0; #X obj 151 93 bang~; #X obj 151 139 f; #X obj 185 139 + 1; #X obj 151 167 mod 1; #X obj 263 88 inlet; #X obj 263 113 max 1; #X obj 151 259 outlet; #X obj 151 193 select 0; #X connect 0 0 1 0; #X connect 1 0 3 0; #X connect 2 0 1 1; #X connect 3 0 2 0; #X connect 3 0 7 0; #X connect 4 0 5 0; #X connect 5 0 3 1; #X connect 7 0 6 0; #X restore 348 92 pd blockmetro; #X obj 228 101 osc~ 200; #N canvas 0 0 450 300 write 0; #X obj 122 65 inlet~; #X obj 256 63 inlet; #X obj 123 230 outlet~; #X obj 123 140 tabwrite~ \$0-x; #X connect 0 0 3 0; #X connect 1 0 3 0; #X restore 228 125 pd write; #N canvas 0 0 450 300 read 0; #X obj 122 65 inlet~; #X obj 256 63 inlet; #X obj 123 230 outlet~; #X obj 122 110 tabplay~ \$0-x; #X obj 210 159 timer; #X floatatom 210 183 8 0 0 0 - - -; #X obj 210 140 t b b; #X connect 1 0 3 0; #X connect 3 0 2 0; #X connect 3 1 6 0; #X connect 4 0 5 0; #X connect 6 0 4 0; #X connect 6 1 4 1; #X restore 229 167 pd read; #X text 437 119 buffer of 100 blocks of size 64 each; #X text 30 114 DSP order forcing; #X text 17 139 See G04.execution.order.pd; #X connect 0 0 11 0; #X connect 2 0 1 0; #X connect 2 0 1 1; #X connect 3 0 2 1; #X connect 5 0 10 0; #X connect 6 0 8 0; #X connect 7 0 6 0; #X connect 7 1 6 1; #X connect 8 0 9 0; #X connect 10 0 7 0; #X connect 10 0 12 1; #X connect 10 0 13 1; #X connect 11 0 12 0; #X connect 12 0 13 0; #X connect 13 0 2 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] abs~ on 64-bit and 0.42.3
Orm Finnendahl wrote: > Hi all, > > sorry, forgot the attachement. Here it is again... > > Hi all, > > abs~ seems to be broken on my machine with 64-bit linux and pd 0.42.3 > > Clicking in the bang in the attached patch should result in a straight > line at +0.5 (at least that's what I think it should do). > > Instead the result is a straight line at -0.5 with only two points at > arrayindex 0 and 64 set to +0.5 > > I checked the sources which were used to compile the program and they > look ok. > > It feels like a 64-bit problem somehow (maybe some compiler flags I > didn't set up correctly), but then again I shouldn't rely too much on > feelings even though it is a computer. there is a bugreport that might be related to this: https://sourceforge.net/tracker/index.php?func=detail&aid=2658537&group_id=55736&atid=478070 mfadr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] abs~ on 64-bit and 0.42.3
Hi all, sorry, forgot the attachement. Here it is again... Hi all, abs~ seems to be broken on my machine with 64-bit linux and pd 0.42.3 Clicking in the bang in the attached patch should result in a straight line at +0.5 (at least that's what I think it should do). Instead the result is a straight line at -0.5 with only two points at arrayindex 0 and 64 set to +0.5 I checked the sources which were used to compile the program and they look ok. It feels like a 64-bit problem somehow (maybe some compiler flags I didn't set up correctly), but then again I shouldn't rely too much on feelings even though it is a computer. Any ideas? -- Orm -- This mail was scanned by AntiVir MailGate. This product is not licensed. See http://www.avira.com/ for details.#N canvas 502 32 1362 1033 10; #N canvas 0 0 450 300 (subpatch) 0; #X array array3 100 float 3; #A 0 0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5; #X coords 0 1 100 -1 200 140 1; #X restore 15 22 graph; #X obj 258 71 tabwrite~ array3; #X obj 257 22 sig~ -0.5; #X obj 258 46 abs~; #X obj 229 22 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X connect 2 0 3 0; #X connect 3 0 1 0; #X connect 4 0 1 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] recording to array in loop mode?
Hallo, Mike Moser-Booth hat gesagt: // Mike Moser-Booth wrote: > If I'm not mistaken, I believe the trick to getting this to work is to > make sure the array size is a multiple of the block size. [tabwrite~] > conforms to block boundaries, to if you bang it in the middle of a > block, it won't begin writing until the end of the block. That's > probably where the clicks are coming from. The actual size of the array doesn't matter: If you have for example an array of size 300, you could record and playback only the first 256 samples (4*64) with block-quantized objects. Just ignore the last 44 samples. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-GUI-Rewrite 0.43 status: usable
Hallo, didn't test it yet, but you probably made my day. :) Ciao -- Frank Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > Indeed! That stupid bug has been around far too long. No more! > > http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=13040 > > Keep reporting, and I'll do my best to keep fixing. > > .hc > > On Jan 18, 2010, at 9:28 AM, Frank Barknecht wrote: > >> Hallo, >> >> probably not related to scrollbar, but to coordinates in general: Do >> you think >> it will now be possible to fix the longstanding issue of Pd showing >> the help >> menu far away from the mouseclick, if the coordinates of the viewport >> and those >> of the canvas disagree (for example if you've scrolled to the bottom >> of the >> help-intro.pd patch and try to open the help for e.g. [pointer] or if >> you have >> moved objects into the upper right area of (0,0)? That would be cool >> to have >> fixed after all these years. :) >> >> Ciao >> -- >> Frank >> >> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: >> >>> Ok, I fixed one source of scrollbar flickering. Its a Tk bug where >>> it >>> first sends a Configure event with a window size of 1x1, then sends >>> another with the actual size, hence the scrollbar flickering. >>> >>> http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=13018 >>> >>> .hc >>> >>> On Jan 10, 2010, at 9:55 PM, Jonathan Wilkes wrote: >>> Hi Hans, There's some scrollbar flickering happening on winxp (see attached patch). -Jonathan --- On Sun, 1/10/10, Hans-Christoph Steiner wrote: > From: Hans-Christoph Steiner > Subject: [PD] Pd-GUI-Rewrite 0.43 status: usable > To: "PD list" > Date: Sunday, January 10, 2010, 11:02 PM > > There has been lots of work on the 0.43 Pd GUI Rewrite, and > it should be quite useable now. Please try it for any > daily patching and report any issues that you might have so > that they can be fixed. There is a bunch of fun new > stuff possible with plugins, like you can bind to any key, > for example make "O" give you an [osc~] and "P" give you a > [pack] while Ctrl-O and Ctrl-P keep their original > meanings. > > For a more complete ChangeLog and links to nightly builds, > see: > http://puredata.info/dev/PdGuiRewrite > > Also, here's the beginning of some docs on how to write GUI > plugins. Please add anything you know of, and ask > questions so we can get more stuff documented: > > http://puredata.info/docs/PdGuiPluginsAPI > > .hc > > > > Programs should be written for people to read, and only > incidentally for machines to execute. > - from Structure and Interpretation of Computer Programs > > > ___ > Pd-list@iem.at > mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >>> >>> >>> >>> >>> >>> >>> >>> "Free software means you control what your computer does. Non-free >>> software means someone else controls that, and to some extent >>> controls >>> you." - Richard M. Stallman >>> >>> >>> >>> ___ >>> 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 > > > > > > Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's > about as sensible to say we declare war on night attacks and expect we're > going to win that war. We're not going to win the war on terrorism. > - retired U.S. Army general, William Odom > > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-GUI-Rewrite 0.43 status: usable
Hans-Christoph Steiner wrote: > > "compute audio" is easier to understand, but it then doesn't match the > 'pd dsp' message or the Media menu items. häh? the media menu items in Pd <=0.42 reads "audio ON" and "audio OFF". these do not match the "pd dsp" message, but kind of relate to "compute audio". indeed in pd-gui-rewrite, the "audio ON" is renamed to "DSP An" and "DSP Aus" (seems like the former is a demand for a de_AT localization :-)) but that doesn't really help the argument. > I think overall, its easier > if people learn that DSP means computing audio as well as other things, > and the term DSP is used consistently throughout. makes sense. otoh, most newbies (those who probably won't start using [; pd dsp 1() will want to turn on audio rather than learn what "dsp" means. on the third hand, they will probaby wonder why they have to turn on anything, so it won't matter whether it's audio or dsp. finally: this is surely time for a tooltip lingering over the "DSP" button, explaining, that this is the button to press if you want to hear something. mfbgasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] 'synced' number and slider
Jonathan Wilkes wrote: > > --- On Sun, 1/17/10, zmoel...@iem.at wrote: > >> the send/receive "magic" in the iemguis are explicitely >> designed to allow the same send/receive names in order to >> sync several different objects. > > So is it a bug that sending input to the inlet of one GUI doesn't > set the value for all other GUI's with the same send/receive name? no. it's a "side effect" (if you are nasty, you could also call it a "bug" with "won't fix" status :-)). the rule is simple: if (and only if) a iemgui object has the same send- & receive-name, then it will not pass (be it via send or via it's outlet) any messages it gets (be it via receive, or via it's inlet). this rule effectively prevents feedback loops when sharing send/receive names, while still allowing to update controllers individually. mfgasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
