hi all
why is [range], that was initially part of maxlib, moved to <pd-svn>/externals/deprecated ?
who decides, what is deprecated and what not?
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
[range] was never part of maxlib. It was a silly kludge I think in like 2002. I created it, so I decided to deprecate it.
.hc
On Jun 24, 2008, at 2:04 AM, Roman Haefeli wrote:
hi all
why is [range], that was initially part of maxlib, moved to <pd-svn>/externals/deprecated ?
who decides, what is deprecated and what not?
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Access to computers should be unlimited and total. - the hacker ethic
On Tue, 2008-06-24 at 12:08 +0200, Hans-Christoph Steiner wrote:
[range] was never part of maxlib. It was a silly kludge I think in like 2002. I created it, so I decided to deprecate it.
from <pd-svn>/externals/deprecated/range.c:
/* ------------------------- range ------------------------------------------ */ /* */ /* Ranges input to lie within an output range. */ /* Written by Olaf Matthes olaf.matthes@gmx.de */ /* Get source at http://www.akustische-kunst.org/puredata/maxlib/ */ /* */
[...]
static char *version = "range v0.2, written by Olaf Matthes olaf.matthes@gmx.de";
[...]
why would you give olaf matthes as author then?
anyway, it seems that it has been years ago, so nevermind. i was confused when trying to help someone with a patch, that uses [range], which i found in /deprecated (this person was using pd-0.38.4-extended, irrc). obviously, i had to think, that the original libraries were split and parts of them were arbitrarily moved around.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
It is literally a copy of maxlib's [scale], with only the name changed.
.hc
On Jun 24, 2008, at 6:52 PM, Roman Haefeli wrote:
On Tue, 2008-06-24 at 12:08 +0200, Hans-Christoph Steiner wrote:
[range] was never part of maxlib. It was a silly kludge I think in like 2002. I created it, so I decided to deprecate it.
from <pd-svn>/externals/deprecated/range.c:
/* ------------------------- range ------------------------------------------ */ /
*//* Ranges input to lie within an output range. */ /* Written by Olaf Matthes olaf.matthes@gmx.de */ /* Get source at http://www.akustische-kunst.org/puredata/ maxlib/ */ /
*/[...]
static char *version = "range v0.2, written by Olaf Matthes olaf.matthes@gmx.de";
[...]
why would you give olaf matthes as author then?
anyway, it seems that it has been years ago, so nevermind. i was confused when trying to help someone with a patch, that uses [range], which i found in /deprecated (this person was using pd-0.38.4- extended, irrc). obviously, i had to think, that the original libraries were split and parts of them were arbitrarily moved around.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
------------------------------------------------------------------------ ----
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
On Tue, 24 Jun 2008, Roman Haefeli wrote:
anyway, it seems that it has been years ago, so nevermind. i was confused when trying to help someone with a patch, that uses [range], which i found in /deprecated (this person was using pd-0.38.4-extended, irrc). obviously, i had to think, that the original libraries were split and parts of them were arbitrarily moved around.
So, should I rename GridFlow's [range] to something else, or not?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Jun 28, 2008, at 1:24 AM, Mathieu Bouchard wrote:
On Tue, 24 Jun 2008, Roman Haefeli wrote:
anyway, it seems that it has been years ago, so nevermind. i was confused when trying to help someone with a patch, that uses [range], which i found in /deprecated (this person was using pd-0.38.4- extended, irrc). obviously, i had to think, that the original libraries were split and parts of them were arbitrarily moved around.
So, should I rename GridFlow's [range] to something else, or not?
FYI: This kludge [range] has been long deprecated, and will be soon removed.
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
On Fri, 2008-06-27 at 19:24 -0400, Mathieu Bouchard wrote:
On Tue, 24 Jun 2008, Roman Haefeli wrote:
anyway, it seems that it has been years ago, so nevermind. i was confused when trying to help someone with a patch, that uses [range], which i found in /deprecated (this person was using pd-0.38.4-extended, irrc). obviously, i had to think, that the original libraries were split and parts of them were arbitrarily moved around.
So, should I rename GridFlow's [range] to something else, or not?
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. 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.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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.
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.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
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).
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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).
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.
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.
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?
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.
however, the naming problem persists (and should be faced by adding some library specific prefix, imo).
Yeah, that was the topic. I wouldn't necessarily say "should" though. I envision some other possibilities, such as overwriting the entry for [moses] and rename [range] to [moses] in all my patches.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
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
-
Hans-Christoph Steiner -
Mathieu Bouchard -
Roman Haefeli