Re: [PD] sms external
Definitally am, although it will probably be all summer before there are any pd externals. This is because the first thing I'm doing is taking old SMS analysis/synthesis code from http://www.iua.upf.es/~sms/ (the one for SGI/NeXTStep that Xavier Serra wrote for his Ph.D) and turning it into a library that works in real-time on modern day platforms... then come the externals. The basic idea idea is to create a buffer that holds the model and allows editing and extraction of the data, while there is a seperate synthesis external that can operate in real-time on the buffer. And lastly, an analysis external that will work on a sound file or pd array. Also, I have been spending the last couple days finishing up a patch called Trax that will do resynthesis of sinusoidal models in real-time. It just needs a little more cleaning up and I'll post it to the forum.. but has its problems, which is why I'm going to be working on the libsms stuff. Glad to know there are others interested in this, and I would appreciate any opinions, as there are many ways to approach this project. rich On Mon, Apr 7, 2008 at 11:17 AM, marius schebella [EMAIL PROTECTED] wrote: hi, some time ago someone (rich e) posted that he wanted to work on an sms (Spectral Modeling Synthesis) external for pd (http://lists.puredata.info/pipermail/pd-dev/2008-01/010709.html), just curious if you're still working on it or if you come up with another solution? thanks, marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] VOSIM - Voice Synth and similar
Hallo, Luigi Rensinghoff hat gesagt: // Luigi Rensinghoff wrote: Yes i saw that vosim patch mentioned, but i think it is not accessible anymore in the pd-archive... What's wrong with the archive? I can get the file just fine. I attached it again because I think, the version in the archives doesn't have the wrap~-bug-workaround. Concerning [paf~], the readme tells that it is a Percussion Detector ?? Which README?? CVS-externals/by-author/tgrill/pd/extra/paf~ contents: Paf is copyright (C) 1999 Miller Puckette. Permission is granted to use this software for any purpose, commercial or noncommercial, as long as this notice is included with all copies. NEITHER THE AUTHORS NOR THEIR EMPLOYERS MAKE ANY WARRANTY, EXPRESS OR IMPLIED, IN CONNECTION WITH THIS SOFTWARE! This is the README file for the paf percussion detector. This software is available from http://www.crca.ucsd.edu/~msp as part of the toys library. - [EMAIL PROTECTED] -- Ah, true. But I think, the README is wrong, it refers to the paf~ synthesis object and that is not a percussion detector: paf~ doesn't even have signal inlets. Ciao -- Frank Barknecht _ __footils.org__ vosim~-help.pd Description: application/puredata vosim~.pd Description: application/puredata ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] makefilename crash
Just discovered this last night. Should I file a bug report? When a float or numeric message (is this the same type as float automatically?) is sent directly to [makefilename %s_PD.aif], PD freezes, and then segfaults/crashes on the next input of any kind. I know this is not how this object should be used, but still PD should be robust enough to handle this kind of type error without totally dying. Simply sending a text-message to the same object without using a [symbol] object to set the type results in a far more benign: error: makefilename: no method for 'dave' best, d. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 21: Be less critical ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] makefilename crash
OK, I'll go through all the archives... want to stick with 0.39 until I know more about what changes in 0.40, 0.41... and want to stick with Extended. I guess there's no retroactive bugfixes ;-) best, d. IOhannes m zmoelnig wrote: Derek Holzer wrote: Just discovered this last night. Should I file a bug report? just upgrade to at least Pd-0.41; this bug has been reported and fixed in the past. When a float or numeric message (is this the same type as float automatically?) yes Simply sending a text-message to the same object without using a [symbol] object to set the type results in a far more benign: error: makefilename: no method for 'dave' hmm, should we go through the entire equivalency-of-messages-thing again? fmgadf IOhannes -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 5: Abandon normal instructions ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] import vs namespace
Hi all, it seems that the ways of dealing with externals and paths is always in flux! I would like to confirm a suspicion that, for the time being, the following works the way I think it does, assuming PD 0.39: [library/object] imports that specific object into global namespace, and can accommodate different objects with the same name from different libs. This method does not allow access to help patches or abstractions in the library path. [import library] imports the whole library into global namespace, including help patches and other abs (usually, although I have often found this broken in Extended). It cannot accommodate different objects with the same name from different libs, as the last library imported will have priority. Is this correct so far? Has anyone documented this any more substantially anywhere? How does this change for 0.40? best! d. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 33: Cluster analysis ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] makefilename crash
Derek Holzer wrote: Just discovered this last night. Should I file a bug report? just upgrade to at least Pd-0.41; this bug has been reported and fixed in the past. When a float or numeric message (is this the same type as float automatically?) yes Simply sending a text-message to the same object without using a [symbol] object to set the type results in a far more benign: error: makefilename: no method for 'dave' hmm, should we go through the entire equivalency-of-messages-thing again? fmgadf IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] externals with same names
On Sun, 2008-04-06 at 22:20 -0400, Chris McCormick wrote: On Sun, Apr 06, 2008 at 10:53:14PM +0200, Frank Barknecht wrote: Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: 2: don't use the full Pd-extended but strip it down to your needs (i personally use a barebone Pd and add 3 or so libraries - i still have an overview about what is loaded...) I'm sometimes thinking about making a pd-condensed fork of pd-extended which includes only externals and abstractions without nameclashes. ;) Same here! It would be good to have a distribution with a maintainer who is slightly less conservative than Miller about what goes in, but still keep it really tight. Maybe it would also be cool to see a democratized version of Pd where externals and libraries must be first nominated and then voted in by some requisite number of positive votes. For this to work I think we'd need to have people for each major GNU/Linux distribution who would do the work of the actual packaging and submission, separate to the building (My aims are totally selfish - I'd love to be able to apt-get install this). Even more talking with no action (sorry Roman), no need to be sorry, because your talk is at least constructive, where mine was just a bit rude, and of course i could start working on it myself instead of asking others to do so. after all, i am happy that there is pd-extended, so that all objects are easily available for everyone. i think the next step should indeed be a cleaned-up version, that - doesn't have nameclashes - only contains classes, that work (the same) on every platform - doesn't conflict with libraries compiled as libraries. i mean conflicts such as no/bad support for aliases and certain class names. even more words. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] import vs namespace
as far as I understood [import] is the same as [declare -lib] and that only adds a library to the local namespace of a patch. see the help file for declare that comes with 0.41. you can declare your library relative to pd [declare -stdlib] or relative to the patch [declare -lib], but - as mentioned in the helpfile - the name stdpath is confusing!]. it is also not 100% clear, how this works in abstractions and if the behaviour will be consistent with future pd versions. there might be a chance that [import] really adds to the global namespace, but I don't think so. (otoh I don't know how to add something to the global namespace.) the idea was that you can use a certain objectclass in one patch and another one with the same name (but from another lib) in another patch. please correct me, if I'm wrong. marius. Derek Holzer wrote: Hi all, it seems that the ways of dealing with externals and paths is always in flux! I would like to confirm a suspicion that, for the time being, the following works the way I think it does, assuming PD 0.39: [library/object] imports that specific object into global namespace, and can accommodate different objects with the same name from different libs. This method does not allow access to help patches or abstractions in the library path. [import library] imports the whole library into global namespace, including help patches and other abs (usually, although I have often found this broken in Extended). It cannot accommodate different objects with the same name from different libs, as the last library imported will have priority. Is this correct so far? Has anyone documented this any more substantially anywhere? How does this change for 0.40? best! d. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] import vs namespace
This is only the case on 0.40 and newer. [import] on 0.39 loads into the global namespace. This stuff is currently alpha and not complete, so it is not very clear. I think for the manual, the best bet for Pd-extended is to use the [library/objectclass] format for objectclasses that aren't loaded by default. That has been supported by every version of Pd for a long time now (as long as you install the libraries that way). .hc On Apr 8, 2008, at 9:22 AM, marius schebella wrote: as far as I understood [import] is the same as [declare -lib] and that only adds a library to the local namespace of a patch. see the help file for declare that comes with 0.41. you can declare your library relative to pd [declare -stdlib] or relative to the patch [declare -lib], but - as mentioned in the helpfile - the name stdpath is confusing!]. it is also not 100% clear, how this works in abstractions and if the behaviour will be consistent with future pd versions. there might be a chance that [import] really adds to the global namespace, but I don't think so. (otoh I don't know how to add something to the global namespace.) the idea was that you can use a certain objectclass in one patch and another one with the same name (but from another lib) in another patch. please correct me, if I'm wrong. marius. Derek Holzer wrote: Hi all, it seems that the ways of dealing with externals and paths is always in flux! I would like to confirm a suspicion that, for the time being, the following works the way I think it does, assuming PD 0.39: [library/object] imports that specific object into global namespace, and can accommodate different objects with the same name from different libs. This method does not allow access to help patches or abstractions in the library path. [import library] imports the whole library into global namespace, including help patches and other abs (usually, although I have often found this broken in Extended). It cannot accommodate different objects with the same name from different libs, as the last library imported will have priority. Is this correct so far? Has anyone documented this any more substantially anywhere? How does this change for 0.40? best! d. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] import vs namespace
On Apr 8, 2008, at 6:01 AM, Derek Holzer wrote: Hi all, it seems that the ways of dealing with externals and paths is always in flux! I would like to confirm a suspicion that, for the time being, the following works the way I think it does, assuming PD 0.39: [library/object] imports that specific object into global namespace, and can accommodate different objects with the same name from different libs. This method does not allow access to help patches or abstractions in the library path. You can load abstractions this way too: [library/myabs]. Help patches should work, there is a bug in 0.39 that I aim to fix in 0.40. [import library] imports the whole library into global namespace, including help patches and other abs (usually, although I have often found this broken in Extended). It cannot accommodate different objects with the same name from different libs, as the last library imported will have priority. Is this correct so far? Has anyone documented this any more substantially anywhere? How does this change for 0.40? It is hopefully properly implemented with canvas-local and global namespaces. I am aiming to have this all fixed up for the 0.40.3- extended release at the end of the month, then this will be all clearer in my head. When's your deadline? .hc best! d. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ macumbista ---Oblique Strategy # 33: Cluster analysis ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list Access to computers should be unlimited and total. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] import vs namespace
But this way doesn't load abstractions and help patches, AFAIK. d. Hans-Christoph Steiner wrote: This is only the case on 0.40 and newer. [import] on 0.39 loads into the global namespace. This stuff is currently alpha and not complete, so it is not very clear. I think for the manual, the best bet for Pd-extended is to use the [library/objectclass] format for objectclasses that aren't loaded by default. That has been supported by every version of Pd for a long time now (as long as you install the libraries that way). .hc On Apr 8, 2008, at 9:22 AM, marius schebella wrote: as far as I understood [import] is the same as [declare -lib] and that only adds a library to the local namespace of a patch. see the help file for declare that comes with 0.41. you can declare your library relative to pd [declare -stdlib] or relative to the patch [declare -lib], but - as mentioned in the helpfile - the name stdpath is confusing!]. it is also not 100% clear, how this works in abstractions and if the behaviour will be consistent with future pd versions. there might be a chance that [import] really adds to the global namespace, but I don't think so. (otoh I don't know how to add something to the global namespace.) the idea was that you can use a certain objectclass in one patch and another one with the same name (but from another lib) in another patch. please correct me, if I'm wrong. marius. Derek Holzer wrote: Hi all, it seems that the ways of dealing with externals and paths is always in flux! I would like to confirm a suspicion that, for the time being, the following works the way I think it does, assuming PD 0.39: [library/object] imports that specific object into global namespace, and can accommodate different objects with the same name from different libs. This method does not allow access to help patches or abstractions in the library path. [import library] imports the whole library into global namespace, including help patches and other abs (usually, although I have often found this broken in Extended). It cannot accommodate different objects with the same name from different libs, as the last library imported will have priority. Is this correct so far? Has anyone documented this any more substantially anywhere? How does this change for 0.40? best! d. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 39: Cut a vital connection ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] import vs namespace
Please file bug reports if you can't load abstractions that way. I think there is one specific case where help patches don't load then, but I don't remember off hand what it was. A bug report for that would also be quite helpful. .hc On Apr 8, 2008, at 11:37 AM, Derek Holzer wrote: But this way doesn't load abstractions and help patches, AFAIK. d. Hans-Christoph Steiner wrote: This is only the case on 0.40 and newer. [import] on 0.39 loads into the global namespace. This stuff is currently alpha and not complete, so it is not very clear. I think for the manual, the best bet for Pd-extended is to use the [library/objectclass] format for objectclasses that aren't loaded by default. That has been supported by every version of Pd for a long time now (as long as you install the libraries that way). .hc On Apr 8, 2008, at 9:22 AM, marius schebella wrote: as far as I understood [import] is the same as [declare -lib] and that only adds a library to the local namespace of a patch. see the help file for declare that comes with 0.41. you can declare your library relative to pd [declare -stdlib] or relative to the patch [declare -lib], but - as mentioned in the helpfile - the name stdpath is confusing!]. it is also not 100% clear, how this works in abstractions and if the behaviour will be consistent with future pd versions. there might be a chance that [import] really adds to the global namespace, but I don't think so. (otoh I don't know how to add something to the global namespace.) the idea was that you can use a certain objectclass in one patch and another one with the same name (but from another lib) in another patch. please correct me, if I'm wrong. marius. Derek Holzer wrote: Hi all, it seems that the ways of dealing with externals and paths is always in flux! I would like to confirm a suspicion that, for the time being, the following works the way I think it does, assuming PD 0.39: [library/object] imports that specific object into global namespace, and can accommodate different objects with the same name from different libs. This method does not allow access to help patches or abstractions in the library path. [import library] imports the whole library into global namespace, including help patches and other abs (usually, although I have often found this broken in Extended). It cannot accommodate different objects with the same name from different libs, as the last library imported will have priority. Is this correct so far? Has anyone documented this any more substantially anywhere? How does this change for 0.40? best! d. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list - --- Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ macumbista ---Oblique Strategy # 39: Cut a vital connection ¡El pueblo unido jamás será vencido! ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] import vs namespace
Well, we're working on the FLOSS Manual this week as part of a book sprint on the Croatian island of Korcula: http://flossmanuals.net/puredata I know, life's hard sometimes... ;-) We can always add things later, but we'd like something publishable at the end of the week. The we can invite more contributions from others. Do you think we should hold off for the 0.40 release, or just update later? d. Hans-Christoph Steiner wrote: It is hopefully properly implemented with canvas-local and global namespaces. I am aiming to have this all fixed up for the 0.40.3-extended release at the end of the month, then this will be all clearer in my head. When's your deadline? -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 39: Cut a vital connection ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] cheap AVR/HID sensor board
Well, it seems to be in the works, but not there yet... http://code.rancidbacon.com/LearningAboutArduinoAVRUSB best! d. Hans-Christoph Steiner wrote: It would be nice to have a little homebrew recipe for turning the Arduino into the AVR/HID. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 103: Left channel, right channel, centre channel ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] import vs namespace
OK, when I run into it again I'll let you know. Usually this happens in workshops, where other things need to get fixed first ;-) d. Hans-Christoph Steiner wrote: Please file bug reports if you can't load abstractions that way. I think there is one specific case where help patches don't load then, but I don't remember off hand what it was. A bug report for that would also be quite helpful. .hc On Apr 8, 2008, at 11:37 AM, Derek Holzer wrote: But this way doesn't load abstractions and help patches, AFAIK. d. Hans-Christoph Steiner wrote: This is only the case on 0.40 and newer. [import] on 0.39 loads into the global namespace. This stuff is currently alpha and not complete, so it is not very clear. I think for the manual, the best bet for Pd-extended is to use the [library/objectclass] format for objectclasses that aren't loaded by default. That has been supported by every version of Pd for a long time now (as long as you install the libraries that way). .hc On Apr 8, 2008, at 9:22 AM, marius schebella wrote: as far as I understood [import] is the same as [declare -lib] and that only adds a library to the local namespace of a patch. see the help file for declare that comes with 0.41. you can declare your library relative to pd [declare -stdlib] or relative to the patch [declare -lib], but - as mentioned in the helpfile - the name stdpath is confusing!]. it is also not 100% clear, how this works in abstractions and if the behaviour will be consistent with future pd versions. there might be a chance that [import] really adds to the global namespace, but I don't think so. (otoh I don't know how to add something to the global namespace.) the idea was that you can use a certain objectclass in one patch and another one with the same name (but from another lib) in another patch. please correct me, if I'm wrong. marius. Derek Holzer wrote: Hi all, it seems that the ways of dealing with externals and paths is always in flux! I would like to confirm a suspicion that, for the time being, the following works the way I think it does, assuming PD 0.39: [library/object] imports that specific object into global namespace, and can accommodate different objects with the same name from different libs. This method does not allow access to help patches or abstractions in the library path. [import library] imports the whole library into global namespace, including help patches and other abs (usually, although I have often found this broken in Extended). It cannot accommodate different objects with the same name from different libs, as the last library imported will have priority. Is this correct so far? Has anyone documented this any more substantially anywhere? How does this change for 0.40? best! d. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 39: Cut a vital connection ¡El pueblo unido jamás será vencido! -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 72: Find a safe part and use it as an anchor ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] shell scripts to tell which externals are used by patches
Hi all, I wrote some shell scripts to find out which externals my patches need. Download: svn co https://devel.goto10.org/svn/maximus/pdpatchinfo Example usage: $ ./internals.sh ~/src/pd-0.41-4 pd-0.41-4.txt $ ./objs.sh ~/maximus/2008/gg/spiral.pd | ./externals.sh pd-0.41-4.txt colorRGB expr gem2graphgrow gemhead gemwin graphgrow pix_snap2tex rotateXYZ scale scaleXYZ separator square translateXYZ $ Future usage: $ ./objs.sh ~/maximus/2008/gg/spiral.pd | ./externals pd-0.41-4.txt | ./externals pd-0.41-4-bundled.txt | ./externals Gem.txt gem2graphgrow graphgrow $ Notes: (1) ./internal.sh depends on the source code format (which is a bit fragile/hacky). (2) To get a list of objects defined by a library would require patching Pd to add printing to class_new() and class_addcreator(). (3) Haven't yet written the list of the externals bundled with Pd. This message brought to you by the characters #X and the number 247. Claude -- http://claudiusmaximus.goto10.org ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] import vs namespace
Derek Holzer wrote: http://flossmanuals.net/puredata wow! that is quite impressive! marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] import vs namespace
It will be twice as nice by the end of the week, we hope! ;-) Then I'll publish a call to contribute new tutorials. Or maybe you can team up with Screaming Frank Barknecht to do a German version... Hope you're interested! best, d. marius schebella wrote: Derek Holzer wrote: http://flossmanuals.net/puredata wow! that is quite impressive! marius. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 1: (Organic) machinery ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] import vs namespace
I am still interested in producing video tutorials and some use case oriented gem tutorials. but this has to wait a little, right now I don't have the time. marius. Derek Holzer wrote: It will be twice as nice by the end of the week, we hope! ;-) Then I'll publish a call to contribute new tutorials. Or maybe you can team up with Screaming Frank Barknecht to do a German version... Hope you're interested! best, d. marius schebella wrote: Derek Holzer wrote: http://flossmanuals.net/puredata wow! that is quite impressive! marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] PD FLOSS Manual [was: Re: import vs namespace]
Would be very cool. I plan to do a simple GEM VJ mixer tut with two [pix_film] objects and a crossfader. Would be a good base to build on. Let me know when you have time! d. marius schebella wrote: I am still interested in producing video tutorials and some use case oriented gem tutorials. but this has to wait a little, right now I don't have the time. marius. Derek Holzer wrote: It will be twice as nice by the end of the week, we hope! ;-) Then I'll publish a call to contribute new tutorials. Or maybe you can team up with Screaming Frank Barknecht to do a German version... Hope you're interested! best, d. marius schebella wrote: Derek Holzer wrote: http://flossmanuals.net/puredata wow! that is quite impressive! marius. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 14: Ask people to work against their better judgement ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] PD FLOSS Manual [was: Re: import vs namespace]
Hi Mike, my experience with Google, Babelfish, Alta Vista and others are that they are useful in a pinch, but they're no replacement for human translation. Especially with technical terms and such, but in general the differences between grammar and such between languages. Lots of proofreading, with the original in hand, would be required... almost as much work as a real translation, I imagine... Actually some of the other FLOSS Manuals are getting translated into Hindi even as we speak, and there's been a call for Farsi translators as well. I think Adam Hyde (director of FLOSS Manuals project) may also be looking at Dutch translators soon (he lives in NL, which has supported the development of FLOSS Manuals so far through various subsidies). But human translators usually cost some money, so it's all about where the resources can be found to pay them, or where volunteers can be found. But now we get really OT, talking about money ;-) Thanks for the interest and I'll let everyone know when the project opens up for more input. best, d. Mike McGonagle wrote: While I would think that it would be useful to have tutorials written in other languages, why not use some translation tools to make them? And then we can get someone to proof read them in whatever language they are being translated into, that way these tutorials will all offer the same information, rather than limiting them to only those that speak that language. Does Google have some policy about storing and publishing any translations they make? I am not a lawyer, but there is nothing on their translation page as to what you can do with the translated content, and ( http://www.google.com/accounts/TOS?loc=US ) I am not positive if this is the applicable legalese... 11.1 You retain copyright and any other rights you already hold in Content which you submit, post or display on or through, the Services. By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive licence to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any Content which you submit, post or display on or through, the Services. This licence is for the sole purpose of enabling Google to display, distribute and promote the Services and may be revoked for certain Services as defined in the Additional Terms of those Services. So, it sounds like you can do whatever you want with it, as long as Google gets to use it as well. Of Course, that being said, I only speak english, and have rudimentary skills in a couple other languages, so I could only offer to proof read a translation to ensure it makes sense, not that it translated correctly. I will say from what start you have on this Floss stuff is quite nice. If this sounds like a good idea, I would be more than happy to help out with these things. On Tue, Apr 8, 2008 at 11:43 AM, Derek Holzer [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It will be twice as nice by the end of the week, we hope! ;-) Then I'll publish a call to contribute new tutorials. Or maybe you can team up with Screaming Frank Barknecht to do a German version... Hope you're interested! best, d. marius schebella wrote: Derek Holzer wrote: http://flossmanuals.net/puredata wow! that is quite impressive! marius. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 185: Which parts can be grouped? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] import vs namespace
While I would think that it would be useful to have tutorials written in other languages, why not use some translation tools to make them? And then we can get someone to proof read them in whatever language they are being translated into, that way these tutorials will all offer the same information, rather than limiting them to only those that speak that language. Does Google have some policy about storing and publishing any translations they make? I am not a lawyer, but there is nothing on their translation page as to what you can do with the translated content, and ( http://www.google.com/accounts/TOS?loc=US ) I am not positive if this is the applicable legalese... 11.1 You retain copyright and any other rights you already hold in Content which you submit, post or display on or through, the Services. By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive licence to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any Content which you submit, post or display on or through, the Services. This licence is for the sole purpose of enabling Google to display, distribute and promote the Services and may be revoked for certain Services as defined in the Additional Terms of those Services. So, it sounds like you can do whatever you want with it, as long as Google gets to use it as well. Of Course, that being said, I only speak english, and have rudimentary skills in a couple other languages, so I could only offer to proof read a translation to ensure it makes sense, not that it translated correctly. I will say from what start you have on this Floss stuff is quite nice. If this sounds like a good idea, I would be more than happy to help out with these things. On Tue, Apr 8, 2008 at 11:43 AM, Derek Holzer [EMAIL PROTECTED] wrote: It will be twice as nice by the end of the week, we hope! ;-) Then I'll publish a call to contribute new tutorials. Or maybe you can team up with Screaming Frank Barknecht to do a German version... Hope you're interested! best, d. marius schebella wrote: Derek Holzer wrote: http://flossmanuals.net/puredata wow! that is quite impressive! marius. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 1: (Organic) machinery ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] cheap AVR/HID sensor board
On Mar 27, 2008, at 3:33 AM, Steffen Juul wrote: Neat lill' thing. On 27/03/2008, at 2.04, Derek Holzer wrote: The circuit diagram is pretty simple, if you can't etch it I think you could still build it in an afternoon. One would need to (purchase parts to and) build a programmer first, right? Also, i can't find locate the code/hex-file on the website (http:// 1010.co.uk/avrhid.html). I put together a Mouser BOM parts list for this: 534-924 1 517-4828-6004-CP1 774-MP120 1 140-100N5-220J-RC 2 291-4.7K-RC 1 291-2.2K-RC 1 291-100-RC 2 291-330-RC 2 291-10K-RC 1 517-850-01-36 1 78-TLHG5400 1 594-K104K15X7RF53K2 2 140-LLRL16V10-RC2 556-ATMEGA168-20PU 1 http://www.mouser.com/BOM/BOM.aspx There is a little fat in this one, for ease of ordering. It could probably be 'tuned' to get it cheaper. .hc http://at.or.at/hans/ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd eating cpu on os x
Hi, I forgot why exactly Pd was eating 32% of my cpu without doing anything (right after starting, only the pd window). was this because of some quicktime or itunes stuff? how can I turn that off. marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd eating cpu on os x
Hi Marius, you can use shark to investigate the reason for this. On my G4 minimac a _lot_ of time is spent in coreaudio and the driver of the audio interface. gr~~~ Am 08.04.2008 um 22:57 schrieb marius schebella: Hi, I forgot why exactly Pd was eating 32% of my cpu without doing anything (right after starting, only the pd window). was this because of some quicktime or itunes stuff? how can I turn that off. marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list smime.p7s Description: S/MIME cryptographic signature ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd eating cpu on os x
Yes, this came up before on the list. Try JackOSX as an audio server to cut the load a bit. d. Thomas Grill wrote: Hi Marius, you can use shark to investigate the reason for this. On my G4 minimac a _lot_ of time is spent in coreaudio and the driver of the audio interface. gr~~~ Am 08.04.2008 um 22:57 schrieb marius schebella: Hi, I forgot why exactly Pd was eating 32% of my cpu without doing anything (right after starting, only the pd window). was this because of some quicktime or itunes stuff? how can I turn that off. marius. ___ 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 -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 80: Go to an extreme, come part way back ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd eating cpu on os x
Thomas Grill wrote: Hi Marius, you can use shark to investigate the reason for this. On my G4 minimac a _lot_ of time is spent in coreaudio and the driver of the audio interface. gr~~~ Am 08.04.2008 um 22:57 schrieb marius schebella: Hi, I forgot why exactly Pd was eating 32% of my cpu without doing anything (right after starting, only the pd window). was this because of some quicktime or itunes stuff? how can I turn that off. marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list thanks thomas, here's the first 20 processes, is there anything that should worry me? marius. 14.7% 14.7% mach_kernel ml_set_interrupts_enabled 12.3% 12.3% AudioToolbox Resampler2::ConvertAltivec_SmallIntegerRatio(float*, float*, unsigned long, int) 6.1%6.1%com.apple.driver.AppleHDA SInt16ToFloat32 5.0%5.0%com.apple.driver.DspFuncLib DspFuncOrgEQ::_EQBoth(float*, float*, unsigned long, unsigned long) 3.5%3.5%mach_kernel lo_mach_scall 1.9%1.9%com.apple.driver.DspFuncLib DspFuncVolume::process(unsigned long, unsigned long) 1.4%1.4%mach_kernel mutex_lock 1.2%1.2%CoreAudio IOA_Time::GetCurrentTime(AudioTimeStamp) const 1.2%1.2%mach_kernel lo_alltraps 1.1%1.1%IOKit iokit_user_client_trap 1.1%1.1%commpage [libSystem.B.dylib]__spin_lock 1.1%1.1%CoreAudio AUGenericOutputEntry 1.0%1.0%libSystem.B.dylib semaphore_timedwait_signal_trap 0.9%0.9%libSystem.B.dylib semaphore_wait_trap 0.9%0.9%libSystem.B.dylib _pthread_cond_wait 0.9%0.9%commpage [libSystem.B.dylib]__nanotime 0.9%0.9%mach_kernel mutex_unlock 0.8%0.8%commpage [libSystem.B.dylib]__memcpy 0.7%0.7%mach_kernel lck_mtx_lock 0.7%0.7%AudioToolboxResampler2::PushConvert(float*, float*, float*, float*, unsigned long, unsigned long, unsigned long, unsigned long) ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd eating cpu on os x
here's the first 20 processes, is there anything that should worry me? I don't think so... you could compare this to Max/MSP or other audio applications. In my experience using jack imposes additional load, since it will be just another layer between the application and coreaudio. gr~~~ 14.7% 14.7% mach_kernel ml_set_interrupts_enabled 12.3% 12.3% AudioToolbox Resampler2::ConvertAltivec_SmallIntegerRatio(float*, float*, unsigned long, int) 6.1%6.1%com.apple.driver.AppleHDA SInt16ToFloat32 5.0% 5.0% com.apple.driver.DspFuncLib DspFuncOrgEQ::_EQBoth (float*, float*, unsigned long, unsigned long) 3.5%3.5%mach_kernel lo_mach_scall 1.9% 1.9% com.apple.driver.DspFuncLib DspFuncVolume::process (unsigned long, unsigned long) 1.4%1.4%mach_kernel mutex_lock 1.2%1.2%CoreAudio IOA_Time::GetCurrentTime(AudioTimeStamp) const 1.2%1.2%mach_kernel lo_alltraps 1.1%1.1%IOKit iokit_user_client_trap 1.1%1.1%commpage [libSystem.B.dylib]__spin_lock 1.1%1.1%CoreAudio AUGenericOutputEntry 1.0%1.0%libSystem.B.dylib semaphore_timedwait_signal_trap 0.9%0.9%libSystem.B.dylib semaphore_wait_trap 0.9%0.9%libSystem.B.dylib _pthread_cond_wait 0.9%0.9%commpage [libSystem.B.dylib]__nanotime 0.9%0.9%mach_kernel mutex_unlock 0.8%0.8%commpage [libSystem.B.dylib]__memcpy 0.7%0.7%mach_kernel lck_mtx_lock 0.7% 0.7% AudioToolbox Resampler2::PushConvert(float*, float*, float*, float*, unsigned long, unsigned long, unsigned long, unsigned long) smime.p7s Description: S/MIME cryptographic signature ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd eating cpu on os x
ok, thanks too... my experiences seem to be outdated. gr~~~ Am 09.04.2008 um 00:51 schrieb marius schebella: ok, I tested now again with shark, and the jack version really uses less cpu (thnks derek). also, shark adds both cpus, so when I measure 20% on one cpu, then shark only sees 10%. (don't know why I got more than 30% before, now it was back to normal (~20%)) according to shark with portaudio pd uses 9.8% and with jack pd uses 0.8% and jackdmp 4.4%. long live jack! ignore the shark output that I posted before, I think it was only the pd process alone and the percentage was related only to the pd process. marius. Thomas Grill wrote: here's the first 20 processes, is there anything that should worry me? I don't think so... you could compare this to Max/MSP or other audio applications. In my experience using jack imposes additional load, since it will be just another layer between the application and coreaudio. gr~~~ 14.7% 14.7% mach_kernel ml_set_interrupts_enabled 12.3% 12.3% AudioToolbox Resampler2::ConvertAltivec_SmallIntegerRatio(float*, float*, unsigned long, int) 6.1% 6.1% com.apple.driver.AppleHDA SInt16ToFloat32 5.0% 5.0% com.apple.driver.DspFuncLib DspFuncOrgEQ::_EQBoth (float*, float*, unsigned long, unsigned long) 3.5% 3.5% mach_kernel lo_mach_scall 1.9% 1.9% com.apple.driver.DspFuncLib DspFuncVolume::process (unsigned long, unsigned long) 1.4% 1.4% mach_kernel mutex_lock 1.2% 1.2% CoreAudio IOA_Time::GetCurrentTime(AudioTimeStamp) const 1.2% 1.2% mach_kernel lo_alltraps 1.1% 1.1% IOKit iokit_user_client_trap 1.1% 1.1% commpage [libSystem.B.dylib] __spin_lock 1.1% 1.1% CoreAudio AUGenericOutputEntry 1.0% 1.0% libSystem.B.dylib semaphore_timedwait_signal_trap 0.9% 0.9% libSystem.B.dylib semaphore_wait_trap 0.9% 0.9% libSystem.B.dylib _pthread_cond_wait 0.9% 0.9% commpage [libSystem.B.dylib] __nanotime 0.9% 0.9% mach_kernel mutex_unlock 0.8% 0.8% commpage [libSystem.B.dylib] __memcpy 0.7% 0.7% mach_kernel lck_mtx_lock 0.7% 0.7% AudioToolbox Resampler2::PushConvert(float*, float*, float*, float*, unsigned long, unsigned long, unsigned long, unsigned long) smime.p7s Description: S/MIME cryptographic signature ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] midi on 0.40.3-extended
Hey Zé, I just used a gambiarra borrowed from a discussion somewhere in this list: http://www.apple.com/downloads/macosx/audio/simplesynth.html Set this software as you MIDI out. Where are you? I am in BH for the moment. Best Luiz On Mon, Apr 7, 2008 at 6:17 PM, padovani [EMAIL PROTECTED] wrote: Is anyone experiencing problems to play midi through QuickTimeMIDI on PD on Leopard (intel)? I've tried three different versions of the 0.40.3-extended for Mac i386 (after having tried the 0.39 version that crashed) and couldn't reach any Midi output device... other Apps play midi through quicktime with no problem... ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Luiz Naveda _ Mobile: + 32 0487 245594 IPEM - Dep. of Musicology Blandijnberg 2 Ghent University, Ghent, B-9000 Belgium ^v^ ^v^ ^v^ ^~^~^~^~^~^~^~^~~^~~^~~^~^~^~~~^^~^ ^~^~^~^~^~^~^~^~^~^~~^~~^~~^~^~^~~~^~~~ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD extended for Ubuntu gutsy : dependencies?
It was a quick hack we did at LAC, but it turns out that there is a Debian tool for this, that's probably the better choice. I think the tool is dpkg-shlibsdeps, but I am just guessing. This seems to be a pretty good article on this: http://www.debian-administration.org/articles/337 .hc On Apr 7, 2008, at 3:58 PM, niko wrote: hi i had the same issue with dependencies on gutsy some days ago maybe the system with autodetection still does not work as it should :) greetings nikola Georg Holzmann wrote: Hallo! I just proceeded to the install of Pd version 0.3- extended-20080402 on a friend's brand new ubuntu gutsy i386 install Thanks for your report - did you install an autobuild version ? Because I just changed the debian packages in the latest autobuild version which tries to detect the dependencies automatically ... so any testing is very welcome ;) ! LG Georg ___ 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 Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] makefilename crash
Move the bug report to Pd-extended, and I'll include the fix. I have been backporting bug fixes from 0.41 .hc On Apr 8, 2008, at 6:47 AM, Derek Holzer wrote: OK, I'll go through all the archives... want to stick with 0.39 until I know more about what changes in 0.40, 0.41... and want to stick with Extended. I guess there's no retroactive bugfixes ;-) best, d. IOhannes m zmoelnig wrote: Derek Holzer wrote: Just discovered this last night. Should I file a bug report? just upgrade to at least Pd-0.41; this bug has been reported and fixed in the past. When a float or numeric message (is this the same type as float automatically?) yes Simply sending a text-message to the same object without using a [symbol] object to set the type results in a far more benign: error: makefilename: no method for 'dave' hmm, should we go through the entire equivalency-of-messages-thing again? fmgadf IOhannes -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ macumbista ---Oblique Strategy # 5: Abandon normal instructions ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list There is no way to peace, peace is the way. -A.J. Muste ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
