[PD-dev] [range] from maxlib

Roman Haefeli reduzierer at yahoo.de
Mon Jul 7 16:28:33 CEST 2008


On Sat, 2008-07-05 at 21:05 -0400, Mathieu Bouchard wrote:
> On Thu, 3 Jul 2008, Roman Haefeli wrote:
> 
> > ÿÿ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 '#').
> 
> Yes, I recently started using the "gf." prefix for some things, first some 
> classes that are for quite internal use, and then in case of name 
> conflicts, but I'd rather not put a prefix, really. Prefixes make the code 
> heavier (among other things that make the code heavier)... compare:
> 
>    [jit.op @op +]
>    [# +]
> 
> and note that they didn't write "jitter." -- and this is not because they 
> were too lazy to write the full name.
> 
> > 'core classes' of gridflow (the ones starting with '#' )

> The "#" does not stand for "core class". It stands for "grid". I always 
> pronounce it "grid". I picked that symbol because it looks griddy (or 
> gridful, gridsome).

sorry, if i now seem to be nitpicking, but this is actually what i mean
by 'core classes': the classes, that cover the initial focus of the
library, in the case of gridflow the classes, that do deal with grids.

> Normally, a class whose name starts in "#" is a class that is made to 
> handle grids. There are a few exceptions (or just one?) -- [#mouse] was an 
> accident... it doesn't do any grids, it just postprocesses output of [#out 
> window]. However, there are classes that take grids as inputs or outputs 
> and don't have the prefix, namely the [cv.*] (OpenCV) classes... but 
> that's another story that we could get into separately.
> 
> > 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.
> 
> No, it turns out that the non-grid part is not there as purely optional 
> add-ons... they are often required by abstractions that process grids. 
> Stuff like [args] [listfind] [listread] [range] etc., are used by 
> abstractions like [#camera] and whatever else.

i don't think, that something hardcoded as [range 8 9 10] in
[#camera]/[pd camera] justifies the use an extra external, if three
[moses] objects cover exaxtly the same.


> > personally i think, that something like [range] shouldn't be part of an
> > external at all, rather should it be simply an abstraction.
> 
> You can't make [range] without both variable number of arguments and 
> [initbang] and dynamic creation of outlets, and by then, it's so 
> complicated to have that done in Pd that I think it just can be done in C 
> until Pd sucks less.

this is perfectly correct. however, i was inprecise by proposing to
implement [range] with pure internals as abs. i rather meant: is it
really necessary to have the exact functionality of [range]? cannot the
same be achieved by having some [moses]es here and there? why adding a
new class, if it not really extends the functionality of the language
pd? but yeah, i agree: implementing the very same [range] as abstraction
in pd as abs would be a pain and yet no possible without using
externals. 

> I mean, when something is more readable in C than in another language, 
> it's usually a real bad sign for that other language... and it's not just 
> about readability, it's about whether you can expect that the features 
> that you need are there in Pd because if they aren't there you are 
> screwed... where do you get [initbang] as an external?

different languages provide different ways to deal with issues. i
personally never felt the urgent need for a [range], although i so
sometimes quite complex patches. i might be wrong, but i haven't seen a
case yet, where [range] would be the only option to solve a certain
problem.

> So I don't have a clue why you say "it should be made as an abstraction" 
> when it's not really doable at this point.

yes, you're right: there is no point in making an exact implementation
of [range] as abstraction. but should there be any at all? i know, that
you hate repetitioins in code and i agree with you, but in this case i
am more in favor of repeating [moses]es instead of introducing another
class, that doesn't really cover new possibilities. in this particular
case, i also prefer [moses], because it does not crash, while [range]
crashes pd, when sending it a list instead of a float message. from a
developers perspective: why bother with making new code work, that
introduces new problems and needs special attention, if pretty much the
same could be achieved with a bit more effort in the user domain?
 

roman


		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de





More information about the Pd-dev mailing list