[PD] DSP abstractions [was: netpd ...]

[Hans-Christoph Steiner]

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 at 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