Oh man, what a great selection of tips! I especially love the sed/perl quick-replace commands, and the extra b's and a's in trigger (to avoid that always unpleasant re-wiring).<br><br>~Kyle<br><br><div><span class="gmail_quote">
On 11/22/06, <b class="gmail_sendername">Frank Barknecht</b> <<a href="mailto:fbar@footils.org">fbar@footils.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hallo,<br>martin brinkmann hat gesagt: // martin brinkmann wrote:<br><br>> >(The subpatches could profit from an interior decorator, though. ;)<br>><br>> i agree that my patches look pretty messy. though this is mainly because
<br>> i am lazy ;), but i also try to avoid a 'misleading layout', where the<br>> objects are all aligned orthogonally, and it is sometimes hard to tell<br>> wether the left or right inlet is connected for example.
<br>><br>> using more subpatches/abstractions would probably help...<br><br>I don't have a real problem with your patch and I think they are<br>amazing.<br><br>They really could profit from abstractions however. You have a lot of
<br>duplicated functionality (sequencers, synths) that would be useful to<br>have in single files for better reusability. However then you should<br>also protect all senders and receivers with $0 and make them local to<br>
the abstraction, so that you don't "overwrite" receivers already in<br>use outside of your abstractions.<br><br>Regarding cleaning up patches: The goal of cleaning up should be<br>readability IMO, not just "nice looks", so yes, avoiding misleading
<br>connections running on top of each other should be a priority. I<br>collected some simple "rules" (meant to be broken of course) on the<br>Tips and Tricks wiki page:<br><br><a href="http://puredata.info/docs/tutorials/TipsAndTricks#keep-your-patches-nice-clean-and-tidy">
http://puredata.info/docs/tutorials/TipsAndTricks#keep-your-patches-nice-clean-and-tidy</a><br>(one line)<br><br>It includes two screenshots of a patch before and after the diet.<br><br><br>It also occured to me that you are doing all the sequencing using
<br>audio signals. While this allows a very tight timing and is common<br>practice among Max users, I don't think it is strictly necessary in<br>Pd. A simple [metro] and [vline~] will be just as tight as using a<br>[phasor~] for sequencing - also because [metro] and [vline~] can be
<br>used as an equivalent replacement for [phasor~] even with subsample<br>timing accuracy.<br><br>In the long run you could save quite some CPU cycles by using the more<br>traditional clock-based sequencing where possible.
<br><br>Ciao<br>--<br> Frank Barknecht _ ______footils.org_ __goto10.org__<br><br>_______________________________________________<br><a href="mailto:PD-list@iem.at">PD-list@iem.at</a> mailing list<br>UNSUBSCRIBE and account-management ->
<a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br></blockquote></div><br><br clear="all"><br>-- <br><br><a href="http://theradioproject.com">http://theradioproject.com
</a><br><a href="http://perhapsidid.blogspot.com">http://perhapsidid.blogspot.com</a><br><br>(((())))(()()((((((((()())))()(((((((())()()())())))<br>(())))))(()))))))))))))(((((((((((()()))))))))((())))<br>))(((((((((((())))())))))))))))))))__________
<br>_____())))))(((((((((((((()))))))))))_______<br>((((((())))))))))))((((((((000)))oOOOOOO