Re: [PD] DSP abstractions [was: netpd ...]
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: I really like the idea of a standard library of DSP objects. I think that one thing that can really make this project that much better is having a clearly defined, usable, and clean common interface for this library. I think it would be nice to use some inlets, rather than just one inlet and a bunch of special messages. So there could be defined classes of objects (synths, filters, effects, etc.), and each would have a standard interface. So all synths would have frequency and amplitude inlets, for example. Another key part of this is using standard values for each thing. For example, with filters, they can be specified using Q and f point, or f and filter order (1st order/6dB, 2nd order/12dB, etc.), or other techniques. Ideally, there would be a standard filter interface for this standard lib. All this is so orthogonal to my original goals (described in my first mail in this thread [1]) that I'd not be able to contribute anymore. [1] http://lists.puredata.info/pipermail/pd-list/2007-06/051109.html Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On Jun 17, 2007, at 7:11 AM, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: On Sun, 2007-06-17 at 11:10 +0200, Frank Barknecht wrote: Then it won't work for people who have iemlib installed somewhere else and/or load it as a library. i thought, we do that effort to include the result into pd-extended? To me this isn't about enforcing a certain kind of Pd-distribution, but just collecting dsp-abstractions in one place, together with help-files, to give peoply the freedom to use them in any way they like. However [iemlib/bp2~] is an object name, that outside of Pd-extended is completely unknown. Unless, of course, you compile iemlib and stick the binaries into extra/iemlib, then it'll work on any version/distro of Pd. .hc if that is the case, shouldn't we focus on make it working there first? Then [import iemlib], [declare -lib iemlib] or so is better. This would give an error, if import isn't available, but at least the abstraction would still work, if someone loads iemlib as a library. Also bp2~.pd is just an abstraction that inside calls [filter~] which is a part of iemlib as well, so loading iemlib as a library/libdir may be necessary anyways. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ 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] DSP abstractions [was: netpd ...]
On Jun 17, 2007, at 7:44 AM, Roman Haefeli wrote: On Sun, 2007-06-17 at 13:11 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: On Sun, 2007-06-17 at 11:10 +0200, Frank Barknecht wrote: Then it won't work for people who have iemlib installed somewhere else and/or load it as a library. i thought, we do that effort to include the result into pd-extended? To me this isn't about enforcing a certain kind of Pd-distribution, but just collecting dsp-abstractions in one place, together with help-files, to give peoply the freedom to use them in any way they like. However [iemlib/bp2~] is an object name, that outside of Pd-extended is completely unknown. it was not my intention to define, for what purpose these dsp-objects are collected. the original question for this thread was: 'why are they not in pd-extended yet?', that is why i assumed, we collect them for pd-extended. if that is the case, shouldn't we focus on make it working there first? Then [import iemlib], [declare -lib iemlib] or so is better. This would give an error, if import isn't available, but at least the abstraction would still work, if someone loads iemlib as a library. no, because in pd-extended the iemlib-objects are directly in / extra and the abstractions are in extra/iemlib, whereas in a common iemlib installation, some objects are in iemlib1 external, others in the iemlib2 external and the abstractions are in a folder called 'iemabs'. If it makes more sense for the heavy users of iemlib stuff, the stuff in Pd-extended could be separated into iemlib1, iemlib2, and iemabs folders. I think that it probably makes sense to keep the binaries from both iemlib1 and iemlib2 in iemlib since you'd never use the name iemlib1 or iemlib2. But it might make more sense to put the iemabs into a iemabs libdir. I stuck them all together so that the abs would find their dependencies without needing a namespace prefix or an [import]/ [declare] statement (since a patch searches its own directory first when loading objects IIRC). .hc Also bp2~.pd is just an abstraction that inside calls [filter~] which is a part of iemlib as well, so loading iemlib as a library/libdir may be necessary anyways. yes: [bp2~] uses [filter~] no: loading the library or the libdir is not necessary in pd-extended, because [filter~] is directly in the extra folder. if i am not totally mistaken, there is no way to ensure, that it works in pd-extended and in non-extended pd at the same time. that means, we have to decide, whether our purpose is to focus on making it work in pd-extended or in pd-vanilla with regular externals installed. it's a pity, but i think, that is how things are. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On Jun 17, 2007, at 8:36 AM, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: Then [import iemlib], [declare -lib iemlib] or so is better. This would give an error, if import isn't available, but at least the abstraction would still work, if someone loads iemlib as a library. no, because in pd-extended the iemlib-objects are directly in / extra and the abstractions are in extra/iemlib, whereas in a common iemlib installation, some objects are in iemlib1 external, others in the iemlib2 external and the abstractions are in a folder called 'iemabs'. Yes, but that's why I said, that depending on installation, the object with the name [bp2~] may also be available under different aliases like [iemlib/bp2~], [iemabs/bp2~] or [myfavouriteabstractions/bp2~]. The canonical name for this object however as it's defined in the iemlib installation instructions for many years, is just [bp2~] and that will work on any system, if the path to that abstraction is set accordingly by whatever means currently are hot, be it .pdrc, .pdsettings, File-Path, [import iemlib], [declare -path ...] or [declare -stdpath ...] (when the declare path in abstractions bug is fixed). no: loading the library or the libdir is not necessary in pd- extended, because [filter~] is directly in the extra folder. It is? Pd-extended continues to surprise/confuse me sometimes ... How is it decided what is directly in extra and what not? There is lots of ugliness because there is often little agreement as to how to organize Pd code. We have just gotten to the point where it seems everyone agrees to name their files after their objects (e.g. [filter~] == filter~.c, rather than sigfilter.c). That helps eliminate some ugliness. The grand plan is to have nothing directly in extra. But there are also still many quick hacks to get things working, so there is stuff directly in extra, and weird things like flatspace. If this was my full time job, this kind of stuff would not happen. But alas, it's what I do after hours, for the most part. .hc Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On Jun 15, 2007, at 3:08 PM, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: without designing to much, how this collection could look like, there are might some little conventions, that we could make up (these are meant as proposals): - finding a naming scheme, maybe using a prefix like dsp_ (similar to the list-abs). I think, this might be done later with a simple directory-prefix. If the help-files themselves use the objects without any dir-prefix, then the name could be decided later and they would still be useable with standard methods of setting only the -path. I didn't use a directory prefix, but instead a hardcoded prefix for [list]-abs mostly because many of them are impossible to use without the prefix anyways since they nameclash with existing objects like [list-moses] vs. [moses]. So import list doesn't make any sense for them. But for the dsp-collection I think, a directory prefix would make sense. - using messages like 'frequency 123' to set parameters, which are routed inside the abstraction. with such a design, only one inlet for an arbitrary number of parameters is needed. Yes, that could be a kind of good practice recommendation. I do this in my personal abstractions a lot, where I now use the attached dispatcher to automate the creation of the necessary [route frequency] and [s $0-frequency] chains plus a tiny help-feature. (Requires pd-0.40 and up because of $1-$2) I really like the idea of a standard library of DSP objects. I think that one thing that can really make this project that much better is having a clearly defined, usable, and clean common interface for this library. I think it would be nice to use some inlets, rather than just one inlet and a bunch of special messages. So there could be defined classes of objects (synths, filters, effects, etc.), and each would have a standard interface. So all synths would have frequency and amplitude inlets, for example. Another key part of this is using standard values for each thing. For example, with filters, they can be specified using Q and f point, or f and filter order (1st order/6dB, 2nd order/12dB, etc.), or other techniques. Ideally, there would be a standard filter interface for this standard lib. Then for non-standard things, I think makes sense to use the messages to the first inlet. Or perhaps the first three inlets would always be the same thing, then the others would be available for special parameters. Also, standard units are important. For example, I think that the pitch/frequency inlet should accept values in Hz and the amplitude should always be between 0-1 like the rest of Pd. There was some discussion about this last year: http://lists.puredata.info/pipermail/pd-list/2006-03/036800.html just my two bits... .hc - the helpfile should at least describe the available parameters and their default values. Yes++. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ dispatcher-help.pd dispatcher.pd ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: On Sat, 2007-06-16 at 18:06 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: oops, i thought, they are done in plain pd. [bp2~] is abstraction from iemabs based on [filter~], which is either in iemlib1 or iemlib2. but since these abs are intended to be included into pd-extended, it shouldn't be a problem, that [bp2~] is used. It also still sounds okay, though different, if replaced with [bp~]. yeah, but definitely not like the original 808 clap [1]. i am bit finical about that ;-) assuming i want to keep [bp2~], would it be better to replace it by [iemlib/bp2~] to make it work out of the box in pd-extended, right? Then it won't work for people who have iemlib installed somewhere else and/or load it as a library. You could built your own bp2~ using elementary filters. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
Yes, please do this. I always get confused with the zillion iem-libs out there. Can they just be either broken apart or consolidated? It makes searching the docs pretty rough. ~Kyle On 6/16/07, Roman Haefeli [EMAIL PROTECTED] wrote: assuming i want to keep [bp2~], would it be better to replace it by [iemlib/bp2~] to make it work out of the box in pd-extended, right? [1] http://machines.hyperreal.org/manufacturers/Roland/TR-808/samples/808-CP.zip roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On Sun, 2007-06-17 at 11:10 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: On Sat, 2007-06-16 at 18:06 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: oops, i thought, they are done in plain pd. [bp2~] is abstraction from iemabs based on [filter~], which is either in iemlib1 or iemlib2. but since these abs are intended to be included into pd-extended, it shouldn't be a problem, that [bp2~] is used. It also still sounds okay, though different, if replaced with [bp~]. yeah, but definitely not like the original 808 clap [1]. i am bit finical about that ;-) assuming i want to keep [bp2~], would it be better to replace it by [iemlib/bp2~] to make it work out of the box in pd-extended, right? Then it won't work for people who have iemlib installed somewhere else and/or load it as a library. i thought, we do that effort to include the result into pd-extended? if that is the case, shouldn't we focus on make it working there first? You could built your own bp2~ using elementary filters. yeah, i personally would prefer that way, but i know too little about filterdesign to implement it myself. since it is meant to be in pd-extended anyway, what speaks against using externals here? 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] DSP abstractions [was: netpd ...]
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: On Sun, 2007-06-17 at 11:10 +0200, Frank Barknecht wrote: Then it won't work for people who have iemlib installed somewhere else and/or load it as a library. i thought, we do that effort to include the result into pd-extended? To me this isn't about enforcing a certain kind of Pd-distribution, but just collecting dsp-abstractions in one place, together with help-files, to give peoply the freedom to use them in any way they like. However [iemlib/bp2~] is an object name, that outside of Pd-extended is completely unknown. if that is the case, shouldn't we focus on make it working there first? Then [import iemlib], [declare -lib iemlib] or so is better. This would give an error, if import isn't available, but at least the abstraction would still work, if someone loads iemlib as a library. Also bp2~.pd is just an abstraction that inside calls [filter~] which is a part of iemlib as well, so loading iemlib as a library/libdir may be necessary anyways. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On Sun, 2007-06-17 at 13:11 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: On Sun, 2007-06-17 at 11:10 +0200, Frank Barknecht wrote: Then it won't work for people who have iemlib installed somewhere else and/or load it as a library. i thought, we do that effort to include the result into pd-extended? To me this isn't about enforcing a certain kind of Pd-distribution, but just collecting dsp-abstractions in one place, together with help-files, to give peoply the freedom to use them in any way they like. However [iemlib/bp2~] is an object name, that outside of Pd-extended is completely unknown. it was not my intention to define, for what purpose these dsp-objects are collected. the original question for this thread was: 'why are they not in pd-extended yet?', that is why i assumed, we collect them for pd-extended. if that is the case, shouldn't we focus on make it working there first? Then [import iemlib], [declare -lib iemlib] or so is better. This would give an error, if import isn't available, but at least the abstraction would still work, if someone loads iemlib as a library. no, because in pd-extended the iemlib-objects are directly in /extra and the abstractions are in extra/iemlib, whereas in a common iemlib installation, some objects are in iemlib1 external, others in the iemlib2 external and the abstractions are in a folder called 'iemabs'. Also bp2~.pd is just an abstraction that inside calls [filter~] which is a part of iemlib as well, so loading iemlib as a library/libdir may be necessary anyways. yes: [bp2~] uses [filter~] no: loading the library or the libdir is not necessary in pd-extended, because [filter~] is directly in the extra folder. if i am not totally mistaken, there is no way to ensure, that it works in pd-extended and in non-extended pd at the same time. that means, we have to decide, whether our purpose is to focus on making it work in pd-extended or in pd-vanilla with regular externals installed. it's a pity, but i think, that is how things are. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
well my mac just totally died, so i am going 100% linux from now on, and bp2~ doesn't work. but i am going 100% linux, so i am getting used to things not working ;) filter~ seems to work ok though, so i guess the path to the abstraction is not set. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On Sun, 2007-06-17 at 21:00 +0900, hard off wrote: well my mac just totally died, so i am going 100% linux from now on, and bp2~ doesn't work. but i am going 100% linux, so i am getting used to things not working ;) i'd say you are getting used to get things fixed instead of having to live with broken things ;-) good luck, then. filter~ seems to work ok though, so i guess the path to the abstraction is not set. without caring about what is set wrong on your system: [bp2~] does work on linux in general. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: Then [import iemlib], [declare -lib iemlib] or so is better. This would give an error, if import isn't available, but at least the abstraction would still work, if someone loads iemlib as a library. no, because in pd-extended the iemlib-objects are directly in /extra and the abstractions are in extra/iemlib, whereas in a common iemlib installation, some objects are in iemlib1 external, others in the iemlib2 external and the abstractions are in a folder called 'iemabs'. Yes, but that's why I said, that depending on installation, the object with the name [bp2~] may also be available under different aliases like [iemlib/bp2~], [iemabs/bp2~] or [myfavouriteabstractions/bp2~]. The canonical name for this object however as it's defined in the iemlib installation instructions for many years, is just [bp2~] and that will work on any system, if the path to that abstraction is set accordingly by whatever means currently are hot, be it .pdrc, .pdsettings, File-Path, [import iemlib], [declare -path ...] or [declare -stdpath ...] (when the declare path in abstractions bug is fixed). no: loading the library or the libdir is not necessary in pd-extended, because [filter~] is directly in the extra folder. It is? Pd-extended continues to surprise/confuse me sometimes ... How is it decided what is directly in extra and what not? Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
Hallo! no: loading the library or the libdir is not necessary in pd-extended, because [filter~] is directly in the extra folder. It is? Pd-extended continues to surprise/confuse me sometimes ... How is it decided what is directly in extra and what not? No, its not in extra - at least not in the latest autobuild versions ... Everything (binaries and abs) are in the extra/iemlib folder. LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
Hallo! You could built your own bp2~ using elementary filters. yeah, i personally would prefer that way, but i know too little about filterdesign to implement it myself. I think it is not a good idea to represent every object in abstractions ... why not is the c object if it is already here and wide distributed (like the iemlib). I know that its nice if there are no additional dependencies, but then you restrict yourself to a given set of object, where one person decides if you can use it or not (Miller) - and not everything is possible as abstractions (at least not efficient). LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On Sun, 2007-06-17 at 15:10 +0200, Georg Holzmann wrote: Hallo! no: loading the library or the libdir is not necessary in pd-extended, because [filter~] is directly in the extra folder. It is? Pd-extended continues to surprise/confuse me sometimes ... How is it decided what is directly in extra and what not? No, its not in extra - at least not in the latest autobuild versions ... Everything (binaries and abs) are in the extra/iemlib folder. but it is in extra in: Pure Data 0.39.2-extended-test3-extended-test3 (this is the version mentioned in the Readme.html in pd-extended for windows) i am confused as well. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On Sun, 2007-06-17 at 14:36 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: Then [import iemlib], [declare -lib iemlib] or so is better. This would give an error, if import isn't available, but at least the abstraction would still work, if someone loads iemlib as a library. no, because in pd-extended the iemlib-objects are directly in /extra and the abstractions are in extra/iemlib, whereas in a common iemlib installation, some objects are in iemlib1 external, others in the iemlib2 external and the abstractions are in a folder called 'iemabs'. Yes, but that's why I said, that depending on installation, the object with the name [bp2~] may also be available under different aliases like [iemlib/bp2~], [iemabs/bp2~] or [myfavouriteabstractions/bp2~]. The canonical name for this object however as it's defined in the iemlib installation instructions for many years, is just [bp2~] and that will work on any system, if the path to that abstraction is set accordingly by whatever means currently are hot, be it .pdrc, .pdsettings, File-Path, [import iemlib], [declare -path ...] or [declare -stdpath ...] (when the declare path in abstractions bug is fixed). yo, you definitely convinced me. thanks for your effort. but still, if i want to load the lib and the path with [declare], i'd have to set both pathes, '-stdpath iemlib' and '-stdpath iemabs' and in either case, one would cause an error. such situations make me unhappy :-( 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] DSP abstractions [was: netpd ...]
Hallo! but it is in extra in: Pure Data 0.39.2-extended-test3-extended-test3 yes, version 0.39.2. The latest (unstable) 0.40 version is always on http://autobuild.puredata.org/auto-build/. There are many more externals and more other stuff changed ... ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On Sun, 2007-06-17 at 15:36 +0200, Roman Haefeli wrote: On Sun, 2007-06-17 at 15:10 +0200, Georg Holzmann wrote: Hallo! no: loading the library or the libdir is not necessary in pd-extended, because [filter~] is directly in the extra folder. It is? Pd-extended continues to surprise/confuse me sometimes ... How is it decided what is directly in extra and what not? No, its not in extra - at least not in the latest autobuild versions ... Everything (binaries and abs) are in the extra/iemlib folder. but it is in extra in: Pure Data 0.39.2-extended-test3-extended-test3 (this is the version mentioned in the Readme.html in pd-extended for windows) i am confused as well. and it is not in: Pd-0.39.2-extended-rc2 yo, it seems, that what you described, georg, became the standard. 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] DSP abstractions [was: netpd ...]
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: but still, if i want to load the lib and the path with [declare], i'd have to set both pathes, '-stdpath iemlib' and '-stdpath iemabs' and in either case, one would cause an error. such situations make me unhappy :-( Well, but that's the unhappy part of Pd-life: For every external in use, someone has to make sure, that this external is available. As I have no control over what people are using (and I don't want to control them anyway), it's in the user's responsibility to make that external available. We can only give hints with import or declare or a README. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
hello, Frank Barknecht a écrit : Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: but still, if i want to load the lib and the path with [declare], i'd have to set both pathes, '-stdpath iemlib' and '-stdpath iemabs' and in either case, one would cause an error. such situations make me unhappy :-( Well, but that's the unhappy part of Pd-life: For every external in use, someone has to make sure, that this external is available. As I have no control over what people are using (and I don't want to control them anyway), it's in the user's responsibility to make that external available. We can only give hints with import or declare or a README. Ciao I just want to make one thing clear. The good reason for not loading all externals and abstraction at pd start-up is because it would take a lot of memory, and might cause many kinds of problems difficult to track? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On Sun, 2007-06-17 at 15:19 +0200, Georg Holzmann wrote: Hallo! You could built your own bp2~ using elementary filters. yeah, i personally would prefer that way, but i know too little about filterdesign to implement it myself. I think it is not a good idea to represent every object in abstractions ... why not is the c object if it is already here and wide distributed (like the iemlib). I know that its nice if there are no additional dependencies, but then you restrict yourself to a given set of object, where one person decides if you can use it or not (Miller) - and not everything is possible as abstractions (at least not efficient). using externals is a pain, when focussing on portability. see that thread. 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] DSP abstractions [was: netpd ...]
Hallo! using externals is a pain, when focussing on portability. see that thread. Yes, but the solution is not to say that one should not use externals at all - instead externals should be better distributed, like e.g. with pd-extended ... LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On Sun, 2007-06-17 at 16:39 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: but still, if i want to load the lib and the path with [declare], i'd have to set both pathes, '-stdpath iemlib' and '-stdpath iemabs' and in either case, one would cause an error. such situations make me unhappy :-( Well, but that's the unhappy part of Pd-life: For every external in use, someone has to make sure, that this external is available. As I have no control over what people are using (and I don't want to control them anyway), it's in the user's responsibility to make that external available. We can only give hints with import or declare or a README. i do not agree, that we (pd-users) should just stick with that. i know, this is a very old story, but if there would be a unified way to load externals, it would be no problem at all to make patches, that make use of externals, work out of the box. to delegate this issue to the user just doesn't have any advantage at all. it is not only, that i think, it would be good to have a unified way, it's also that discussions like this one take so much energy, that could be spend better for other things (like creating abstractions for the dsplib). it is frustrating me a bit, that the good idea of a dsp-abs collection is eaten up by a discussion, that wouldn't exist, if there'd be a unified way. in the end, the only 'portable' way of specifying externals, is to mention them in the help-file :-( roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On Sun, 2007-06-17 at 17:20 +0200, Georg Holzmann wrote: Hallo! using externals is a pain, when focussing on portability. see that thread. Yes, but the solution is not to say that one should not use externals at all - instead externals should be better distributed, like e.g. with pd-extended ... but when making things work for pd-extended, they don't work in other environments and vice versa. we are turning around in the same circle again and again.. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
Hallo! i do not agree, that we (pd-users) should just stick with that. i know, this is a very old story, but if there would be a unified way to load externals, it would be no problem at all to make patches, that make use of externals, work out of the box. to delegate this issue to the user just doesn't have any advantage at all. that's what should be possible with pd-extended ... LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On Sun, 2007-06-17 at 17:33 +0200, Georg Holzmann wrote: Hallo! i do not agree, that we (pd-users) should just stick with that. i know, this is a very old story, but if there would be a unified way to load externals, it would be no problem at all to make patches, that make use of externals, work out of the box. to delegate this issue to the user just doesn't have any advantage at all. that's what should be possible with pd-extended ... what extended does, cannot be considered as a 'unified' way at all, since it works differently from pd-vanilla with the common way of installing externals. it is stupid, but since pd-extended, one has to decide, wheather he/she wants to make something work for pd-extended or for pd-vanilla/externals. is that what is called 'unified'? roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: On Sun, 2007-06-17 at 16:39 +0200, Frank Barknecht wrote: Well, but that's the unhappy part of Pd-life: For every external in use, someone has to make sure, that this external is available. As I have no control over what people are using (and I don't want to control them anyway), it's in the user's responsibility to make that external available. We can only give hints with import or declare or a README. i do not agree, that we (pd-users) should just stick with that. As I see it we kind of have to stick with that for now, unless we want to force everyone to set up their systems exactly the same and to install all externals. And with everyone I'm not only talking about users, but also about developers (i.e. the author of bp2~.pd which doesn't use import or declare or a directory prefix in front of [filter~]) And it's not only about externals, it's also about differences like the setable sends, [list length] etc. in 0.40 which are all missing in the latest stable pd-extended. If you want to use these, you have to ask the user to install a more recent version of Pd anyway in a README. But actually with pd-extended it's not hard to make most externals available right from the start. In fact, most libraries like zexy or iemlib or so are all activated in pd-extended, at least the .pdsettings of RC2 has a lot of stuff already in it, so there's not much user interaction involved. Regarding the missing bp2~: I think, this abstraction is more or less gone and replaced by bpq2~.pd and bpw2~.pd. At least these are included in pd-extended. Probably your TR808 will clap correctly for every pd-extended user if you use these names instead. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
This is a bit off the current thread, but is still relevant to the subject. I like the discussion about DSP-abs, but in my opinion, we should not forget also the CTRL-abs that netpd provides. I think that the sequencer objects in there are quite efficient and usable from a newbie point of view, and whereas getting crazy bleeps and bloops out of Pd can be done quickly with a help file or two, creating a decent sequence is a little more removed/frustrating. So carry on guys, I am enjoying following this thread even though I haven't said much. Just please do not forget about the non-DSP abstractions in netpd! ~Kyle On 6/17/07, Roman Haefeli [EMAIL PROTECTED] wrote: On Sun, 2007-06-17 at 16:39 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: but still, if i want to load the lib and the path with [declare], i'd have to set both pathes, '-stdpath iemlib' and '-stdpath iemabs' and in either case, one would cause an error. such situations make me unhappy :-( Well, but that's the unhappy part of Pd-life: For every external in use, someone has to make sure, that this external is available. As I have no control over what people are using (and I don't want to control them anyway), it's in the user's responsibility to make that external available. We can only give hints with import or declare or a README. i do not agree, that we (pd-users) should just stick with that. i know, this is a very old story, but if there would be a unified way to load externals, it would be no problem at all to make patches, that make use of externals, work out of the box. to delegate this issue to the user just doesn't have any advantage at all. it is not only, that i think, it would be good to have a unified way, it's also that discussions like this one take so much energy, that could be spend better for other things (like creating abstractions for the dsplib). it is frustrating me a bit, that the good idea of a dsp-abs collection is eaten up by a discussion, that wouldn't exist, if there'd be a unified way. in the end, the only 'portable' way of specifying externals, is to mention them in the help-file :-( roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
sorry for double posting again: i thought, the bandlimited oscillators would fit as well into dsplib : [blsaw~] [blsquare~] [bltriangle~] still on: http://www.romanhaefeli.net/software/pd/dsplib.tar.gz roman On Fri, 2007-06-15 at 22:20 +0200, Roman Haefeli wrote: to make a start, i put these two abstractions together (with according helpfiles): [tr808-bd~] [tr808-cp~] (which are part of my try to rebuild all 808-instruments in plain pd, but unfortunately i lost most of the instrumenst during a harddisk backup, which made me so depressed, that i made this song: http://195.176.254.167/~all/mp3/2006-08-15_backup_blues.mp3 ) you can get them here: http://www.romanhaefeli.net/software/pd/dsplib.tar.gz i still don't know, what is the best way to get them into cvs. will someone collect all the works and include them? i do actually not have writing access to cvs. 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] DSP abstractions [was: netpd ...]
sorry for double posting, but it seems, that it is not only me who didn't receive that mail: to make a start, i put these two abstractions together (with according helpfiles): [tr808-bd~] [tr808-cp~] (which are part of my try to rebuild all 808-instruments in plain pd, but unfortunately i lost most of the instrumenst during a harddisk backup, which made me so depressed, that i made this song: http://195.176.254.167/~all/mp3/2006-08-15_backup_blues.mp3 ) you can get them here: http://www.romanhaefeli.net/software/pd/dsplib.tar.gz i still don't know, what is the best way to get them into cvs. will someone collect all the works and include them? i do actually not have writing access to cvs. roman On Fri, 2007-06-15 at 18:40 +0200, Frank Barknecht wrote: Hallo, Patco hat gesagt: // Patco wrote: Hello, Frank Barknecht a écrit : All that would be necessary are a clean and documented interfaces for the DSP abstractions. Yes exactly. Things like state saving, GUIs or network control then could easily be built as wrapper abstractions. It might be necessary to have a bridge between the wrapper and the DSP abs. This bridge would find all GUIs inside DSP abstraction, IMO there should be no GUI at all inside the actual DSP abstraction, just a couple of documented(!) inlets and arguments. and construct a wrapper with all necessary GUIs concatenated into one dynamically made abstraction. A bridge with automated service discovery could be nice, but I fear that it may also be too much bureaucracy and in the end may not help, but hinder moving forward and actually getting things done. The first step should be to 1) abstract DSP out into abstraction and 2) at the same time document each of them with a stupid black and white, help-patch. That help-patch may be quick and dirty, but it must *exist*. Keeping formalisms and requirements on help-patches etc. low, in the end will lead to them actually being written, instead of just being planned. For example every single [list]-abs has a help patch. They aren't pretty or anything, they don't all have the same layout, but they are there, which to me, now is the most important thing. (It took me a while to realize this. For example many RRADical abstractions are not documented ...) And a service discovery bridge may also be built later as a decorator abstraction itself around the original abstractions. Ciao ___ Der fr�he Vogel f�ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
i sent my two previous mails again, but it seems, that they didn't make it through again. but they are in the archives: [1] http://lists.puredata.info/pipermail/pd-list/2007-06/051118.html [2] http://lists.puredata.info/pipermail/pd-list/2007-06/051121.html (sorry for spaming the list with those two mails over and over again) cheers roman On Sun, 2007-06-17 at 00:18 +0100, Andy Farnell wrote: I missed that thread. Any1 got a copy of Romans tune? a. On Sat, 16 Jun 2007 08:24:53 +0900 hard off [EMAIL PROTECTED] wrote: beautiful piece roman, so lush. thanks for the dsp objects too. ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
hey roman, what is bp2~ in the clap patch? is it an abstraction? care to post it? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
oops, i thought, they are done in plain pd. [bp2~] is abstraction from iemabs based on [filter~], which is either in iemlib1 or iemlib2. but since these abs are intended to be included into pd-extended, it shouldn't be a problem, that [bp2~] is used. roman On Sat, 2007-06-16 at 23:04 +0900, hard off wrote: hey roman, what is bp2~ in the clap patch? is it an abstraction? care to post it? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ 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] DSP abstractions [was: netpd ...]
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: oops, i thought, they are done in plain pd. [bp2~] is abstraction from iemabs based on [filter~], which is either in iemlib1 or iemlib2. but since these abs are intended to be included into pd-extended, it shouldn't be a problem, that [bp2~] is used. It also still sounds okay, though different, if replaced with [bp~]. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
Man, that sucks about the backup wackiness. Good thing your netpd efforts have multiple data sources for retention! ~Kyle On 6/15/07, Roman Haefeli [EMAIL PROTECTED] wrote: (which are part of my try to rebuild all 808-instruments in plain pd, but unfortunately i lost most of the instrumenst during a harddisk backup, which made me so depressed, that i made this song: http://195.176.254.167/~all/mp3/2006-08-15_backup_blues.mp3 ) you can get them here: http://www.romanhaefeli.net/software/pd/dsplib.tar.gz i still don't know, what is the best way to get them into cvs. will someone collect all the works and include them? i do actually not have writing access to cvs. roman On Fri, 2007-06-15 at 18:40 +0200, Frank Barknecht wrote: Hallo, Patco hat gesagt: // Patco wrote: Hello, Frank Barknecht a Ã(c)crit : All that would be necessary are a clean and documented interfaces for the DSP abstractions. Yes exactly. Things like state saving, GUIs or network control then could easily be built as wrapper abstractions. It might be necessary to have a bridge between the wrapper and the DSP abs. This bridge would find all GUIs inside DSP abstraction, IMO there should be no GUI at all inside the actual DSP abstraction, just a couple of documented(!) inlets and arguments. and construct a wrapper with all necessary GUIs concatenated into one dynamically made abstraction. A bridge with automated service discovery could be nice, but I fear that it may also be too much bureaucracy and in the end may not help, but hinder moving forward and actually getting things done. The first step should be to 1) abstract DSP out into abstraction and 2) at the same time document each of them with a stupid black and white, help-patch. That help-patch may be quick and dirty, but it must *exist*. Keeping formalisms and requirements on help-patches etc. low, in the end will lead to them actually being written, instead of just being planned. For example every single [list]-abs has a help patch. They aren't pretty or anything, they don't all have the same layout, but they are there, which to me, now is the most important thing. (It took me a while to realize this. For example many RRADical abstractions are not documented ...) And a service discovery bridge may also be built later as a decorator abstraction itself around the original abstractions. Ciao ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
Yeah Roman, your track is really nice--good for a late night/early morning chill out before bedtime. ~Kyle On 6/15/07, hard off [EMAIL PROTECTED] wrote: beautiful piece roman, so lush. thanks for the dsp objects too. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- - - - -- http://perhapsidid.wordpress.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On Sat, 2007-06-16 at 18:06 +0200, Frank Barknecht wrote: Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: oops, i thought, they are done in plain pd. [bp2~] is abstraction from iemabs based on [filter~], which is either in iemlib1 or iemlib2. but since these abs are intended to be included into pd-extended, it shouldn't be a problem, that [bp2~] is used. It also still sounds okay, though different, if replaced with [bp~]. yeah, but definitely not like the original 808 clap [1]. i am bit finical about that ;-) assuming i want to keep [bp2~], would it be better to replace it by [iemlib/bp2~] to make it work out of the box in pd-extended, right? [1] http://machines.hyperreal.org/manufacturers/Roland/TR-808/samples/808-CP.zip roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On Sat, 2007-06-16 at 12:22 -0500, Kyle Klipowicz wrote: Man, that sucks about the backup wackiness. Good thing your netpd efforts have multiple data sources for retention! yeah, otherwise i would have lost all instruments. the clap and kick remained, because i've already turned them into netpd-patches... thank netpd ;-) roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On Fri, 2007-06-15 at 18:40 +0200, Frank Barknecht wrote: Hallo, Patco hat gesagt: // Patco wrote: Hello, Frank Barknecht a écrit : All that would be necessary are a clean and documented interfaces for the DSP abstractions. Yes exactly. Things like state saving, GUIs or network control then could easily be built as wrapper abstractions. It might be necessary to have a bridge between the wrapper and the DSP abs. This bridge would find all GUIs inside DSP abstraction, IMO there should be no GUI at all inside the actual DSP abstraction, just a couple of documented(!) inlets and arguments. and construct a wrapper with all necessary GUIs concatenated into one dynamically made abstraction. A bridge with automated service discovery could be nice, but I fear that it may also be too much bureaucracy and in the end may not help, but hinder moving forward and actually getting things done. The first step should be to 1) abstract DSP out into abstraction and 2) at the same time document each of them with a stupid black and white, help-patch. That help-patch may be quick and dirty, but it must *exist*. Keeping formalisms and requirements on help-patches etc. low, in the end will lead to them actually being written, instead of just being planned. For example every single [list]-abs has a help patch. They aren't pretty or anything, they don't all have the same layout, but they are there, which to me, now is the most important thing. (It took me a while to realize this. For example many RRADical abstractions are not documented ...) And a service discovery bridge may also be built later as a decorator abstraction itself around the original abstractions. Ciao hello frank and everyone you just did what i wanted to do: continue this thread under a new topic. you also just said, what i wanted to say: -pure dsp-abstraction would be the first step (guis might be made on top of them afterwards for different purposes) -every abs needs a help-patch (which i agree, that this is essential) without designing to much, how this collection could look like, there are might some little conventions, that we could make up (these are meant as proposals): - finding a naming scheme, maybe using a prefix like dsp_ (similar to the list-abs). - using messages like 'frequency 123' to set parameters, which are routed inside the abstraction. with such a design, only one inlet for an arbitrary number of parameters is needed. - the helpfile should at least describe the available parameters and their default values. then: kyle wrote: 3) Find the best way to keep the files checked in to cvs. 4) Actually check it in. 5) Test it out. 6) Fix errors. what do you pd-people think? 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] DSP abstractions [was: netpd ...]
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote: without designing to much, how this collection could look like, there are might some little conventions, that we could make up (these are meant as proposals): - finding a naming scheme, maybe using a prefix like dsp_ (similar to the list-abs). I think, this might be done later with a simple directory-prefix. If the help-files themselves use the objects without any dir-prefix, then the name could be decided later and they would still be useable with standard methods of setting only the -path. I didn't use a directory prefix, but instead a hardcoded prefix for [list]-abs mostly because many of them are impossible to use without the prefix anyways since they nameclash with existing objects like [list-moses] vs. [moses]. So import list doesn't make any sense for them. But for the dsp-collection I think, a directory prefix would make sense. - using messages like 'frequency 123' to set parameters, which are routed inside the abstraction. with such a design, only one inlet for an arbitrary number of parameters is needed. Yes, that could be a kind of good practice recommendation. I do this in my personal abstractions a lot, where I now use the attached dispatcher to automate the creation of the necessary [route frequency] and [s $0-frequency] chains plus a tiny help-feature. (Requires pd-0.40 and up because of $1-$2) - the helpfile should at least describe the available parameters and their default values. Yes++. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ dispatcher-help.pd Description: application/puredata dispatcher.pd Description: application/puredata ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
to make a start, i put these two abstractions together (with according helpfiles): [tr808-bd~] [tr808-cp~] (which are part of my try to rebuild all 808-instruments in plain pd, but unfortunately i lost most of the instrumenst during a harddisk backup, which made me so depressed, that i made this song: http://195.176.254.167/~all/mp3/2006-08-15_backup_blues.mp3 ) you can get them here: http://www.romanhaefeli.net/software/pd/dsplib.tar.gz i still don't know, what is the best way to get them into cvs. will someone collect all the works and include them? i do actually not have writing access to cvs. roman On Fri, 2007-06-15 at 18:40 +0200, Frank Barknecht wrote: Hallo, Patco hat gesagt: // Patco wrote: Hello, Frank Barknecht a écrit : All that would be necessary are a clean and documented interfaces for the DSP abstractions. Yes exactly. Things like state saving, GUIs or network control then could easily be built as wrapper abstractions. It might be necessary to have a bridge between the wrapper and the DSP abs. This bridge would find all GUIs inside DSP abstraction, IMO there should be no GUI at all inside the actual DSP abstraction, just a couple of documented(!) inlets and arguments. and construct a wrapper with all necessary GUIs concatenated into one dynamically made abstraction. A bridge with automated service discovery could be nice, but I fear that it may also be too much bureaucracy and in the end may not help, but hinder moving forward and actually getting things done. The first step should be to 1) abstract DSP out into abstraction and 2) at the same time document each of them with a stupid black and white, help-patch. That help-patch may be quick and dirty, but it must *exist*. Keeping formalisms and requirements on help-patches etc. low, in the end will lead to them actually being written, instead of just being planned. For example every single [list]-abs has a help patch. They aren't pretty or anything, they don't all have the same layout, but they are there, which to me, now is the most important thing. (It took me a while to realize this. For example many RRADical abstractions are not documented ...) And a service discovery bridge may also be built later as a decorator abstraction itself around the original abstractions. Ciao ___ Der fr�he Vogel f�ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
i thought, the bandlimited oscillators would fit as well into dsplib : [blsaw~] [blsquare~] [bltriangle~] still on: http://www.romanhaefeli.net/software/pd/dsplib.tar.gz roman On Fri, 2007-06-15 at 22:20 +0200, Roman Haefeli wrote: to make a start, i put these two abstractions together (with according helpfiles): [tr808-bd~] [tr808-cp~] (which are part of my try to rebuild all 808-instruments in plain pd, but unfortunately i lost most of the instrumenst during a harddisk backup, which made me so depressed, that i made this song: http://195.176.254.167/~all/mp3/2006-08-15_backup_blues.mp3 ) you can get them here: http://www.romanhaefeli.net/software/pd/dsplib.tar.gz i still don't know, what is the best way to get them into cvs. will someone collect all the works and include them? i do actually not have writing access to cvs. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
On 15/06/2007, at 22.20, Roman Haefeli wrote: i still don't know, what is the best way to get them into cvs. will someone collect all the works and include them? i do actually not have writing access to cvs. If they are to be in _the_ cvs, it might be good to: - make a project out of it, with a written up goal, ala what you wrote in the previous email. - make a folder in _the_ cvs named something shortish, say inst, where everyone can add instruments aka dsp abstraction as long as they are true to the form specified in the goal. The goal could be in a simple README. Of cause only folks having write access can add stuff. Another form could make another project, if needed be. I see no reason to restrict that. This would also follow the trent of the Montreal abstraction-set. This also brings to mind the fairly reason discussion about instrument making. It was about defining much the same set of design forms, but had a focus on modeling typical orchestra instruments. See fx: http://lists.puredata.info/pipermail/pd-list/2007-04/049367.html ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP abstractions [was: netpd ...]
beautiful piece roman, so lush. thanks for the dsp objects too. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
