[PD] ehu abstractions to be released

[Hans-Christoph Steiner]

On Dec 15, 2008, at 11:14 AM, Chris McCormick wrote:

> On Sun, Dec 14, 2008 at 12:15:26PM -0500, Hans-Christoph Steiner  
> wrote:
>>
>> On Dec 14, 2008, at 6:38 AM, Chris McCormick wrote:
>>
>>> On Thu, Dec 11, 2008 at 01:33:41PM -0500, Hans-Christoph Steiner
>>> wrote:
>>>>
>>>> On Dec 11, 2008, at 4:19 AM, IOhannes m zmoelnig wrote:
>>>>
>>>>> altern wrote:
>>>>>> Hans-Christoph Steiner(e)k dio:
>>>>>>>
>>>>>>> You can force the version by using the namespace prefix:
>>>>>>>
>>>>>>> [cyclone/counter]
>>>>>>> [cyclone/prepend]
>>>>>>> [iemlib/gate]
>>>>>> this is what i am doing. i think that solves the issue.
>>>>>
>>>>> i think even better would be to use built-in objects.
>>>>> in the case of [gate] and [prepend] this maps to one (or 2) built-
>>>>> ins, so no need for strange prefixes.
>>>>
>>>> Except [list prepend], which I consider a stranger prefix. :)  I
>>>> still prefer [cyclone/prepend] since you don't need to add [list
>>>> trim] to keep things in the same format they came in as (at  
>>>> least for
>>>> the things I seem to do regularly.)
>>>
>>> Thereby rendering even the simplest of your patches completely  
>>> useless
>>> to me, or anyone else who is a Pd-vanilla fan. I can understand  
>>> using
>>> externals when they are neccessary, such as doing something with  
>>> weird
>>> hardware, or some algorithm that is slow in pure Pd, but I really
>>> can't
>>> understand using an external in a situation like this.
>>>
>>> Your choice though, I guess. Myself, I prefer to make my patches as
>>> portable as possible to the widest range of Pd users (pd-extenders
>>> included).
>>>
>>> Sorry if I sound grumpy; not getting too much sleep here in  
>>> Berlin. :)
>>
>> If you compile cyclone as a libdir and stick it in 'extra', then
>> using [cyclone/prepend] is fully compatible with Pd-vanilla.
>
> Great.
>
>> Any objectclass that is not included in Pd-vanilla is an external,
>> whether it is written in C, Pd, etc.  For example, even if s-
>> abtractions or list-abs use only pd-vanilla object, when someone uses
>> them, they then have an external dependencies.
>
> Yes, for sure, but are a couple of big difference between using
> s-abstractions or list-abs in your composition and spreading
> [cyclone/prepend] willy-nilly throughout your patches.
>
> First, using abstractions is a simple matter of copying a folder,  
> whilst
> cyclone requires compilation and linking of bloating 3rd party  
> software
> into my sleek, pristine Pd binary, or using pd-extended, which I  
> choose
> not to do. It also means that if I use your patches in my own work,  
> I am
> straight away demanding that my users install pd-extended, or go  
> through
> the painful compilation exercise. They probably don't even have a
> compiler installed. This issue escalates rapidly if every Pd user
> follows the advice you are giving out. Soon we have all kind of people
> using all kinds of crap, and forcing everyone else who wants to use
> their patches to do the same. It's a bad way to make software.
>
> Second, and a much more important reason, is that a perfectly good
> prepend exists in vanilla. As soon as you start using cyclone/prepend
> for the very dubious advantage of having to make one less [list trim]
> object, you instantly alienate me and others like me.

There is a third option: people can release libraries like 'cyclone'  
as libdirs.  Then you could just download the right one and drop it  
into place to install it.

This reminds me of a similar discussion that happens in Java-land.   
Lots of people still swear by Java 1.0.  Sure, you can do what you  
need, but newer versions of Java are widespread and have more  
shoulders of giants included to stand on.

.hc


>> My aim is to make my code as compatible as possible, while taking
>> advantage of all the good code that other people have written,  
>> like s-
>> abstractions and list-abs.  But there is no standard way to set up
>> externals when using pd-vanilla, so it is not really possible to
>> support.  Read the archives to see all of the problems running other
>> people's patches.  That's why Pd-extended was started, to have a
>> standard platform.
>
> Pd-extended is great. It's excellent to have that standared platform.
> All I am advocating is preferring the 'lowest common denominator'  
> as far
> as possible. I am saying that you should follow Occam's Razor when
> making patches, and make them as simple and widely portable as  
> possible.
> I am definately not saying that you shouldn't use externals, libdirs,
> other libraries or whatever when you need to. I understand completely
> the need for externals in many situations, but I also think that it's
> bad practice to use an external when a builtin will do. I am actually
> just putting forward a very common computer science precept; reuse.
> Spare a thought for us poor chumps in vanilla land. :)
>
> Best,
>
> Chris.



------------------------------------------------------------------------ 
----

If you are not part of the solution, you are part of the problem.