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" hard.off@gmail.com 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
hey roman, what is bp2~ in the clap patch? is it an abstraction? care to post it?
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
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__
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
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__
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
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__
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
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.
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
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__
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
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
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
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 ...
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
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__
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?
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
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
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
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__
On Sun, 2007-06-17 at 17:53 +0200, Frank Barknecht wrote:
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.
i wasn't aware, that [bp2~] was removed from iemabs. thanks for mentioning it. i changed it to [bpq2~] (which is the same as the old [bp2~]).
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hello,
Frank Barknecht a écrit :
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.
Almost all activated, multiplex 0 1 2 3 ... couldn't create mux 0 1 2 3 ... couldn't create this is what's happening if I load my patches with pd-vanilla that shares the same pdsettings than pd-0.39.2-extended-windowsXP-RC4, other libs seems to be ok, and fortunately i'v made a backup of the registry before installing pdsettings.
Ciao
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 reduzierer@yahoo.de 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
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
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
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
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
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
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
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
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 reduzierer@yahoo.de 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
-
Frank Barknecht -
Georg Holzmann -
Hans-Christoph Steiner -
hard off -
Kyle Klipowicz -
Patco -
Roman Haefeli