Re: [PD-dev] compiling pdlua in windows, macos, android, ...
Hi, I built it a long time ago on OS-X, which even for me was pretty trivial. I don't have access to the machine nor the binary anymore. If you compile Lua into the external's binary, it will depend on basically nothing anymore. Lua is pure ANSI C and really teenytiny, so compiling Lua into the external will not be a memory hog, but has the advantage that you can reuse the same binary on many machines just by copying over. Ciao -- Frank On Tue, Jan 18, 2011 at 08:53:52AM -0500, Martin Peach wrote: Yes I'm interested in that too, still learning lua. It would be nice to have [pdlua] in pd-extended. I can try to build it for WinXP and see what's involved. Martin On 2011-01-18 06:54, João Pais wrote: Hi, I looked at [pdlua] last week, and was quite impressed by the examples there, and how it's easy to create new externals that go beyond pd's capabilities (for example to parse lists and symbols, etc.) - provided you learn about lua. I wanted to use this in a project, but in the website - http://claudiusmaximus.goto10.org/cm/2008-06-19_pdlua-0.5_released.html - there's only instructions to compile in linux. Since the developer isn't responding to my mails, I wanted to know if it's possible to get this working on other plattforms. So I wanted to ask around: - does anyone has any already built binaries of pdlua for windows and macos? - since I guess the answer is going to be no, is anyone interested in helping me trying to compile pdlua in these systems? Although since I have limited access to macos, and never compiled anything on windows, helping me means telling me what to do, which dependencies to get, etc. - this project is something that should work on all plattforms, and, in the future also in android (when pd for android is also that far). can anyone say something about the feasibility of porting pdlua to android? [I cannot evaluate the dumbness of this question] I would like to use pdlua, but if it's not a feasible solution, I'll ask instead someone to write a C external for me. Thanks, João ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] initbang and friends WAS: run-up to release 0.43
On Tue, Aug 24, 2010 at 12:40:59AM -0400, Matt Barber wrote: [createbang] and [destroybang] is a nice pair. :) .hc But then we'd need [evolvebang] and [extinctbang] ... Unless you patches are intelligently designed. :) Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] initbang and friends WAS: run-up to release 0.43
Hi, On Fri, Aug 20, 2010 at 02:02:08PM -0400, Hans-Christoph Steiner wrote: On Aug 20, 2010, at 5:42 AM, IOhannes m zmölnig wrote: I'm saying I like the interface of having a suite of objects called *bang rather than [loadbang close], etc. it makes them super easy to use and remember. [initbang] [loadbang] [propertybang] [closebang] The only issue I have with this is the difference between initbang and loadbang. In several patches posted to this list in the past I observed, that sometimes people tended to use initbang where a simple loadbang would be sufficient, i.e. they were doing nothing that would actually require initbang.(*) I assume this is because they actually didn't know or understand the difference. That's where a loadbang object that somehow combined initbang into it with an argument *may* be preferable. I don't see any reason to combine load- and closebang (or propertybang, but I don't really know that. I assume it will fire when Help-Properties is selected.) (*) A typical example were abstractions using initbang because their loadbang would not fire after dynamic patching. Here initbang is not the correct solution, but a loadbang-message to the dynamic patching canvas. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] 0.43 omission: 'set-startup' and 'set-path'
Hi, On Wed, Jul 21, 2010 at 09:09:59PM -0700, Miller Puckette wrote: [declare] sets a path local to the patch it's in. ... and to the abstractions used in the patch it's in, at least at the moment. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] path for embedded examples
On Sat, Apr 10, 2010 at 11:01:22PM +0200, Roman Haefeli wrote: On Sat, 2010-04-10 at 13:25 -0400, Hans-Christoph Steiner wrote: Part of the idea of a libdir is to also include examples. Currently, this is done using an 'examples' subfolder. The problem with that is the example patches won't automatically find the objects from the libdir that they are embedded in. So I'm wondering what the best way to handle this is. Here are a couple ideas: - require [declare -path ..] for all example patches (works on any branch of Pd) - instead of 'examples' folder, use mypatch-example.pd in the main dir of the libdir (works without extra tricks) - use [import mylib] for all example patches (works even when the example patch is saved elsewhere) - use [declare -stdpath extra/mylib] for all example patches (works on any branch of Pd and works even when the example patch is saved elsewhere) I think, this doesn't work if mylib isn't installed or isn't installed in extra. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] worth to create external?
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: and probably one more reason: if you know that you can implement the entire thing in C within 5 minutes and it will take 3 days to do the patching, i would go for the eternal. And if you want to do something whose outcome you are not yet sure of, i.e. something which might change a lot over the next 3 days, then the faster turnaround times and the ease of testing and livecoding when working with Pd's patching side come in handy as well. And using patching makes your stuff easier to share. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] GUI performance clarification
Hallo, Lee Azzarello hat gesagt: // Lee Azzarello wrote: Hot on the heels of the great GUI rewrite thread, I have a simple question that would help clarify some CPU performance questions I have with my current project. I have incoming serial data from an arduino. This data is getting buffered every n milliseconds and sent to a vslider object. I have 6 channels of data with a vslider on each, so 6 vsliders and 6 buffers. If I set n to 20ms, my dual core 2.4 ghz CPU with an i945 graphics card on Linux 2.6.32 hits 100% with no audio processing. If I lower n to 60ms the CPU usage drops to about 15%. Is this the expected performance for a vslider? About yes. You can't see faster than about 50msec anyway, so I don't think it makes much sense to update a slider any faster. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-2957058 ] pointer to [route symbol]-[print] crashes pd
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: for what it is worth, i have just created a little object [rawprint] in zexy, that should allow you to inspect messages a bit closer. it's basically a clone of [print] without all the fancy handling of special atoms. for [foo 1 bar( it will print: foo 1.0 'bar' the output of [pointer] could print: pointer pointer[0xBFD62658] the selector is indicated with double-quotes and ordinary symbols with single-quotes. So the selector of a pointer-message *is* pointer? And why doesn't route [route] it? Puzzled ... Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Scheduling to activate control objects
Hallo, PSPunch hat gesagt: // PSPunch wrote: However, since I could not think of any other object where the user had to connect a metro specifically for polling, on the surface it seemed like a lame, not elegant design. There are some examples for this approach in the msd and pmpd physical modelling objects. Here it makes sense as you can change the polling rate and you can sync to other schedules like the Gem bang instead of to a metro. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding standard install paths to the 'puredata' package
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: The problem is versioning. One of the goals of Pd-extended is to be compatible with the same version of Pd-vanilla, i.e. Pd-extended 0.40.3 can run anything that Pd-vanilla 0.40.3 can. I imagine that desiredata has a similar goal, but maybe not. The objects in 'extra' are part of what Pd-vanilla 0.40.3 provides. Okay, now here's an issue: I agree that the objects in extra are something, that pd should provide. But if the packages pdextended and desiredata provide pd they also have to provide, say, expr.pd_linux, even if puredata is not installed. This gets even hairier with things like helpfiles: a package that provides pd should include and provide route-help.pd, of which we have a different one in PDDP which maybe is part of pdextended.deb (or maybe isn't). So if the objects in extra come with the 'puredata' package and are put into the common /usr/lib/pd directory, then the 'pdextended' and 'desiredata' packages would use the versions that come with 'puredata'. So that means they would need to be removed from the 'pdextended' and 'desiredata' packages. If pdx and dd provide pd and if providing pd includes providing an [expr] object, then you can't do that, see above. That's not a big deal, I am ok with that. But the problem is that if 'puredata' gets updated to 0.43 while 'pdextended' is still at 0.42, and 'puredata' puts the 'extra' externals into the shared directory. Then 'pdextended' can't be 0.42 compatible anymore. You can do versioned dependencies with Debian (Depends: pd = 0.44), but of course a package that provides X itself cannot depend on X = y.z in a sensible way. One idea is to package Pd vanilla's 'extra' separately, i.e. 'pd-extra'. Then 'puredata' can Recommend 'pd-extra' and 'pdextended' can Conflict with 'pd-extra' and I can make versioned packages for 'pdextended', ie 'pd-extra042'. Another is to have the extra folder from 'puredata' in /usr/lib/puredata. pdextended could also a) depend on puredata == 0.42, so that it gets deinstalled or updated, when a newer puredata is installed, or b) it could be completely independent of puredata (i.e. have its own expr.pd_linux) or c) it could conflict, replace and provide pd so that you can only install one. Maybe there are some other possibilities. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding standard install paths to the 'puredata' package
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: But that means the definition of /usr/lib/pd has to be changed. We discussed these this at the last PdCon, and there was agreement on the fact that the three directories are needed. So then we have three directories that overlap the meaning of the original /usr/lib/pd: 1. a /usr/lib directory for objects that work for everything that provides 'pd' 2. a /usr/lib directory for objects that work only for 'puredata' 3. a /usr/lib directory for objects that work only for 'pd-extended' I am ok with keeping /usr/lib/pd as the first directory since it matches the virtual package 'pd'. (Previously we'd decided on /usr/ lib/pd-externals as the name for the first directory).In terms of the packaged libraries, using /usr/lib/pd for the first directory means the existing ones don't have to change unless they are incompatible with Pd-extended/DesireData. I think, this makes sense and I'd go that way as well. But not only because of the name of the virtual package, also because pd is just *the* name for this, like X11 is *the* name for everything regarding X software, even when no package carries that name anymore. Now that we have new players like maybe desiredata, they can and should use their custom directories if they need to, but this should not directly affect the old ones. A different issue is version changes. Here a possibility could be to follow examples like Vim or Python, which use a versioned subdirectories like /usr/share/vim/vim71/ or /usr/lib/python2.5/site-packages. But that means changing the 'puredata' package to use /usr/lib/puredata for the stuff that comes in pd/extra (i.e. bonk~, etc). This I don't understand. They are externals, but they work and come with the original, vanilla Pd. In my opinion they can and should stay in /usr/lib/pd Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding standard install paths to the 'puredata' package
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: On Nov 30, 2009, at 6:33 PM, Mathieu Bouchard wrote: On Mon, 30 Nov 2009, Frank Barknecht wrote: Additionally, I'd like to Debianize the directory names (i.e. / usr/lib/puredata) What's un-Debian about /usr/lib/pd? the package name is not pd. alternatively, the package name could be changed, if there is no nameclash. There is a nameclash. 'pd' is a virtual package for library packages to depend on. 'puredata' and 'pd-extended' provide 'pd. A 'desiredata' package could also provide 'pd'. Then library packages would install properly with any or all Pd flavors installed. So doesn't it make sense to keep pd as a name for the lib-directory, just like vim in /usr/share/vim is the common install place for all flavours of Vim (i.e. vim, vim-gnome, vim-gtk, vim-lesstif etc.)? Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding standard install paths to the 'puredata' package
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: Hans-Christoph Steiner wrote: The compelling reason is that 'pd' means multiple packages 'puredata', 'pd-extended', and perhaps others. Where is the harm in changing this? but there are so many trivial patches in the world that won't do no harm to anybody. this is not a reason to apply them just so. i understand that /u/l/puredata seems to be more natural than /u/l/pd. however, so far _this_ hasn't caused any problems i know of yet. so why change it? if it does cause problem and changing it to /usr/lib/puredata would fix them, then i don't see a reason not to change it. Its a trivial patch, its not a directory that people should be ever changing since its managed by the packages. If it causes problems, we can change it back. Wow, that's a cute attitude for a maintainer! Renaming /u/l/pd to /u/l/puredata is a solution in search of a problem. Pd upstream uses /usr/(local/)lib/pd for ages. All documentation is written with this in mind, many Makefiles use it as default. The only reason why someone may consider to use /usr/(local/)lib/puredata instead is that the Debian package is called puredata. But this is a very specific peculiarity of this particular distribution. Miller's source archive is called pd, the autobuilds use pd or for Pd-extended Pd-version-extended which is a completely illegal package name as far as Debian's policy is concerned btw. If you want to support and package the various forks of Pd, then the only thing you need to do is make a meta package pd and let all forks provide pd, and that's already done and in fact is the reason for Debian's pd package carrying the name puredata! It's no problem to have them all use a shared directory for extensions as far as Debian and the filesystem is concerned. I mentioned the vim packages as an example. If you want fork-specific data, you can always add special directories in these packages, like /usr/lib/puredata-extended Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding standard install paths to the 'puredata' package
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: On Mon, 30 Nov 2009, Frank Barknecht wrote: Additionally, I'd like to Debianize the directory names (i.e. / usr/lib/puredata) What's un-Debian about /usr/lib/pd? the package name is not pd. There also is no X11 package. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding standard install paths to the 'puredata' package
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: however, i don't see a really compelling reason why things should be moved from /usr/lib/pd to /usr/lib/puredata. it might be sufficient to symlink from /u/l/puredata to /u/l/pd for now. or the other way round. /usr/lib/pd should be kept. AFAIK not even the Debian policy requires the lib-directory name to be the same as the package name. It sometimes talks about preferably choosing the package name for certain directory names in /etc/ /usr/share or /usr/lib, but I found no mentioning of required. X11, vim, emacs are examples, where the directory-name is not the same as the package name. There is no X11 package, the emacs package is an empty meta package and the vim package is just one of many vims available in Debian - and the one, that does *not* include /usr/share/vim. To my knowledge the policy isn't violated - but I'm no Debian maintainer in training, so I may be wrong. But still the current package has no open bug about this, the pure:dyne packages use pd as well. Btw: What about these packages? Weren't the p:d maintainers planning to incorporate their packages into Debian proper as well? Is there cooperation between HCS' efforts and those in pure:dyne? Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding standard install paths to the 'puredata' package
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: For the new 'puredata' package, I think we should add the user-installed paths that have been included with Pd-extended for a while now. Additionally, I'd like to Debianize the directory names (i.e. / usr/lib/puredata) What's un-Debian about /usr/lib/pd? Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] updating 'puredata' package to 0.42.5
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: On Thu, 19 Nov 2009, Hans-Christoph Steiner wrote: It seems that Günter is no longer updating the 'puredata' package, so I wanted to start the process of updating it. I am working on becoming a Debian Maintainer, so I can get direct upload access. This is what I would like to address: - improved puredata.desktop for file associations, etc. - built against Tcl/Tk 8.5 We don't need the «puredata» package, because we have the «pd-extended» package, and that's enough for essentially everybody. There is no pd-extended package in Debian and there never was. There are some debs for pd-extended on the build servers, but there also are many other Pd-based debs around, for example there are really good community-supported ones in pure:dyne. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] namespaces for send/receive
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: On Nov 18, 2009, at 2:35 AM, Frank Barknecht wrote: If you use the route-approach, you can use settable routes (as an abstraction like sroute.pd in [list]-abs). But actually I have no idea why a settable receive should be necessary anyway? :) Why not have settable receives? I dont' see the downside or harm. In this case, a settable receive is only possible via arguments and dollarargs in the receive object box. I guess that's an old issue... I didn't mean to start a discussion on the general usefulness of settable receives (about which I have an opinion), I only meant your usecase, which as I understand is that you want to share a global or remote value like a video's FPS in many abstractions. For this I don't think you need a settable receive, as you can reserve a single, unchanging reveiver to receive such information, either a multi-use single-name receiver that distributes items with [route] or many separate receivers (with the namespace pollution problem). Perhaps another approach would be to have a standard receive name for a library, then make it local using routes. So something like [receive framesync/framesync] then the next route would be the project ID, then the standard bits of data (i.e. fps). Yep. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] namespaces for send/receive
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: (*) Pd has no non-globals, just obfuscated names.. Yeah, I also try to avoid globals as much as possible. With this library, its kind of mirroring the audio clock of tilde objects, so [fps] is like [samplerate~] and the frameclock is transparent, just like you don't have to tell tilde objects which audio clock to use. I am trying to address situations when you are scoring to a video. I can't see a time when you would have to deal with multiple video framerates within the same project. I want to avoid having all this as arguments, since some of the objects already have 4 arguments. But I am open to suggestions to how else to deal with this. It would be nice to have the frame clock and fps within a project namespace, I just can't think of a way to do it without making things too complicated. If you really want to use globals I think you should minimize the number of global names in use by using a [route]-based approach like this: [r GLOBAL_FRAMESYNC_RECEIVER] | [route fps pos ...] | |... Personally I have all my globals in UPPERCASE. In sssad, I used SSSAD_ as prefix with divider. A way to give users some flexibility in regard to globals is to let them name the globals with a $1 argument. This would make it possible for users to create groups of related code sections that are still independend from each other, for example to have two things playing at different FPS values, which would be impossible if fps is global. In the audio system of Pd the samplerate can be changed in subpatches, although a different approach is used for that. Passing $0 as $1 would even make things local again. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: On Nov 1, 2009, at 4:15 AM, Frank Barknecht wrote: I cannot check out Ico's patch nor the GUI rewrite in general ATM, but generally all this stuff should always be tested with data structure displaying subpatches we well, as the coordinates there directly reflect the x/y float field values. Can you suggest a particular patch? Nothing in particular, but the examples in 4.data.structures provide an ample number of subpatches filled with data structures. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] namespaces for send/receive
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: So I guess to make it localizable, it would have to be something like framesync/fps$1. Without a settable receive, it makes this kind of chore to deal with then. If you use the route-approach, you can use settable routes (as an abstraction like sroute.pd in [list]-abs). But actually I have no idea why a settable receive should be necessary anyway? :) Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: I rewrote the scrollbar logic in 0.43 and its working well, as far as I can tell. Have you tried it out? I think its a similar approach, but the difference is that my code tries to keep things at 0,0 since Pd has a historical preference for patches having 0,0 as the upper left. I cannot check out Ico's patch nor the GUI rewrite in general ATM, but generally all this stuff should always be tested with data structure displaying subpatches we well, as the coordinates there directly reflect the x/y float field values. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how to tell when a patch is finished loading
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote: I don't think there's any existing way to do it--- time to design some appropriate hooks :) Actually at RjDj we would also appreciate a hook for telling the user when a scene has been fully loaded and displaying a kind of hourglass while the patch is still loading. Ideally this would also wait for the time objects like textfile or soundfiler take for loading their files. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] funny segfault in pd-0.42-5
Hallo, mescali...@gmail.com hat gesagt: // mescali...@gmail.com wrote: pd -noloadbang x.pd doesn't segfault, I can still make it segfault then by pressing the normally loadbang'd message box in the upper right of [pd fft]. pvu~ ... couldn't create I don't get this error. No pvu~ in my version of phasebash example at all. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] new pd-devel feature: patches for file associations
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: So I fixed a couple bugs in Pd-devel and added a new feature which I'd like feedback on: Here's some quick feedback, it's all IMO, of course. I created a system for associating pd patches to file extensions and created an example wav.pd for opening .WAVs. Basically, create a patch using the text $FILENAME for the filename should go, name it after the file extension (i.e. wav.pd), then drop it into 'pd/associations'. On start-up, Pd will set up the associations for that filetype. When you then open a .wav in Pd, it will open wav.pd, replace $FILENAME with the complete path, then create the patch by sending the contents of wav.pd to pd. I think, that the $FILENAME syntax is a bit strange in adding another meaning to dollar signs in messages. Having a message without any incoming connection do something is pretty mysterious. I'd very much prefer a receiver message coming in through [r pd] and tagged accordingly like: [r pd] | [route dnd] | [route wav] | [s $0-dropped-wavefile] Alternatively and IMO even better would be to use an object like: [draganddrop wav] | [s $0-dropped-wavefile] The next step would be to use this for drag-n-drop functionality, so when you drop an associated file on a canvas (i.e. voice.wav), it would copy-n-paste the contents of wav.pd to that canvas, with the $FILENAME replacement. Thoughts, objections, comments, improvements? In general the global registering of filetypes in my view is too restrictive. I'm pretty sure, that if I'd want to use d'n'd, I'd want it to do different things depending on which canvas I drop it in. A sample might be played, when dropped on a sample player, and it might be loaded into a table when used in a sample bank. The only useful way to make wav.pd work for everything with your system then would be: [symbol $FILENAME( | [s DROPPED_FILE] and then we could just directly use a receiver like above. Third: I'd don't like, that some information about what the associations patch does is encoded in the filename rsp. object name wav.pd, which is a bit against Pd's loose convention of having patches retain crucial information when printed. [route wav] would better fit this philosophy. However patchers should also remember, that some systems (the command line, RjDj, ...) don't support drag and drop at all. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] cyclone and uppercase
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Since Max has long since downcased all of their objects, I am thinking that it would be useful to add aliases to the cyclone objects for the downcased versions, like Line~ and line~, MouseState and mousestate, etc. Any comments or objections? Objection, judge! :) Some of the uppercase objects in Cyclone are there so the don't clash with builtins. Line~ is different from line~. Also why add aliases and cram even more stuff into the already filled namespace? Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] cyclone and uppercase
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: The central and stated aim of cyclone is to provide Max/MSP compatibility. As of Max/MSP 4.5 or maybe 4.6, they downcased all of the objects. Therefore, in order for cyclone to remain compatible with recent versions of Max/MSP (we're talking like 5 years old), it should also work with the downcased names. If someone can come up with a better way to support this, I am all ears. I think, it would be better to update Cyclone's maxmode then instead of making changes to the library in general. I don't know exactly how and where this is programmed, but it's activated when you load cyclone as a real library. For example probably one could register [mousestate] as an object that Cyclone will replace with [MouseState] in maxmode in additional to [MouseState]. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] cyclone and uppercase
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: I not sure what you mean by real library. With real I mean everything that is loaded with the -lib command line option. There was a time, when only that was called a library, collections of abstractions were called abstractions and externals were externals, sometimes collected into or preloaded as libraries. The confusion about terms is not my fault. Maybe I should call them library-libraries, in accordance with the usage of [sssad/sssad] or [list-abs/list-abs] :-P Well, maxmode is that black magic that I was referencing. I don't really want to learn it in order to use these objects. I think that objects like [mousestate] are generally useful, so it would help in Pd to have them lowercase, then we could think of the uppercase versions as the Max/MSP compatibility mode. _From what you wrote I assumed your motivation for suggesting aliases was Max 4.5/6 compatibility, not a problem with uppercase library names (which Python has plenty of btw.) Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote: I just took a look at Max/MSP and they have a nice tagging system, as well as an excellent configurable filter on their file browser that ends up being a pretty elegant solution to many of these problems. Perhaps going the route of adding parsable tags to object help patches (e.g. a comment containing ##os ##midi ##oscillator (hm, quite an odd object)) that can then be read back by the help-browser is more what you're suggesting (I got that feeling from the threads you linked Mathieu). I think, that's a good aproach (although it doesn't solve any namespacing issues) and a start for this is already existing in the [pd META] subpatch that you can find in some help patches in the svn. Documentation and categorization IMO should live as closely as possible to where the action is, i.e. in a help file or embedded in an abstraction/external. BTW: That is (and already was in the discussion about it at pd~conv Montreal) my main problem with pdpedia: IMO a Pd doc wiki takes the reference documention too far away from the files. I'm pretty sure, that people will rather add a [pd META] or so to their help files than go and edit a pdpedia page. In turn, a pdpedia page can parse and read out the META data from a help file - in fact, most of the useful stuff in pdpedia has been generated that way. The success of comment-generated docs or Python's docstrings illustrate my reasoning. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-ext documentation [was something else]
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Sounds like a useful thing. How about sticking this info into a subpatch in the help patch? They could easily be parsed with textfile and route. Then there is only one file per object to maintain. The [pd META] approach, yes. But there is no vanilla way to get a directory listing. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote: is something like this possible: each developer drops his stuff in svn in the current structure, but when compiled all externals are divided into categories (e.g. like the above named)? each developer has his own corner to drop stuff, but he has to check to which category each object belongs to, and they get distributed at compiling time. and, unchecked objects don't get compiled. is this feasible/logic? it sounds logic to me, as f.e. my abstractions cover a bit of everything: GUI, midi, audio, ... (The following uses the term library also for abstraction collections.) There is one big problem to solve with reorganizing (which I'm generally in favour of): interdependencies between libraries. That's why [list]-abs deliberately avoids these completely and relies only on Pd-vanilla, but libs like RTClib or mapping etc. depend on other collections (RTClib depends on [list]-abs and some externals, mapping has purepd and externals,...) Now if you rename all libraries you will also have to change some of their objects to refer to the objects in new ways. mapping for example could not use [purepd/float_argument] anymore and would have to be changed to something like [utils/float_argument] or [import utils]+[float_argument]. But then, mapping would not work in other distributions anymore. A route that I would suggest (and suggested several times in the past) would be to work on a kind of standard library that a) consists only of abstractions b) uses no externals at all c) is selfcontained (i.e. no interdependencies) If you feel reminded of [list]-abs now, that's intentional. Basically such a standard library would define an *interface* for standard objects. Where performance is an issue, the interface could alternatively implemented with externals. This also is exemplified in [list]-abs, where personally I use a version of [list-drip] that has zexy's [drip] inside for speed reasons. It behaves exactly like the abstraction version so it doesn't matter if people don't have zexy installed. Actually I'm working on such a project for a while now: the rj-lib for RjDj http://trac.rjdj.me/wiki/RjLibnew It's pure vanilla, has a well documented and (generally) consistend interface, has categories, a preset system and is generally patched in a clean, KISS and self-contained way. It's not so much intended to be loaded with -path, instead you should just drop the rj directory into your project directory as a whole and use the objects either as [rj/s_drumelectro] or you use [declare -patch rj] in your main patch and write the object names as [s_drumelectro]. This works surprisingly well: Most of the Scenes written for RjDj use this library sucessfully, although it's still far from 1.0. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: I think you outlined the argument against this proposal with your zexy example. It doesn't sound like a real solution if you include one version of list-drip in the list-abs library because of technical restrictions, but then you use a different version because it works better. Both [list-drip] objects from a user perspective work exactly the same, only that one is faster. If you encounter a patch that uses [list-drip] it's much better to have a slow [list-drip] than no [list-drip] at all. On some platforms not every external etc. is available. E.g. zexy is not available in RjDj's Pd or in a plain vanilla install so you cannot use [drip]. [list-drip] however can just be dropped into your working directory and you can use it. Abstractions and Pd builtins work everywhere, so they are the common denominator. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: I am bummed that we have to even discuss Apple's anti-free-software tactics in relation to the design of Pd. The only reason why you can't include externals as libdirs on the official iPhone is because of Apple's ridiculous restrictions that are in place solely for the purpose of making the Apple iTunes Store a monopoly. The decision, not to bundle the 102MB of externals currently in pd-extended into RjDj has *absolutely nothing* to do with Apple's license policy or any other licence issues: It's a technical decision made by the RjDj team. By keeping RjDj's number of objects limited we aim to avoid a maintainance nightmare and provide everyone with that least common denominator: Pd vanilla and a small number of selected externals. This will be the same for future ports to other platforms. And personally I made a very similar decision by avoiding to use too many externals on my GNU/Linux machine. Ciao -- Frank Barknecht ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: I am not talking about including files, I am talking about the forced static linking, i.e no dlopen(). It makes sense to me to not include 102 MB of files for rjdj, no complaints about that. Ah, okay, I misunderstood that. Yeah, the static-linking enforcement sucks big time especially for testing purposes. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: This just doesn't sound workable to me. Then you can never rely on an externals or even abstractions, since they might be an incompatible internal that comes along and overrides them. The alternative would have been never to include pow~ and abs~ inside of Pd main, but give them different names. I prefer to have them available in Pd main under their natural names now. There will always be backwards incompatible changes in any programming language or framework. Pd only had a very small number of these so far - I can only remember [atan2] - but it must be allowed to create them while moving along. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] why using vanilla better than extended; was :Re: pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hallo, cyrille henry hat gesagt: // cyrille henry wrote: this is what i was thinking for the last 5 year. i don't say that this will never change. anyway, i really appreciate the work made on pd-extended, but it is not ready for me yet. i know that my position is a bit extreme, but i don't really have problem with it. I have a similar position. :) To me the problem of Pd-extended or the reason why I don't use it is because it is not only a collection of externals and abstractions, but it also bundles it with a modified, often out-of-date version of Pd into a big monolithic package. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hallo, Martin Peach hat gesagt: // Martin Peach wrote: Well isn't it just easier to use something with a different name? If you have a backwards [pow] why not just call it [backwardspow] instead of letting users guess which [pow] is the right one? If a former external becomes a builtin in some future Pd version, you cannot use something with a different name, you can only rename the old external to something else. And what if the new builtin name was used by different, conflicting classes? What if Pd gets a [counter] builtin as is sometimes requested? Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hallo, Martin Peach hat gesagt: // Martin Peach wrote: I suggest that the first object to use the name 'owns' the name and any subsequently invented objects use different names. I think, that's good for external and abstraction libraries (in the repository), but Pd builtins should be free to use any name they want (within reason) and not be forced to scan every available collection of externals or abstractions if a name is taken. That's just not practical, especially not for abstractions (of which I have thousands on my disk, most of them local to a project of course) Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: 2.: using [cyclone/pow~] will force the use of the single-object external, and while doing so it will call the class_new() method for pow~ which will override the internal [pow~]. [pow~] will become the cyclone version. This is correct. I made a test whose results you can see in the attached screenshot and patch. It's weird. :) Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ pow-weirdness.pd Description: application/puredata attachment: pow-weirdness.png___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: they could, but it was an effort to do so. any ordinary external would not be able to do it. So am I understanding it correctly, that Zexy's [pack] is not doing the fuddling Cyclone does and now suddenly became an object that overwrites internals by changes in Pd 0.42? Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: 2.: using [cyclone/pow~] will force the use of the single-object external, and while doing so it will call the class_new() method for pow~ which will override the internal [pow~]. [pow~] will become the cyclone version. This is correct. I made a test whose results you can see in the attached screenshot and patch. It's weird. :) Okay, replying to myself: The attached patch IMO illustrates a severe bug with the aliasing. It is possible to have the same object in a patch behave differently depending on opaque circumstances like creation order. That's not only weird, it's nasty. Generally from time to time Pd will get new builtins that may use names of objects, that are already in some library. These internals should not be overwritten by the old externals by default, but overwriting may be included as an optional feature. So I would suggest something like a (gloabl or canvas-local) switch that explicitly enables builtin-overwriting. That way, Cyclone could still import Max patches, but zexy-pack wouldn't break anything in the default case. Still IOhannes would be able to use his pack when developing and RjDj could overwrite [soundfiler] with a [soundfiler] external that also loads ogg-files. Cyclone's fragile part probably could even be simplified in the code. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: On Tue, 2009-02-17 at 07:26 +0100, Frank Barknecht wrote: how can someone assume so? no, that is so not true. i didn't even know, that zexy comes with their own version of [pack] and [unpack] until some weeks ago. and why the hell to they use the same names as internals? no, by no means i don't want to be forced to use the zexy version, just because some patches i use need zexy. You have been forced to do so for many years, you just haven't been told about it until 0.42. I just now discovered that something is overwriting my [wrap]. I don't know yet which library does that. It would be nice if Pd could report the source library file together with the warning. It's a difference between Pd = 0.42 and Pd 0.42. I don't think, overriding builtins ever worked with single-file externals, that is what i am saying: this is introducing a _new_ incompatibility between pd-extended and pd vanilla. Huh? The only incompatibility is the new *feature* of alias names for overwritten objects. 0.42's [pow~] or [abs~] also are a new *feature* implemented by popular demand. Loading libraries and the overwriting itself hasn't changed at all AFAIK. If you don't use the alias names, you don't have any problems. but maybe I'm wrong. IOhannes? The overriding with lib-libraries works as before, additionally you now can use the builtins with an alias. That may not be the most pretty solution, but it doesn't break anything. i neeed to use an alias when i want to use vanilla objects? this is simply insane. I agree with you that external libraries generally shouldn't overwrite builtins. When using Cyclone for Max-importing it makes sense, though. But IMO the aliasing is less insane than not being able to use the builtins at all, as is the case if you load object-overwriting-libraries like zexy or cyclone in any Pd version before 0.42, including pd-extended. Note that here I use libraries in the -lib-loading many-externals-in-one-file sense here, not in the sense where everything (libs, singles, abstractions, libdirs) is called a library and setting a path is called loading a library. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: now, that pd has its own [pow~], why not just using that? yeah, it takes a bit more time to write the abstractions, but then they are more vanilla friendly. But that's exactly why I brought this topic up and asked: What to do about pow~? Because of the reversed inlets you cannot use the buildin pow~ when importing Max-patches without breaking the patch. I think, the smartest thing would be to use the builtin pow~, but reverse the *connections* made to it. Because that's what I'd have to do manually now after importing a Max patch with cyclone. An alternative would be to rename the pow~ in cyclone to something like [max_pow~] or [Pow~] and use that instead when importing. I suppose the connection-mangling is not trivial to write and as only this one object is affected, it may be easier to just do it manually when needed. The feature, that Pd now reports overwritten classes is very useful for spotting such differences. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: i still think that the loading-order in 0.42 is broken by design. Could you elaborate this a bit? Or point me to the relevant archive post? How is the loading order in 0.42? Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] stripping down Pd-extended's default libs
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: Frank Barknecht wrote: How does minimizing the number of loaded libraries affect the goal of storing preferences in patches? depends on what you mean by storing the preferences in patches. one part of the preferences is the libraries to be loaded. personally, i think it is a good thing to explicitely require libraries in patches that need them. Yeah, but IMO one has nothing to do with the other. Just because a pd-extended user would be forced to manage preferences manually doesn't make [import] a builtin or makes everyone layout their patches and externals as Pd-extended does it neither lets it [declare] work in abstractions. So I don't see how a minimized set of libraries affects anything. Personally I don't care what pd-extended loads and what not, but *if* minimizing libraries should be done, then I think no library should be loaded at all besides [import]. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: correct me, if this is wrong, but i understand, that overriding internal classes doesn't work with single-file externals. so the feature of overriding internal classes doesn't and won't work with pd-extended. I believe that's not quite correct: AFAIK overriding classes requires that a file is loaded with -lib filename. -lib also works for single-file-externals and is still supported in Pd-extended for all I know. :) Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hallo, Steffen Juul hat gesagt: // Steffen Juul wrote: So if you load a single-file-external without the -lib flag but just having it in the path does not override any internal (object-)classes? No, it doesn't. I tested this with Cyclone as single externals without -lib: pow~ is the builtin one. Pd 0.42 tells you on startup every class that has been overwritten. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] stripping down Pd-extended's default libs
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: To be clear, the libraries will all still be included in the package, they just won't be loaded by default. That means you'll have load them as part of the patch using either [declare] or [import], or using namespace prefixes like [cyclone/prepend]. This puts us further towards the goal of having all of the patch settings stored in the patch itself, making it more likely to work on more computers. How does minimizing the number of loaded libraries affect the goal of storing preferences in patches? Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hallo, Matt Barber hat gesagt: // Matt Barber wrote: At least we know it was an intentional difference: http://lists.puredata.info/pipermail/pd-list/2008-04/061603.html For extended would it be possible to exclude cyclone pow~ from the library, or less drastically patch both cyclone and vanilla pow~ to throw a warning, as was discussed last april? This is not related to Pd-extended which AFAIK doesn't include cyclone as a library (a -lib loadable one), but when loaded as a lib, Cyclone does some magic to even overwrite Pd internals. I made a little check now and actually Cyclone then is very smart and aliasses the builtins to different names. Running pd-0.42 -lib cyclone gives this: ... warning: class 'pow~' overwritten; old one renamed 'pow~_aliased' ... and now the [pow~] behaves like in Max, while [pow~_aliased] is the new pow~ from 0.42. That's pretty cool, actually. Unfortunatly you cannot use the other cyclone objects without rewriting [pow~] when cyclone is loaded as a library. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] stripping down Pd-extended's default libs
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: On Feb 16, 2009, at 4:46 PM, Frank Barknecht wrote: How does minimizing the number of loaded libraries affect the goal of storing preferences in patches? So people don't rely on the libraries being already loaded and explicitly set the libraries that the patch requires. This is how it works with C, PHP, Java, Python, C++, Tcl, etc. etc. etc. If you want to use a library, you need to include/declare/require/import it where you need it. Changing the number of loaded libraries doesn't solve the problem of how to store preferences in patches. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: from what i have understood, it is not cyclone's ability to replace built-ins, but it is a so called new feature of pd 0.42. the same happens also with zexy's [pack] and [unpack] and many others. why is that so cool? i personally find it _very much_ confusing, that you cannot be sure anymore to use only pd-vanilla classes, when libraries are loaded. IIR that's not how the feature in 0.42 works. It does not affect each external and also does not affect single-file externals. The only object classes affected are those, that override Pd builtins. If you load zexy and if zexy overrides [pack], then its sensible to assume, that you want to use zexy's [pack]. Pd 0.42 keeps its own [pack] in an alias, but allows zexy to override it with its own version. Same with some versions of pow~, wrap, abs~, ... If you use Cyclone in its single externals files version, the version of [pow~] that you get is the one from 0.42. Fixing this would involve changing Cyclone and Zexy. then again, as you say, this new features introduces _another_ difference between pd-extended and vanilla: overriding internal classes works only with libs and not with single-class-per-file collections. It's a difference between Pd = 0.42 and Pd 0.42. I don't think, overriding builtins ever worked with single-file externals, but maybe I'm wrong. IOhannes? The overriding with lib-libraries works as before, additionally you now can use the builtins with an alias. That may not be the most pretty solution, but it doesn't break anything. ___ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie z... Right! ;) Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]
Hallo, Matt Barber hat gesagt: // Matt Barber wrote: Getting rid of cyclone's pow~ would break all of the patches that rely on cyclone's pow~, and would also make it harder to import Max/MSP patches. Removing it is not a solution. Okay. But I don't see why something that is a rather obvious breach of style should be allowed to bully the rest of the application. I have never used Max/MSP, but it seems like its (and cyclone's) [pow~] is really something more like an [exp~] with a changeable base. Cyclone's overriding is pretty important for importing Max files. Without it I wouldn't have been able to port the RTC library that fast. Of course porting RTC involved replacing many objects with their Pd equivalents (and being a pd-vanilla fanboy, I mostly used builtins and abstractions for that). Other users may be fine with keeping Cyclone loaded and run the Max originals - freedom of choice is fine here. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] maxlib's and Gem's scale objects
Hallo, Loic Kessous hat gesagt: // Loic Kessous wrote: yes, thanks [+], [*] and expr too! to make the exponential mapping ;-) ..., that can be done in an abstraction , that I may have somewhere in max before scale has been ported to os X, but for me the real question was to know what can I use from Pd-extended, so if i work on a another computer and even another platform I can just take my patch and not taking care about other things to add (because I'm always forgotting them...) The safest thing to do really is to use an abstraction that only relies on Pd vanilla objects (if possible) and copy that into your patch directory. Then every Pd user everywhere will be able to use your work. maxlib's scale is pretty easy to do as an abstraction, Gem's scale obviously is not. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] seteuid vs. setuid
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote: I was just merging 0.41 vanilla into pd-extended 0.40 and noticed something worthwhile to point out. It seems there isn't a patch submitted for this, but it is quite simple. Basically, in s_inter.c, 'seteuid()' is used to lose setuid privileges. As far as I understand it, seteuid() allows the program to keep the root privilege and switch back and forth between root and non-root. hm, why does pd need root privileges, anyway? shouldn't the resource limiting be handled by pam these days? Agreed. IMO it's unnecessary: None of my Pd Linux installs has Pd installed setuid, still the -rt switch works fine for every user in group audio and I never run Pd as root. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] object name conflicts
Hallo, Daniel Aschauer hat gesagt: // Daniel Aschauer wrote: I committed my external to the svn. But I then realized that in the 0.40.3 extended pd version that I downloaded there is an external (flatspace) included that has similar object with the same name. How are these name conflict processed, and can they be resolved. There should be different object with the same name, right? There can be no two objects with the same name! :( To avoid nameclashes, there are several ways. You can compile your objects as single externals instead of a library, put them in a directory algocomp and load them as [algocomp/map] etc. Basically you rename your objects then to include algocomp/ as a prefix. This also requires certain things with regard to help files etc. You can use [import algocomp] then if you install the import external and make your users install it, too. Or you can chose a different object name on the source code level. For example rename your objects to ac_map or algo_henon or whatever scheme. That's what I would do, it's the solution with the least hassles. Btw.: You maybe want to rename your help files to NAME-help.pd as that's the usual standard now. (I only checked algocomp from your site, sorry if you made changes for the SVN version) Btw++: [map] is a bit superflous: Its functionality is also available as [maxlib/scale], [range] and in many abstractions. I'd just drop it or replace it with an abstraction. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] maxlib's and Gem's scale objects
Hallo, Loic Kessous hat gesagt: // Loic Kessous wrote: I recently start to work with Pd (I was a Max guy only before) and I'm a little confuse about the 'scale' and range objects. Both [scale]s, and [range] are externals, so they don't ship with a standard Pd and one has to chose which one to use. Gem is one of the oldest collections of externals and its [scale] is a very important object, so I'd reserve the name scale for the one in Gem. If you think so, too, then every other [scale] has to get a different name. You can use the maxlib scale by refering to it as [maxlib/scale] in Pd-extended. Personally I'd rather use an abstraction that is easier to rename. I use m_scale.pd from the RjDj library: http://trac.rjdj.me/browser/trunk/rjlib/rj Ciao -- Frank Barknecht ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] maxlib's and Gem's scale objects
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: On Jan 8, 2009, at 12:51 PM, Frank Barknecht wrote: Personally I'd rather use an abstraction that is easier to rename. I use m_scale.pd from the RjDj library: http://trac.rjdj.me/browser/trunk/rjlib/rj There are others as well, like [mapping/autoscale] aka [autoscale]. I thought there was something in 'cyclone' too... There's also [+ ] and [* ]. ;) Ciao -- Frank Barknecht ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Tcl/Tk code formatting and file organization
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote: On Sat, Jan 03, 2009 at 01:48:11PM -0800, Miller Puckette wrote: A bit OT, but if you're using vi, a quick and painless way to reformat between all-tabs or all-spaces is the following: :0,$s//\t/g- converts 4 spaces to a tab :0,$s/\t//g- converts a tab to 4 spaces In Vim you can also use the :retab command. The manual contains an example for automating things. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Patches-2419952 ] Add 'get' method to toggle
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: The iemguis have had their unique behavior for a very long time, so I think it is a bad idea to change them. The beauty of free software means that anyone can take all the iemguis and modify them however they want and make a new library out of them. See attachement for a toggle with get message as an abstraction. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ get-toggle-help.pd Description: application/puredata get-toggle.pd Description: application/puredata ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] osc automatic routing
Hallo, Forwind info hat gesagt: // Forwind info wrote: Does anybody know if there is a way to automatically send an OSC message to an internal PD messaging address which happens to be the same as the route of the OSC message. So for instance, an osc message arrives with route /a/sample/route and value 50, I would like to automatically send the value of the message to the internal message address of /a/sample/route. You could use a settable [send] for this: [dumpOSC] or whatever | [list split 1] | | | [s $0-rest-of-message] | [t b a] || |[s $0-sender-name] | |[r $0-rest-of-message] || [list] | |[r $0-sender-name] || [send] It's imperative that you use the [t b a] here, because the rest-of-message would be generated before the sender-name otherwise as there's right-to-left ordering in [list split]. In a non-ASCII-patch I'd use direct connections, not sends, but that would be hard to read in ASCII. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] i can has svn commit access?
Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote: i'd like SVN commit access, so that i can work on improvements to some of the Pd usability issues that have been bugging me lately. i would like to implement multithreaded [soundfiler] read, and i'd like to in the longer term make a stab at multithreaded the entire DSP engine, or at least investigating whether this project is a feasible one. You're welcome, but take note, that the MAIN branch of Pd in svn is strictly reserved for commits by Miller, so if you want to make changes to [soundfiler] using the sourceforge patch tracker is the way to go. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] trigger: [t b 1 2]
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: Damian Stewart wrote: [t 1 a] i like this Me doesn't like it too much: Conceptually it clashes a bit with the possibility to replace f with a number in [pack]: [pack f f f f f f f f f] is almost the same as [pack 1 2 3 4 5 6 7 8 9] but the latter is easier for counting the arguments. And how should [t 1 a] react to a list of 2 3 4: Should the first outlet give 1 or 2? Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] poly library
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: I didn't think of changing the behavior by using different wrappers, that makes sense. I guess with nqpoly4 vs polypoly the main difference in the wrapper. I think there are a couple advantages to not using a wrapper: - makes it easier and more transparent to find instances when debugging, [$1 $2 $3 $4 $5 $6 $7 $8 $9] is a strange construct to see Yep, that's true, but OTOH a wrapper is just a Pd patch, which is much easier to change than a dynamic patching construct. That has to be taken into account when it comes to longer-term maintainability. Generally less dynamic patching is better. - it should make it much easier to make the *poly objectclass behave like a normal objectclass, with one file being in extra, but usable anywhere. This would require [ggee/getdir], but it should be pretty straightforward from there. You mean getdir for finding the objects to instantiate? Maybe you can elaborate this a bit... The big problem of all *polys so far is that it's hard for them to finde the objects to instantiate. At first I had hoped that your solution of omitting the wrapper would be an easy fix, but in my tests it showed the same issue. I am not a fan of huge routes, unless they are being dynamically generated. It makes some really nice line drawings when you have 30 or more instances :) Yep, it looks really cool. ;) Is there any real difference in efficiency between one big route and many small ones? I don't think so. I'd guess that small ones are a tiny bit less efficient because of the additional inlets, but I wouldn't care about this. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] poly library
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: - [rawpoly] allows for dynamic addition while each existing instance will keep it's state. It also creates objects in the subpatch with proper $0 and $1. - [instances] uses one [route] for all instances I think, the proper $1 can be pretty useful, especially when combined with IOhannes' trick to detect empty creation arguments. The real $0 doesn't have a real advantage inside *poly, but it allows copy-and-paste of the whole subpatch into a static patch, that isn't generated dynamically anymore, which can be useful as a patching utility. The other changes are more cosmetic, I think, and here it's probably a matter of taste if an additional wrapper or the added dynamic patching is easier to handle. I'm a bit undecided in this regard, but the wrapper has as an advantage, that just by creating different wrappers one could induce different types of *poly-behaviour. I'm not a big fan of huge [route]s, though. ;) Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] future of [declare]
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote: I think (probably as you're saying below) that an abstraction's declarations should affect only itself and things called from within it. I think, that's what Luke meant, and I would agree here. Generally it's not necessary and even against common sense for an abstraction's declare to modify the paths of its parents. (If we want to have this functionality for some exotic meta-programming techniques we should implement this in a different object.) Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] make uninstall problem in bash with vanilla
Hallo, patco hat gesagt: // patco wrote: hello, when I do 'make uninstall', bash still have a reference of pd being in /usr/local/bin (with using ./configure --prefix=/usr/local) $ pd bash: /usr/local/bin/pd: Aucun fichier ou dossier de ce type how could I remove this reference? logout login again Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Problem building pdlua on MinGW (solved for now)
Hallo, PSPunch hat gesagt: // PSPunch wrote: #ifdef MSW #ifdef PD_INTERNAL #define EXTERN __declspec(dllexport) extern #else #define EXTERN __declspec(dllimport) extern #endif /* PD_INTERNAL */ Without PD_INTERNAL defined, dllexport - dllimport which looks kind of critical. Sorry, actually this difference slipped me (must be my new glasses ...) Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] dump OSC bugs?
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: whenever i find the time, i want to add a note into the constructor of the OSCx objects, so you get a warning each and everytime you create one of these objects. I think, such warnings may be a bit too patronizing. Also OSCroute doesn't have any critical bugs AFAIK. Bundling some replacement abstractions build with Martin's osc objects for ease of transition would be useful, though, and the osc help files could benefit from some polishing like replacing [prepend] with a no-nameclash solution based on [list] etc. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] dump OSC bugs?
Hallo, Martin Peach hat gesagt: // Martin Peach wrote: Probably moving the mrpeach osc objects (routeOSC, packOSC and unpackOSC) into an /osc folder and the net objects (udpreceive, udpsend, tcpreceive, tcpsend, tcpclient, tcpserver) into a /net folder would be a good idea, making them easier to find for the uninitiated. I think, that's a great idea. Unfortunately it would break some existing patches that currently use the /mrpeach prefix. They could make a copy or symlink, if the OS allows, to the old location. And I'm not sure how much svn enjoys moving things around like that. Moving is well supported in SVN, much better than in CVS. I cannot comment if it breaks something in pd-extended or how its (auto)build system has ot be adapted. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] recording the overall state of a patch
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote: forwind wrote: Apologies if this is not the correct place to post this but could someone point me towards ways to record/save the overall state of a patch. http://lists.puredata.info/search/PD-list?query=state+saving What solutions do people generally use ? sssad appears to be popular memento/rradical was also popular, not sure what the current status is I still use Memento, as I'm used to it, but for new users I would rather recommend sssad, as it's much easier to install, has most of Memento's features now, doesn't require any externals, has a clean patching style etc. Yesterday I posted a complete example that shows how easy it can be to convert a patch to use sssad: http://lists.puredata.info/pipermail/pd-list/2008-08/064547.html Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] closing bugs (was Re: [ pure-data-Bugs-2004979 ] hid defaults to debugging (flood of hid_get_events))
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Bug reports should be closed when they don't need any more attention. When reporting bugs, ideally people would also search closed reports to see if the issue has ever been reported or if there has been any work or discussion related to this issue. Closed should not be a synonym for Complete. There is a separate pull- down menu for that, with states like Accepted for patches and Fixed for bugs. A bug that is Closed can not be(come) Fixed anymore. hmm, technically it can (on the sf tracker); but i guess you are rather referring to the social aspects of it. Yes. To me, Closed means that an issue doesn't need any more work. This can mean that it's tested and fixed, that it won't be fixed, that is is invalid, a duplicate etc. But the main feature of bugs marked Closed to me is, that no further work is needed in this issue, and Open bugs are bugs that still need one or more Actions to be performed. The bug in question is fixed in a branch, but what was still left to do was to apply that fix to the trunk. After that the report would be closed. I don't understand what is gained by closing a report when there is still work pending, however minor that may be? (And personally I don't think, a bug fix missing from trunk is that minor, but that's another story.) An open bug report is just a little reminder and it doesn't hurt anyone. At least I hope it doesn't ... Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] abstractions
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: And Pd doesn't provide enough when it comes to supporting abstractions in a way that makes them be able to use Pd in a way equivalent to how normal externals can use Pd, and at a price not significantly greater. For example, [#in] and [#out] aren't in such great shape since they became abstractions, and they're significantly more complicated, because even the simplest dynamic patching is complicated. At Pd Convention 2004, there was a nice moment during the papers sessions, where there was an apparent consensus that as many things as possible should be made as abstractions. I still think about that. I like the idea, and I've always liked the idea, and you can trace my appreciation of that idea back to the original design of GridFlow, but it's not always so feasible just by using Pd. I think, Pd could benefit a lot by providing a default scripting language to write operations like [range] which are tediuos to do as an abstraction. Altough I'm not a fan of Tcl (and would prefer Lua), Tcl would be a natural choice as it's available anyway. Ideally the scripts would be saved within the patch, e.g. inside message boxes. Oh wait, that's toxy! Hm, ... but toxy has a horrible syntax, which I could never get around. But the general approach of it is a fantastic idea. The advantages of a scripted Pd classes are: For certain tasks, especially those involving lots of repetition, patching is too much work. And as pd-extended shows, if you pack each and every external and abstraction into the pd-distribution, you either have to deal with ugly long names or live with namespace pollution. Btw.: That's why today I tend to avoid installing lots of externals and rather copy them to a project's folder when needed. Apart from extensions that provide special functionality like Gem, msd, OSC or iemfilters, I don't use convenience collections like maxlib anymore - expect my own of course. Joao would probably call me a hardcore user. ;) Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Using Arrow Keys in Vanilla and Extended Pd
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote: Could you submit this bug report? It has been a while since I have logged into SourceForge and I have to find my password... Oki. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Using Arrow Keys in Vanilla and Extended Pd
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote: Over the weekend, I was building a program that I wanted to use the Arrow keys to control direction, and one thing that I found was that anytime I hit one of those keys, the front most window is marked as dirty (as if I made a modification in the Edit Mode). Is there some reason for this? Is this a bug? Interesting: Happens on pd-vanilla as well by just opening the key/keyname helpfile and pressing any arrow key. Looks like a bug to me. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Using Arrow Keys in Vanilla and Extended Pd
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote: Over the weekend, I was building a program that I wanted to use the Arrow keys to control direction, and one thing that I found was that anytime I hit one of those keys, the front most window is marked as dirty (as if I made a modification in the Edit Mode). Is there some reason for this? Is this a bug? Interesting: Happens on pd-vanilla as well by just opening the key/keyname helpfile and pressing any arrow key. Actually you can open *any* file, press Up and it gets marked as dirty. Definitely a bug. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-2004979 ] hid defaults to debugging (flood of hid_get_events)
Hallo, SourceForge.net hat gesagt: // SourceForge.net wrote: Submitted By: Frank Barknecht (fbar) Assigned to: Hans-Christoph Steiner (eighthave) Summary: hid defaults to debugging (flood of hid_get_events) Initial Comment: It seems, [hid] still defaults to have debugging on which results in a flood of hid_get_events messages to the console, when polling is on, unless one sends [debug 0( to [hid] Also see http://lists.puredata.info/pipermail/pd-list/2007-01/046275.html -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-06-28 13:14 Message: Logged In: YES user_id=27104 Originator: NO One Pd-extended 0.40.3 is released, I'll merge all of the changes into trunk (this is a fairly standard way to deal with release branches). A fairly standard way to deal with bugs fixes is to include them in trunk. I don't think, one can expect users to follow every branch. In fact, I don't check out the branches at all, because there are so many of them and I don't want to search every branch for a bug fix. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-2004979 ] hid defaults to debugging (flood of hid_get_events)
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: On Jun 29, 2008, at 2:10 PM, Frank Barknecht wrote: Though there is a larger question lurking here: What should trunk be and how should bug reporters check, if a bug may be already fixed? Or in short: What is the reference repository: some branches or the trunk? To me, trunk was that reference version (and for the record: to me it is for bug reports regarding my stuff, unless the reports are branch-specific). But if you regard pd-extended branches as reference for your externals, I'll take note of that for future reports. Trunk is the reference, but during a release cycle, I am following the practice laid out by a number of other projects of focusing all my work on the release branch. Then once the release is done, I'll merge those changes into trunk. Otherwise, it is a lot of work maintaining changes in two branches at the same time. That's perfectly fine. Maybe I should rephrase the question to: When to close bugs? If I encounter a bug, I first update my checkout to the latest version of the trunk, recompile, and if the bug still is there, I go to the bug report page and look, if there is an open bug report regarding it. Mabye I'll also search the mailing list. In this case I didn't find a bug report, and in the archive I saw you asking for a report. So I sat down and wrote one. It was closed some minutes later because there is a branch that doesn't have the bug anymore. Now someone else may come along, do the same thing as I did, but now there is no open bug report anymore so she may go through the same procedure again. Anyway, no need to further pursue this issue in this petty case, but in general I'd prefer if bug reports would stay open until they are fixed in the main branch i.e. the trunk to avoid duplicate reports. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] bang [block~] to query current blocksize
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: On May 25, 2008, at 5:29 PM, [EMAIL PROTECTED] wrote: Quoting Hans-Christoph Steiner [EMAIL PROTECTED]: i think the [r pd][route dsp] approach is a kludge... Maybe this: [dsp( | [s pd] [r pd] | [route dsp] exactly this is the kind of kludge i am talking about. i hope that kludge means something really bad and ugly, as this is how i use this word here. You mean it's a kludge if there isn't a special object for this? The real problem is that it's global: I may not want all my [r pd] receivers to get activated every time something somewhere queries the state of DSP. Ciao -- Frank Barknecht ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] bang [block~] to query current blocksize
Hallo, On May 23, 2008, at 9:48 PM, Miller Puckette wrote: Or, how about three extra outlets to samplerate~ (so as not to have to add more to the top-level namespace) Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Hmm, while the idea of a single object is good, I think the object is clearly called samplerate so getting the rest of that info from it doesn't really make sense. I agree with Hans (except for the top-posting reply style) and would like to add that instead of separate outlets, maybe a single outlet would be better, that spits out messages prefixed with blocksize N, overlap M, samplerate O would be better as it could be extended with other messages later. Notice that I included samplerate here: such an object could be a general info object for the dsp state ([dspinfo~]?) Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] the future of [declare] and canvas_savedeclarationsto()
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: I think this issue is pretty clear, and the languages that I know would fall along the lines of each patch/abstraction has its own namespace or in other words #include only affects the one .c file, import only affects the one .py file, etc. So I agree with Frank. Global settings are global, and canvas-local settings are local to the original file. I think, it's not yet pretty clear at all otherwise we wouldn't discuss this issue so often. Here are some random thoughts on the topic. The languages you mentioned have something like a scope, they know global and local variables. In Pd, everything is global and there is no local scope as far as I can see. Even $0 evaluates to a global value, that is easily accessed from the outside of an abstraction. So you cannot just take a concept from, say, Python and include it one-to-one in Pd - it has to be adapted. (Also Pd has more in common with LISP or Lua than with C or Python IMO, so we should look there first.) Currently [declare] modifies global settings like path and loaded libraries, that you normally modify outside of a patch with .pdsettings/.pdrc or command line options. That's simple and beautiful at first, but has the ugly side effect of conflicting declares, that need to be resolved. Having the toplevel [declare] win over other declarations is simple as well, but not that beautiful anymore as it makes writing abstractions more error prone because they cannot rely anymore on their own declarations being valid. So in the end I'd agree with you that we would (also?) need a way to modify settings in a non-global way. As far as I see it, we'd have two places for doing this: We could use a restricted scope for such declarations either a) per abstraction i.e. in a region where $0 is equal. b) per subpatch: [pd zexy-is-loaded-here] It could also be realised with messages sent to pd-subname, but that's probably not a good idea because of execution order problems. Or is it? Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] the future of [declare] and canvas_savedeclarationsto()
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: [declare -std*] modifies the global namespace [declare] with -lib and -path modify the canvas-local namespace. Not according to the help-file for declare, where the only difference between the options with std and those without is how the arguments are evaluated: relative to the patch for the naked, relative to Pd for the std-decorated versions of the options. There's nothing about scope in the help file (and I'm currently not taking into account how declare works in reality, as that is deliberatly restricted in 0.41) Tcl has namespaces that can be used across procedure/class, provided you import them into procedure/class. I suppose Pd could have that too, so you could set dependencies across a whole project. But I don't see this as being especially useful in Pd, and it would add complexity. If I write an objectclass (aka abstraction), I only want to have to think about what libs that objectclass needs. I don't want to think about how those libs related to other files in the project at that point. Having the local namespace per objectclass/abstraction allows for this. Agreed. But it seems that's not what [declare] does ATM or was intended to do when Miller wrote it, while [import] was designed to do it, IIR. Lets not confuse the two. Ciao -- Frank Barknecht ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] the future of [declare] and canvas_savedeclarationsto()
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote: I use 'declare' all the time.. don't think it's semifunctional at all. I think the questions about how declares should act inside abstractions are hard to resolve; in my own usage (and in the way I suggest others might want to use declare) it's always in the main patch, as a way to show the patch what libraries, etc, it needs. In Pd as I see it there is no inherent distinction between a main patch and an abstraction. Even a patch designed as main patch can become an abstraction quickly, for example if I make a toplevel performance patch that loads other main patches as abstractions. If [declare] only works in the new main patch, I will have to manually collect all dependencies from the sub-abstractions again, which is tedious, duplicate work, if they all include appropriate [declare]s already. An open question is how to deal with conflicts, i.e. what to do when the toplevel patch declares -path /to/zexy/ and an abstration used in that patch declares -path /to/cyclone and both try to use [urn] which acts differently in zexy and cyclone. As many things in Pd are global per default (value, send/receive, arrays, ...) it may make sense to add something like a -localpath option to [declare], so that abstraction authors could add their local settings to a canvas, while still accepting toplevel declarations: toplevel patch: [declare -path /to/zexy] [urn] = zexy's urn [abstraction1] [abstraction2] abstration1: [declare -localpath /to/cyclone] [urn] = cyclone's urn [abstraction1a] abstration1a inside abs. 1: no declare [urn] = zexy's urn, as abs. 1 only uses -localpath abstration2: [declare -path /to/cyclone] [urn] = zexy's urn, if main patch declares zexy, cyclone's urn otherwise [abstraction2a] abstration2a inside abs. 2: no declare [urn] = as in abs. 2. But actually I would feel more comfortable if all settings would be local to a canvas. For example abstraction2a from above would act differently depending on the toplevel patc. All local would conflict with your usage so far, though. OTOH it seems [import] tries to be just that (never used it, though): A modifier for the local canvas only, so maybe we can use both? Ciao -- Frank Barknecht ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-1963644 ] http-links do not open...
Hallo, SourceForge.net hat gesagt: // SourceForge.net wrote: Bugs item #1963644, was opened at 2008-05-14 04:03 Summary: http-links do not open... -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-15 15:50 Message: Logged In: YES user_id=27104 Originator: NO I added xdg-utils as a recommended package, since it includes xdg-open, which should open irc:// URLs. I am going to leave the browsers in as a fallback, since it is better opening only http:// than nothing at all. Firefox is not a fallback for XChat. I'm going to leave it at that and close this report, if anyone wants to take this up, they can reopen this bug. -- Well, it's a different bug now anyways: pd-extended tries to open unsupported url-schemes in webbrowsers. (xdg-open here throws irc-schemes to iceweasel btw.) I think the only valid solution is to handle web urls like http:// and application URLs like irc:// differently in Pd. (I don't file a report as I use pd-vanilla.) Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-1963644 ] http-links do not open...
Hallo, SourceForge.net hat gesagt: // SourceForge.net wrote: -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-14 05:49 Message: Logged In: YES user_id=27104 Originator: NO Since you are using KDE, I recommend: apt-get remove gnome-open The URLs in the Help menu work for me on Ubuntu, Debian/GNOME, Mac OS X, and Windows. I don't use KDE at all, so if you can make it work better there, please do. -- On Debian-based system you could use sensible-browser and let Debian decide which browser is sensible to use. Ciao -- Frank ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Feature Requests-1065953 ] mouse pointer for moving a point in a scalar
Hallo, SourceForge.net hat gesagt: // SourceForge.net wrote: Feature Requests item #1065953, was opened at 2004-11-13 18:44 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478073aid=1065953group_id=55736 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: data structures Group: Next Release (example) Status: Closed Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: mouse pointer for moving a point in a scalar Initial Comment: When editing scalars with the mouse in Run mode, the mouse pointer changes to a two-headed arrow to represent that you can change the width of an array point. The mouse pointer does not change when its above the spot where you can move an array point with the mouse. -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-14 08:54 Message: Logged In: YES user_id=27104 Originator: YES This has been implemented in Pd-extended 0.40.3 I'm wondering why this bug/Feature request was closed? It wasn't related to pd-extended as far as I can see. And the assignement to Miller made it look like a report regarding Pd vanilla. Ciao -- Frank ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] new distro: pd-vanilla+libs
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Now that Pd can be built on all platforms without patches, I think we can have a pd-vanilla+libs distro that is based on an unpatched pd- vanilla build. Another question regarding pd-vanilla+libs as a complete package: Isn't this already done, if the patches, pd-extended applies, would be left out when building? Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] new distro: pd-vanilla+libs
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: You are welcome to deal with it. I've done it enough. I have no interest in dealing with those issues, so how about we get the unified build working, then y'all can find out the joys of binary incompatibilies without me. :) Well, you're experience could be a helpful time saver. Ciao -- Frank ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] new distro: pd-vanilla+libs
Hallo Hans, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Now that Pd can be built on all platforms without patches, I think we can have a pd-vanilla+libs distro that is based on an unpatched pd- vanilla build. It could also have a more limited subset of included libraries, much like others have been proposing. They would be having the same library format and install methods as Pd-extended, so that patches would be compatible. I think, this is a very good idea and I'll stick it on my TODO list, however I believe, that instead of a vanilla+libs bundle a pure libs installer/package would be more appropriate, kind of like the traditional pd-externals package. We already have binary packages of vanilla Pd (Miller's and autobuild) and I believe it's easier to get more people to use the same externals setup by providing a package independent from a certain Pd build. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] new distro: pd-vanilla+libs
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Ultimately, that sounds like a good goal, but it would also be a lot more work, and would cuase more bugs. There are incompatibilities between versions, not always large, but there. That means you'd then have to add code to manage that. Externals are a lot like linux kernel modules. Is it really that bad? I often don't recompile my externals when I install a newer Pd version (and just for fun loaded maxlib 0.3, compiled Jul 8 2002 with the newest Pd, seems to work just fine). I know, some externals are dependent on a specific version, e.g. GUI externals like knob or some that use private headers, and of course some abstraction may require features not available in early versions. But this may be possible to work around by requiring a minimum version of Pd(-vanilla). Ciao -- Frank ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] allow only one instance of external object
Hallo, best boy hat gesagt: // best boy wrote: is there a way to keep track of the number of opened instances of an external? if so, can anyone point me to an example object? You could wrap it inside an abstraction which has a running counter stored in a [value MYOBJECTCOUNT] object. MYOBJECTCOUNT should be unique. The counter then gets incremented with each new instance of your abstraction. You cannot delete objects though without the counter getting out of sync unless you use a Pd with [closebang] or so. For various obvious reasons, this is not a very good general solution, though. Ciao -- Frank Barknecht _ __footils.org__ objcounter.pd Description: application/puredata objcounter-help.pd Description: application/puredata ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding pdpedia links to all help patches
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: I want to add links to all of the help patches in SVN to their respective pdpedia pages. Ideally, I could check these into trunk so that they would become a permanent addition. The problem is that the link object is not included in pd-vanilla ([pddp/pddplink]). Who does not want this checked into trunk? I think, this should be decided on an opt-in, not an opt-out basis. Anyway: I opt out. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Calling a method periodically
Hallo, Greg Surges hat gesagt: // Greg Surges wrote: It looks like this is the right track... Looking at the metro code, I'm a little confused as to how the object continues to output bangs after the first. What does it mean that clock_delay calls back? When you create a new clock with clock_new, you pass it a method fn: EXTERN t_clock *clock_new(void *owner, t_method fn); fn is the callback method, that gets called, if you later run clock_delay with your clock and the delaytime. It gets owner passed as argument, so it's called as: fn(owner) In the metro-code, the clock is created in metro_new: x-x_clock = clock_new(x, (t_method)metro_tick); Here metro_tick get registered as the callback method of clock x-c_clock. Then metro_float is responsible to start the metro, which is made by calling metro_tick(x) directly once, if the incoming float is not 0. After that, metro_tick kind of calls itself over and over again using clock_delay(x-x_clock, x-x_deltime);: Each time, clock_delay is called, it waits for x-x_deltime to then call the registered method, metro_tick(x), again. You use clock_unset to stop the clock, and clock_free to destroy and free it completely. It may be easier to first understand how [delay] works, as it's a bit simpler. And for a more complicated object, try to figure out how [pipe] works. ;) Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] naming loaders: pdlua, tclpd, etc.
Hallo, Albert Graef hat gesagt: // Albert Graef wrote: Claude Heiland-Allen wrote: Yes, a simple one: there is a function typedef (for the loader hook functionality) and a function to add a hook to the list. I forget the exact names, they're in m_pd.h if you have a new enough Pd. You mean this? (From your Lua external.) /* defined in pd/src/s_loader.c but not in any header file... */ typedef int (*loader_t)(t_canvas *, char *); void sys_register_loader(loader_t loader); This looks like it may be useful for Pd/Q, too. I guess I'll have to dive into the sources to see how it works, or is it documented somewhere? In my experience trying to use Haskell in Pd didn't work so well, partly because it was compiled. Lua, being interpreted, worked much better. Yeah, the nice thing about interpreted languages is that they allow you to change the code on the fly which is great for live coding. This point however is a bit tricky with loaders, see the difference between the loader functionality in pdlua and the luax objectclass. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] naming loaders: pdlua, tclpd, etc.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Any perferred name? I don't think I have a strong preference of any name, but I do think there should be a simple, standard naming scheme. May I throw in another one: As loaders are a bit different than externals, maybe a loader pre- or suffix would be good, like lua_loader.pd_linux or loader_lua.pd_linux. That way, [lua] would still be possible. I also don't have a strong preference for any of the suggestions, but I agree that consistent naming can be useful. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd OSC implementation(s) incompatible with SC3? [Fwd: Re: [sc-users] NetAddr]
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote: Thought this might be of interest to developers of OSC externals. In short: Pd OSC implementations should send OSC on the same port that they listen on, as that is the standard way OSC works. I don't know what standard Marije is referring to in her mail. The OSC spec at least doesn't say anything about ports. I searched for port in the spec, there is only one mention of it and that is in a non-standard type tag (m for midi). Ciao -- Frank Barknecht ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] gui separation on mac
Hallo, Smør På Flesk hat gesagt: // Smør På Flesk wrote: i was hoping to compile pd without tcl/tk, and then to control pd by other means. is this possible? is there documentation somewhere showing how to do it? You don't you just start Pd with -nogui then it won't load the GUI? Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-meeting at LAC
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote: Since there are so many pd people at the Linux Audio Conference next week, should we make something like a developer meeting ? Great idea, though I won't be able to participate during LAC itself[1], and all of Graz is leaving on Sunday. :( Anyway, the final schedule for LAC is online now, so you can check when each of you is occupied. As far as I see - and as one of the two LAC organizers I probably see farther than most of you - Saturday afternoon probably will be the best time, as Miller is occupied all Friday afternoon with a workshop, while Thursday afternoon and Friday/Saturday morning some of you will do talks. I could arrange a discussion room to do the Pd meeting on Saturday. [1] My only larger wish regarding the topics Georg has mentioned would be to split off a pd-externals package from pd-extended for the Debs, but IOhannes probably will bring up many of by arguments for this himself. ;) Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] renaming /import to /vendor
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: Since the /import section is supposed to be for vendor branches AFAICT, I propose to rename it /vendor like the SVN book uses: http://svnbook.red-bean.com/en/1.1/ch07s05.html Any objections? No, that's cool. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] svn password
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: some svn clients (e.g. kdesvn) have an option relocate repository which will do this for you - but i guess internally these use find/sed too... It's also available in the standard svn client: $ svn swith --relocate FROM TO Btw. Do some of you still remember that tcl-script many of us used to change the repository URLs after SF changed their layout? That's built into svn already. ;) Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Protecting Pd-MAIN [was: Re: [PD] Problem in os x 10.5.1?]
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: Ah, how is that something that SF has to setup themselves?... I have never been admin on a SF.net project, so, I don't know, but wouldn't that only be about whether a web interface is available for handling the ACL ? What's the SVN equivalent of the CVSROOT directory? Read http://tinyurl.com/2hhcay Section: Permissions Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
