Pd-dev August 2010

pd-dev@lists.iem.at

22 participants
147 discussions

[ pure-data-Bugs-3052388 ] donecanvasdialog stops arrays from redrawing until reload
by SourceForge.net 24 Aug '10

24 Aug '10

Bugs item #3052388, was opened at 2010-08-24 12:43 Message generated for change (Tracker Item Submitted) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3052388&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: v0.43 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: donecanvasdialog stops arrays from redrawing until reload Initial Comment: If you send a donecanvasdialog to an array, then that array will no longer redraw. This bug exists in the HEAD of pure-data.git, but not in pd-gui-rewrite/0.43. I suspect it is due to some of the GOP bug fixes that have been recently included, and perhaps this code in canvas_donecanvasdialog(): /* LATER avoid doing 2 redraws here (possibly one inside setgraph) */ canvas_setgraph(x, graphme, 0); canvas_dirty(x, 1); if (x->gl_havewindow) canvas_redraw(x); else if (glist_isvisible(x->gl_owner)) { gobj_vis(&x->gl_gobj, x->gl_owner, 0); gobj_vis(&x->gl_gobj, x->gl_owner, 1); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3052388&group_…

1 0

[ pure-data-Bugs-3052385 ] Properties panels don't open unless you click on Pd Window
by SourceForge.net 24 Aug '10

24 Aug '10

Bugs item #3052385, was opened at 2010-08-24 12:38 Message generated for change (Tracker Item Submitted) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3052385&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: v0.43 Status: Open Resolution: None Priority: 8 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: Properties panels don't open unless you click on Pd Window Initial Comment: • launch pd • open any existing patch using File->open • right-click on canvas or array and select Properties • nothing happens except this: ‣ .pdwindow done-popup 0 206 47; ‣ error: .pdwindow: no such object • click on Pd window, then on patch • now click properties panel and it works This bug exists in the HEAD of pure-data.git but not in pd-gui-rewrite/0.43. I suspect it is due to the changes in the startup procedure and things are not getting initialized properly. I'll try to take a look later today. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3052385&group_…

1 0

template Makefile
by IOhannes zmölnig 23 Aug '10

23 Aug '10

i cleaned up the template Makefile (externals/template/Makefile) a bit. namely i switched to using $@, $< and $^, which makes a lot of things way more elegant. other cleanups: removed the SOURCES_android since this is not used anywhere and is misleading use PD_PATH where appropriate added SOURCES_LIB for .c files holding shared functions use HELPPATCHES to enumerate -help.pd (usually this info is gathered automatically; the average user will never see that) these changes should make zero difference to the user experience of the templ Makefile. remaining questions: DIST PATH: why does the makefile enforce the manual and examples to be examples/ resp. manual/ folders _in the source directory_ ? i understand that they should be laid out standardized in the install directory, but why in the source folder? why not just: MANUAL = doc/manual.pdf manuals/anothermanual.pd and install that into .../$(LIBRARY_NAME)/manual/ INSTALL PATH why the heck is the default installation path: $(libdir)/pd-externals ?? i cannot remember that this was agreed on by anybody but hans. i do remember that ~/pd-externals was discussed (and i still would prefer ~/.pd/extra/ over this unnecessary homedirectory cluttering), but $(libdir)/pd-externals is news to me. instead i do remember, that $(libdir)/pd/extra was meant to be the canonical name for all flavours of Pd (e.g. with PdX and pd-vanilla, in debian pd-vanilla would look into both /usr/lib/puredata/extra and /usr/lib/pd/extra, whereas PdX would look into /usr/lib/pd-extended/extra and /usr/lib/pd/extra (in this order)) i also find, that a related patch has made it into puredata.git. unfortunately, it is inconsinstent with the template Makefile, as puredata.git has hardcoded /usr/local/lib/pd-externals/ whereas the tmpl uses $(libdir)/pd-externals which could well be /usr/lib/pd-externals/ which in turn is never ever searched by Pd. in case, i haven't said it yet: i don't like this. ,asdr IOhannes

2 1

[ pure-data-Patches-3051663 ] make slipdec reassemble arbitrary packages
by SourceForge.net 23 Aug '10

23 Aug '10

Patches item #3051663, was opened at 2010-08-23 18:45 Message generated for change (Tracker Item Submitted) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3051663&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: bugfix Status: Open Resolution: None Priority: 6 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Martin Peach (mrpeach) Summary: make slipdec reassemble arbitrary packages Initial Comment: current slipdec doesn't work if the SLIP encoded package is not presented as a single list (which kind of defeats the idea of SLIP, which is to paketize a _stream_ of data) with the attached patch, [slipdec] is able to decode a stream even if it was [1, 192 2, 3 4, 5 192, 6, 192( before applying and committing the patch, please have a close look at it. for now, i just disabled the "valid" output (because it doesn't make so much sense anyhow, a SLIP stream is almost always valid) i know think that the flag could indicate whether there is still data waiting in the queue (and is updated after each message received) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3051663&group_…

1 0

Re: [PD-dev] run-up to release 0.43
by Jonathan Wilkes 22 Aug '10

22 Aug '10

--- On Thu, 8/19/10, Miller Puckette <msp(a)ucsd.edu> wrote: > From: Miller Puckette <msp(a)ucsd.edu> > Subject: Re: [PD-dev] run-up to release 0.43 > To: "Jonathan Wilkes" <jancsika(a)yahoo.com> > Cc: "Hans-Christoph Steiner" <hans(a)at.or.at>, pd-dev(a)iem.at > Date: Thursday, August 19, 2010, 10:44 PM > Hi Jonathan - > > I don't feel confortable with the design but don't > understand the rationale > for them well enough to know how to evaluate them. > (And I think initbang > and closebang are totally different animals...) They definitely are very different. As for [initbang] - my only use has been for making abstractions that can spawn a variable number of inlets/outlets. That's the only way I've used it and the only way I've ever seen it used-- if there are other uses maybe someone else on this list can give an example. The [initbang] object gives abstractions the ability to do something that otherwise would only be possible by coding an external in another programming language. For example, with [initbang] I can quickly make an abstraction that can act like Max/MSP's [trigger] object-- where you can specify numeric values as arguments ( like [trigger b 0] ). > > I want to redesign loadbang to take arguments, one of which > could indicate > at what "phase" of loading or closing the message should > come out -- but this > is a bigger design problem than I'm able to attack right > now. I worry, though, > that enshrining the proposed initbang/closebang will make > thiings uglier and > more complicated than necessary. The addition of initbang would be a rather restricted ugliness, since a) neither [loadbang] nor [initbang] have an inlet (and therefore must always be at the head of an object chain), and b) both have a single outlet that sends a single message, and that message is a bang in both cases. If future compatibility is the issue, and if the current [initbang] is to be a subset of the features of future [loadbang], wouldn't it be fairly straightforward to make [initbang] an alias of future [loadbang] (like a shortcut to whatever args you have to give future [loadbang] to get the functionality of current [initbang])? -Jonathan > > cheers > Miller > > > > Miller- would you mind commenting on the > initbang/closebang patch > > on Sourceforge, as to why it's still not included in > your Pd? > > > > Thanks, > > Jonathan > > > > > I'm > > > curious what features you have in mind, and > looking forward > > > to having > > > you in NYC. Perhaps we should have a mini PdCon > here > > > in the Fall :) > > > > > > .hc > > > > > > On Wed, 2010-08-18 at 17:06 -0700, Miller > Puckette wrote: > > > > Hi all, > > > > > > > > I have only 2 weeks left in the vicinity of > my usual > > > collection of testing > > > > machines (will be in New York Sept 1 - Jan. > 1!) and so > > > should probably > > > > try to get 0.43 finalized. I have several > bugs > > > to work on but I think the > > > > whole thing is ready to put out compiled > "test > > > versions" for people to > > > > exercise. > > > > > > > > I'll try not to add new "features" but just > fix bugs > > > for the next 2 weeks -- > > > > I'll have all fall for the next bunch of > features > > > (including, perhaps, the > > > > ones I've been trying to find time to work > on). > > > > > > > > I'll do my usual compiling and spot testing, > hopefully > > > putting out the > > > > test versions within the next day. > > > > > > > > cheers > > > > Miller > > > > > > > > > _______________________________________________ > > > > Pd-dev mailing list > > > > Pd-dev(a)iem.at > > > > http://lists.puredata.info/listinfo/pd-dev > > > > > > > > > > > > _______________________________________________ > > > Pd-dev mailing list > > > Pd-dev(a)iem.at > > > http://lists.puredata.info/listinfo/pd-dev > > > > > > > > > > > > > _______________________________________________ > > Pd-dev mailing list > > Pd-dev(a)iem.at > > > http://lists.puredata.info/listinfo/pd-dev >

3 4

dynamic patching: getting info on objects
by Ted Hayes 22 Aug '10

22 Aug '10

Hi all, this is t3db0t, been meaning to subscribe here for a while and finally did, and I have a question. I'm writing a remote front-end that sends FUDI internal messages over a socket to a server running a -nogui Pd instance. I'd like to be able to get a listing of every object available to that instance with how many inlets and outlets each object has, i.e., osc~ 2 1 etc. etc. I wouldn't assume this is possible, but I had to ask before I just start hand-coding my own. I image the native Pd front-end builds this list when it initializes, so is there any way I can listen in to that—over a socket? Thanks everyone!! —t3db0t

6 18

[ pure-data-Patches-2952880 ] a partial float fix
by SourceForge.net 21 Aug '10

21 Aug '10

Patches item #2952880, was opened at 2010-02-16 16:33 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2952880&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: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Peach (mrpeach) Assigned to: Miller Puckette (millerpuckette) Summary: a partial float fix Initial Comment: Pd currently doesn't store floats to their full precision because atom_string uses the %g format specifier to print them into the binbuf. As a result 24-bit numbers lose precision. This patch changes the format specifier to %f and also adds a routine to chop off trailing zeros and the decimal point if nothing is to the right of it. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-08-21 20:27 Message: I thought I had patched my source but somehow hadn't... just tried the patch and it has a problem - if you type 1e20 in a message box and duplicate it you get a ridiculous string. Somehow a fix is needed that can deal with exponential notation but still have the advantages of %f when appropriate. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-08-20 19:07 Message: This one did not seem to get accepted, or at least its not in git as of today. There is a commit in git (2488dcef8a72906cd1fa3785ef549ea7b33533b5) marked "patch 2952880 - a partial float fix", but that commit makes only a small change to extra/expr~/vexp_if.c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2952880&group_…

1 0

[ pure-data-Patches-1952001 ] on OSX, made canvas windows show dirty in OS-native style
by SourceForge.net 21 Aug '10

21 Aug '10

Patches item #1952001, was opened at 2008-04-25 19:57 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1952001&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: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Luke Iannini (lukeiannini) Assigned to: Miller Puckette (millerpuckette) Summary: on OSX, made canvas windows show dirty in OS-native style Initial Comment: This is a patch to add proxy icons (a tiny representation of the file being worked on in the window's titlebar; it can be dragged to grab a reference to the file for drag and drop, or right/command-clicked to get the parent folders of the file). The patch also adds a dot in the close button when the Pdpatch is dirty, consistent with other OS X apps. The patch is untested; Pd-Vanilla doesn't seem to support the Tk attributes necessary (for reasons I don't understand), but Pd-Extended does (hardwiring wm attributes $name -modified 0 -titlepath {insertPathHere} in pd.tk's pdtk_canvas_new works in pd-e but not in pd-v). ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-08-21 14:01 Message: Yes indeed, its true! ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-08-21 12:54 Message: This patch has either been incorporated into pd-gui-rewrite pd-devel 0.43 or made irrelevant by it. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 12:41 Message: Logged In: YES user_id=27104 Originator: NO added to branches/pd-extended/0.40 ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-27 20:20 Message: Logged In: YES user_id=27104 Originator: NO I uploaded a version of Luke Iannini's proxy_icon_and_modified_state.patch fixed to eliminate crash (caused by using %f in sys_vgui for an int value). Also, made the title bar fully Mac OS X-style. Pd-vanilla uses an old version of Tcl/Tk, that's probably why it doesn't work there. If Pd-vanilla is built against a recent version of Tcl/Tk, then I'll bet it'd work. File Added: proxy_icon_and_modified_state-0.41.4.patch ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-26 20:34 Message: Logged In: YES user_id=27104 Originator: NO I tried this with the latest from branches/pd-extended/v0-40 and I am getting a lot of crashes. It didn't seem to change the window behavior either. Are there some changes to u_main.tk that are missing from the patch, perhaps? I'll try to troubleshoot it more later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1952001&group_…

1 0

[ pure-data-Patches-1952001 ] on OSX, made canvas windows show dirty in OS-native style
by SourceForge.net 21 Aug '10

21 Aug '10

Patches item #1952001, was opened at 2008-04-26 01:57 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1952001&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: Pending Resolution: Works For Me Priority: 5 Private: No Submitted By: Luke Iannini (lukeiannini) Assigned to: Miller Puckette (millerpuckette) Summary: on OSX, made canvas windows show dirty in OS-native style Initial Comment: This is a patch to add proxy icons (a tiny representation of the file being worked on in the window's titlebar; it can be dragged to grab a reference to the file for drag and drop, or right/command-clicked to get the parent folders of the file). The patch also adds a dot in the close button when the Pdpatch is dirty, consistent with other OS X apps. The patch is untested; Pd-Vanilla doesn't seem to support the Tk attributes necessary (for reasons I don't understand), but Pd-Extended does (hardwiring wm attributes $name -modified 0 -titlepath {insertPathHere} in pd.tk's pdtk_canvas_new works in pd-e but not in pd-v). ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-08-21 18:54 Message: This patch has either been incorporated into pd-gui-rewrite pd-devel 0.43 or made irrelevant by it. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 18:41 Message: Logged In: YES user_id=27104 Originator: NO added to branches/pd-extended/0.40 ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 02:20 Message: Logged In: YES user_id=27104 Originator: NO I uploaded a version of Luke Iannini's proxy_icon_and_modified_state.patch fixed to eliminate crash (caused by using %f in sys_vgui for an int value). Also, made the title bar fully Mac OS X-style. Pd-vanilla uses an old version of Tcl/Tk, that's probably why it doesn't work there. If Pd-vanilla is built against a recent version of Tcl/Tk, then I'll bet it'd work. File Added: proxy_icon_and_modified_state-0.41.4.patch ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-27 02:34 Message: Logged In: YES user_id=27104 Originator: NO I tried this with the latest from branches/pd-extended/v0-40 and I am getting a lot of crashes. It didn't seem to change the window behavior either. Are there some changes to u_main.tk that are missing from the patch, perhaps? I'll try to troubleshoot it more later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1952001&group_…

1 0

[ pure-data-Patches-1917574 ] fix absolute path support for [declare] and #X declare
by SourceForge.net 21 Aug '10

21 Aug '10

Patches item #1917574, was opened at 2008-03-18 02:01 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1917574&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: None Priority: 5 Private: No Submitted By: marius schebella (mariusschebella) Assigned to: Miller Puckette (millerpuckette) Summary: fix absolute path support for [declare] and #X declare Initial Comment: I am not sure if declare is working the way it is supposed to on OSX the object I am trying to create is [OSCroute]. I can create [oscx/OSCroute], but what I want to accomplish is to avoid the oscx prefix, so I tried [declare -stdpath extra/oscx] [declare -stdpath oscx] [declare -path extra/oscx] [declare -path oscx] [declare -stdlib extra/oscx] [declare -stdlib oscx] [declare -lib extra/oscx] [declare -lib oscx] I even tried [declare -stdpath extra/oscx] in combination with import oscx. and I get a console printout saying [import] loaded library: oscx, but OSCroute ... couldn't create don't know how to track down the error, or if I am maybe doing something wrong. pd-extended-0.40.3-20080222. ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-08-21 18:51 Message: is this stil an issue with 0.43? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-22 21:26 Message: Logged In: YES user_id=27104 Originator: NO (repost of my pd-dev post) The realpath() is definitely related. If you start Pd using a relative path, like I do when doing dev work (e.g. make && ../bin/pd), then sys_libdir will be a relative path. That means it is impossible to make absolute paths using sys_libdir, which is what I need to do to make [import] work, or loading libdirs with [declare -lib] and the libdir loader. I can't see any problems that realpath() might cause. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2008-05-22 19:21 Message: Logged In: YES user_id=313747 Originator: NO I patched 0.42 with th epart of it that dealt with declare... there's something else in the patch that invokes a "realpath" function I don't know about (and I assume won't compile as is) so I ignored that bit. I think I should also update 0.41 since this is a fairly important bug fix and also a safe-looking one. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-21 20:19 Message: Logged In: YES user_id=27104 Originator: NO This patch should add support for absolute paths in [declare] and the #X declare lines in the .pd files. Here's the related commit for Pd-extended: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=9862 File Added: fix_absolute_paths_for_declare-0.41.4.patch ---------------------------------------------------------------------- Comment By: marius schebella (mariusschebella) Date: 2008-05-06 18:45 Message: Logged In: YES user_id=1856112 Originator: YES that's how -stdpath works on os x. it does not work for absolute paths, and seems to be relative to some directory outside of /Applications. I tried all relations with less ../ and from inside /Applications. declare -stdpath ../../../../../../../../Applications/Pd-0.40.3-extended-20080428.app/Contents/Resources/extra/boids maybe this helps. m. ---------------------------------------------------------------------- Comment By: marius schebella (mariusschebella) Date: 2008-05-04 19:35 Message: Logged In: YES user_id=1856112 Originator: YES I just realized that I made some mistakes in the past and that declare actually is working better than I thought. here is what I forgot: 1) declare only takes effect when you open the patch. stupid, I think I read it, but... Some alleged "bugs" were caused by the assumption that it is enough to create a declare object and paths will be set... 2) no absolute paths! absolute paths work for -lib, but not for -path/-stdpath. at least on OS X it is not possible to set absolute paths (or at least I don't know how), all paths have to be relative to Pd (-stdpath) or to the patch (-path). ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2008-03-20 14:38 Message: Logged In: YES user_id=1895440 Originator: NO oops... from some quick fix from before i accidently still had a symbolic link from /home/roman/extra pointing to /usr/local/lib/pd/extra/, that is why it found [bar] in that funny place: /home/roman/extra/foo/bar.pd tried again without the symlink: -------------------------------- tried /home/roman/declare_test.pd and succeeded tried /home/roman/../extra/foo/bar.l_i386 and failed tried /home/roman/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar.l_i386 and failed tried /home/roman/../extra/foo/bar.pd_linux and failed tried /home/roman/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar.pd_linux and failed tried /home/roman/../extra/foo/bar/bar.l_i386 and failed tried /home/roman/bar/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar/bar.l_i386 and failed tried /home/roman/../extra/foo/bar/bar.pd_linux and failed tried /home/roman/bar/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar/bar.pd_linux and failed tried /home/roman/../extra/foo/bar.pd and failed tried /home/roman/bar.pd and failed tried /usr/local/lib/pd/extra/bar.pd and failed tried /home/roman/../extra/foo/bar.pat and failed tried /home/roman/bar.pat and failed tried /usr/local/lib/pd/extra/bar.pat and failed ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2008-03-20 12:49 Message: Logged In: YES user_id=1895440 Originator: NO i just did the same test again on my box, ubuntu dapper i686: tried /home/roman/declare_test.pd and succeeded tried /home/roman/extra/foo/bar.l_i386 and failed tried /home/roman/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar.l_i386 and failed tried /home/roman/extra/foo/bar.pd_linux and failed tried /home/roman/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar.pd_linux and failed tried /home/roman/extra/foo/bar/bar.l_i386 and failed tried /home/roman/bar/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar/bar.l_i386 and failed tried /home/roman/extra/foo/bar/bar.pd_linux and failed tried /home/roman/bar/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar/bar.pd_linux and failed tried /home/roman/extra/foo/bar.pd and succeeded which means: - there is a difference between linux ppc and linux intel - currently linux intel is the _only_ platform where [declare] works as documented. ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2008-03-20 12:20 Message: Logged In: YES user_id=1895440 Originator: NO could we give this issue a higher priority? the longer [declare] is not working correctly, the more confusion it will cause. also it currently cannot be used to create portable patches, that work on every platform with every pd-distro, which i find would be the strong point in using [declare]. ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2008-03-20 12:11 Message: Logged In: YES user_id=1895440 Originator: NO the same test on a ubuntu ppc machine with pd 0.41-4 compiled from source and installed to the default location gave similar results: output from pd-window: ---------------------- tried /home/olivia/declare_test.pd and succeeded tried /home/olivia/extra/foo/bar.l_i386 and failed tried /home/olivia/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar.l_i386 and failed tried /home/olivia/extra/foo/bar.pd_linux and failed tried /home/olivia/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar.pd_linux and failed tried /home/olivia/extra/foo/bar/bar.l_i386 and failed tried /home/olivia/bar/bar.l_i386 and failed tried /usr/local/lib/pd/extra/bar/bar.l_i386 and failed tried /home/olivia/extra/foo/bar/bar.pd_linux and failed tried /home/olivia/bar/bar.pd_linux and failed tried /usr/local/lib/pd/extra/bar/bar.pd_linux and failed tried /home/olivia/extra/foo/bar.pd and failed tried /home/olivia/bar.pd and failed tried /usr/local/lib/pd/extra/bar.pd and failed tried /home/olivia/extra/foo/bar.pat and failed tried /home/olivia/bar.pat and failed tried /usr/local/lib/pd/extra/bar.pat and failed bar ... couldn't create instantiating [foo/bar] works fine, which means, that installation of [bar] is correct and pd finds it in extra/foo. ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2008-03-20 11:48 Message: Logged In: YES user_id=1895440 Originator: NO while [declare -stdlib] seems to work, [declare -stdpath] doesn't work on windows as well. i created a folder 'foo' into the extra directory and put a file 'bar.pd' in there. my test setup: -------------- pd installation path: D:\programme\pd-0.41\ pd executable: D:\programme\pd-0.41\bin\pd.exe test-abstraction: D:\programme\pd-0.41\extra\foo\bar.pd test-patch: D:\home\declare_test.pd test-patch contains: [declare -stdpath extra/foo] [bar] pd start command: D:\programme\pd-0.41\bin\pd.exe -verbose -open D:\home\declare_test.pd output from pd-window: ---------------------- tried D:\\home\\declare_test.pd and succeeded tried D:\\home\\..\\extra\\foo\\bar.m_i386 and failed tried D:\\home\\bar.m_i386 and failed tried D:\\programme\\pd-0.41\\extra\\bar.m_i386 and failed tried D:\\home\\..\\extra\\foo\\bar.dll and failed tried D:\\home\\bar.dll and failed tried D:\\programme\\pd-0.41\\extra\\bar.dll and failed tried D:\\home\\..\\extra\\foo\\bar\\bar.m_i386 and failed tried D:\\home\\bar\\bar.m_i386 and failed tried D:\\programme\\pd-0.41\\extra\\bar\\bar.m_i386 and failed tried D:\\home\\..\\extra\\foo\\bar\\bar.dll and failed tried D:\\home\\bar\\bar.dll and failed tried D:\\programme\\pd-0.41\\extra\\bar\\bar.dll and failed tried D:\\home\\..\\extra\\foo\\bar.pd and failed tried D:\\home\\bar.pd and failed tried D:\\programme\\pd-0.41\\extra\\bar.pd and failed tried D:\\home\\..\\extra\\foo\\bar.pat and failed tried D:\\home\\bar.pat and failed tried D:\\programme\\pd-0.41\\extra\\bar.pat and failed bar ... couldn't create it looks like [declare -stdpath] is adding the search path relative to the patch instead of relative to pd. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1917574&group_…

1 0

← Newer
1
2
3
4
5
6
7
...
15
Older →

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 August 2010