Re: [PD-dev] Going from CVS to Subversion
> > i am all for it, but: does sourceforge already implement some kind of > > acl for svn? or can we live without acl's? > > According to the Site Docs, "no means is provided to limit access to a > repository on a per-path basis" for Subversion. This seems to be > planned, but as we know Sourceforge, one shouldn't hold his/her > breath. well, the pd repository doesn't need to be located at sourceforge ... i mean, the plone site is located on an iem server, so, if someone takes the work of converting a cvs repository to a subversion, why not move the repository server? currently two features of sf are used ... the cvs and the tracker ... imo, it wouldn't be a bad idea, to put the svn server as well as a decent bug tracker (bugzilla/mantis/whatever) onto the puredata.info server and abandon sourceforge ... not sure, if the iem / the puredata.info server has enough resources, but at least no one would complain about sourceforge any more :) tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk You can play a shoestring if you're sincere John Coltrane signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] FYI: gcc 4.1 in auto-build
On Sun, 2006-08-13 at 21:29 -0400, Hans-Christoph Steiner wrote: > > Just an FYI: I set up the Debian/etch (testing) box to use gcc 4.1. > Both pd-MAIN and Pd-extended are compiling fine with gcc 4.1. It > would be nice to try some of the auto-vectorization features. Has > anyone messed with them at all? the biggest problem, the compiler faces, is not only the loop itself, but memory alignment and aliasing ... if the compiler doesn't allocate the memory itself, it's unlikely that it generates decent vectorized code ... so, i suppose, the performance gain of auto-vectorization for pd is more or less placebo but iirc, there is an -ftree-vectorizer-verbose option for gcc to get some information from the vectorizer ... cheers ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Which is more musical, a truck passing by a factory or a truck passing by a music school? John Cage signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Refactoring Pure Data
hi vincent ... > That implies a primary work on architecture and a cooperation of all > devs (commit often, criticize, propose, improve, test, submit > patches, ...). > I'll develop on architecture on other posts soon, but I want to first > focus on making the best out of what we have today. well, i've been following the development of the pd kernel for two or three years now ... most problems i faced where social rather than technical problems, e.g. i introduced features to devel, that didn't work with a more recent vanilla release ... so i had to port them over, or abandon them ... spending days with merging code is no fun, though ... > It deserves a clear roadmap, and a little of architecture work. > I think this work on architecture will be mandatory as we add new > features (like video~) again, there are social problems ... the people contributing to the code have different goals (data structures, fancy gui, gui/kernel separation, performance, threading) ... however ... a roadmap would only make sense, if these people would communicate ... since they don't do it, there are 2.5 separate branches at the moment ... > You could work on devel_0_39, but I doubt you can make any big > changes. I > once tried to remove unused variables from the code, and my > change got > reverted. Any change that doesn't bring a new feature is > likely to be > reverted, IMHO. This is both due to the diffing process used > for > submitting diffs to Miller and the diffing process used for > merging new in theory, cleaning up the code would be really nice ... but it makes merging of trivial code much harder (believe me, i tried it) ... the diff between devel and vanilla are several thousand lines of code ... and still increasing, mainly because of the desiredata stuff ... > - Self explanatory naming (how many single letters variables and / or > funny functions names do we have ?) > - Short functions (20 lines) > - Short files (100 to 200 lines) > - Reasonable Cyclomatic number > - A little indenting > - Getting rid of stuff.h which is a nonsense to me and having .h in > modules when required. > > > > I went through a little static analysis and this is the start of my > work. > Again, naming refers to architecture / modules, and that's where the > work needs to be done. > I think isolating Audio, MIDI, GUI, network, CoreLibs is a good, > ambitious but necessary start. It will make the development of Pd much > faster, and the overall quality of the code, thus the final executable > will be improved. i wish you good luck with that ... sounds like a _lot_ of work ... however i doubt, that these drastic changes are really going to make it into vanilla pd, taking into account that a simple patch as the tooltip patch is still pending after about two years ... cheers ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Most of the trouble in this world has been caused by folks who can't mind their own business, because they have no business of their own to mind, any more than a smallpox virus has. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Refactoring Pure Data
> 1. Does communication imply collaboration? does collaboration work without communication? > 2. Does collaboration imply everybody on the same branch? a->b <=> ¬b->¬a > > the diff between devel and vanilla are several thousand lines of code > > ... and still increasing, mainly because of the desiredata stuff ... > > DesireData hardly changes anything in files that are already existing... > Ok, there are 33 small #ifdefs, many of which around one-liners. yes ... the desiredata code is separated from the rest and so shouldn't affect merging ... t -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Happiness is a byproduct of function, purpose, and conflict; those who seek happiness for itself seek victory without war. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
On Tue, 2006-09-26 at 23:21 +0200, Frank Barknecht wrote: > > I should add, the next key step is to remove as many classes as > > possible from the root namespace (i.e. compiled into Pd). > > IMO this step should wait until we have the equivalent to Python's > "from pdcore import *" or C++'s "using namespace std" sorry for some 'implementation details', but this is not as trivial as it would be in a script language. i can think of two ways to implement a namespace: - a property of the canvas - a |using| or |import| object the first solution would be a contrary to pd's design principle (as written by miller in the pd docs, §2.6.2. persistence of data). for the second solution the creation time of the import object would be crucial (which would also be a contrary to §2.6.2), or objects will have to be reloaded when import objects are created/destroyed, which would increase the complexity of the implementation quite a bit... just my 1.95 ¢ cheers ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk A paranoid is a man who knows a little of what's going on. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
On Wed, 2006-09-27 at 03:05 -0400, Mathieu Bouchard wrote: > On Tue, 26 Sep 2006, Tim Blechmann wrote: > > On Tue, 2006-09-26 at 23:21 +0200, Frank Barknecht wrote: > >> IMO this step should wait until we have the equivalent to Python's > >> "from pdcore import *" or C++'s "using namespace std" > > sorry for some 'implementation details', but this is not as trivial as > > it would be in a script language. > > 1. It's not that trivial in a "script" language > > 2. It's exactly as difficult in a "script" languages as in pd. (pd isn't > as special as we may believe it is) well, it is in one term ... scripting languages are written in a text file, that's parsed from the top to the bottom. _this_ is absolutely the same as with pd ... the difference is, pd patches are not written in a text editor (at least, this is the usual case, i know, it's possible) and the parsing order is not transparent to the user ... unlike other interpreted languages, changes to the patch are done immediately, i.e. after changing something in the patch, there is no need to reload the patch file (compared with python's 'reload' or recompiling with a langugage like c/c++). what makes you think, that this is similar in text-based languages? tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Which is more musical, a truck passing by a factory or a truck passing by a music school? John Cage signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
On Wed, 2006-09-27 at 12:00 +0200, IOhannes m zmoelnig wrote: > Tim Blechmann wrote: > > > what makes you think, that this is similar in text-based languages? > > i think "script" language here did not mean "text-based" language > (ignoring the etymology of "script"), but rather "interpreted" language. when talking about script languages, i was referring to text-based languages like, c, c++, tcl, ada, ruby, python, lisp, scheme and in some extend esoteric languages like whitespace or brainfuck ... i used this term in contrary to graphical languages like max, jmax, pd or pnpd ... cheers ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Avoid the world, it's just a lot of dust and drag and means nothing in the end. Jack Kerouac signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
> Loading from a file shouldn't be too hard, the file could be loaded > into memory, reordered as necessary, then executed. The hard part > would be when inserting an [import] statement into a patch, if that > is going to take effect immediately and reload objects based on that > [import]. > > For the next step, it could just change the loading statement, only > affecting the load. Then we can test the idea out, and see whether > its worth the effort of making it take effect immediately. yes ... it's just that someone has to volunteer to do that :) > I guess realtime languages don't usually have namespaces. Anyone > know of some examples? pnpd contains namespaces similar to python, although it still lacks an 'import'-facility ... cheers ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk The aim of education is the knowledge, not of facts, but of values William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pd cvs list policy
hi hans, hi rest, would it be possible to forward the pd extended autobuild notification mails to another list than pd-cvs? - i'm interested in the commit messages, not in the autobuild error messages - it's not possible to switch off digest mode for the pd-cvs list and thus, i'm not able to filter out the autobuild mails by forwarding to /dev/null i see two possibilities: - switch off the forced digest mode for pd-cvs to make it possible to automatically delete pd-extended mails - send pd extended mails to a pd-extended-log list i'd prefer the second possibility, since pd-CVS implies that it's a list for CVS commit logs... thanks ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Just what the hell is the experimental tradition? Morton Feldman signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd cvs list policy
> i have changed that before the autobuild-logs started. > you can now turn off digest mode if you want to. wonderful! > > > > i see two possibilities: > > - switch off the forced digest mode for pd-cvs to make it possible to > > automatically delete pd-extended mails > > - send pd extended mails to a pd-extended-log list > > > > another possibility would be to use "topics" for the pd-cvs list. > subscribees can then choose, which topics they would like to receive (a > topic is set, if the subject-line matches a certain criterion) this sounds like the best solution ... cheers ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Nothing exists until or unless it is observed. An artist is making something exist by observing it. And his hope for other people is that they will also make it exist by observing it. I call it 'creative observation.' Creative viewing. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Re: zexyconf.h conflicts
hi hans ... > Also, since Pd is free software, it makes sense that it should be > buildable with free software. Right now, Windows and ASIO are the > the only non-free parts. is coreaudio free? > A ReactOS build would fix that. concerning the wikipedia page of reactos (their website is currently down), it's still considered as an alpha software. have you ever tried it? cheers tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Silence is only frightening to people who are compulsively verbalizing. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: opt-in usage statistics 'phone home' WAS: [PD-dev] BUG: namespace prefixes broken in 0.40
> >> Incidentally, I also think this highlights the need for a poll of the > >> Pd list at some point so we can get some idea of what users are using > >> what externals, abstraction sets, libraries, etc. I would love to see > >> the numbers, and it would probably be useful for Miller to see > >> what is > >> popular about Pd in a quantifiable scientific way. > > > > what about an opt-in usage statistics 'phone home'. initng does > > this for example.. firefox just does it without even asking.. > > Funny, I was just thinking about something like that. It would be > cool to know how many people are using Pd. If you code it, I'll > include it in Pd-extended. Then maybe it could make it into devel or > MAIN. this doesn't add any useful functionality for the user and is using the means of adware/spyware/activation ... it will definitely not make it into devel as long i still have a write access to the cvs ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Relying on the government to protect your privacy is like asking a peeping tom to install your window blinds. John Perry Barlow signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] gdb listening to PD
On Sun, 2006-11-12 at 10:01 -0500, Hans-Christoph Steiner wrote: > Hmm, never seen that. I just got the "pd" process. Which platform > are you on? did you ever have a look at m_pd.h? > .hc > > On Nov 11, 2006, at 8:04 PM, Conor J Curran wrote: > > > Hi, > > Tonight I was trying to hook up GDB with PD. When attempting to attach > > to PD, I was presented with the following options. Could anyone > > tell me > > which process/es should I connect to? > > > > pd_bang pd_free > > pd_setloadingabstraction > > pd_bind [EMAIL PROTECTED] pd_symbol > > pd_canvasmakerpd_getparentwidgetpd_typedmess > > pd_checkobjectpd_init [EMAIL PROTECTED] > > pd_compiledatepd_list pd_unbind > > pd_compiletimepd_newpd_version > > pd_doloadbang [EMAIL PROTECTED]pd_vmess > > pd_error pd_newest pdfloat_setup > > pd_fftpd_objectmakerpdint_setup > > pd_findbyclasspd_pointerpdsymbol_setup > > pd_float pd_popsym > > pd_forwardmesspd_pushsym it's not a list of processes, but a list of symbols ... hth, tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] gdb listening to PD
several ways to debug pd externals with gdb: - crash the external (with asserts) - declare pending breakpoint, that are resolved after the shared library has been loaded - set breakpoint after the dlopen stuff, when the symbols are available - break manually after the external has been loaded and the symbols are available - use the gdb integration into your favorite ide to set breakpoints in source files. (should work with about every decent ide like emacs, eclipse, kdevelop) tim On Mon, 2006-11-13 at 09:17 -0800, Miller Puckette wrote: > Just to add to the fun... I've NEVER been able to get teh debugger to > see Pd externals. I can debug Pd itself on linux and Mac OK. The > only thing I've found is that, on Mac, it's important to be sure > not to 'debug' the GUI process instead of Pd by accident. > > cheers > Miller > > On Mon, Nov 13, 2006 at 11:12:31AM -0500, james tittle wrote: > > On Nov 13, 2006, at 9:59 AM, forwinder wrote: > > > > > >Still can't get the bugger to set a break point though. GDB was > > >helpfully in that once PD died I could at least the back trace. > > > > ...did you compile pd with "-g -O0"? Are you stripping symbols > > somewhere? What platform are you trying to debug on? > > > > james > > > > ___ > > PD-dev mailing list > > PD-dev@iem.at > > http://lists.puredata.info/listinfo/pd-dev > > ___ > PD-dev mailing list > PD-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Cheat your landlord if you can and must, but do not try to shortchange the Muse. It cannot be done. You can't fake quality any more than you can fake a good meal. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] gcc 4.1 and auto-vectorization
On Thu, 2006-11-16 at 16:28 -0500, Hans-Christoph Steiner wrote: > Debian/testing now uses gcc 4.1 as its default compiler. I just > noticed when doing the apt-get upgrades. Has anyone tried the auto- > vectorization stuff? Is it worthwhile with Pd? you might want to check the archives: http://lists.puredata.info/pipermail/pd-dev/2006-08/007324.html to explain the terms 'alignment' and 'aliasing': alignment: audio blocks are not known to be aligned to 16byte boundaries aliasing: for functions in the form foo(t_sample * a, t_sample * b, int n), the compiler is unable to know if the memory regions of a and b are overlapping (b may be a+1) cheers ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk The price an artist pays for doing what he wants is that he has to do it. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] gcc 4.1 and auto-vectorization
On Fri, 2006-11-17 at 09:10 -0500, Hans-Christoph Steiner wrote: > On Nov 17, 2006, at 7:01 AM, Tim Blechmann wrote: > > > On Thu, 2006-11-16 at 16:28 -0500, Hans-Christoph Steiner wrote: > >> Debian/testing now uses gcc 4.1 as its default compiler. I just > >> noticed when doing the apt-get upgrades. Has anyone tried the auto- > >> vectorization stuff? Is it worthwhile with Pd? > > > > you might want to check the archives: > > http://lists.puredata.info/pipermail/pd-dev/2006-08/007324.html > > > > to explain the terms 'alignment' and 'aliasing': > > > > alignment: > > audio blocks are not known to be aligned to 16byte boundaries > > > > aliasing: > > for functions in the form foo(t_sample * a, t_sample * b, int n), the > > compiler is unable to know if the memory regions of a and b are > > overlapping (b may be a+1) > > Right, I remember that, I was meaning more has anyone tried any > benchmarks. i must admit, but i'm a bit confused ... how can an auto-vectorizer, that's known not to have any effect for a piece of code improve it's performance? tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Beware of bugs in the above code; I have only proved it correct, not tried it. Donald Knuth signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] gcc 4.1 and auto-vectorization
> I really doubt that the gcc devs put a lot of effort into something > that has no effect. Perhaps not for Pd, that may be true. But they > are talking about vectorizing loops, it may not be the best thing to > vectorize, but there are definitely vectorizable loops in Pd. the problem is not vectorizing, but auto-vectorizing. the best thing, that gcc (or icc) can do, is to generate vectorized code for non-aligned (read non-optimal) for setting audio blocks ... loops that access two or more blocks will face the aliasing problem > I'd say its worth trying. just try it, i'm curious about your oprofile dumps > Compilation optimization is not an > exercise in pure deduction. no, but you can figure out a lot by examining the machine code (if you can read machine code) and read the debugging output of the vectorizer. t -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk You can play a shoestring if you're sincere John Coltrane signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] gcc 4.1 and auto-vectorization
On Sat, 2006-11-18 at 23:00 -0500, Hans-Christoph Steiner wrote: > On Nov 18, 2006, at 8:07 PM, Thomas Grill wrote: > > > > > Am 18.11.2006 um 22:16 schrieb Mathieu Bouchard: > > > >> On Sat, 18 Nov 2006, Hans-Christoph Steiner wrote: > >> > >>> I really doubt that the gcc devs put a lot of effort into > >>> something that has no effect. Perhaps not for Pd, that may be > >>> true. But they are talking about vectorizing loops, it may not > >>> be the best thing to vectorize, but there are definitely > >>> vectorizable loops in Pd. > >> > >> perhaps it would be a good start to reimplement newbytes(n) using > >> memalign(16,n) instead of malloc(n). > > > > A few years ago i introduced aligned memory allocation in the pd- > > devel branch. > > Have you tried submitting a patch? It would be at least useful in Pd- > extended. How big a difference did it make? what makes you think, that just aligning memory regions introduces a performance boost? how can a compiler generate code for aligned memory, if the memory is aligned, but the compiler isn't aware of that? tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Relying on the government to protect your privacy is like asking a peeping tom to install your window blinds. John Perry Barlow signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Fwd: PD-cvs Digest, Vol 21, Issue 29
On Tue, 2006-11-28 at 12:31 +0100, Thomas Grill wrote: > Hi all, > would it be possible to exclude the autobuild results from this > digest, like e.g. by making a separate mailing for that. > It's has become absolutely impossible to track the cvs changes. it's possible to switch off the digest mode for pd-cvs and forward the autobuild mails to the trash. not a solution, just a hack ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk There's no such entity as "most people". These are generalities. All generalities are meaningless. You've got to pin it down to a specific person doing a specific thing at a specific time and space. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Fwd: PD-cvs Digest, Vol 21, Issue 29
On Tue, 2006-11-28 at 09:42 -0500, Hans-Christoph Steiner wrote: > > My the same measure, I find it difficult to track changes when the > CVS checkins from the forks are also included. But I am not > suggesting they be removed from the list because I am willing to > tolerate that if it means more cooperation. then i'm proposing to change the name from pd-cvs into [EMAIL PROTECTED] ;) sorry ... just kidding ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Fwd: PD-cvs Digest, Vol 21, Issue 29
On Wed, 2006-11-29 at 17:24 +0100, IOhannes m zmölnig wrote: > Tim Blechmann wrote: > > On Tue, 2006-11-28 at 12:31 +0100, Thomas Grill wrote: > >> Hi all, > >> would it be possible to exclude the autobuild results from this > >> digest, like e.g. by making a separate mailing for that. > >> It's has become absolutely impossible to track the cvs changes. > > > > it's possible to switch off the digest mode for pd-cvs and forward the > > autobuild mails to the trash. > > ähm, if you choose to receive pd-cvs in non-digest mode, you should also > be possible to select the "cvs" topic (and not no-topic (which is > equivalent to ALL topics) or the "autobuild" topic). in this case you > should not receive "autobuild" emails. ah, cool ... thanks ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Silence is only frightening to people who are compulsively verbalizing. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Re: PD-cvs Digest, Vol 21, Issue 30
On Wed, 2006-11-29 at 11:09 -0500, Hans-Christoph Steiner wrote: > Since Matju has stated that desire is a fork, I think it would be > most beneficial to all of us, including the desire people, if it used > its own repository. do you want to restrict their access to the pd cvs? what would be the benifits of a desire repository for the dd devs? and for the pd devs (well, taking into account, that miller doesn't use the cvs for his development works)? wasn't the initial purpose of the pd sf repository a way to avoid duplicate developments (i'm really curious, as i haven't been involved with pd at that time)? > pd-devel is already pretty far afield for being > a branch, but pd-devel is still allowed to stay in the sf cvs? > it seems to have many changes that are never intended to be > merged into the main. come on, this has been overdiscussed in the past... i guess everyone can read about everything on this in the pd-dev archive of the last two years... i don't really care if vanilla/devel/desire are forks, branches, use the same repository or different ones, or if the developers work together, against each other, or don't care what they are doing, but there is a really interesting article about 'floss developers as a social formation' (http://www.firstmonday.org/issues/issue9_11/lehmann/index.html). cheers ... tim ps: hans, please don't mind my grumpy mails ... we owe each others a few bottles of beer/glasses of wine, though :) -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk A paranoid is a man who knows a little of what's going on. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Re: PD-cvs Digest, Vol 21, Issue 30
wonderful ... matju/chun on desire, thomas on devel, miller on vanilla, me on pnpd ... that makes 5 devs for 3 branches and one rewrite ... what a wonderful waste of resources ... no please cool down ... one thing, that you people need to realize: open source software development doesn't work, if you don't care, what other people are doing. and how i see the current situation no one really cares about the other ones ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk There's no such entity as "most people". These are generalities. All generalities are meaningless. You've got to pin it down to a specific person doing a specific thing at a specific time and space. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] Re: [PD-cvs] pd SConstruct,1.1.4.18,NONE
On Thu, 2006-11-30 at 03:39 +, Mathieu Bouchard wrote: > Update of /cvsroot/pure-data/pd > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20618 > > Removed Files: > Tag: devel_0_39 > SConstruct > Log Message: > bye. > > > --- SConstruct DELETED --- was SConstruct a desire-related file? -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Happiness is a byproduct of function, purpose, and conflict; those who seek happiness for itself seek victory without war. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Re: PD-cvs Digest, Vol 21, Issue 30
> > one thing, that you people need to realize: open source software > > development doesn't work, if you don't care, what other people are > > doing. > > Why did you start pnpd? as you might now, the pnpd core and the pd core follow different design concepts. > > and how i see the current situation no one really cares about the other > > ones ... > > And you still see this as a problem? i don't see it as a problem, it just can be used in a textbook on project management as bad example... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Re: PD-cvs Digest, Vol 21, Issue 30
i'm not sure, if you understand, what i wanted to tell you, maybe because of by bad written english, i'm not a native speaker. i'm not sure, if i'm reading you mail correctly, maybe because of the same reason. nevertheless, if you're interested in the concept differences between pd and pnpd, you are free to read my design docs or my dev blog or post questions of the mailinglist. i think, we can stop the flamewar, now On Thu, 2006-11-30 at 11:10 -0500, Mathieu Bouchard wrote: > On Thu, 30 Nov 2006, Tim Blechmann wrote: > > >>> one thing, that you people need to realize: open source software > >>> development doesn't work, if you don't care, what other people are > >>> doing. > >> Why did you start pnpd? > > as you might now, the pnpd core and the pd core follow different design > > concepts. > > And that's how you escape your own reasoning? I care about what other > people are doing, I keep compatibility with maybe 99% of the pd patches. > Do you have any compatibility with pd in pnpd? > > Pnpd must not be that far off in terms of design principles, because the > GUI that it's made to connect to, as a client-server system, is Klippels > Karma, which was first intended as a rather direct rewrite of jMax 2.5, > and jMax 2.5 is enough like PureData so that GridFlow can support both at > once and confine the differences between the two systems to about 5% of > GridFlow's code. What I mean, is that basically, it's all the same. > > Don't even try to rub yourself out of the picture by contemplating how > much your design differences are so important and ignoring how the design > resemblances are so even more important. > > >>> and how i see the current situation no one really cares about the other > >>> ones ... > >> And you still see this as a problem? > > i don't see it as a problem, it just can be used in a textbook on > > project management as bad example... > > And you are very much part of that "bad example". That's my point in this > whole message. > > _ _ __ ___ _ _ _ ... > | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju > | Freelance Digital Arts Engineer, Montréal QC Canada -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk There's no such entity as "most people". These are generalities. All generalities are meaningless. You've got to pin it down to a specific person doing a specific thing at a specific time and space. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] devel branch
hi thomas, > Once i started the new devel branch, i'll try to provide patches of > the various extra features, which would save you from brwosing > through the codebase. I'm wondering if we can find a way to even > include SIMD, since i'm going to reimplement it without using > assembly but rather compiler instrinsics i've implemented most of the vectorizable dsp functions with intrinsics for pnpd. it's written with c++ templates, but it should be easy to wrap these functions into a c api for pd. possibly faster to reuse this code than rewriting the codelets from scratch and they are quite separate from the pnpd codebase, just implemented as header files. cheers ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk The price an artist pays for doing what he wants is that he has to do it. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] devel branch
> The other thing is that i guess it has to be straight C for Miller > to > accept it, yes, possibly ... > plus, older gcc versions have problems with intrinsics in c > ++ code. well, older gcc versions have problem with intrinsics in general. ;) as for the license, it could be optional like the fftw support ... cheers ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Linux is like a wigwam: no windows, no gates, apache inside, stable. signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] audio interruptions from outside events (only with Pd)
On Mon, 2006-12-04 at 09:30 -0500, Hans-Christoph Steiner wrote: > We are in the middle of trying to make [hidio] as robust as possible > in terms of plugging and unplugging devices. One thing I noticed is > that if I have Pd running only a sine wave, then I plug or unplug a > USB device, I get an interruption in the sound. > > If I do the same thing with Audacity or Max/MSP, there is not > interruption in the sound. Any ideas what's the root of this? which os? tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk The composer makes plans, music laughs. Morton Feldman signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: HID and threads WAS: [PD-dev] audio interruptions from outside events (only with Pd)
On Mon, 2006-12-04 at 14:53 -0500, Hans-Christoph Steiner wrote: > > > I have no idea about the inner workings of hidio (is there a > > separate low-priority thread for handling the HID requests?) > > This was bugging me so I have to respond to it. From what I've > seen, > I think handling HID I/O in a low priority thread would be a bad > idea. Do you know any application that does that? The effect would > be that your mouse pointer would skip whenever something with higher > priority was run. This may be the case on Windows, but definitely > not on Mac OS X and GNU/Linux. > > On Mac OS X, the kernel queues HID events and uses wired kernel > memory for the queues to ensure that those events get out there as > soon as possible and reliably without a thread. No example code > that > I have seen, from Apple or others, puts HID event handling in a > thread. To put it simply: you don't want your mouse pointer to be > pre-empted. well, it depends on how you can query the hid i/o. if the access to the hid backend is either blocking or slow, you should think about putting the specific code in a thread with a lower priority than the audio thread, unless you prefer a smooth mouse movement over audio dropouts :) imo, all non-audio i/o of a low-latency system should should be detached from the audio thread to avoid dropouts. tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: HID and threads WAS: [PD-dev] audio interruptions from outside events (only with Pd)
hi hans, > [comport] and [hid] both use the standard calls and both do not use > threads at all, yet neither has problems with blocking I/O (or at > least no one has been able to make a patch that causes it to > happen). I am pretty sure they both use high priority queues in the > kernel so that return very quickly. after having a brief look at the hidio sources, you seem to use a mutex for synchronization with a child thread ... this is basically not save and may lead to audio dropouts, when running with low latencies. i know, miller's portaudio implementation is not able to run under low latencies, but the callback scheduler of devel is able to do so... cheers ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk There's no such entity as "most people". These are generalities. All generalities are meaningless. You've got to pin it down to a specific person doing a specific thing at a specific time and space. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: HID and threads WAS: [PD-dev] audio interruptions from outside events (only with Pd)
> > after having a brief look at the hidio sources, you seem to use a > > mutex > > for synchronization with a child thread ... this is basically not save > > and may lead to audio dropouts, when running with low latencies. i > > know, > > miller's portaudio implementation is not able to run under low > > latencies, but the callback scheduler of devel is able to do so... > > We are currently in the discussion of how to use threads in externals/ > io/hidio, so we are testing various configurations, so this is > probably going to change drastically. (one hidio author that shall > remain unnamed prefers to avoid this list for understandable but > unfortunate reasons). > > How would you handle this particular situation? well, devel contains some data structures to provide lockfree synchronization, which vanilla is lacking. but since other technical problems don't allow vanilla to run with low latencies, i wouldn't really care about vanilla. however, if you use thomas's flext framework, you won't really have to deal with the threading problems, since he wrapped both vanilla's and devel's api into flext, so no need to deal with it separately. beside that, the max-port doesn't require 17 ifdefs ;) cheers ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Every word is like an unnecessary stain on silence and nothingness Samuel Beckett signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] slowing down dsp function inside perform loop
> > Basically, I have two buffers with some sound in buffer #1. I'm planning > > at some time in the future to start playing from buffer #2. I copy the > > contents of buffer #1 to buffer #2 and then do all kinds of evil DSP to > > the contents of buffer #2, all done asynchronously from the main DSP > > perform loop. > > okay, but this code don't have to be in the dsp perform loop ... > > I see 2 possibilities for that: > > - you can do the copy + DSP-transformation of the buffer in a seperate > thread, as it is done in the [sndfiler] external please note, that sndfiler is basically not clickfree, because it requires resorting of the dsp chain, which is not trivial, if your patch contains quite a number of dsp objects > - maybe you can also do it with vasp, which is a set of externals for > buffer calculation and I think they can do it also in a seperate thread i guess the 'vanilla' way would be to downsample the 'evil DSP' ;) tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Desperation is the raw material of drastic change. Only those who can leave behind everything they have ever believed in can hope to escape. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] slowing down dsp function inside perform loop
On Wed, 2006-12-06 at 12:24 -0500, Mathieu Bouchard wrote: > On Wed, 6 Dec 2006, Tim Blechmann wrote: > > > please note, that sndfiler is basically not clickfree, because it > > requires resorting of the dsp chain, which is not trivial, if your patch > > contains quite a number of dsp objects > > Does it really need re-sorting the dsp chain, or could the compiled dsp be > only slightly modified? Doesn't it only need to change the array pointers > in it? yes, you just need to change the pointer to the array. however, they are stored directly in the dsp chain. i proposed some changes, even changes, that are not changing the binary compatibility of garray_getfloatarray. i guess, you can find some of them, in the archives... asynchronous buffer operations are not a problem in pnpd, though ;) tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Silence is only frightening to people who are compulsively verbalizing. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] first auto-vector test
> These flags are used in the standard build: > > -Os -funroll-loops -fomit-frame-pointer -mcpu=powerpc -mtune=7450 - > mpowerpc-gfxopt the standard build is optimized for size ??? > (fdn~ NOT vectorized; d_soundfile.c, d_ctl.c, m_sched.c vectorized) have the _whole_ files been vectorized or only certain loops? which loops have been vectorized, which haven't? tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Linux is like a wigwam: no windows, no gates, apache inside, stable. signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
> of course the only real way to vote for this would be write the code - > i think i'll wait for PNPD instead.. :) pnpd is currently supporting both hashed symbols and full-featured string ;) however, there are no objects for handling strings, yet t -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
On Mon, 2006-12-18 at 12:46 -0500, Mathieu Bouchard wrote: > >> of course the only real way to vote for this would be write the > code - > >> i think i'll wait for PNPD instead.. :) > > > > pnpd is currently supporting both hashed symbols and full-featured > > string ;) however, there are no objects for handling strings, yet > > Are there any implicit casts between strings and symbols? i haven't decided, yet, but i guess no ... -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww! Jack Kerouac signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-1518030 ] subpatch clearing itself crashes Pd
On Sun, 2007-02-11 at 12:42 +0100, Frank Barknecht wrote: > > What the patch is doing is deleting an object. The message causing > the > > deletion was triggered by (a message that was triggered by[...]) > that > > object, so what? > > There's nothing semantically incorrect in doing that. > > There is. You may be missing some implications of Pd's "depth first > message passing" as described in the manual, chapter "2.3.2. depth > first message passing": [1] i wouldn't say that committing suicide is illegal, just because there is an easy explanation / workaround or the implementation of pd is buggy. it somehow reminds me of the old jokes beginning with "if cars would be built like software is written" ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk The composer makes plans, music laughs. Morton Feldman signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-1518030 ] subpatch clearing itself crashes Pd
> Well, then how should Pd solve the logical pitfalls in your opinion? mark the object as deletable, if the messaging is happening, wait for the object to return from the message function, then it can be safely deleted. implementing it shouldn't be difficult as it is completely compatible with pd's synchronous architecture. do any logical pitfalls exist in this situation? tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk There's no such entity as "most people". These are generalities. All generalities are meaningless. You've got to pin it down to a specific person doing a specific thing at a specific time and space. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-1518030 ] subpatch clearing itself crashes Pd
> > mark the object as deletable, if the messaging is happening, wait > for > > the object to return from the message function, then it can be > safely > > deleted. > > implementing it shouldn't be difficult as it is completely > compatible > > with pd's synchronous architecture. > > If I understand it right, what you suggest is similar to adg a > [delay] object into the chain to defer the actual killing to a point, > when all current operations are complete. or the other way round ... you use the delay object to achieve, that the object is deleted after the messages have occurred ... :P > But additionally your proposal would introduce the possibility, that > an object disappears, before all other objects have completed the > current logical step, too. So the bottom line would be dividing the > single logical step we have now into two (or even more) steps, that > all need to be executed in the correct order. What's the gain of > making execution order more complicated? I guess this is not just to > allow sloppily coded suicides. i'm not splitting the logical step, i just change the interpreter state in a totally predictable way. but don't worry, i'll leave the implementation of this to a pd developer ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk There's no such entity as "most people". These are generalities. All generalities are meaningless. You've got to pin it down to a specific person doing a specific thing at a specific time and space. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-1518030 ] subpatch clearing itself crashes Pd
On Sun, 2007-02-11 at 23:27 +0100, Frank Barknecht wrote: > Hallo, > Tim Blechmann hat gesagt: // Tim Blechmann wrote: > > > i'm not splitting the logical step, i just change the interpreter state > > in a totally predictable way. > > I don't know Pd's internals nearly as good as you, but still it seems > to me, that suicides in the middle of a logical step have pitfalls. As > Thomas wrote, a suicidal object should not generate further messages. > However this suicidal object may already have scheduled further > messages. What happens to other branches after the suicidal object, > e.g.: > > [r y] > | > [symbol x] > | > [t a b] > | | > | [s kill-symbol-x] > | > [s y] i don't see a problem with the following signal flow (indentation represents the message stack): symbol x, execute outlet 1 t a b, execute outlet 2 s kill-symbol-x, mark 'symbol x' deletable t a b, execute outlet 1 s y, send r y, receive symbol x, set object symbol x, returning from outlet 1, as it's marked as deletable, remove it from the interpreter tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Most of the trouble in this world has been caused by folks who can't mind their own business, because they have no business of their own to mind, any more than a smallpox virus has. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-1518030 ] subpatch clearing itself crashes Pd
> I probably misunderstood you: I thought, that as soon as the [symbol > x] object was killed the reason to fire the "anything" outlet of the > trigger was gone as well, so this outlet should *not* be allowed to > fire. if the pd language would have a notion of exceptions, this would make sense, but otherwise this would contradict with the pd language, wouldn't it? > But as I understand it now, your proposal is exactly the same as the > current [delay] solution, just one object less (the [delay]), one > crash less and still no "micro steps". [symbol x] would live until the > end of the logical step and be killed afterwards. of course, several of these structures could be nested like: | |t b b| | | | |pd suicide| | |pd suicide2| providing several interpreter states at the same logical time. > I still prefer the explicitness of [delay], though. which of course only provides one interpreter state per logical time, but of course, it's a workaround, that should work fine ... t -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Desperation is the raw material of drastic change. Only those who can leave behind everything they have ever believed in can hope to escape. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Fwd: Request for dev access
On Thu, 2007-02-15 at 13:55 +0100, Georg Holzmann wrote: > > Of course we would loose the possibility that everyone can quickly > fix > > a bug everywhere, but then, I don't see this as such a big problem. > > There still would be "trusted core developers" with access to almost > > everything - or maybe we could let each user decide with an ACL file > > in her/his user directory, who should have access to it. > > I think this is only a good idea if there were already problems, that > other developers broke things ... which I cannot really remember. > If not, it will only prevent some people from developing, trying to > improve other code, improving the build system etc. iirc, carmen once messed with the plugin~ help files, which was not in everyone's interest. > I see your point, but I think this is more appropriate for a project, > where you really have some core developers (or maintainers) which > work > quite a lot on the code - but I don't think that it is like that in > pd! > (exception: millers main, maybe the pd-extended-release branch from > hans > and pd-devel-core) it would have the advantage, that there is a certain amount of quality assurance, so no one messes with other people's code ... but i guess your observation is correct, currently the cvs is not used as version control system, but rather as a code publishing system. tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Which is more musical, a truck passing by a factory or a truck passing by a music school? John Cage signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] d_math.c "break[s] strict-aliasing rules"
hi miller, On Wed, 2007-04-18 at 18:13 -0700, Miller Puckette wrote: > Well, I measured the difference and didn't see significant speedup (on an > imac recently)... eventually it might make a difference, of course. But > certain bit-bashing code (the square root thing, but more importantly > phasor~ and osc~) runs half again faster than any version I've been able > to write with strict aliasing. i did some benchmarks of pd's phasor~ code against a straight-forward implementation on my pentium-m, when implementing the objects for nova. the straight-forward implementation ran about 20 to 30 % faster than the pd-style implementation. code like sqare root or inverse square root can be coded by just utilizing the rsqrtps and sqrtps opcodes, with a 14 bit precision, when working on the sse unit ... > An alternative would be to special-case the offending code somehow. This > could be part of a larger effort to make the DSP code modular so that SSE > instructions and whatnot could also be "plugged in". Worth thinking about... according to the gcc manual, simple vectorizable operactions, that's used for audio processing, can be autovectorized, if (and only if) the programmer takes care of both alignment and aliasing issues ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Life is really simple, but we insist on making it complicated. Confucius signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] d_math.c "break[s] strict-aliasing rules"
> > i did some benchmarks of pd's phasor~ code against a straight-forward > > implementation on my pentium-m, when implementing the objects for > > nova. > > the straight-forward implementation ran about 20 to 30 % faster > > than the > > pd-style implementation. > > Do you still have the code from the straight forward implementation? i'm not sure, if i still have the benchmark code somewhere on my machine, the phasor~/osc~ implementation can be found at http://svn.klingt.org/nova/trunk/source/language/dsp/oscillator.cpp ... > > code like sqare root or inverse square root can be coded by just > > utilizing the rsqrtps and sqrtps opcodes, with a 14 bit precision, > > when > > working on the sse unit ... > > 14bit precision would leave a lot to be desired in Pd. Are there high > precision operators? erm, according to the comments in d_math.c, miller's code only precise for 8 mantissa bits and sqrt/rsqrt are aliases for q8_sqrt/q8_rsqrt > >> An alternative would be to special-case the offending code > >> somehow. This > >> could be part of a larger effort to make the DSP code modular so > >> that SSE > >> instructions and whatnot could also be "plugged in". Worth > >> thinking about... > > > > according to the gcc manual, simple vectorizable operactions, that's > > used for audio processing, can be autovectorized, if (and only if) the > > programmer takes care of both alignment and aliasing issues ... > > Is complying with -fstrict-aliasing enough to take care of the > aliasing issues? aeh, no ... when referring to the term aliasing when talking about of vectorizable functions, i'm referring to the aliasing of pointers as function arguments ... it should be described in the gcc manual in detail ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Silence is only frightening to people who are compulsively verbalizing. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] devel_0_39 ? devel_0_40 ?
On Sat, 2007-07-21 at 16:09 -0700, Miller Puckette wrote: > > Finally, 0.40 still isn't 64-bit safe; for that you'll need 0.41. > This > is a serious problem in some distributions of linux in which many > libraries > aren't available in 32-bit form in the 64-bit version of the OS. Just > as > a teaser, I tried running the same patch as 32-bit and 64-bit programs > on > my 64-bit machine, hoping to find the 32-bit version so much faster > that I > could just forget optimizing the 64 bit version entirely. But I found > the > 64-bit one 33% faster than the 32-bit one for the particular patch I > tried. > So 64-bit compatibility has to be taken seriously! when compiling for x86_64, floating-point opertations are generated for the sse unit instead of the fpu ... seeing the increased number of xmm registers, less memory operations need to be used ... e.g. second order systems (biquad) can be computed in registers only ... another nice side-effect is the more robust handling of denormal numbers on the sse unit ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Life is really simple, but we insist on making it complicated. Confucius signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] devel_0_39 ? devel_0_40 ?
> Now for the hard part: in Pd, 32-bit floating point tables are stored as > 64-but 'atoms' for a 50% hit in memory efficiency. Something Must Be Done; > but what? split audio buffers and array-of-atoms? maybe this could include rewriting the whole audio buffers with an asynchronous interface ... imo, data structures and audio buffer have completely different real-time and performance constraints, so i see no real benefit in combining both concepts ... > OTOH, I'm falling out of my chair for joy that there's finally a way to > write C code that doesn't choke on denormals. well, one should still tweak the sse unit by setting the daz/ftz flags ... see the code that is enabled by the preprocessor symbol DAZ in s_main.c of devel_0_39 ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Your mind will answer most questions if you learn to relax and wait for the answer. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] devel_0_39 ? devel_0_40 ?
On Tue, 2007-07-24 at 11:08 -0700, Miller Puckette wrote: > On Mon, Jul 23, 2007 at 12:20:33PM +0200, Tim Blechmann wrote: > > > Now for the hard part: in Pd, 32-bit floating point tables are stored as > > > 64-but 'atoms' for a 50% hit in memory efficiency. Something Must Be > > > Done; > > > but what? > > > > split audio buffers and array-of-atoms? maybe this could include > > rewriting the whole audio buffers with an asynchronous interface ... > > imo, data structures and audio buffer have completely different > > real-time and performance constraints, so i see no real benefit in > > combining both concepts ... > > > Well, I only just combined table~ with 'data structures' in 0.39 (I > think), because there were hundreds of lines of essentially duplicate > GUI code for the two types of arrays. > > The other complication is that I'm trying to design a new system of > buffers suitable for images, perhaps with 8- 16- and 32- bit cells. > It would be desirable for tabread4~ and all that to be able to talk to > images too. Big design problem... the problem of generic design is, that you might have an implementation, that does everything more or less, but does nothing completely right ... like ... do you want/need 128bit alignment? do you want/need power-of-two sizes? what are your real-time constraints (1.3 ms or 40 ms deadlines)? can you affort to waste memory? generic design is great, if you don't have to sacrifice too much performance / usability ... i'm not sure about combining ds, audio buffers and video buffers (and maybe multi-dimensional matrices), though ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org I had nothing to offer anybody except my own confusion Jack Kerouac signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] JACK transport and syncing
On Tue, 2007-08-28 at 11:40 -0700, Ken Restivo wrote: > > In particular, I'd like metro object to be synced with JACK. i have once written an external that is running as jack transport client, because i needed to sync pd and ardour for a composition ... it's available from the sf cvs (externals/tb/jack_transport) ... hth, tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] cleaning up the list of developers
i am not really a fan of removing people from a project, but maybe one could distinguish between 'active' and 'retired' developers ... retired developers should loose their cvs access, but still kept in the sourceforge developer lists ... best, tim On Mon, 2007-09-10 at 16:42 -0400, Hans-Christoph Steiner wrote: > Hey all, > > IOhannes started this discussion at PdCon, I think we should finish > it. Since it is now quite easy to be added to the list of developers > on the pure-data project, I think we should remove people if they are > inactive for a long time (2 years). If they want to be active again, > they can just post out to pd-dev like anyone else. > > I propose that we leave Gerard van Dongen and Jamie Tittle on the > list since they are still with us in spirit. > > I believe IOhannes had the list with last commit dates (or some who > never committed). > > Lazy consensus time? :D > > .hc > > > > > >¡El pueblo unido jamás será vencido! > > > > ___ > PD-dev mailing list > PD-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org I must say I find television very educational. The minute somebody turns it on, I go to the library and read a good book. Groucho Marx signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] audioindev with several devices
actually, i have never done it, but wouldn't you have to link the clocks of both audio devices in order to avoid timing problems? wini one told me that one can combine devices with alsa, which includes some code, that actually synchronizes multiple audio-devices by software, which includes resampling in order to avoid timing problems ... iirc, pd doesn't include such error correction, so it might be a source of unwanted audio dropouts ... best, tim On Mon, 2007-09-17 at 09:06 -0400, David Merrill wrote: > I have only done this in Linux, but here are some thoughts: > > - are your device numbers *really* 2 and 13? In my experience, they > start at 1, and are numbered sequentially, meaning that you'd have to > have a lot of sound cards in your system to get all the way up to 13. > - when you list channels, you typically give a number of channels for > each sound device that you're using, and I always list in and out > separately, as in: > > -audiodev 1,2 -inchannels 2,2 -outchannels 2,2 > (meaning that I'm using devices 1 and 2, and each one has 2 ins and 2 > outs) > -David M. > > On 9/16/07, João Miguel Pais <[EMAIL PROTECTED]> wrote: > Hi, > > I wanted to use two soundcards for input, my built-in stereo > soundmax and > an rme multiface (for output only the rme). I tried the > following > parameters, > > asio > audioindev 2,13 (2 is soundmax, 13 the rme) > audiooutdev 12 > channels 18 > audiobuf 40 > > but it didn't work, only one device was taken by pd, the rme. > Is it > possible in windows to have 2 different soundcards working? > > > Thank you, > > João Miguel Pais > > -- > Friedenstr. 58 > 10249 Berlin > Deutschland > Tel +49 30 42020091 > Mob +49 162 6843570 > [EMAIL PROTECTED] > skype: jmmmpjmmmp > http://www.puredata.org/Members/jmmmp > IBM Thinkpad R51, XP, Pd-Ext-0.39-2-t5 > > ___ > PD-dev mailing list > PD-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev > > > > -- > MIT Media Lab > [EMAIL PROTECTED] > http://web.media.mit.edu/~dmerrill/ > ___ > PD-dev mailing list > PD-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Nothing exists until or unless it is observed. An artist is making something exist by observing it. And his hope for other people is that they will also make it exist by observing it. I call it 'creative observation.' Creative viewing. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] audioindev with several devices
On Mon, 2007-09-17 at 09:24 -0400, David Merrill wrote: > > to find the post online about wiring the clocks together from multiple > sound cards, google: el cheapo howto argh ... i'd somehow prefer the software solution :P t -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org The price an artist pays for doing what he wants is that he has to do it. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd code formatter?
> Ah, ok, I didn't notice the switch. I've originally used the default > Emacs settings for the indent. Now I think I now use stroustrup, > because it was the closest to Miller's style that I found. i generally avoid tabs in my source files with the following before-save-hook: (defun clean-code() "Remove trailing spaces, turn tab into spaces" (when (memq major-mode '(c-mode c++-mode emacs-lisp-mode python-mode)) (delete-trailing-whitespace) (untabify (point-min) (point-max (add-hook 'before-save-hook 'clean-code) if you then set c-basic-offset to 4 you are almost there ... hth, tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Linux is like a wigwam: no windows, no gates, apache inside, stable. signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd code formatter?
On Fri, 2007-09-28 at 04:12 +0200, Yves Degoyon wrote: > > yeah, pd was nice when it was free of normalisation and b*** ... and people where polite and respecting each other ... -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Cheat your landlord if you can and must, but do not try to shortchange the Muse. It cannot be done. You can't fake quality any more than you can fake a good meal. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] SVN?
> I don't know much about git, but what I have read this would defenitely > be an option. > Then also synching developer and millers version should be easier if I > understood that correctly ? > > What do the others think ? i recently started using git for nova, it is really an extremely powerful tool, compared to cvs/svn ... especially for nonlinear distributed development it is far more suited than cvs/svn ... also maintaining parallel branches is way easier ... however i am not sure, if it is the right tool for the pd developer community, which seems to be quite conservative in terms of which tools are used ... beside that, i am not sure, how access to specific parts of the repository can be restricted ... best, tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Happiness is a byproduct of function, purpose, and conflict; those who seek happiness for itself seek victory without war. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] SVN?
On Tue, 2007-10-23 at 11:56 -0400, Hans-Christoph Steiner wrote: > A distributed repository sounds interesting, but given Linus > Torvald's love of KDE, constant dissing of usability, and the fact > that git has 119 commands, this gives me pause. in order to evaluate git, one should maybe give it a try ... > Sounds like software designed for someone with an encyclopedic > memory. I really only use 8 commands in CVS (update, commit, > checkout, add, remove, tag, diff, import). do you remember all the cvs command options? tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Every word is like an unnecessary stain on silence and nothingness Samuel Beckett signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] SVN?
> My experience is that Linus is > super focused on issues that affect him and pretty much totally > ignores other issues that don't affect him. Also, he approaches > things with arrogance. So chances are, that effects the software he > writes. i am not sure whether one should judge the functionality of a piece of software by the personality of the author ... > I want to write code, not play with SCM systems. i think it took me two days to merge devel_0_38 to devel_0_39 with cvs ... it could have been done in one day with git ... 4 hours learning git and setting up the repository, 2 hours doing the merge :) cheers, tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Every word is like an unnecessary stain on silence and nothingness Samuel Beckett signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] SVN?
> The hard thing for me with patches is that I feel > I should understand the patch fully and believe it both works and that > it won't make future trouble. For the last month or more I've been > working on HC's font patch, trying to adapt it so that it's bug-free > but still accomplishes HC's aim. one way to go would be: 1. point hc to the bugs, ask him to fix them 2. when the patch is bug-free, ask hc to document it 3. read the docs, read the code, try to understand it 4. point hc to the issues that you don't like in the code 5. review the patch again 6. if the patch doesn't match your criteria, go to point 4 tim -- [EMAIL PROTECTED]ICQ: 96771783 http://tim.klingt.org Who need fossil fuel when the sun ain't goin' nowhere Amiri Baraka signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Error when crosscompiling pdlua
On Mon, 2007-12-10 at 17:59 +0100, Frank Barknecht wrote: > And why does gcc not complain on native Linux using practically > the same command line? iirc, the windos binary of pd uses a dll, exposing the public api, while on linux, all symbols are exposed by the pd binary (-Wl,--export-dynamic) t -- [EMAIL PROTECTED] http://tim.klingt.org The first question I ask myself when something doesn't seem to be beautiful is why do I think it's not beautiful. And very shortly you discover that there is no reason. John Cage. signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] i can has svn commit access?
hi damien, > i would like to > implement multithreaded [soundfiler] read, did you have a look at my sndfile external? a threaded soundfiler has to face two issues: - read the file in a separate thread - synchronize the buffers while the first issue is trivial, the second one requires some changes to the public api of pd in order to avoid a recompilation of the dsp chain ... if you just deal with the first issue like sndfiler, you will have audio dropouts when you patches get bigger ... sndfiler used to work without dropouts in the help patches, but not in the rather complex performance patch, i was using those days ... i'd suggest to search the archive of the pd-dev list, iirc i posted a more detailed analysis of the problem a few years ago ... > and i'd like to in the longer > term make a stab at multithreaded the entire DSP engine, or at least > investigating whether this project is a feasible one. i would like to hear your approach for that, since this is a very interesting issue ... the design of a real-time, multi-threaded dsp engine is actually the topic of my master thesis :) there are two interesting publications about multi-threaded dsp engines, avoiding pipelining techniques: - U. Reiter and A. Partzsch. Multi Core / Multi Thread Processing in Object Based Real Time Audio Rendering: Approaches and Solutions for an Optimization Problem. - S. Letz, Y. Orlarey, D. Fober. Jack audio server for multi-processor machines while the approach of the `letz' paper, as it is implemented in jackdmp is only feasible for graphs with a small number of nodes, the `reiter/ partzsch' paper describes an interesting algorithm for clustering big graphs. unfortunately, implementing the `reiter/partzsch' approach for a pd/max/ nova graph is not that simple ... while the signal flow is explicitly defined in the pd/max/nova graph, the order of accessing shared resources (buffers, busses, ...) is done implicitly ... i had a multi-threaded implementation of the nova engine, only taking the explicit ordering of the signal graph into account. i did not implement the implicit ordering, since the implementation would be quite complex and i didn't have the feeling that pd/max/nova graphs are feasible to represent a multi-threaded dsp engine, because the lack of expressive power concerning resource use ... so, i'd be curious to hear your approach for implementing a multi- threaded dsp engine for pd ... cheers, tim -- [EMAIL PROTECTED] http://tim.klingt.org The most wonderful opportunity which life offers is to be human. Henry Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd and threads with pd~ : was Re: i can has svn commit access?
> So, i'd like to know it i'm to much optimistic, or if work on thread > with pd will be obsolet when pd 0.42 will be out. i didn't check the sources, but from the description in miller's icmc paper, pd~ introduces a pipelined approach, i.e. adding one block of latency when audio data is passed from one thread to another. from my understanding, the pd~ approach is static, so a patch would need to be written explicitly for the number of threads ... pd~ has different limitations than max5's poly~, but is still far away from a general solution ... tim -- [EMAIL PROTECTED] http://tim.klingt.org All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd and threads with pd~ : was Re: i can has svn commit access?
> >> So, i'd like to know it i'm to much optimistic, or if work on thread > >> with pd will be obsolet when pd 0.42 will be out. > > > > i didn't check the sources, but from the description in miller's icmc > > paper, > does anyone know where to fine this article? i read it in the proceedings of the icmc 2008 > >pd~ introduces a pipelined approach, i.e. adding one block of > > latency when audio data is passed from one thread to another. > > from my understanding, the pd~ approach is static, so a patch would need > > to be written explicitly for the number of threads ... > well, if you can make an threaded_soudfiler abstraction based on pd~ and > soundfiler, then it should be ok... from my understanding pd~ provides a pipelining approach for distributing signal processing to multiple threads ... the soundfiler limitations are a different issue ... tim -- [EMAIL PROTECTED] http://tim.klingt.org Linux is like a wigwam: no windows, no gates, apache inside, stable. signature.asc Description: This is a digitally signed message part ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] i can has svn commit access?
> As for implementing substantial changes to soundfiler, I think the way > to do it is not to try to get the modifications into Pd-vanilla, there > are so many issues of backwards compatibility. Instead make a new > object, even if it is largely just a modified version of the original. > [sndfiler] is a good example of that. as i mentioned before, sndfiler works around one limitation of soundfiler, but is unable to work around fundamental limitations of pd's architecture ... t -- [EMAIL PROTECTED] http://tim.klingt.org I had nothing to offer anybody except my own confusion Jack Kerouac ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] seteuid vs. setuid
> I was just merging 0.41 vanilla into pd-extended 0.40 and noticed > something worthwhile to point out. It seems there isn't a patch > submitted for this, but it is quite simple. Basically, in s_inter.c, > 'seteuid()' is used to lose setuid privileges. As far as I understand > it, seteuid() allows the program to keep the root privilege and switch > back and forth between root and non-root. hm, why does pd need root privileges, anyway? shouldn't the resource limiting be handled by pam these days? tim -- t...@klingt.org http://tim.klingt.org Life is really simple, but we insist on making it complicated. Confucius ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Using PD funcs from inside a threaded external
> The problem is that I've approached all the gphoto calling functions the > same, but one particular function (listconfig) segfaults when I use PD > functions, in particular outlet_symbol(). when calling pd's api functions from a separate thread, make sure to hold the global pd lock ... tim -- t...@klingt.org http://tim.klingt.org Wherever we are, what we hear is mostly noise. When we ignore it, it disturbs us. When we listen to it, we find it fascinating. John Cage signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Using PD funcs from inside a threaded external
Mathieu Bouchard wrote: > On Wed, 18 Mar 2009, Tim Blechmann wrote: > >>> The problem is that I've approached all the gphoto calling functions the >>> same, but one particular function (listconfig) segfaults when I use PD >>> functions, in particular outlet_symbol(). >> when calling pd's api functions from a separate thread, make sure to >> hold the global pd lock ... > > Yes, sorry, I should have known. > > This is sys_lock() and sys_unlock() if pd is compiled with THREAD_LOCKING > enabled. right, didn't remember the function names ... > Afaik, this will do the rough equivalent of a [delay 0] across threads, so > that your (Ben's) thread's execution is inserted between two t_clock > events ([delay], [metro], etc.) not really ... [delay 0] will schedule the outlet during the next dsp tick in the pd thread ... waiting for the interpreter lock requires the os to schedule the thread, the function and all triggered object functions, are called in the object thread ... tim -- t...@klingt.org http://tim.klingt.org Linux is like a wigwam: no windows, no gates, apache inside, stable. signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Using PD funcs from inside a threaded external
>>> Afaik, this will do the rough equivalent of a [delay 0] across threads, so >>> that your (Ben's) thread's execution is inserted between two t_clock >>> events ([delay], [metro], etc.) >> not really ... [delay 0] will schedule the outlet during the next dsp >> tick in the pd thread ... > > uh, i haven't read that part of the code in detail, but wouldn't that be > _before_ the next dsp tick instead? (I was likening sys_lock to the use of > [delay] in a single-threaded setting, I wasn't suggesting to use the real > [delay] in a multi-thread setting) tick: - timer callbacks - signal processing >> waiting for the interpreter lock requires the os to schedule the thread, >> the function and all triggered object functions, are called in the >> object thread ... > > I was beginning to reply to this paragraph, but I realised that I don't > understand the grammar of it. Could you please rephrase? |threaded object a| | |trivial object b| thread of object a: - call sys_lock(), blocking - os wakes this thread - call inlet handlers of object b - ... tim -- t...@klingt.org http://tim.klingt.org I don't write music for sissy ears. Charles Ives signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Using PD funcs from inside a threaded external
>> not really ... [delay 0] will schedule the outlet during the next dsp >> tick in the pd thread ... > > i'm pretty sure that this is _not_ true. > a [delay 0] will schedule the message within the same tick. rescheduling a timer interrupt from a second thread, there is no such thing as the `same tick' ;) -- t...@klingt.org http://tim.klingt.org A paranoid is a man who knows a little of what's going on. William S. Burroughs signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] x86_64 fixes
hi all, attached you find a series of two patches against the pd-extended branch to compile pd extended on the x86_64 architecture: 0001-pd-extended-build-fix-for-x86_64.patch: passes -fPIC to the cyclone build system 0002-iem_tab-x86_64-fixes.patch compile fixes for the iem_tag library best, tim -- t...@klingt.org http://tim.klingt.org The price an artist pays for doing what he wants is that he has to do it. William S. Burroughs signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] x86_64 fixes
> Thanks for the patches. But they don't seem to be attached. The best > thing to do would be to post them to the patch tracker as separate > items, since they are patches for different people's code. i submitted my patches to the tracker ... the 0.41 part of the pd-extended branch now compiles on x86_64 except for pidip. btw, my patches are also available from my git mirror [1] ... best, tim [1] http://tim.klingt.org/git?p=pure-data.git;a=shortlog;h=refs/heads/pd-extended-x86_64 -- t...@klingt.org http://tim.klingt.org You don't have to call it music if the term shocks you. John Cage signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] denormals: svf, freeverb (was Re: [PD] bug in freeverb???)
On 08/15/2009 11:42 PM, Ed Kelly wrote: > Once again, I personally would like to have this implemented in the PD core, > since denormals are a real pain in the ass and often cause CPU pegging. This > limits the real-time uses of PD, since there are some performance patches > that are realizable but ultimately un-performable. As such I'm surprised it > doesn't class as a bug, but I guess this is up to the extern writer. as stated before in this thread, denormals can slow down the computation on the fpu. the problem is not as big, when compiling the binary to use the sse unit, though (btw, this is the default, when compiling for x86_64) pd devel_0_39 did also set the DAZ/FTZ flags, which affect the denormal handling on the sse unit, but that was never merged into vanilla pd hth, tim -- t...@klingt.org http://tim.klingt.org Only very good and very bad programmers use goto in C signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] denormals: svf, freeverb (was Re: [PD] bug in freeverb???)
>> pd devel_0_39 did also set the DAZ/FTZ flags, which affect >> the denormal >> handling on the sse unit, but that was never merged into >> vanilla pd > > I see there's a new pd_devel branch. I should check it out. i doubt, that the new pd_devel branch shares anything with the old pd_devel except for the name ... also, please note that daz/ftz only deal with the behavior of the sse unit ... if your external is compiled to use the fpu, you will still see performance issues, when denormal numbers occur best, tim -- t...@klingt.org http://tim.klingt.org The price an artist pays for doing what he wants is that he has to do it. William S. Burroughs signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
