[PD] gallery section (Was:Re: [PD-announce] some works done with pd)
Please reply to pdweb to continue this discussion. On 29/07/2008, at 19.36, Hans-Christoph Steiner wrote: > This reminds me, we really need that gallery section on puredata.info > to show stuff like this off... It was so close to completion, anyone > want to take it live? First off, i'm the slack bus-hit someone that didn't complete the gallery (ie. the exhibition) section mentioned. I have been meaning to get back about it, but decided to not do it till i had more solid things to offer then ideas. Well, now i'll have to push in the ideas without the solid stuff. I'll be brief and leave out (most of) my reasons: * I think the exhibition section should be discarded. It has in parts been replaced by a goto10 project (that reach much wider in scope though) and more importantly - to put it diplomatically - the publishing scheme is not compatible with the target community. * There should instead be made weblog sync point for Pd related weblogs posts á la ProcessingBlogs. It should be simple to manage: Anyone wanting their Pd related weblogs posts to be in the common feed should supply a feed url with a "tag" for the Pd related posts in their feed. Either to a person doing the management (could be done in turns) or if possible through the IEM/Pd.info/plone-setup thing. * Also there should be a concise wiki page with examples of what could be done with Pd. People writing that would want to suppress there ego for a second and think about what newcomers would most- likely want to see when looking into what Pd is by what can be done in Pd. Also therefore it shouldn't seek all the outer limits but include stuff like a simple algo-composing and loop-sampler example. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] Pd-extended 0.40.3 released, dedicated to Jamie Tittle
Finally, it's done! The most polished release of Pd yet. We are further refining Pd into a truly powerful and usable programming platform. http://puredata.org/downloads/ This release is dedicated to Jamie Tittle, aka tigital, who recently died of cancer. He was a long time and key contributor to Gem and Pd in general, even while he was in the hospital undergoing treatment. He is sorely missed in this community, and I am sure by many others. Some highlights of this release: * more functional namespace tools ([declare] and [import]) * new appearance designed to enhance readability * GLSL shader support in Gem * usability improvements * on Mac OS X, you can now build "standalone" applications * standard locations for user-installed externals * many bug fixes Here's the rough changelog: - next visual appearance designed for readability - default locations for user-installed externals, helpfiles, etc. GNU/Linux: /usr/local/lib/pd-externals and ~/pd-externals Mac OS X: /Library/Pd and ~/Library/Pd Windows: %ProgramFiles%/Common Files/Pd and %UserProfile%/ Application Data/Pd - lots of standard key bindings added: Enter/Return for OK Escape for Cancel Ctrl/Cmd-W closes all windows on Mac OS X, Cmd-` cycles thru open windows on Mac OS X, Cmd-m minimizes windows Ctrl/Cmd-R raises/lowers Pd window Ctrl/Cmd-Shift-R shrinks/grows Pd window Ctrl/Cmd-Shift-L clears Pd window's text console Ctrl/Cmd-B opens the Help Browser - you can now use "~" in all paths to mean home folder, and on Windows you can use environment variables, lie %UserProfile% in paths - improved Cut/Copy/Paste support for working in object and message boxes - fixed Cut/Copy/Paste for the Pd window's console - [declare] and [import] now sorted out for loading (but much work needs to be done before there namespace support is complete) - "File -> Save As" defaults to the Home folder (~/) on Mac OSX - new patches default to the folder last saved in - included pgp_opengl aka 3dp on GNU/Linux and Mac OS X - 'hardware' and 'deprecated' removed from libraries loaded by default - On Debian/Ubuntu, the packages now install into /usr rather than / usr/local - On Mac OS X, you can now build "standalone" applications from the File menu. - bug fixes and clean up of [hid] and mapping externals - included config in Info.plist for the Spotlight Importer KNOWN BUGS - check http://puredata.info/dev/bugtracker before reporting bugs - Escape, Enter, and Ctrl/Cmd-W don't close the Path and Startup preferences - pdp_opengl is alpha and will definitely crash Pd - loading pdp_opengl will crash Pd if X11 is not open before trying to load it - the GUI runs slower in some situations All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ Pd-announce mailing list [EMAIL PROTECTED] http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
On Jul 29, 2008, at 4:29 PM, Matt Barber wrote: >> >>> When 0.39 begins to wane (so [declare] can be used), ... >> >> Careful here: [declare -path ...] is disabled inside of abstractions >> in Pd-0.41. >> > > > Right -- but [declare -path ...] is terribly useful for not having a > patch's main directory cluttered with 100 abstractions, which was the > main point... but since 0.39 is still widely in use I tend to avoid it > unless it's for patches I know only I am going to be running. I guess > it's okay to be conservative in some parts of life. =o) > > OT -- out of curiosity, if it were to be enabled within an > abstraction, would the -path be relative to the abstraction file or to > the patch in which it's instantiated? The relative path stuff seems to be a can of worms that is more trouble that it is worth, IMHO. But in order to make sure it doesn't make things more complicated, the path declared by [declare -path] would have to be same absolute path everywhere it is used. I think the simplest solution is to make the only option be loading libraries and setting the global search path. Then use a unified library format that is very easy to setup. That's the goal with libdir. .hc > > M > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-0.41-4 can't extract
Here's the checksum I just ran... $ sha1sum pd-0.41-4.mac.tar.gz f8bed34a8ab43dfe3fc270368ef41c61c398ecc6 pd-0.41-4.mac.tar.gz ... I should start publishing these, now that I finally found out how to make one :) M On Tue, Jul 29, 2008 at 02:10:00PM -0400, Enrique Erne wrote: > nobody on osx 10.5.4 except me? > > still got 22GB left.. > i just downloaded it again with a different browser. > > is there a md5 thingy around? > > eni > > > > Miller Puckette wrote: > >That's wierd... the only situation I can think of that could cause that > >would > >be a full disk. > > > >cheers > >Miller > > > >On Tue, Jul 29, 2008 at 05:42:07AM -0400, Enrique Erne wrote: > >>pd-0.41-4.mac.tar.gz from http://crca.ucsd.edu/~msp/software.html > >> > >>i get > >> > >>Could not extract the file "Pd-0.41-4.app/Contents": Could not create > >>the folder > >> > >>this is on i386 osx 10.5.4 the file is 5.5MB > >> > >>does anybody else have the same error? > >> > >>eni > >> > >>___ > >>Pd-list@iem.at mailing list > >>UNSUBSCRIBE and account-management -> > >>http://lists.puredata.info/listinfo/pd-list > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] call for 10gig+ disks for build farm
So the disk just died in the Windows XP build server. All the rest of the disks are quite old. I would like to replace the Windows XP build server and add disk mirroring on as many of the servers as possible. So, if anyone has any _working_ disks 10 gigs or bigger that are just sitting around taking up space, please send them my way to support the Pd auto-build farm. Then you'll get a lovely mention on the PdLab page and the undying gratitude of the community. http://puredata.info/docs/developer/PdLab .hc 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
> >> When 0.39 begins to wane (so [declare] can be used), ... > > Careful here: [declare -path ...] is disabled inside of abstractions > in Pd-0.41. > Right -- but [declare -path ...] is terribly useful for not having a patch's main directory cluttered with 100 abstractions, which was the main point... but since 0.39 is still widely in use I tend to avoid it unless it's for patches I know only I am going to be running. I guess it's okay to be conservative in some parts of life. =o) OT -- out of curiosity, if it were to be enabled within an abstraction, would the -path be relative to the abstraction file or to the patch in which it's instantiated? M ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
Hans-Christoph Steiner wrote: > On Jul 29, 2008, at 2:04 PM, Frank Barknecht wrote: >> I really cannot see where you got the impression that I'm squelching >> Luke's suggestion, when I briefly expressed a certain personal >> scepticism regarding style guides in two sentences of currently three >> much longer mails in this thread, which I considered to be >> constructive, >> at least as brainstorming fodder or to give some motivations on how >> and >> why my personal style evolved the way it did. > > From this sentence: > > "I'm not too much in favour of a style "guide" however. Let people be > creative." > > Maybe I overreacted. I think there is a lot of negative tone on this > list, I am sure I have contributed to that as well. I think we > should encourage people to try things more than telling them its > wrong before they have started. > > Or maybe I'm just a fucking hippie... "peace 'n' love dude!" Although I am more or less just a lurker on this list, and sometimes an asker of stupid questions, not to mention a person with too messy patches, I find the idea of a style guide very good, and here is my reasoning: As most of us Pd users think of Pd as a programming language, then Pd should have one or more style guides just as any other programming language, so other people's patches (read: source code) are easy to read to you. You do not need to have a definite style guide, just as there are several indent styles for functional programming languages, there may be several styles for Pd programming, but guidelines for newbies are a Good Thing (tm), as you can't teach an old dog new tricks. Just my two cents, Thomas -- "Prisons are needed only to provide the illusion that courts and police are effective. They're a kind of job insurance." (Leto II. in: Frank Herbert, God Emperor of Dune) http://thomas.dergrossebruder.org/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] font sizes WAS: Idiomatic Pd
>> >> If font sizes are indeed different on Pd-extended, then that's a bug. >> From all my tests, they are pixel-accurate on all three platforms since >> 0.39.3. You might have the problem where Tcl/Tk can't load the fonts >> properly on GNU/Linux, which is addressed in this FAQ: >> >> http://puredata.info/docs/faq/on-gnu-linux-the-fonts-are-strange-and- >> or-too-big-or-small >> >> Otherwise, if you are indeed seeing different font/pixel sizes with >> Pd-extended 0.40.3 then please file a bug report with as much detail as >> possible and an example patch. >> >> .hc > > hans, > I think matt was referring to font differences _on vanilla_ bet. different > platforms. and font differences bet pdx and vanilla. but english is not my > first language, maybe I am wrong... > marius. > That's right -- differences between vanilla on different platforms, and between vanilla and extended. The point is, it's hard to ensure things will line up with nice, clean, right angles in all cases. M ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
Actually, reading this thread for me has shown me that one idea that I have been using is a lot more common that I had thought. The idea of naming the receives on an object with an "r" at the end (or whatever) to distinguish it from the send was something that I wasn't really sure if it was a "Pd Idiom" or not, and I really had no idea how to ask a question about it... Mike On Tue, Jul 29, 2008 at 1:25 PM, marius schebella < [EMAIL PROTECTED]> wrote: > Hans-Christoph Steiner wrote: > > On Jul 29, 2008, at 1:31 AM, Frank Barknecht wrote: > > > >> Hallo, > >> Luke Iannini hat gesagt: // Luke Iannini wrote: > >> > >>> There are some amazing sets of abstractions being released recently, > >>> which has served to highlight the many extant styles of patching. I > >>> was wondering if there was interest in establishing a set of > >>> guidelines for patching in the vein of PEP 8 for Python; I've found > >>> that document to be very relaxing as it is a standardized approach to > >>> OCD. More seriously, it greatly helps when reading other people's > >>> code or collaborating. > >>> http://www.python.org/dev/peps/pep-0008/ > >> I think, it would be important to first collect every possible style > >> element in the wild and document what people are using in reality. > >> That would be interesting. I'm not too much in favour of a style > >> "guide" > >> however. Let people be creative. > > > > Nobody is talking about requirements. If you don't like style > > guides, don't use them. But it is really not useful to squelch other > > people's efforts, especially when you don't even have an intention of > > using this stuff. > > I actually liked frank's idea to collect different people's ideas and > compare them. maybe there is some common sense in all of them? > marius. > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
On Jul 29, 2008, at 2:25 PM, marius schebella wrote: > Hans-Christoph Steiner wrote: >> On Jul 29, 2008, at 1:31 AM, Frank Barknecht wrote: >>> Hallo, >>> Luke Iannini hat gesagt: // Luke Iannini wrote: >>> There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/ >>> I think, it would be important to first collect every possible style >>> element in the wild and document what people are using in reality. >>> That would be interesting. I'm not too much in favour of a style >>> "guide" >>> however. Let people be creative. >> Nobody is talking about requirements. If you don't like style >> guides, don't use them. But it is really not useful to squelch >> other people's efforts, especially when you don't even have an >> intention of using this stuff. > > I actually liked frank's idea to collect different people's ideas > and compare them. maybe there is some common sense in all of them? > marius. Yeah, I think that was Luke's idea from the beginning. I agree that it is a good one. .hc Access to computers should be unlimited and total. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
On Jul 29, 2008, at 2:04 PM, Frank Barknecht wrote: > Hallo, > Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > >> On Jul 29, 2008, at 1:31 AM, Frank Barknecht wrote: >>> I think, it would be important to first collect every possible style >>> element in the wild and document what people are using in reality. >>> That would be interesting. I'm not too much in favour of a style >>> "guide" >>> however. Let people be creative. >> >> Nobody is talking about requirements. If you don't like style >> guides, don't use them. But it is really not useful to squelch other >> people's efforts, especially when you don't even have an intention of >> using this stuff. > > I really cannot see where you got the impression that I'm squelching > Luke's suggestion, when I briefly expressed a certain personal > scepticism regarding style guides in two sentences of currently three > much longer mails in this thread, which I considered to be > constructive, > at least as brainstorming fodder or to give some motivations on how > and > why my personal style evolved the way it did. From this sentence: "I'm not too much in favour of a style "guide" however. Let people be creative." Maybe I overreacted. I think there is a lot of negative tone on this list, I am sure I have contributed to that as well. I think we should encourage people to try things more than telling them its wrong before they have started. Or maybe I'm just a fucking hippie... "peace 'n' love dude!" .hc > > Ciao > -- > Frank Barknecht > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Calling Mac OS X 10.3 Panther users! Please test new release!
On Jul 29, 2008, at 6:03 AM, Enrique Erne wrote: > Hans-Christoph Steiner wrote: >> Try this one: >> http://idmi.poly.edu/pdlab/Pd-0.40.3-extended-rc3/Pd-0.40.3- >> extended-rc3-macosx103-powerpc.dmg This rc3 build worked on 10.3, >> so it should be possible to make a final 10.3 release without too >> much work. >> .hc > > there was a typo in the link. this worked for me: > http://idmi.poly.edu/pdlab/Pd-0.40.3-extended-rc3-macosx103- > powerpc.dmg > > > > looks good now! Pd opens. > > zexy (and <~), maxlib, t3_lib are ok. > > matrix can't create but iemmatrix/matrix does > (note: with rc4 [matrix] works) > > Gem, PDP, and Pidip seem to not do well. Ok, could you try this one: http://autobuild.puredata.info/auto-build/2008-07-29/Pd-0.40.3- extended-macosx103.dmg I know Gem won't work, I'll fix that later, but please test the rest. .hc > > eni > > > > > > > libdir loader $Revision: 1.8 $ > written by Hans-Christoph Steiner <[EMAIL PROTECTED]> > compiled on Jul 1 2008 at 04:02:40 > compiled against Pd version 0.40.3.extended-20080701 > hex loader $Revision: 1.5 $ > written by IOhannes m zmölnig, IEM <[EMAIL PROTECTED]> > compiled on Jul 1 2008 at 04:02:41 > compiled against Pd version 0.40.3.extended-20080701 > /Applications/Pd-extended.app/Contents/Resources/extra/Gem.pd_darwin: > dlcompat: dyld: > /Applications/Pd-extended.app/Contents/Resources/Scripts/../bin/pd > can't open library: /usr/X11R6/lib/libfreetype.6.dylib (No such file > or directory, errno = 2) > > /Applications/Pd-extended.app/Contents/Resources/extra/Gem.pd_darwin: > dlcompat: dyld: > /Applications/Pd-extended.app/Contents/Resources/Scripts/../bin/pd > can't open library: /usr/X11R6/lib/libfreetype.6.dylib (No such file > or directory, errno = 2) > > Gem: can't load library > libdir_loader: added 'cyclone' to the global objectclass path > libdir_loader: added 'zexy' to the global objectclass path > libdir_loader: added 'creb' to the global objectclass path > libdir_loader: added 'cxc' to the global objectclass path > libdir_loader: added 'iemlib' to the global objectclass path > libdir_loader: added 'list-abs' to the global objectclass path > libdir_loader: added 'mapping' to the global objectclass path > libdir_loader: added 'markex' to the global objectclass path > libdir_loader: added 'maxlib' to the global objectclass path > libdir_loader: added 'memento' to the global objectclass path > libdir_loader: added 'mjlib' to the global objectclass path > libdir_loader: added 'motex' to the global objectclass path > libdir_loader: added 'oscx' to the global objectclass path > libdir_loader: added 'pddp' to the global objectclass path > libdir_loader: added 'pdogg' to the global objectclass path > libdir_loader: added 'pixeltango' to the global objectclass path > libdir_loader: added 'pmpd' to the global objectclass path > libdir_loader: added 'rradical' to the global objectclass path > libdir_loader: added 'sigpack' to the global objectclass path > libdir_loader: added 'smlib' to the global objectclass path > libdir_loader: added 'toxy' to the global objectclass path > libdir_loader: added 'unauthorized' to the global objectclass path > libdir_loader: added 'pan' to the global objectclass path > libdir_loader: added 'freeverb' to the global objectclass path > libdir_loader: added 'hcs' to the global objectclass path > libdir_loader: added 'jmmmp' to the global objectclass path > libdir_loader: added 'ext13' to the global objectclass path > libdir_loader: added 'ggee' to the global objectclass path > libdir_loader: added 'flib' to the global objectclass path > libdir_loader: added 'ekext' to the global objectclass path > libdir_loader: added 'flatspace' to the global objectclass path > /Applications/Pd-extended.app/Contents/Resources/extra/pdp.pd_darwin: > dlcompat: dyld: > /Applications/Pd-extended.app/Contents/Resources/Scripts/../bin/pd > can't open library: /usr/X11R6/lib/libX11.6.dylib (No such file or > directory, errno = 2) > > /Applications/Pd-extended.app/Contents/Resources/extra/pdp.pd_darwin: > dlcompat: dyld: > /Applications/Pd-extended.app/Contents/Resources/Scripts/../bin/pd > can't open library: /usr/X11R6/lib/libX11.6.dylib (No such file or > directory, errno = 2) > > pdp: can't load library > /Applications/Pd-extended.app/Contents/Resources/extra/ > pidip.pd_darwin: > dlcompat: dyld: > /Applications/Pd-extended.app/Contents/Resources/Scripts/../bin/pd > can't open library: /usr/X11R6/lib/libX11.6.dylib (No such file or > directory, errno = 2) > > /Applications/Pd-extended.app/Contents/Resources/extra/ > pidip.pd_darwin: > dlcompat: dyld: > /Applications/Pd-extended.app/Contents/Resources/Scripts/../bin/pd > can't open library: /usr/X11R6/lib/libX11.6.dylib (No such file or > directory, errno = 2) > > pidip: can't load library Terrorism is not an enemy. It cannot be defeated. It's a ta
Re: [PD] Idiomatic Pd
Hans-Christoph Steiner wrote: > On Jul 29, 2008, at 1:31 AM, Frank Barknecht wrote: > >> Hallo, >> Luke Iannini hat gesagt: // Luke Iannini wrote: >> >>> There are some amazing sets of abstractions being released recently, >>> which has served to highlight the many extant styles of patching. I >>> was wondering if there was interest in establishing a set of >>> guidelines for patching in the vein of PEP 8 for Python; I've found >>> that document to be very relaxing as it is a standardized approach to >>> OCD. More seriously, it greatly helps when reading other people's >>> code or collaborating. >>> http://www.python.org/dev/peps/pep-0008/ >> I think, it would be important to first collect every possible style >> element in the wild and document what people are using in reality. >> That would be interesting. I'm not too much in favour of a style >> "guide" >> however. Let people be creative. > > Nobody is talking about requirements. If you don't like style > guides, don't use them. But it is really not useful to squelch other > people's efforts, especially when you don't even have an intention of > using this stuff. I actually liked frank's idea to collect different people's ideas and compare them. maybe there is some common sense in all of them? marius. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] font sizes WAS: Idiomatic Pd
Hans-Christoph Steiner wrote: > On Jul 29, 2008, at 10:29 AM, Matt Barber wrote: > >>> Date: Tue, 29 Jul 2008 10:02:05 -0400 >>> From: marius schebella <[EMAIL PROTECTED]> >>> Subject: Re: [PD] Idiomatic Pd >>> To: pd-list@iem.at >>> Message-ID: <[EMAIL PROTECTED]> >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> >>> I am quite pedantic in regard to spacing and aligning of objects. I >>> started to space all objects using ctrl+arrow keys. that way all >>> objects >>> are spaced like on a grid and always a multiple of 10px away of >>> each other. >>> I don't know if that should go into a style guide, but for "official" >>> patches like tutorials it could be considered. >> Yes, I am this way too -- but with font sizes sometimes being >> different from one platform to the next, and even between extended and >> vanilla, it's really hard to ensure that things will line up sweetly >> every time you open it, everywhere. > > If font sizes are indeed different on Pd-extended, then that's a > bug. From all my tests, they are pixel-accurate on all three > platforms since 0.39.3. You might have the problem where Tcl/Tk > can't load the fonts properly on GNU/Linux, which is addressed in > this FAQ: > > http://puredata.info/docs/faq/on-gnu-linux-the-fonts-are-strange-and- > or-too-big-or-small > > Otherwise, if you are indeed seeing different font/pixel sizes with > Pd-extended 0.40.3 then please file a bug report with as much detail > as possible and an example patch. > > .hc hans, I think matt was referring to font differences _on vanilla_ bet. different platforms. and font differences bet pdx and vanilla. but english is not my first language, maybe I am wrong... marius. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-0.41-4 can't extract
Enrique Erne wrote: > nobody on osx 10.5.4 except me? I just downloaded it and had no problems extracting. maybe your account is monitored and nsa swapped some bits during listening... marius. > > still got 22GB left.. > i just downloaded it again with a different browser. > > is there a md5 thingy around? > > eni > > > > Miller Puckette wrote: >> That's wierd... the only situation I can think of that could cause that would >> be a full disk. >> >> cheers >> Miller >> >> On Tue, Jul 29, 2008 at 05:42:07AM -0400, Enrique Erne wrote: >>> pd-0.41-4.mac.tar.gz from http://crca.ucsd.edu/~msp/software.html >>> >>> i get >>> >>> Could not extract the file "Pd-0.41-4.app/Contents": Could not create >>> the folder >>> >>> this is on i386 osx 10.5.4 the file is 5.5MB >>> >>> does anybody else have the same error? >>> >>> eni >>> >>> ___ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-0.41-4 can't extract
nobody on osx 10.5.4 except me? still got 22GB left.. i just downloaded it again with a different browser. is there a md5 thingy around? eni Miller Puckette wrote: > That's wierd... the only situation I can think of that could cause that would > be a full disk. > > cheers > Miller > > On Tue, Jul 29, 2008 at 05:42:07AM -0400, Enrique Erne wrote: >> pd-0.41-4.mac.tar.gz from http://crca.ucsd.edu/~msp/software.html >> >> i get >> >> Could not extract the file "Pd-0.41-4.app/Contents": Could not create >> the folder >> >> this is on i386 osx 10.5.4 the file is 5.5MB >> >> does anybody else have the same error? >> >> eni >> >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > On Jul 29, 2008, at 1:31 AM, Frank Barknecht wrote: > >I think, it would be important to first collect every possible style > >element in the wild and document what people are using in reality. > >That would be interesting. I'm not too much in favour of a style > >"guide" > >however. Let people be creative. > > Nobody is talking about requirements. If you don't like style > guides, don't use them. But it is really not useful to squelch other > people's efforts, especially when you don't even have an intention of > using this stuff. I really cannot see where you got the impression that I'm squelching Luke's suggestion, when I briefly expressed a certain personal scepticism regarding style guides in two sentences of currently three much longer mails in this thread, which I considered to be constructive, at least as brainstorming fodder or to give some motivations on how and why my personal style evolved the way it did. Ciao -- Frank Barknecht ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] some works done with pd
This reminds me, we really need that gallery section on puredata.info to show stuff like this off... It was so close to completion, anyone want to take it live? .hc On Jul 28, 2008, at 4:23 PM, ||| wrote: > WOW - that stuff is beautiful!! > espezially this one is great: > http://drpichon.free.fr/ch/article.php?id_article=80 > > i'm sorry i don't speak french, so i can't understand the describing > text - could you explain me what it's about? > > thank you very much, > > emanuel > > > > On Jul 25, 2008, at 8:38 PM, cyrille henry wrote: > >> hello, >> >> for those which are interested, here is some work that i recently >> made with pd/Gem : >> >> http://drpichon.free.fr/ch/article.php?id_article=88 >> >> http://drpichon.free.fr/ch/article.php?id_article=80 >> >> http://drpichon.free.fr/ch/article.php?id_article=76 >> >> http://drpichon.free.fr/ch/article.php?id_article=95 >> >> http://drpichon.free.fr/ch/article.php?id_article=94 >> >> http://drpichon.free.fr/ch/article.php?id_article=89 >> >> >> Cyrille >> >> ___ >> Pd-announce mailing list >> [EMAIL PROTECTED] >> http://lists.puredata.info/listinfo/pd-announce > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
Can I suggest using the MoinMoin wiki syntax? IMHO the python wikis all have weak syntax compared to MediaWiki, but MoinMoin is the closest to MediaWiki, which is a widely used and relatively easy to use syntax. It is also what is used in most of the rest of the 'docs' section. To use MoinMoin, the page has to be a "wiki page". A regular Plone "page" doesn't allow it for some reason. Also, to make an index page for that folder, create a page called "FrontPage" or "index_html" IIRC. I think that would be a good place to lay out all of the things that are relevant to the style guide, like a survey of programming elements. Then people can make their own style pages for things that are a matter of opinion. And hopefully at the end, we can come up with something unified. .hc On Jul 29, 2008, at 2:30 AM, Luke Iannini wrote: > Okay, here it is: > http://puredata.info/docs/style-guide > > On Mon, Jul 28, 2008 at 1:39 PM, Hans-Christoph Steiner > <[EMAIL PROTECTED]> wrote: >> >> I think a style guide is a great idea. There have been some >> discussions along these lines in the past. I'd say just start a >> "wiki folder" on puredata.info in the /docs/ section and edit it up. >> Something like /docs/style-guide/ I think that the main page could >> lay out all of the possible realms of style, like dollar arguments, >> abstractions, subpatches, inlets/outlets, trigger, etc. Then the >> next step people can create sub-pages that outline all of their >> styles. Then ultimately, things would be organized into a single >> style-guide. > >> .hc >> >> On Jul 27, 2008, at 9:34 PM, Luke Iannini wrote: >> >>> There are some amazing sets of abstractions being released recently, >>> which has served to highlight the many extant styles of patching. I >>> was wondering if there was interest in establishing a set of >>> guidelines for patching in the vein of PEP 8 for Python; I've found >>> that document to be very relaxing as it is a standardized >>> approach to >>> OCD. More seriously, it greatly helps when reading other people's >>> code or collaborating. >>> http://www.python.org/dev/peps/pep-0008/ >>> >>> The only one I have seen so far for Pd covers best practices for >>> layout. I'd want to include that, but also codify naming, >>> arguments, >>> common idioms, and so on. >>> >>> I've begun to collect some of my practices to start things off. >>> I was >>> hoping we could all lazy-vote the document together in this >>> thread and >>> I'll then compile it into a PdPedia/Pd.info document. So, feel free >>> to object to or replace my propositions. >>> >>> Style: >>> * If giving $0 as an argument to an abstraction, it is always >>> first in >>> the argument list [1] >>> * * When possible, pass parent arguments in numeric order, like >>> [child >>> $0 $1 $2 other1 other2] etc. >>> * Sends and Receives are written in camelCase, with "R" appended to >>> complementary receives (e.g. in GUIs, $0mySlider for the send and >>> $0mySliderR for the receive) >>> * When prepending $0 to a symbol, only add a "-" to separate it from >>> another number, like [r $0-1stSend]. Otherwise the symbol should >>> immediately follow, like [r $0mySend]. >>> * When working with stereo, Left and Right pairs are written with Le >>> and Ri appended (to distinguish them from an R denoting "receive", >>> above) >>> >>> Programming recommendations >>> * To invert a toggle, use [== 0] >>> * Use the loadbang of the parent of both abstractions to initialize >>> two or more interdependent abstractions >>> >>> [1] I think of this like emulating the "self" convention in Python >>> >>> And so on... >>> Cheers >>> Luke >>> >>> ___ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ >>> listinfo/pd-list >> >> >> >> - >> --- >> >> >> Terrorism is not an enemy. It cannot be defeated. It's a tactic. >> It's about as sensible to say we declare war on night attacks and >> expect we're going to win that war. We're not going to win the war >> on terrorism.- retired U.S. Army general, William Odom >> >> >> >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ >> listinfo/pd-list >> > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.pure
[PD] font sizes WAS: Idiomatic Pd
On Jul 29, 2008, at 10:29 AM, Matt Barber wrote: >> Date: Tue, 29 Jul 2008 10:02:05 -0400 >> From: marius schebella <[EMAIL PROTECTED]> >> Subject: Re: [PD] Idiomatic Pd >> To: pd-list@iem.at >> Message-ID: <[EMAIL PROTECTED]> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> I am quite pedantic in regard to spacing and aligning of objects. I >> started to space all objects using ctrl+arrow keys. that way all >> objects >> are spaced like on a grid and always a multiple of 10px away of >> each other. >> I don't know if that should go into a style guide, but for "official" >> patches like tutorials it could be considered. > > Yes, I am this way too -- but with font sizes sometimes being > different from one platform to the next, and even between extended and > vanilla, it's really hard to ensure that things will line up sweetly > every time you open it, everywhere. If font sizes are indeed different on Pd-extended, then that's a bug. From all my tests, they are pixel-accurate on all three platforms since 0.39.3. You might have the problem where Tcl/Tk can't load the fonts properly on GNU/Linux, which is addressed in this FAQ: http://puredata.info/docs/faq/on-gnu-linux-the-fonts-are-strange-and- or-too-big-or-small Otherwise, if you are indeed seeing different font/pixel sizes with Pd-extended 0.40.3 then please file a bug report with as much detail as possible and an example patch. .hc >> If I work on big patches that run as installations (no interface) the >> parent patch is basically empty, it only shows piece information and >> credits, everything is in a subpatch called [MACHINE]. and that >> usually >> is more a visual representation of the space (according to >> positioning >> of sensors/speakers) or a basic overview of the patch structure >> with an >> short explanation of what the different subpatches are doing. >> even, if everybody says, pd patches are their own documentation, >> because >> everything is visible, that's not true, commenting should be an >> important part of patching (cyclone's comment allow differnt fonts, >> sizes, colors and width of comments). > > This is a good point. In fact, for some patches e.g. for interactive > pieces to be sent to musicians who don't do Pd for a living -- =o) -- > I prefer to put everything in a subpatch which has a GOP control > surface. I think it's productive to petition against the "spider web" > style, but even too many objects and connections on the main patch > seems wasteful somehow. It's nice to include a subpatch which can be > opened with a bng, that is basically a readme. I do this for > abstractions, too, but without the bng -- just something to describe > how it works inside the patch itself, I suppose as a quick substitute > for a help file. > > Most of this is really personal, though, and I don't think it should > be codified. > > > > >> then, for patches that rely on abstractions, *maybe* it would be >> good to >> give them either unique names or put them into subfolders. (I have to >> say, I do not really stick with this rule. but at least one thing: >> the >> main patch should always be recognizable, I usually put it in capital >> letters, so that people know, which patch to start. >> >> resources (images, textfiles, data) could be kept in a subfolder, >> too. >> (just think of the GEM examples, how often one of the images or >> videos >> can not be found. - at least in the past). > > > Abstractions, whenever possible I think, should try not to conflict > with names in extended, even when the patch is designed for vanilla. > Also, I think it's helpful to include tilde in abstraction names when > audio signals are involved. > > When 0.39 begins to wane (so [declare] can be used), it might be > productive to keep abstractions in subfolders, and possibly control in > one and tilde in another. Same, as you suggest, with textfiles, > qlists, images, and soundfiles. This way the main patch is there > cleanly for anyone who might need to use the patch besides you, and > especially nice for musicians. > > Again, not essential, but ergonomic. > > Matt > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
On Jul 29, 2008, at 1:31 AM, Frank Barknecht wrote: > Hallo, > Luke Iannini hat gesagt: // Luke Iannini wrote: > >> There are some amazing sets of abstractions being released recently, >> which has served to highlight the many extant styles of patching. I >> was wondering if there was interest in establishing a set of >> guidelines for patching in the vein of PEP 8 for Python; I've found >> that document to be very relaxing as it is a standardized approach to >> OCD. More seriously, it greatly helps when reading other people's >> code or collaborating. >> http://www.python.org/dev/peps/pep-0008/ > > I think, it would be important to first collect every possible style > element in the wild and document what people are using in reality. > That would be interesting. I'm not too much in favour of a style > "guide" > however. Let people be creative. Nobody is talking about requirements. If you don't like style guides, don't use them. But it is really not useful to squelch other people's efforts, especially when you don't even have an intention of using this stuff. >> >> I've begun to collect some of my practices to start things off. > > I added where I do things different. > >> I was >> hoping we could all lazy-vote the document together in this thread >> and >> I'll then compile it into a PdPedia/Pd.info document. So, feel free >> to object to or replace my propositions. >> >> Style: >> * If giving $0 as an argument to an abstraction, it is always >> first in >> the argument list [1] > > I often put it last (and it's specified to be that way e.g. in > Memento) > >> * * When possible, pass parent arguments in numeric order, like >> [child >> $0 $1 $2 other1 other2] etc. >> * Sends and Receives are written in camelCase, with "R" appended to >> complementary receives (e.g. in GUIs, $0mySlider for the send and >> $0mySliderR for the receive) > > I use the underscore style sometimes but often a simple "dash" style: > "r some-thing" instead of camelCase. My reason: It doesn't need any > Shift-key-combinations on German keyboards, and I find camelCase hard > to read. > > When I want to name matching send/receive pairs I use $0-some-s and > $0-some-r. > >> * When prepending $0 to a symbol, only add a "-" to separate it from >> another number, like [r $0-1stSend]. Otherwise the symbol should >> immediately follow, like [r $0mySend]. > > I always seperate $0 with a $0-dash. $0myGod is easy to misunderstand. > >> * When working with stereo, Left and Right pairs are written with Le >> and Ri appended (to distinguish them from an R denoting "receive", >> above) > > Nice idea. I never did that, though. I like the idea of standard labels, but I find unix-isms hard to remember. Why not just use the whole word? Code is read far more than it is written. It takes a trivial amount of time to type 'right' vs 'ri', it will take a lot longer for people to figure out what "Ri" means if they don't know or have forgotten (like I undoubted will). .hc > > Ciao > -- > Frank Barknecht _ > __footils.org__ > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-0.41-4 can't extract
That's wierd... the only situation I can think of that could cause that would be a full disk. cheers Miller On Tue, Jul 29, 2008 at 05:42:07AM -0400, Enrique Erne wrote: > pd-0.41-4.mac.tar.gz from http://crca.ucsd.edu/~msp/software.html > > i get > > Could not extract the file "Pd-0.41-4.app/Contents": Could not create > the folder > > this is on i386 osx 10.5.4 the file is 5.5MB > > does anybody else have the same error? > > eni > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-0.41-4 can't extract
Works fine for me on Mac OS X 10.4.11/Intel. .hc On Jul 29, 2008, at 5:42 AM, Enrique Erne wrote: > pd-0.41-4.mac.tar.gz from http://crca.ucsd.edu/~msp/software.html > > i get > > Could not extract the file "Pd-0.41-4.app/Contents": Could not create > the folder > > this is on i386 osx 10.5.4 the file is 5.5MB > > does anybody else have the same error? > > eni > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
> Abstractions, whenever possible I think, should try not to conflict > with names in extended, even when the patch is designed for vanilla. > Also, I think it's helpful to include tilde in abstraction names when > audio signals are involved. > Also, I forgot to mention that I think abstractions (and maybe to a lesser extent subpatches) should follow the right-to-left conventions of Pd objects for input/output, even if it complicates layout on the parent. So for instance [gate] from cyclone is bad Pd style, IMO, and an abstraction designed to mimic it ([gator], say) should be set up more like a multi-outlet [spigot]. Even [timer] still bothers me, but I guess it's a special case. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
Hallo, Matt Barber hat gesagt: // Matt Barber wrote: > Yes, I am this way too -- but with font sizes sometimes being > different from one platform to the next, and even between extended and > vanilla, it's really hard to ensure that things will line up sweetly > every time you open it, everywhere. A lot can be had with at least left-aligning connected objects. You get a clean left side, which is the important side of most Pd objects because of the hot inlet there. Then even if something like the "a"s in your [t b a a a a] aren't aligned anymore because of platform/version issues, you still have the clear layout of the main logic flow to the left. It's also good to leave a bit more room to the right of objects and comments to avoid overlapping boxes. I think, Pd-extended runs quite a bit narrower than Pd-vanilla with a 10px font on Linux, which is what I use. (I'm guilty of not leaving enough room to the right myself, though.) > When 0.39 begins to wane (so [declare] can be used), ... Careful here: [declare -path ...] is disabled inside of abstractions in Pd-0.41. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
> Date: Tue, 29 Jul 2008 10:02:05 -0400 > From: marius schebella <[EMAIL PROTECTED]> > Subject: Re: [PD] Idiomatic Pd > To: pd-list@iem.at > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I am quite pedantic in regard to spacing and aligning of objects. I > started to space all objects using ctrl+arrow keys. that way all objects > are spaced like on a grid and always a multiple of 10px away of each other. > I don't know if that should go into a style guide, but for "official" > patches like tutorials it could be considered. Yes, I am this way too -- but with font sizes sometimes being different from one platform to the next, and even between extended and vanilla, it's really hard to ensure that things will line up sweetly every time you open it, everywhere. > If I work on big patches that run as installations (no interface) the > parent patch is basically empty, it only shows piece information and > credits, everything is in a subpatch called [MACHINE]. and that usually > is more a visual representation of the space (according to positioning > of sensors/speakers) or a basic overview of the patch structure with an > short explanation of what the different subpatches are doing. > even, if everybody says, pd patches are their own documentation, because > everything is visible, that's not true, commenting should be an > important part of patching (cyclone's comment allow differnt fonts, > sizes, colors and width of comments). This is a good point. In fact, for some patches e.g. for interactive pieces to be sent to musicians who don't do Pd for a living -- =o) -- I prefer to put everything in a subpatch which has a GOP control surface. I think it's productive to petition against the "spider web" style, but even too many objects and connections on the main patch seems wasteful somehow. It's nice to include a subpatch which can be opened with a bng, that is basically a readme. I do this for abstractions, too, but without the bng -- just something to describe how it works inside the patch itself, I suppose as a quick substitute for a help file. Most of this is really personal, though, and I don't think it should be codified. > then, for patches that rely on abstractions, *maybe* it would be good to > give them either unique names or put them into subfolders. (I have to > say, I do not really stick with this rule. but at least one thing: the > main patch should always be recognizable, I usually put it in capital > letters, so that people know, which patch to start. > > resources (images, textfiles, data) could be kept in a subfolder, too. > (just think of the GEM examples, how often one of the images or videos > can not be found. - at least in the past). Abstractions, whenever possible I think, should try not to conflict with names in extended, even when the patch is designed for vanilla. Also, I think it's helpful to include tilde in abstraction names when audio signals are involved. When 0.39 begins to wane (so [declare] can be used), it might be productive to keep abstractions in subfolders, and possibly control in one and tilde in another. Same, as you suggest, with textfiles, qlists, images, and soundfiles. This way the main patch is there cleanly for anyone who might need to use the patch besides you, and especially nice for musicians. Again, not essential, but ergonomic. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
I am quite pedantic in regard to spacing and aligning of objects. I started to space all objects using ctrl+arrow keys. that way all objects are spaced like on a grid and always a multiple of 10px away of each other. I don't know if that should go into a style guide, but for "official" patches like tutorials it could be considered. It is almost not possible for me to look at the montreal abstractions... I also want to point out the importance of good grouping. sometimes I use bg canvases to underline that certain objects belong together (do some transformation or algorithm). If I work on big patches that run as installations (no interface) the parent patch is basically empty, it only shows piece information and credits, everything is in a subpatch called [MACHINE]. and that usually is more a visual representation of the space (according to positioning of sensors/speakers) or a basic overview of the patch structure with an short explanation of what the different subpatches are doing. even, if everybody says, pd patches are their own documentation, because everything is visible, that's not true, commenting should be an important part of patching (cyclone's comment allow differnt fonts, sizes, colors and width of comments). some things are important for patches that should be portable. please mention, which libraries are used, and consider to use declare to load the objects. do not store patches with position <0/0. some window managers will not allow to drag the patch window around. (oh, and please don't place objects outside the canvas and esp. not <0/0, having to scroll to the left to see the beginning of a patch can cause heart attack). and not all people have widescreen monitors or hi-res monitors, so I think 1024 should be the maximum width of a patch. then, for patches that rely on abstractions, *maybe* it would be good to give them either unique names or put them into subfolders. (I have to say, I do not really stick with this rule. but at least one thing: the main patch should always be recognizable, I usually put it in capital letters, so that people know, which patch to start. resources (images, textfiles, data) could be kept in a subfolder, too. (just think of the GEM examples, how often one of the images or videos can not be found. - at least in the past). I don't care about send and receive naming conventions( - _ / camelCase), as long as they are unique ($0). more later. marius. Luke Iannini wrote: > There are some amazing sets of abstractions being released recently, > which has served to highlight the many extant styles of patching. I > was wondering if there was interest in establishing a set of > guidelines for patching in the vein of PEP 8 for Python; I've found > that document to be very relaxing as it is a standardized approach to > OCD. More seriously, it greatly helps when reading other people's > code or collaborating. > http://www.python.org/dev/peps/pep-0008/ > > The only one I have seen so far for Pd covers best practices for > layout. I'd want to include that, but also codify naming, arguments, > common idioms, and so on. > > I've begun to collect some of my practices to start things off. I was > hoping we could all lazy-vote the document together in this thread and > I'll then compile it into a PdPedia/Pd.info document. So, feel free > to object to or replace my propositions. > > Style: > * If giving $0 as an argument to an abstraction, it is always first in > the argument list [1] > * * When possible, pass parent arguments in numeric order, like [child > $0 $1 $2 other1 other2] etc. > * Sends and Receives are written in camelCase, with "R" appended to > complementary receives (e.g. in GUIs, $0mySlider for the send and > $0mySliderR for the receive) > * When prepending $0 to a symbol, only add a "-" to separate it from > another number, like [r $0-1stSend]. Otherwise the symbol should > immediately follow, like [r $0mySend]. > * When working with stereo, Left and Right pairs are written with Le > and Ri appended (to distinguish them from an R denoting "receive", > above) > > Programming recommendations > * To invert a toggle, use [== 0] > * Use the loadbang of the parent of both abstractions to initialize > two or more interdependent abstractions > > [1] I think of this like emulating the "self" convention in Python > > And so on... > Cheers > Luke > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] New sssad.pd now in SVN repository - please test! [was: sssad slowness]
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: > In the near future there will be some more SSSAD_ADMIN messages I'd > like to support: "setlocal" and "savelocal" to save to receivers > called "$2-SSSAD_ADMIN" where $2 will usually be the parent's $0, to > allow saving of all/some [sssad]s with canvas-local scope. Okay, the future is here: I took a different approach after looking though my old notes to make it possible to use [sssad] for local parameter saving and loading Attached [sssad-l] is compatible to normal [sssad] (but requires at a Pd with $1-$2 expansion). What's new: It also accepts a second argument which should be a number (designed for $0). If this number is 0 or missing, everything is as before. If $2 is different from 0, the global senders and receivers SSSAD and SSSAD_ADMIN are *deactivated* completely and replaced by $2-SSSAD and $2-SSSAD_ADMIN. sssad-l-test.pd includes some tests for this and also an example, how this change can be used for local parameter handling. Comments welcome. Ciao -- Frank Barknecht _ __footils.org__ sssad-l-test.pd Description: application/puredata sssad-l.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
Hi Luke Luke Iannini wrote: > There are some amazing sets of abstractions being released recently, > which has served to highlight the many extant styles of patching. I > was wondering if there was interest in establishing a set of > guidelines for patching in the vein of PEP 8 for Python; I've found > that document to be very relaxing as it is a standardized approach to > OCD. More seriously, it greatly helps when reading other people's > code or collaborating. > http://www.python.org/dev/peps/pep-0008/ > > The only one I have seen so far for Pd covers best practices for > layout. I'd want to include that, but also codify naming, arguments, > common idioms, and so on. > > I've begun to collect some of my practices to start things off. I was > hoping we could all lazy-vote the document together in this thread and > I'll then compile it into a PdPedia/Pd.info document. So, feel free > to object to or replace my propositions. > > Style: > * If giving $0 as an argument to an abstraction, it is always first in > the argument list [1] > * * When possible, pass parent arguments in numeric order, like [child > $0 $1 $2 other1 other2] etc. > * Sends and Receives are written in camelCase, with "R" appended to > complementary receives (e.g. in GUIs, $0mySlider for the send and > $0mySliderR for the receive) > * When prepending $0 to a symbol, only add a "-" to separate it from > another number, like [r $0-1stSend]. Otherwise the symbol should > immediately follow, like [r $0mySend]. i arbitrary use ".", "-" and "_" . IMO a separator in a send/receive name is needed when you use a dollar, and i would welcome a guideline, especially if there is a certification and quality brand for pd-patches :) but there are so many styles and i don't even know which way to declare an external. now a bit personal: i don't like $0 :) . It's fine for a namespace within a patch, but I found myself often needing to access something from "outside" so i have to pass $0 around, which is ugly. I much more prefer a global receiver and route everything. so i pass the name of my patch to it's abstractions. abstracions get global receiver with $1 in it which is the motherpatchname. it helps for orientation i.e. look at the window title: yourabstraction.pd (mother) isn't it better than: yourabstraction.pd (1284) you can even use it for [sssad $1/vol] without having the $0 making your sssad key into a unusable name. If I have GUI inside the GOP each sliders send and receive name begin with $1. or $1- or $1_ (guideline please!), that makes it possible to hijack the patch from an other patch. Like the midilearn or automator patch can control any slider in this setup. Franks recommendation UPPERCASE for globals is really neat. For GUI elements like sliders I've never regret to use a kind of name hierarchy ($1.vol), usually mypatch-myabs-myparameter or mypatch.myabs.myparameter or mypatch_myabs_myparameter or whatever. so you can hijack your channel aux-sender with anything. but that means you can't open a patch multiple times, no problem for me because i reuse code always with abstractions. does somebody run 1 patch multiple times? (sounds like fun would you mind and share?) i look forward to the lazy-vote :) eni > * When working with stereo, Left and Right pairs are written with Le > and Ri appended (to distinguish them from an R denoting "receive", > above) > > Programming recommendations > * To invert a toggle, use [== 0] > * Use the loadbang of the parent of both abstractions to initialize > two or more interdependent abstractions > > [1] I think of this like emulating the "self" convention in Python > Programming recommendations always use [trigger] for 1tomany connections ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] New sssad.pd now in SVN repository - please test! [was: sssad slowness]
Hallo Enrique, Enrique Erne hat gesagt: // Enrique Erne wrote: > That looks great. hehe, I already committed it. ;) > Still, personally I will initialize all keys, this > guarantees to always have complete presets. > > [loadbang] > | > [; > SSSAD vol 20, freq 42, other 1.2345( Yes, that's probably good practice. > Basically i would like it if there was a possibility to let some SSSAD > instances in a new patch output the value. Attached SSSAD has a possible > solution. ... > case 4) ___ > > [loadbang] > | > [; > SSSAD vol 0.5, vol bang( > > [sssad vol] > / > [*~] > > > How about something like that? [SSSAD vol bang( could be used to specify > one key to output it's value. One more [route bang] would be required. > > One could argue [SSSAD vol bang( should delete the value, but i can't > think of a use of having a key without value. Hm, maybe it could be nice to at least have the possibility to reset a key, and the "SSSAD"-receiver kind of represents the right, cold inlet. I tend to think of [sssad] like a variant of [list] and [value]. OTOH the syntax "SSSAD vol 0.5, vol bang" looks nice. Attached is a different approach for comparison: Here I introduced two new messages for SSSAD_ADMIN: "setonly KEY" and "saveonly KEY". It may be cleaner to reuse the original messages and check if the user supplied a specific key: "set KEY" to only set this key, but I didn't manage to patch this (in a clean and simple way) that quick. In the near future there will be some more SSSAD_ADMIN messages I'd like to support: "setlocal" and "savelocal" to save to receivers called "$2-SSSAD_ADMIN" where $2 will usually be the parent's $0, to allow saving of all/some [sssad]s with canvas-local scope. Ciao -- Frank Barknecht _ __footils.org__ sssad.pd Description: application/puredata sssad-initandsave.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Calling Mac OS X 10.3 Panther users! Please test new release!
Hans-Christoph Steiner wrote: > > Try this one: > > http://idmi.poly.edu/pdlab/Pd-0.40.3-extended-rc3/Pd-0.40.3-extended-rc3-macosx103-powerpc.dmg > > > > This rc3 build worked on 10.3, so it should be possible to make a final > 10.3 release without too much work. > > .hc > there was a typo in the link. this worked for me: http://idmi.poly.edu/pdlab/Pd-0.40.3-extended-rc3-macosx103-powerpc.dmg looks good now! Pd opens. zexy (and <~), maxlib, t3_lib are ok. matrix can't create but iemmatrix/matrix does (note: with rc4 [matrix] works) Gem, PDP, and Pidip seem to not do well. eni libdir loader $Revision: 1.8 $ written by Hans-Christoph Steiner <[EMAIL PROTECTED]> compiled on Jul 1 2008 at 04:02:40 compiled against Pd version 0.40.3.extended-20080701 hex loader $Revision: 1.5 $ written by IOhannes m zmölnig, IEM <[EMAIL PROTECTED]> compiled on Jul 1 2008 at 04:02:41 compiled against Pd version 0.40.3.extended-20080701 /Applications/Pd-extended.app/Contents/Resources/extra/Gem.pd_darwin: dlcompat: dyld: /Applications/Pd-extended.app/Contents/Resources/Scripts/../bin/pd can't open library: /usr/X11R6/lib/libfreetype.6.dylib (No such file or directory, errno = 2) /Applications/Pd-extended.app/Contents/Resources/extra/Gem.pd_darwin: dlcompat: dyld: /Applications/Pd-extended.app/Contents/Resources/Scripts/../bin/pd can't open library: /usr/X11R6/lib/libfreetype.6.dylib (No such file or directory, errno = 2) Gem: can't load library libdir_loader: added 'cyclone' to the global objectclass path libdir_loader: added 'zexy' to the global objectclass path libdir_loader: added 'creb' to the global objectclass path libdir_loader: added 'cxc' to the global objectclass path libdir_loader: added 'iemlib' to the global objectclass path libdir_loader: added 'list-abs' to the global objectclass path libdir_loader: added 'mapping' to the global objectclass path libdir_loader: added 'markex' to the global objectclass path libdir_loader: added 'maxlib' to the global objectclass path libdir_loader: added 'memento' to the global objectclass path libdir_loader: added 'mjlib' to the global objectclass path libdir_loader: added 'motex' to the global objectclass path libdir_loader: added 'oscx' to the global objectclass path libdir_loader: added 'pddp' to the global objectclass path libdir_loader: added 'pdogg' to the global objectclass path libdir_loader: added 'pixeltango' to the global objectclass path libdir_loader: added 'pmpd' to the global objectclass path libdir_loader: added 'rradical' to the global objectclass path libdir_loader: added 'sigpack' to the global objectclass path libdir_loader: added 'smlib' to the global objectclass path libdir_loader: added 'toxy' to the global objectclass path libdir_loader: added 'unauthorized' to the global objectclass path libdir_loader: added 'pan' to the global objectclass path libdir_loader: added 'freeverb' to the global objectclass path libdir_loader: added 'hcs' to the global objectclass path libdir_loader: added 'jmmmp' to the global objectclass path libdir_loader: added 'ext13' to the global objectclass path libdir_loader: added 'ggee' to the global objectclass path libdir_loader: added 'flib' to the global objectclass path libdir_loader: added 'ekext' to the global objectclass path libdir_loader: added 'flatspace' to the global objectclass path /Applications/Pd-extended.app/Contents/Resources/extra/pdp.pd_darwin: dlcompat: dyld: /Applications/Pd-extended.app/Contents/Resources/Scripts/../bin/pd can't open library: /usr/X11R6/lib/libX11.6.dylib (No such file or directory, errno = 2) /Applications/Pd-extended.app/Contents/Resources/extra/pdp.pd_darwin: dlcompat: dyld: /Applications/Pd-extended.app/Contents/Resources/Scripts/../bin/pd can't open library: /usr/X11R6/lib/libX11.6.dylib (No such file or directory, errno = 2) pdp: can't load library /Applications/Pd-extended.app/Contents/Resources/extra/pidip.pd_darwin: dlcompat: dyld: /Applications/Pd-extended.app/Contents/Resources/Scripts/../bin/pd can't open library: /usr/X11R6/lib/libX11.6.dylib (No such file or directory, errno = 2) /Applications/Pd-extended.app/Contents/Resources/extra/pidip.pd_darwin: dlcompat: dyld: /Applications/Pd-extended.app/Contents/Resources/Scripts/../bin/pd can't open library: /usr/X11R6/lib/libX11.6.dylib (No such file or directory, errno = 2) pidip: can't load library ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Pd-0.41-4 can't extract
pd-0.41-4.mac.tar.gz from http://crca.ucsd.edu/~msp/software.html i get Could not extract the file "Pd-0.41-4.app/Contents": Could not create the folder this is on i386 osx 10.5.4 the file is 5.5MB does anybody else have the same error? eni ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] New sssad.pd now in SVN repository - please test! [was: sssad slowness]
Hi Frank Barknecht wrote: Enrique Erne hat gesagt: // Enrique Erne wrote: now the point why i write this email: it would be nice to have a little note in sssad-help that says "initializing is strongly recommended" or similar. Hm, probably [sssad] should get a [route bang] after the [route save] as well to prohibit saving parameters that haven't been initialized - similar to the protection of the outlet. I attached a version which has this with a little demo patch. That looks great. Still, personally I will initialize all keys, this guarantees to always have complete presets. [loadbang] | [; SSSAD vol 20, freq 42, other 1.2345( An other minor issue: In my post before I wrote to do [SSSAD_ADMIN set( on load, but on a second thought this is not good practice. It would force all SSSAD to output their value, even other already existing patches. Basically i would like it if there was a possibility to let some SSSAD instances in a new patch output the value. Attached SSSAD has a possible solution. case 1) ___ [sssad vol] | [*~ 0.5] Here SSSAD would not be initialized. case 2) ___ [loadbang] | [; SSSAD vol 0.5( [sssad vol] | [*~ 0.5] Here all is good except i don't want to write the value twice. case 3) ___ [loadbang] | [; SSSAD vol 0.5( [sssad vol] / [*~] *~ is missing the init value. It would work with [SSSAD_ADMIN set( but then all SSSAD's will output their value. That seems wrong. case 4) ___ [loadbang] | [; SSSAD vol 0.5, vol bang( [sssad vol] / [*~] How about something like that? [SSSAD vol bang( could be used to specify one key to output it's value. One more [route bang] would be required. One could argue [SSSAD vol bang( should delete the value, but i can't think of a use of having a key without value. In attached SSSAD i have 2 minor changes. A [route bang] to - output a specific key (i like that change a lot and see no problem) $1 in [route save $1] to - save a specific key (this is not a clean solution and doesn't work when with [sssad save] instance, but it would allow to collect specific data) wow pretty long email for such a minor thing. thanks for having a look at it :) eni #N canvas 282 224 783 400 10; #X floatatom 130 69 5 0 0 0 - - -; #X floatatom 138 102 5 0 0 0 - - -; #X obj 594 192 list prepend add; #X obj 594 218 list trim; #X obj 438 267 s SSSAD_ADMIN; #X obj 594 124 r SSSAD_ADMIN; #X obj 594 168 route persist; #X obj 594 146 list trim; #X msg 438 201 save; #X msg 452 240 set; #X obj 438 63 bng 24 250 50 0 empty empty save_all 0 -6 0 8 -262144 -1 -1; #X msg 594 258 other-patch 8 \; freq 12 \; vol 11 \;; #X obj 438 134 t b b; #X msg 470 167 set; #X obj 57 66 sssad vol; #X obj 56 157 loadbang; #X floatatom 192 289 5 0 0 0 - - -; #X msg 57 180 \; SSSAD vol 11 \, vol bang \; SSSAD freq 12 \, freq bang; #X obj 290 59 bng 24 250 50 0 empty empty save_this_patch 0 -6 0 8 -262144 -1 -1; #X obj 285 104 t b b; #X msg 319 128 set; #X obj 58 101 sssad freq; #X obj 72 288 sssad other-patch; #X msg 281 156 \; SSSAD_ADMIN vol \, freq; #X connect 0 0 14 1; #X connect 1 0 21 1; #X connect 2 0 3 0; #X connect 3 0 11 0; #X connect 5 0 7 0; #X connect 6 0 2 0; #X connect 7 0 6 0; #X connect 8 0 4 0; #X connect 9 0 4 0; #X connect 10 0 12 0; #X connect 12 0 8 0; #X connect 12 1 13 0; #X connect 13 0 11 0; #X connect 14 0 0 0; #X connect 15 0 17 0; #X connect 16 0 22 1; #X connect 18 0 19 0; #X connect 19 0 23 0; #X connect 19 1 20 0; #X connect 20 0 11 0; #X connect 21 0 1 0; #X connect 22 0 16 0; #N canvas 58 42 1019 539 10; #X obj 123 24 inlet; #X obj 197 130 r SSSAD; #X obj 197 87 s SSSAD; #X obj 197 53 list prepend \$1; #X obj 197 158 list trim; #X obj 197 23 inlet; #X obj 16 258 r SSSAD_ADMIN; #X obj 16 306 b; #X obj 16 284 route set; #X obj 123 51 b; #X obj 197 221 route \$1; #X obj 574 442 s SSSAD_ADMIN; #X obj 507 156 r SSSAD_ADMIN; #X obj 507 304 b; #X obj 507 248 spigot; #X obj 633 70 loadbang; #X obj 633 248 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 633 93 value \$1.SSSAD.req; #X obj 633 192 select 0; #X obj 665 139 + 1; #X obj 665 162 value \$1.SSSAD.req; #X obj 633 118 t a a; #X obj 633 214 f 1; #X obj 190 420 outlet; #X obj 123 394 route bang; #X text 207 393 filter out empty lists; #X obj 574 412 list prepend persist \$1; #X obj 123 365 list append; #X text 195 108 on SSSAD we eavesdrop the communication; #X text 656 247 <- only the first instance responds to "save"; #X text 129 498 2007/2008 fbar; #X text 780 93 Enhancement by Enrique Erne; #X obj 507 363 list append; #X obj 507 386 route bang; #X text 591 385 filter out empty lists here \, too.; #X obj 196 249 route bang; #X obj 507 275 route save \$1; #X text 266 240 to output a specific key; #X text 539 297 dol1 to save a specific key; #X connect 0 0 9 0; #X connect 1 0 4 0; #X connect 3 0
Re: [PD] [PD-announce] some works done with pd
|| | a écrit : > WOW - that stuff is beautiful!! thanks > espezially this one is great: > http://drpichon.free.fr/ch/article.php?id_article=80 > > i'm sorry i don't speak french, i'm sorry for the missing translations > so i can't understand the describing > text - could you explain me what it's about? the text explain a bit the algorythm used to select the word : starting from a word, the aim is to select 3 other word that are relatted to this 1st word (in a book / in the web) this 3 new word create the 3 branches etc... cyrille > > thank you very much, > > emanuel > > > > On Jul 25, 2008, at 8:38 PM, cyrille henry wrote: > >> hello, >> >> for those which are interested, here is some work that i recently >> made with pd/Gem : >> >> http://drpichon.free.fr/ch/article.php?id_article=88 >> >> http://drpichon.free.fr/ch/article.php?id_article=80 >> >> http://drpichon.free.fr/ch/article.php?id_article=76 >> >> http://drpichon.free.fr/ch/article.php?id_article=95 >> >> http://drpichon.free.fr/ch/article.php?id_article=94 >> >> http://drpichon.free.fr/ch/article.php?id_article=89 >> >> >> Cyrille >> >> ___ >> Pd-announce mailing list >> [EMAIL PROTECTED] >> http://lists.puredata.info/listinfo/pd-announce > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pdync-mailbox>set editor="vim -f +7 -s ~/.vim/mail.scr "
Hallo, Matt Barber hat gesagt: // Matt Barber wrote: > A related topic is: in general, if there's an adequate solution with > an abstraction, should one use it rather than an external? Does this > change in pedagogical situations where a student might profit in > learning from a rather sparse set of unit generators? Does this > change when performance is required above all? etc. etc. Unless performance becomes an issue I always prefer abstractions or pure-Pd idioms over externals when possible. Of course sometimes it's not possible, but for example I generally use [list prepend 0] | [route 0 1 2 3] instead of [demux 4] and [f 0]X[+ 1] instead of some [counter] external as that makes it easier for other people to run my patches (and for me to run my patches on different machines). > Another related topic -- for GOP abstractions, is it bad form to cover > the abstraction name and arguments with a canvas? What if these > things are printed as labels on canvases? I usually leave some room for the abstraction's names and arguments. If I really want to hide it (e.g. in a [sssad]-enabled slider clone which otherwise should look like a normal slider) I use the "Hide object name and arguments" property. > Thanks for the great suggestion about a style guide, though -- it > would be especially helpful to newcomers and students. Things like > "decouple number boxes and bangs used for debugging from the workings > of the patch" I feel are almost essential examples of efficient and > "proper" pd patching. And early, strong, and repetitive grounding in > [trigger]. I guess we could agree that fanning connections generally are an indicator of bad style and should make people feel physically uncomfortable. ;) Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
Luke, I like some of your ideas, but I'd offer the following: >>> Style: >>> * If giving $0 as an argument to an abstraction, it is always first in >>> the argument list [1] >> >> I often put it last (and it's specified to be that way e.g. in >> Memento) > My reasoning here is that $0 is probably the most common thing to pass > to an abstraction, but abstractions have varying numbers of arguments, > so $0 will sometimes be $3, sometimes $2, sometimes $7, and that > swings my brain around. Putting it in the first slot means that $1 > gains a sort of second meaning as "my parent's $0", which I think is > handy. Why should we assume anything about an abstraction's parent? It seems to me a lot has to be assumed about the general purpose of abstractions for one to say that a child's $1 should usually be the parent's $0... I tend not to hierarchize my abstractions to quite this extent, and prefer to allow abstractions to be relatively agnostic about their surroundings when possible. There's one style of patching which suggests that abstractions should operate as closely as possible to built-in objects, which (in vanilla at least) are usually also basically unaware of their surroundings (save for [block~] and other canvas-local settings, or send-receive type bindings, which granted depend a lot upon $0 but not usually explicitly as a single argument passed to objects)... Though, I suppose I agree that when $0 *does* need to be passed, it could go first. I can think of many situations where it would want to go last, though -- for instance an abstraction which takes mandatory arguments and optional arguments, of which one of the latter is a number to prepend to a symbol to designate, say, the send symbol of a group of instances within a parent abstraction which might be used e.g. for error cleanup, and which otherwise should be set to that instance's (not the parent's) $0 when not in the presence of a parent that knows what to do with the error message (so it isn't sent anywhere at all). A related topic is: in general, if there's an adequate solution with an abstraction, should one use it rather than an external? Does this change in pedagogical situations where a student might profit in learning from a rather sparse set of unit generators? Does this change when performance is required above all? etc. etc. Another related topic -- for GOP abstractions, is it bad form to cover the abstraction name and arguments with a canvas? What if these things are printed as labels on canvases? >>> * When prepending $0 to a symbol, only add a "-" to separate it from >>> another number, like [r $0-1stSend]. Otherwise the symbol should >>> immediately follow, like [r $0mySend]. >> >> I always seperate $0 with a $0-dash. $0myGod is easy to misunderstand. >> > That's all cool, and I think you are in the majority on that. I think > I just took camelCase because it reminded me of Smalltalk and Cocoa, > which remind me of Pd : ). Smalltalk and Cocoa remind me more of supercollider (y/n?), which isn't a bad thing at all. Still, I prefer the hyphen after $0 in general, as it can apply to all cases. As an aside, I also prefer $0 at the beginning of a symbol whenever possible to ensure backwards compatibility with <0.40 -- and a [makefilename %d] trick with $0 to allow things like pd-$0-edge_of_now (I suppose I prefer underscores to camelCase... meh - I'm not sure this is vital to "proper" patching, but it does remind me of the C-style the objects themselves are written in). >>> * When working with stereo, Left and Right pairs are written with Le >>> and Ri appended (to distinguish them from an R denoting "receive", >>> above) I think it's better to remain completely neutral with regard to the numbering of channels. Stereo should not stand out as a preferred case... many other more general nomenclatures could apply, e.g. ch1 ch2 ch3 ch4 (or ch0 ch1, etc. for channel array lovers), or just the numbers, or something else. This might allow code from a stereo garden to be plucked and implemented in a multichannel space in the future, with little worry. Also, actual pairing of loudspeaker to channel number should not, in general, be codified. There are too many "standard" and acceptable configurations by now to anoint some over others. I guess I second Frank's suggestion and say let's see what patching styles abound and let people be creative -- but when there's codification, let it be generalizable to as many situations as possible. Thanks for the great suggestion about a style guide, though -- it would be especially helpful to newcomers and students. Things like "decouple number boxes and bangs used for debugging from the workings of the patch" I feel are almost essential examples of efficient and "proper" pd patching. And early, strong, and repetitive grounding in [trigger]. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.pu
Re: [PD] Idiomatic Pd
Luke Iannini wrote:
> On Mon, Jul 28, 2008 at 7:49 PM, Chris McCormick <[EMAIL PROTECTED]> wrote:
>> On Sun, Jul 27, 2008 at 06:34:05PM -0700, Luke Iannini wrote:
>>> * Sends and Receives are written in camelCase, with "R" appended to
>>> complementary receives (e.g. in GUIs, $0mySlider for the send and
>>> $0mySliderR for the receive)
>> Will this even work? I think sends and receives have to be named the
>> same to work.
>>
> Yo, sorry, just poor wording on my part. Usually when I make a GUI
> object, I give it $0mySlider as its sending target and $0mySliderR as
> its receiving target so I can choose to either route things through
> the slider (so it picks up the change to the parameter) or not, or, so
ähm, isn't this already built-into the iemgui objects?
i mean, it will just pick up values without passing them on so that no
feedback is generated, and if you actively use it (moving the slider) it
will send out things.
> I can send "set", "color" etc. messages to the slider without it going
> to the slider's destination.
right, the above mentioned built-in mechanism doesn't work so well with
special messages like "color".
>
> I know at least Hard-off does the same in his DIY2 library (which is
> fantastic, by the way).
>
>>> * When prepending $0 to a symbol, only add a "-" to separate it from
>>> another number, like [r $0-1stSend]. Otherwise the symbol should
>>> immediately follow, like [r $0mySend].
>> I like using a forward slash ("/") since this is forwards compatable
>> with the day when OSC externals make it into Vanilla Pd. ;)
> Aok by me.
hmm, even though there surely _are_ uses for a combination of OSC and
$0, i guess this is the least common field of application...
fmasdr
IOhannes
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
