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

Luke Iannini lukexipd at gmail.com
Fri Jul 4 00:46:16 CEST 2008


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")

Luke


More information about the Pd-list mailing list