Re: [PD] [PD-dev] SQLite for PD v0.0
Mike McGonagle wrote: > Rob, > I am planning on putting this stuff up this weekend in the Extended CVS. I what is the "Extended CVS"? why don't you just put it into the pure-data CVS? fmgdsar. IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] "Structured" dataflow?
Hans-Christoph Steiner wrote: > This all makes me think that we should write a Pd book that covers > things like good form. Perhaps we could make it a decentralized > collaborative effort with strange consensus decisionmaking to mirror > the Pd community :D i guess that Pd might be out of existence when the book will be ready... seriously, i do think that there are fundamentally (and not so fundamentally) different views on "good form" (as all the flaming on [t a] vs. [trigger anything] shows), and i don't think that we would come to a conclusion. so i see 2 approaches to such project: - a collection of several individiual "good style" articles; possibly contradictory (e.g. in the way of the "beautiful code" book that primarily shows how differently "beauty" is perceived) - a single (group of) person(s) that write(s) the book and can decide on their definition of "good style"; since they do all the work, they have all the right to ignore (or whatever) other opinions i personally would favour #1, but i think both approaches are legitimate fgmadsr. IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] "Structured" Data Flow?
I think the original post was not about "good style" but about methods/techniques for "structured" patching, that is (as I interprete it and I may be wrong), how to "write" mantainable, reusable, scalable (etc.) "code" in PD. I do understand that the two things are related, as "good style" improves readability, and readability is essential for mantainability, reusability and scalability (etc.). Let me do a parallelism with "coding" programming languages. Suppose we were talking about a book on object-oriented programming techniques. The subjects discussed in the book would not be such things as when to use upper or lower case in method/class names, nor indentation, nor whether/when it is more elegant to use for vs. while, or switch vs. if... else if... The subjects discussed would be things like: using private variables and get/set methods vs. using public variables; defining and implementing interfaces vs. extending classes; singletons vs. static classes etc. Things that are less subject to personal tastes and can be analysed at a more "objective" level - although OF COURSE everything is always questionable. Also, one thing that had been mentioned as an aim was avoiding spaghetti, and this is reasonably objective, although the amount of spaghetti cannot be scientifically measured of course :) Just my 0.2 cents m. IOHannes wrote: -- Hans-Christoph Steiner wrote: > This all makes me think that we should write a Pd book that covers > things like good form. Perhaps we could make it a decentralized > collaborative effort with strange consensus decisionmaking to mirror > the Pd community :D i guess that Pd might be out of existence when the book will be ready... seriously, i do think that there are fundamentally (and not so fundamentally) different views on "good form" (as all the flaming on [t a] vs. [trigger anything] shows), and i don't think that we would come to a conclusion. so i see 2 approaches to such project: - a collection of several individiual "good style" articles; possibly contradictory (e.g. in the way of the "beautiful code" book that primarily shows how differently "beauty" is perceived) - a single (group of) person(s) that write(s) the book and can decide on their definition of "good style"; since they do all the work, they have all the right to ignore (or whatever) other opinions i personally would favour #1, but i think both approaches are legitimate ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] about fiddle~
I can't find a online archive of the Music-IR list, but there was recently a post by Arturo Camacho about a "New pitch estimator" with link to a PhD dissertation: http://www.cise.ufl.edu/~acamacho/publications/dissertation.pdf It might be of interest. (untested) ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] any tips on fart synthesis?
Hi all, Anyone got any advice on how to make sounds similar to the basses in this excerpt from Nightwalker - Rolling Through [NWR005]? http://claudiusmaximus.goto10.org/files/temp/fartstep.ogg (80kB) Really stinky wet fart noises. Thanks, Claude -- http://claudiusmaximus.goto10.org ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Font rendering quite CPU expensive in GEM (Jerome Tuncer)
[text3d] is much much quicker than [text2d] be it when rapidly changing displayed text or when just displaying... (: ++ Jé Jerome Tuncer a écrit : > Interesting point. > > I didn't know it actually worked that way. > > This CPU exepensiveness using [text2d] made me think maybe it doesn't > use OpenGL and only [text3d] does so. But it finally appears [text2d] > uses OpenGL as well. I'll try implementing my patches with [text3d] and > see how it goes... > > By the way : my fonts are already not too curved... (: > > ++ > > > > Jé > > Timon Botez a écrit : >>> Font rendering quite CPU expensive in GEM (Jerome Tuncer) >> Its also down to what typeface you are using. The more complex the >> curve, the higher the polygon count. Straight edge/polygon faces such >> as Gridnik (http://www.foundrytypes.co.uk/foundry_gridnik/ >> gridnik.html) or Citizen (http://www.myfonts.com/fonts/emigre/citizen/ >> familytree.html) tend to speed things up. These are not gratis if you >> are not so fussy, but there are plenty of free ones (http://www. >> 1001freefonts.com/). Simple pixel based fonts also speed up, but they >> look shit in 3d. Stay away from the serif - unless you do like cyrill >> suggest - and go for texture mapping. Helps turning off antialiasing >> too. >> >> T. >> >> ___ >> 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
