[PD] [PD-dev] [range] from maxlib

[Hans-Christoph Steiner]

On Jul 4, 2008, at 12:46 AM, Luke Iannini wrote:

> On Thu, Jul 3, 2008 at 2:51 PM, Roman Haefeli <reduzierer at yahoo.de>  
> wrote:
>> On Thu, 2008-07-03 at 16:05 -0400, Mathieu Bouchard wrote:
>>> On Thu, 3 Jul 2008, Roman Haefeli wrote:
>>>
>>>> sorry for late reply. i couldn't figure out, what [range] from  
>>>> gridflow
>>>> does, so it makes you difficult to have an opinion about this.  
>>>> the fact,
>>>> that it doesn't have a '#' in its name, makes me assume, that it  
>>>> does
>>>> something, that cannot only be applied to grids, which means, it  
>>>> has
>>>> kind of a general use.
>>>
>>> It's a cascaded [moses]. For example,
>>>
>>> [range 11 13 17 19] = [moses 11]/[moses 13]/[moses 17]/[moses 19]
>>>
>>> where the slash is a right-outlet-to-left-inlet connection.
>>>
>>> this is what jMax had instead of moses, and I added it to GF in  
>>> order to
>>> avoid having to cascade many [moses].
>>>
>>>> this speaks for keeping the name. on the other hand, i find it
>>>> problematic, if libraries with a dedicated focus (processing  
>>>> grids in
>>>> the case of gridflow) include classes, that aren't really part  
>>>> of that
>>>> focus AND at the same time occupy a generic name.
>>>
>>> If they wouldn't be there, they would be in some library that  
>>> would be
>>> required for using GridFlow (because it would be used in GridFlow's
>>> abstractions), and the problem would be exactly the same, only  
>>> with one
>>> more library dependency to think about.
>>>
>>> Frankly, I don't know what to do to solve your problem. I think  
>>> that it's
>>> a problem of your perception of what GridFlow is supposed to be,  
>>> vs what
>>> it is.
>>
>> the solution would be to give it a name, that clearly relates to
>> gridflow. [gf.range] or whatsoever (similar to grid processing
>> classnames starting with a '#').
>>
>>> Besides, if you read one sentence of "GridFlow is..." it doesn't  
>>> tell you
>>> the whole picture and you shouldn't take it as such. I also  
>>> didn't want to
>>> call the library MatjuLib just because its most defining  
>>> characteristic is
>>> that all the things in there are things that I have wanted and/or  
>>> that my
>>> collaborators have wanted. I thought about making a separate  
>>> library but
>>> quickly figured out that there was not much of a point to it.
>>
>> sorry, matju, i didn't meant to tell YOU what the focus of  
>> gridflow is
>> or is supposed to be. however, it's not me, who made the distinction
>> between 'core classes' of gridflow (the ones starting with '#' ) and
>> some additional classes, but it's the name, that distinguishes them.
>> this distinction made me believe, that there is something like a core
>> part and a peripheral part (whereas the peripheral part is not
>> necessarily necessary for the core part, that has the dedicated  
>> focus,
>> to work properly). this might be wrong and my own faulty personal
>> interpretation.
>>
>> personally i think, that something like [range] shouldn't be part  
>> of an
>> external at all, rather should it be simply an abstraction.  
>> however, the
>> naming problem persists (and should be faced by adding some library
>> specific prefix, imo).
>
> Well, as always, the namespace thing is at the root of all this - if
> the namespace stuff was working (and it sounds like it's getting
> closer) then it would be perfectly fine to call it just [range] since
> it would require gridflow/range or import/declare gridflow to use.
>
> And, the second answer is other-language (e.g. Python) style
> reorganization of libraries to be author-agnostic - ordered by
> functionality.  But, this requires a Organization Czar, it seems, and
> maybe no one is ready to be that person yet, so, until then, such
> helper-objects must stay in the homes of their authors for there's
> nowhere else to put them.  (also, I think in this case, since
> grid-operators in GF have the #-prefix, those objects without the
> prefix are clearly distinguished as "generic helpers")

Actually, I think it more needs people to wrote those libraries.   
Cyrille and I were just talking about this here in Barcelona.  Pd  
definitely needs working namespaces and logically organized  
libraries.  If you also think this is important, then pick a topic  
and make a clean, well-organized library around it.

.hc


>
> Luke
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



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

Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.   
It's about as sensible to say we declare war on night attacks and  
expect we're going to win that war.  We're not going to win the war  
on terrorism.        - retired U.S. Army general, William Odom