Btw-- the manual makes a distinction between "abstractions" and "externs".
But it shouldn't, right? I mean, it's not real in practice, for abstractions can be externals...
porres
On Tue, 15 Feb 2011, Alexandre Porres wrote:
Btw-- the manual makes a distinction between> "abstractions" and "externs".
But it shouldn't, right? I mean, it's not real in practice, for abstractions can be externals...
Which definitions are you using ?
I've never seen « abstractions are externals » nor anything that would imply it.
I tried introducing the word « class » in users' vocabulary, to include both abstraction definitions and external definitions under a same word, and using the word « object » to mean instances of either, but there is still some resistance to using industry-standard vocabulary instead of whatever the MAX manuals coughed up, for example.
It would be good if you stated the definitions you use. It'd help me understand how « abstractions are externals » can be a true statement.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
I didn't say they strictly are, but that they can be (as with list-abs).
alex
2011/2/16 Mathieu Bouchard matju@artengine.ca
On Tue, 15 Feb 2011, Alexandre Porres wrote:
Btw-- the manual makes a distinction between> "abstractions" and "externs".
But it shouldn't, right? I mean, it's not real in practice, for abstractions can be externals...
Which definitions are you using ?
I've never seen « abstractions are externals » nor anything that would imply it.
I tried introducing the word « class » in users' vocabulary, to include both abstraction definitions and external definitions under a same word, and using the word « object » to mean instances of either, but there is still some resistance to using industry-standard vocabulary instead of whatever the MAX manuals coughed up, for example.
It would be good if you stated the definitions you use. It'd help me understand how « abstractions are externals » can be a true statement.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
For me external is different from abstraction. For what I understand there's a need for a joint concept, one that says "this visual object box is <<something>>".
Is that what you call class Mathieu?
best, Pedro p.s.: this kinda answers another thread, where I posted that table of concepts "mental exercise" (for me).
On Wed, Feb 16, 2011 at 4:36 AM, Alexandre Porres porres@gmail.com wrote:
I didn't say they strictly are, but that they can be (as with list-abs).
alex
2011/2/16 Mathieu Bouchard matju@artengine.ca
On Tue, 15 Feb 2011, Alexandre Porres wrote:
Btw-- the manual makes a distinction between> "abstractions" and "externs".
But it shouldn't, right? I mean, it's not real in practice, for abstractions can be externals...
Which definitions are you using ?
I've never seen « abstractions are externals » nor anything that would imply it.
I tried introducing the word « class » in users' vocabulary, to include both abstraction definitions and external definitions under a same word, and using the word « object » to mean instances of either, but there is still some resistance to using industry-standard vocabulary instead of whatever the MAX manuals coughed up, for example.
It would be good if you stated the definitions you use. It'd help me understand how « abstractions are externals » can be a true statement.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think the term 'external' was coined by David Zicarelli (in the context of the M program, before Max) to mean an external code segment. I've always used it to mean a calss defined in a dynamically linked object module (presumably written in C).
I use the word 'abstractions' to refer to patches invoked by name in object boxes. So for me at least, the two are different animals.
cheers Miller
On Wed, Feb 16, 2011 at 04:42:26AM +0000, Pedro Lopes wrote:
For me external is different from abstraction. For what I understand there's a need for a joint concept, one that says "this visual object box is <<something>>".
Is that what you call class Mathieu?
best, Pedro p.s.: this kinda answers another thread, where I posted that table of concepts "mental exercise" (for me).
On Wed, Feb 16, 2011 at 4:36 AM, Alexandre Porres porres@gmail.com wrote:
I didn't say they strictly are, but that they can be (as with list-abs).
alex
2011/2/16 Mathieu Bouchard matju@artengine.ca
On Tue, 15 Feb 2011, Alexandre Porres wrote:
Btw-- the manual makes a distinction between> "abstractions" and "externs".
But it shouldn't, right? I mean, it's not real in practice, for abstractions can be externals...
Which definitions are you using ?
I've never seen « abstractions are externals » nor anything that would imply it.
I tried introducing the word « class » in users' vocabulary, to include both abstraction definitions and external definitions under a same word, and using the word « object » to mean instances of either, but there is still some resistance to using industry-standard vocabulary instead of whatever the MAX manuals coughed up, for example.
It would be good if you stated the definitions you use. It'd help me understand how « abstractions are externals » can be a true statement.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Pedro Lopes (MSc) contact: pedro.lopes@ist.utl.pt website: http://web.ist.utl.pt/Pedro.Lopes / http://pedrolopesresearch.wordpress.com/ | http://twitter.com/plopesresearch
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I see.
I was thinking of externals as anything that can be loaded as an object or library - like any non native/pd vanilla object - at startup.
Therefore, my concept of externals is broad, and can include abstractions if their path is listed on Pd preferences.
I don't use vanilla, so I don't know if the [sin~] object or list-abs is loaded there. But then, what matters is that I am actually wrong to conceive it this way, and need to be corrected, right?
The thing is that I am translation my long Pd Tutorial to english, and I make this assumption there somewhere. One of my intent to translate to english is to see if you guys find inconsistent information there too.
Thanks a lot Alex
2011/2/16 Miller Puckette msp@ucsd.edu
I think the term 'external' was coined by David Zicarelli (in the context of the M program, before Max) to mean an external code segment. I've always used it to mean a calss defined in a dynamically linked object module (presumably written in C).
I use the word 'abstractions' to refer to patches invoked by name in object boxes. So for me at least, the two are different animals.
cheers Miller
On Wed, Feb 16, 2011 at 04:42:26AM +0000, Pedro Lopes wrote:
For me external is different from abstraction. For what I understand there's a need for a joint concept, one that says "this visual object box is <<something>>".
Is that what you call class Mathieu?
best, Pedro p.s.: this kinda answers another thread, where I posted that table of concepts "mental exercise" (for me).
On Wed, Feb 16, 2011 at 4:36 AM, Alexandre Porres porres@gmail.com
wrote:
I didn't say they strictly are, but that they can be (as with
list-abs).
alex
2011/2/16 Mathieu Bouchard matju@artengine.ca
On Tue, 15 Feb 2011, Alexandre Porres wrote:
Btw-- the manual makes a distinction between> "abstractions" and "externs".
But it shouldn't, right? I mean, it's not real in practice, for abstractions can be externals...
Which definitions are you using ?
I've never seen « abstractions are externals » nor anything that would imply it.
I tried introducing the word « class » in users' vocabulary, to
include
both abstraction definitions and external definitions under a same
word, and
using the word « object » to mean instances of either, but there is
still
some resistance to using industry-standard vocabulary instead of
whatever
the MAX manuals coughed up, for example.
It would be good if you stated the definitions you use. It'd help me understand how « abstractions are externals » can be a true statement.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal,
QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Pedro Lopes (MSc) contact: pedro.lopes@ist.utl.pt website: http://web.ist.utl.pt/Pedro.Lopes / http://pedrolopesresearch.wordpress.com/ |
http://twitter.com/plopesresearch
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
On Wed, 16 Feb 2011, Alexandre Porres wrote:
I was thinking of externals as anything that can be loaded as an object or library - like any non native/pd vanilla object - at startup.
In terms of the usual word «external», Pd's «externals» are external to the Pd language ; it's not a matter of being external to («outside of») the main programme.
Therefore, my concept of externals is broad, and can include abstractions if their path is listed on Pd preferences. I don't use vanilla, so I don't know if the [sin~] object or list-abs is loaded there. But then, what matters is that I am actually wrong to conceive it this way, and need to be corrected, right?
Well, if your conception is useful, it's good to have it remain in some way, though it's better to use different words when possible. Pd has already too many things called the same : the several confusing uses of the words "pd", "object", "canvas", for example.
The thing is that I am translation my long Pd Tutorial to english, and I make this assumption there somewhere. One of my intent to translate to english is to see if you guys find inconsistent information there too.
You might be using it in a consistent manner within your own text, but it's not consistent with the usage of the community, nor of any part of the community, nor in communities outside of pd.
I'm sure, though, that you can find a word for it. Anyone got an idea about how to name this ?
"Non-internal classes", "classes outside of the main executable" ?
(I don't think it really needs to have a single-word name. Do you think it does ?)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On 2011-02-16 14:02:52, Mathieu Bouchard matju@artengine.ca appears to have written:
On Wed, 16 Feb 2011, Alexandre Porres wrote:
I was thinking of externals as anything that can be loaded as an object or library - like any non native/pd vanilla object - at startup.
I'm sure, though, that you can find a word for it. Anyone got an idea about how to name this ?
"Non-internal classes", "classes outside of the main executable" ?
"user-defined objects" ? "non-primitive objects"? ... or maybe "civilized objects" ? ;-)
marmosets, Bryan
On Wed, 16 Feb 2011, Bryan Jurish wrote:
On 2011-02-16 14:02:52, Mathieu Bouchard matju@artengine.ca appears to have written:
On Wed, 16 Feb 2011, Alexandre Porres wrote:
I was thinking of externals as anything that can be loaded as an object or library - like any non native/pd vanilla object - at startup.
I'm sure, though, that you can find a word for it. Anyone got an idea about how to name this ?
"Non-internal classes", "classes outside of the main executable" ?
"user-defined objects" ? "non-primitive objects"? ... or maybe "civilized objects" ? ;-)
hehe
also, "non-builtin classes" ?
(why do you say "objects" instead of "classes" here ?)
Also I just noticed some words on the front page of puredata.info that might be quite confusing :
« It is easy to extend Pd by writing object classes ("externals") or patches ("abstractions"). »
...?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Miller Puckette wrote:
I think the term 'external' was coined by David Zicarelli (in the context of the M program, before Max) to mean an external code segment. I've always used it to mean a calss defined in a dynamically linked object module (presumably written in C).
I use the word 'abstractions' to refer to patches invoked by name in object boxes. So for me at least, the two are different animals.
That has always been my understanding too (didn't know of the historical background of course :) ... I have always though that:
externals = the ones made in C
abstractions = the ones in Pd
objects = the 'boxes' (as in Put->object vs message, numberbox etc.)
especially the vanilla ones (is [osc~] and object or an external?) ...
but also an umbrealla term for abstractions, externals,...
(Pd) application = a set of multiple abstractions and/or externals
which run in Pd and constitute a somewhat 'self-contained' applicetion
(like a sequencer, sampler etc.) often simply denoted by a cool/funky
name like "Super-duper-hyper-mega-wave-a-tronic sampler" etc.
Lorenzo
cheers Miller
On Wed, Feb 16, 2011 at 04:42:26AM +0000, Pedro Lopes wrote:
For me external is different from abstraction. For what I understand there's a need for a joint concept, one that says "this visual object box is<<something>>".
Is that what you call class Mathieu?
best, Pedro p.s.: this kinda answers another thread, where I posted that table of concepts "mental exercise" (for me).
On Wed, Feb 16, 2011 at 4:36 AM, Alexandre Porresporres@gmail.com wrote:
I didn't say they strictly are, but that they can be (as with list-abs).
alex
2011/2/16 Mathieu Bouchardmatju@artengine.ca
On Tue, 15 Feb 2011, Alexandre Porres wrote:
Btw-- the manual makes a distinction between> "abstractions" and "externs".
But it shouldn't, right? I mean, it's not real in practice, for abstractions can be externals...
Which definitions are you using ?
I've never seen « abstractions are externals » nor anything that would imply it.
I tried introducing the word « class » in users' vocabulary, to include both abstraction definitions and external definitions under a same word, and using the word « object » to mean instances of either, but there is still some resistance to using industry-standard vocabulary instead of whatever the MAX manuals coughed up, for example.
It would be good if you stated the definitions you use. It'd help me understand how « abstractions are externals » can be a true statement.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Pedro Lopes (MSc) contact: pedro.lopes@ist.utl.pt website: http://web.ist.utl.pt/Pedro.Lopes / http://pedrolopesresearch.wordpress.com/ | http://twitter.com/plopesresearch _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 16 Feb 2011, Lorenzo Sutton wrote:
objects = the 'boxes' (as in Put->object vs message, numberbox etc.) especially the vanilla ones (is [osc~] and object or an external?) ...
Where did you get the idea that it was « especially the vanilla ones » ?
And also, when you send to the name 'pd' to turn 'dsp' on, and you write 'dps' by mistake, how do you explain the error message "no method for 'dps'" ? what are you sending to ? (what is a method ?)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Wed, 16 Feb 2011, Pedro Lopes wrote:
For me external is different from abstraction.For what I understand there's a need for a joint concept, one that says "this visual object box is <<something>>".
Is that what you call class Mathieu?
Classes are definitions of what each box means in your patches : if I have three [+] boxes, I have three objects, but a single "+" class involved.
There are two useful definitions of the word "class" in Pd : usually, it's best to think of each abstraction file as being a class of its own, because that's (by analogy) nearly the same idea of class that is being used in other programming languages.
However, internally, the abstraction-loader doesn't give each abstraction its own t_class structure. (almost no pd user needs to take the latter into account, even among those who write externals ; but I had to.)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Just some ideas...
- Not that this is particularly important, but the word "class" will
not intensify the BIG confusion of considering PureData as a object-oriented language even further?
- I understand the word 'external' as external to PD, but PD isn't
itself written in C/C++? Aren't they 'extensions' ? Externals, following that logic, are the ones written in Lua, Python, Ruby, Haskell etc.
- Abstraction makes a lot of sense, since they really are abstractions
written in PD, even if from the point of the user they can look like a built-in 'object'.
On Wed, 16 Feb 2011, Bernardo Barros wrote:
- Not that this is particularly important, but the word "class" will not
intensify the BIG confusion of considering PureData as a object-oriented language even further?
It's not even particularly wrong to call PureData an object-oriented language. It just shouldn't be the words we use the most, because it's not its most defining characteristic. But "object-oriented" doesn't refer to a single way of doing things... it's a collection of related approaches. Consider the definition of OOP to be fuzzy, and PureData being on the fuzzy edge.
- I understand the word 'external' as external to PD, but PD isn't
itself written in C/C++?
They're external to the pd language, because inside of [+], [moses], [metro], etc., there are pieces of behaviour that aren't coded in terms of patching in pd. I mean, [+], [moses], [metro] are made to do patching with them, but they aren't made of patching.
Aren't they 'extensions' ? Externals, following that logic, are the ones written in Lua, Python, Ruby, Haskell etc.
Never seen the word "extension" in the Pd world. Speaking of Ruby, over there, they have a word for what Miller and I calls "externals" : they say "extensions".
Abstraction makes a lot of sense, since they really are abstractions written in PD, even if from the point of the user they can look like a built-in 'object'.
what about a box makes it look built-in vs not ?... is it just the habit of having learned a lot of built-ins and then suddenly realise that the boxes don't have to be built into ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
2011/2/16 Mathieu Bouchard matju@artengine.ca:
what about a box makes it look built-in vs not ?... is it just the habit of having learned a lot of built-ins and then suddenly realise that the boxes don't have to be built into ?
That's funny how other languages jargons uses words with different meanings.. :-) In SuperCollider, for instance, "plugins" are the extensions to the UGens used by scsynth, the synthesis engine, written in C++. The "classes" are those writen in the SuperCollider language. In this case they are actually 'classes' in the OOP original jargon, since they have methodes, inheritance etc.
On Wed, 16 Feb 2011, Bernardo Barros wrote:
That's funny how other languages jargons uses words with different meanings.. :-) In SuperCollider, for instance, "plugins" are the extensions to the UGens used by scsynth, the synthesis engine, written in C++. The "classes" are those writen in the SuperCollider language. In this case they are actually 'classes' in the OOP original jargon, since they have methodes, inheritance etc.
How do you explain a C function like class_addmethod, which registers a method under a certain selector, in a class of your choice ?
It's in <m_pd.h>, Pd's main header.
(There's no actual support for inheritance though. There's no so often a use for it in the context of Pd. My library supports inheritance internally, but uses it seldom.)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Nevertheless, i've seen people say and use inheritance to refer about parent patches sending info to abstractions via arguments
What is the deal there?
Cheers
Em quarta-feira, 16 de fevereiro de 2011, Mathieu Bouchardmatju@artengine.ca escreveu:
On Wed, 16 Feb 2011, Bernardo Barros wrote:
That's funny how other languages jargons uses words with different meanings.. :-) In SuperCollider, for instance, "plugins" are the extensions to the UGens used by scsynth, the synthesis engine, written in C++. The "classes" are those writen in the SuperCollider language. In this case they are actually 'classes' in the OOP original jargon, since they have methodes, inheritance etc.
How do you explain a C function like class_addmethod, which registers a method under a certain selector, in a class of your choice ?
It's in <m_pd.h>, Pd's main header.
(There's no actual support for inheritance though. There's no so often a use for it in the context of Pd. My library supports inheritance internally, but uses it seldom.)
_______________________________________________________________________ | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Wed, 16 Feb 2011, Alexandre Porres wrote:
Nevertheless, i've seen people say and use inheritance to refer about parent patches sending info to abstractions via arguments. What is the deal there?
That sounds like a casual use of the word that doesn't have to do with commonly-used definitions. Others would call it argument-passing or parameter-passing.
Nonstandard vocabulary also happens in other programming languages, but it does not mean it's a good thing to let it proliferate.
Inheritance usually means that a class is defined as a variant of another class, such that if a method is not found in a class, the other class will be searched for that method. Thus, methods of objects can come from several different classes at once. Nearly all languages that have this concept call it "inheritance".
Granted that the word "inheritance" is sometimes used for meanings other than that one, but it normally means something automatic, not an argument that you have to pass by writing it down.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-
Alexandre Porres -
Bernardo Barros -
Bryan Jurish -
Lorenzo Sutton -
Mathieu Bouchard -
Miller Puckette -
Pedro Lopes