Pd-dev December 2012

pd-dev@lists.iem.at

14 participants
173 discussions

info classes
by Jonathan Wilkes 11 Mar '13

11 Mar '13

Here is a quick snapshot of a bundle of classes I'm working on to provide a standardized way to get properties from parts of pd that aren't "objectified": [canvasinfo] get the properties of a canvas [pdinfo] get info about the running Pd instance [classinfo] info on a class (still under construction) I currently have them below [print] in x_interface.c from 0.43, so you can just drop it in and compile with Pd Vanilla if you want to check it out. (I'll make a patch later.) The props for [canvasinfo] are from my patch on the tracker that adds a "get" method to canvas. The nice thing about this particular interface is that there is only one class per domain which makes it much easier IMO to learn and remember the tools you need to inspect data (vs the one class per property approach which I find cumbersome). For example, a bang to canvasinfo or pdinfo will print out a complete sequence of all properties and their values to the Pd window, so one doesn't even have to memorize the methods in order to see the values. Incoming messages are done "pack" style, so that "symbol method" and "method" work the same, and with [canvasinfo] "A_SYMBOL A_FLOAT" messages get distributed among the inlets as lists do. I only have "dsp" and "version" properties for [pdinfo] so far. I'm curious what else would be useful. [classinfo] just tells whether the incoming symbol is one that will create an object that is already loaded. I'm not sure what an incoming bang would do here, or what more information would be useful. Actually I think [declare -lib blah] fails silently, so you could use this as a way to "catch" missing objects and specify an alternative. I stole some code from IOhannes to get canvas args without digging into the innards of g_canvas.c. :) -Jonathan

3 12

I have 3 broken installs [was: Re: double precision Pd: .patch files, tests and benchmarks]
by András Murányi 23 Feb '13

23 Feb '13

> >>>> Do you have access to an ARM >>>>> machine? If not, I could probably get one online with ssh access, if >>>>> that's >>>>> useful. >>>>> >>>> >>>> I've mailed Joe White with the question if he can patch the code for >>>> libpd and check performance on ARM. He has done some extremely popular >>>> RjDj apps and needed to optimize for them as well. Think it would be >>>> good anyway to keep in touch with libpd users and app programmers >>>> about this topic, even though we're in an early stage with it. >>>> >>> >>> >>> Yes definitely, we should let everyone who wants to be get involved. I >>> am just saying with need a development platform to start with. Once that's >>> nailed down, we can deal with more issues, like porting to libpd, dealing >>> with externals that could be either 32-bit or 64-bit, etc. >>> >>> I setup a nightly build on the macosx106-x86_64 and called it pd-double. >>> Andras and r33p, if you are listening, could you run this build on your >>> 64-bit boxes also? All you need to do is: >>> >>> ~pd/auto-build >>> cp -a pd-extended pd-double >>> >>> >> Listening now. >> I did: >> $ cd ~pd/auto-build >> $ sudo cp -a pd-extended pd-double >> What's next? Shall I try patching or rather pull IOhannes's sources? >> >> >> If you have the run-automated-builder script in a cron job, that is all >> you have to do. >> >> .hc >> >> > Ah, so tomorrow a single and double precision build will automatically be > made? Cool. > > Also, as I was busy with my life (buying a flat) these days, and I couldn't > follow the list as precisely as I wished, could you advise me what's the > current best way to roll my own double precision pd? Because I would like to > benchmark a fully optimised one. > > > That would great to have those numbers. [...] > Aaargh. I've arrived to the point where I have almost no functional pd on my box (with the exception of l2ork). vanilla says: "bash: /usr/bin/pd: No such file or directory" (i remember this is a known issue... for 64bit? can it be fixed by any chance?) extended (latest autobuild), and the fresh-built double keep on saying "watchdog: signaling pd..." What did I mess up? Will complete removals/reinstalls help? Andras

2 4

pix_opencv maintaining
by Antoine Villeret 02 Jan '13

02 Jan '13

hi, I would like to try to maintain pix_opencv on several platform as far as it's possible for me so I would like to have SSH access to the compile farm my ssh public key is attached any objection ? cheers antoine -- do it yourself http://antoine.villeret.free.fr

3 2

[ pure-data-Bugs-3599056 ] Problem with localized version of the search plug-in
by SourceForge.net 01 Jan '13

01 Jan '13

Bugs item #3599056, was opened at 2012-12-31 15:37 Message generated for change (Tracker Item Submitted) made by po-b You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3599056&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: v0.43 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pierre-Olivier Boulant (po-b) Assigned to: Hans-Christoph Steiner (eighthave) Summary: Problem with localized version of the search plug-in Initial Comment: I've installed and run the latest beta of Pd-extended on a Windows 7, 64bit computer. It detects I'm French and want to load the Franch translation of the search plug-in but fails with this message: ----------- UNHANDLED ERROR: bad menu entry index "Signaler un bogue" while executing "$mymenu index [_ "Report a bug"]" ("uplevel" body line 1097) invoked from within "uplevel #0 $tclcode" FAILED TO LOAD C:/Program Files (x86)/pd/extra/search-plugin/search-plugin.tcl ----------- And I can't see "search" in the help menu. If I rename the "pd/extra/search-plugin/po" to "pd/extra/search-plugin/_po" Pd starts fine and I can see "search" in the help menu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3599056&group_…

1 0

[ pure-data-Patches-3589133 ] Patcher windows always open on "primary" monitor
by SourceForge.net 30 Dec '12

30 Dec '12

Patches item #3589133, was opened at 2012-11-22 04:18 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3589133&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Jamie Bullock (postlude) Assigned to: Miller Puckette (millerpuckette) Summary: Patcher windows always open on "primary" monitor Initial Comment: Pd version tested with: 0.43.3 Vanilla Steps to reproduce: - connect a second monitor - open Pd - create a new patch and move it to the second monitor - create a subpatch Expected behaviour: - the subpatch window opens on the same monitor as the parent patch Actual behaviour: - the subpatch window opens on the primary monitor ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-12-30 08:01 Message: I must say, as very much as I enjoyed reading what you had to say, I couldnt help but lose interest after a while. Its as if you had a great grasp on the subject matter, but you forgot to include your readers. Perhaps you should think about this from additional than one angle. Or maybe you shouldnt generalise so significantly. Its better if you think about what others may have to say instead of just heading for a gut reaction to the subject. Think about adjusting your own believed process and giving others who may read this the benefit of the doubt. <a href="http://fit2wed.org/activity/p/50224/" title="Selecting Proper">Selecting Proper</a> ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-12-15 15:04 Message: I didn't see the need to place the wondw over the object (patch number 2) but applied the first one to vanilla. Will mark this 'pending' pending... ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-12-14 18:36 Message: The code was just always placing the new subpatch windows in the top left corner of the main screen. I did two things in Pd-extended: 1. made the window placement logic aware of the full desktop size, not just the main screen http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended… 2. made the window of new subpatches open near where the object was placed. http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3589133&group_…

1 0

[ pure-data-Patches-3598832 ] Print entire abstraction
by SourceForge.net 29 Dec '12

29 Dec '12

Patches item #3598832, was opened at 2012-12-28 22:01 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3598832&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: feature Status: Open Resolution: None Priority: 5 Private: No Submitted By: Trevor Fancher (trevorfancher) >Assigned to: Miller Puckette (millerpuckette) Summary: Print entire abstraction Initial Comment: Purpose: Change menu_print to print the entire canvas. Justification: I think this is what most people expect. I know I sure did In my opinion cropping should be done in a separate app. For example, here on OSX, Preview.app can crop really easily. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-12-29 07:22 Message: works for me, I've included it in Pd-extended. Thanks, that's definitely a big improvement over the old behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3598832&group_…

1 0

[ pure-data-Patches-3598832 ] Print entire abstraction
by SourceForge.net 29 Dec '12

29 Dec '12

Patches item #3598832, was opened at 2012-12-28 22:01 Message generated for change (Tracker Item Submitted) made by trevorfancher You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3598832&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: feature Status: Open Resolution: None Priority: 5 Private: No Submitted By: Trevor Fancher (trevorfancher) Assigned to: Nobody/Anonymous (nobody) Summary: Print entire abstraction Initial Comment: Purpose: Change menu_print to print the entire canvas. Justification: I think this is what most people expect. I know I sure did In my opinion cropping should be done in a separate app. For example, here on OSX, Preview.app can crop really easily. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3598832&group_…

1 0

[ pure-data-Feature Requests-3598776 ] let us know when file is loaded
by SourceForge.net 28 Dec '12

28 Dec '12

Feature Requests item #3598776, was opened at 2012-12-28 10:42 Message generated for change (Tracker Item Submitted) made by kubriel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3598776&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Priority: 5 Private: No Submitted By: kubriel (kubriel) Assigned to: Nobody/Anonymous (nobody) Summary: let us know when file is loaded Initial Comment: let us know when file is loaded and ready for playback in [soundfiler], [readsf~] and maybe others ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3598776&group_…

1 0

renaming delay into buffer size
by Max 28 Dec '12

28 Dec '12

hi list, something between a feature request and a usability bug report. also submitted on the tracker here: http://sourceforge.net/tracker/?func=detail&atid=478070&aid=3598740&group_i… i think it would make the audio properties clearer if instead of "delay (ms)" it would read either of those instead: buffer (ms) buffer size (ms) I/O buffer size (ms) or am i missing something? m.

2 1

[ pure-data-Bugs-3598768 ] hid-0.7-2 sending last values mouse every poll
by SourceForge.net 28 Dec '12

28 Dec '12

Bugs item #3598768, was opened at 2012-12-28 09:35 Message generated for change (Tracker Item Submitted) made by kubriel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3598768&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kubriel (kubriel) Assigned to: Nobody/Anonymous (nobody) Summary: hid-0.7-2 sending last values mouse every poll Initial Comment: i want to read data from mouse, but [hid] is sending last values every poll. like this(im doing nothing with mouse): print: rel rel_wheel 1 print: rel rel_x 2 print: rel rel_y -1 print: rel rel_wheel 1 print: rel rel_x 2 print: rel rel_y -1 print: rel rel_wheel 1 print: rel rel_x 2 print: rel rel_y -1 print: rel rel_wheel 1 print: rel rel_x 2 print: rel rel_y -1 print: rel rel_wheel 1 print: rel rel_x 2 print: rel rel_y -1 print: rel rel_wheel 1 print: rel rel_x 2 print: rel rel_y -1 print: rel rel_wheel 1 print: rel rel_x 2 print: rel rel_y -1 print: rel rel_wheel 1 values are correct, but this problem makes reading mouse wheel unusable, and lead also to other problems. i tested two mouses.. this is not happening in [linuxevent] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3598768&group_…

1 0

Jump to page:

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 December 2012