-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/11/2010 10:36 AM, Kim Cascone wrote:
> > plugin~: "Delayorama" > print: port in control Random seed 0 1000 >
looks good, doesn't it?
er, sure if it matched the console report (when plugin~ is sent [info]) it would look even better! ;)
it reports all "relevant" information.
ahhhhh...I now see why you say that it reports 'all relevant info' given the console info you posted below
because I've been (unknowlingly) using the GridFlow [print] and I'm missing this info
[see attached patch]
I tested this with both [pd/print] and [print] and here are the results:
using the [print] object [info] reports to console: a: port in control Random seed 0 1000 error: [print a]: close-paren without open-paren error: [print a]: close-paren without open-paren a: port in control Number of taps 2 128 error: [print a]: close-paren without open-paren error: [print a]: close-paren without open-paren a: port in control Delay change 0.2 5 error: [print a]: close-paren without open-paren a: port in control Amplitude change 0.2 5 error: [print a]: close-paren without open-paren a: port in control Dry/wet mix 0 1 a: port in audio Input 0 1 a: port out audio Output 0 1
using the [pd/print] object [info] reports to console: b: port in control Random seed 0 1000 b: port in control Input gain (dB) -96 24 b: port in control Feedback (%) 0 100 b: port in control Number of taps 2 128 b: port in control First delay (s) 0 5 b: port in control Delay range (s) 0.0001 6 b: port in control Delay change 0.2 5 b: port in control Delay random (%) 0 100 b: port in control Amplitude change 0.2 5 b: port in control Amplitude random (%) 0 100 b: port in control Dry/wet mix 0 1 b: port in audio Input 0 1 b: port out audio Output 0 1
this is really confusing for people using [print] not knowing they are using the GridFlow external instead of the standard Pd version
how do we disentangle this and make it obvious? and why isn't there a GridFlow [print] external called [gf_print] instead?
is this a bug or known issue?
> error: [print]: close-paren without open-paren >
oops; seems there is a problem with displaying symbols with parenthesis.
I'm assuming here that not all LADSPA plugs send info with parentheses? so this would be a problem only for those plugs that send data with parentheses
correct. anyhow, when i try your plugin i get:
<snip> plugin~: "Delayorama" a: port in control Random seed 0 1000 a: port in control Input gain (dB) -96 24 a: port in control Feedback (%) 0 100 a: port in control Number of taps 2 128 a: port in control First delay (s) 0 5 a: port in control Delay range (s) 0.0001 6 a: port in control Delay change 0.2 5 a: port in control Delay random (%) 0 100 a: port in control Amplitude change 0.2 5 a: port in control Amplitude random (%) 0 100 a: port in control Dry/wet mix 0 1 a: port in audio Input 0 1 a: port out audio Output 0 1 </snip>
looks good to me.
yes and this matches the analyseplugin <foo> data
??
i don't seem to have this problem here (though i don't have the delayorama plugin;
I've attached it - see if this works for you?
and the "invada_mono_tube_module_0_1" works just fine (with pd-vanilla 0.42.6)
***do you have any info on how params are listed in [info]->[plugin~] versus [analyseplugin <foo>] in the term? how does one understand what to name the params when controlling a plugin?
the message is: "port symbol:direction symbol:type symbol:name float:lowerlimit float:upperlimit"
with symbol:direction being either "in" or "out" with symbol:type being "control" or "audio" with symbol:name being the name of the port (e.g. "Amplitude random (%)")
and lower/upperlimit define the valid range of the value.
for controlling, you use "control symbol:name float:value"
symbol:name is not case-sensitive, and it tries to find a simple match. e.g. "Amplitude random (%)" can be controlled with "amp" or "AMPLItude" or "Amplitude random (%)". it will take the first port that matches, so if you have parameters "FrequencyUpper" and "FrequencyLower", then "freq" will match "FrequencyUpper", in order to conrol the other param you have to use at least "frequencyl"
thanks a million for this :) -- let me chew on this info today and I'll see if I have any more questions
also, I also noticed that I can't use a number in the [print] external in my current version of PdX that I'm working in without causing the error: 'expected symbol' but in the latest version of PdX I can use a number as well as a symbol in [print]
well, you can use [print :1], if you want to stay compatible with e.g. Pd-vanilla.
ok -- a good tip -- thanks again!
mfgasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwSNM0ACgkQkX2Xpv6ydvRhdACgpld4N/mRShDv/OT6p9Z8D/MT MyMAn0b1mNdDPvlGn8FuMOf7Fp4iNhZ4 =v7Gc -----END PGP SIGNATURE-----
On Fri, 2010-06-11 at 11:34 -0700, Kim Cascone wrote:
this is really confusing for people using [print] not knowing they are using the GridFlow external instead of the standard Pd version
I fully agree with you. I find replacing built-in vanilla object classes a rather bad habit and quite confusing. I don't see a valid reason for doing that. Since one needs to load 'gridflow' anyway to use GridfFlow, why not simply put a Gridflow specific print object when needed?
how do we disentangle this and make it obvious? and why isn't there a GridFlow [print] external called [gf_print] instead?
Yeah, I cannot understand that either.
Too bad there are also other examples of libraries replacing built-in classes around (e.g. zexy). Also too bad we both seem to disagree with whom I consider the most Pd-savvy developers in the community.
Roman
Roman Haefeli wrote:
On Fri, 2010-06-11 at 11:34 -0700, Kim Cascone wrote:
this is really confusing for people using [print] not knowing they are using the GridFlow external instead of the standard Pd version
I fully agree with you. I find replacing built-in vanilla object classes a rather bad habit and quite confusing. I don't see a valid reason for doing that. Since one needs to load 'gridflow' anyway to use GridfFlow, why not simply put a Gridflow specific print object when needed?
coming from Max-landia it would most likely be done as follows: [print] = standard object ships with both Pd-vanilla and extended [gf_print] = print object shipped with the GridFlow libraries and _only_ called when [gf_print] is instantiated in a patch
consider the [prepend <foo>] object and jasch's [_] object the do the same thing but are named differently so there is no collision in name-space confusion in which lib to load from first etc
how do we disentangle this and make it obvious? and why isn't there a GridFlow [print] external called [gf_print] instead?
Yeah, I cannot understand that either.
Too bad there are also other examples of libraries replacing built-in classes around (e.g. zexy).
we need to make a list of these or is there a place that this has already been done?
Also too bad we both seem to disagree with whom I consider the most Pd-savvy developers in the community.
I say let's put that aside and just work to make sure all PdX objects/libs work in a logical concise manner
:)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/11/2010 08:50 PM, Kim Cascone wrote:
[print] = standard object ships with both Pd-vanilla and extended [gf_print] = print object shipped with the GridFlow libraries and _only_ called when [gf_print] is instantiated in a patch
why would it. (i guess that) gf's [print] is meant as a fully compatible [print], with some added features. most users should never notice (unless in a pleasant way).
in the specific case here, i consider the behaviour of gf's print to be a bug, which should be fixed (just like zexy's pack/unpack). however, i consider the inability of gf's [print] to print everything correctly a way less important problem that an object (like plugin~) that keeps crashing the entire system.
and of course what do we make of things like zexy's [tabread4] and [wrap] objects? (i just use zexy because i know it well; i'm sure it applies to a number of libs)
fgmasdr IOhannes
IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/11/2010 08:50 PM, Kim Cascone wrote:
[print] = standard object ships with both Pd-vanilla and extended [gf_print] = print object shipped with the GridFlow libraries and _only_ called when [gf_print] is instantiated in a patch
why would it. (i guess that) gf's [print] is meant as a fully compatible [print], with some added features.
yes but collision in name space is really confusing for the user
most users should never notice (unless in a pleasant way).
I noticed the difference in a not so pleasant way :)
in the specific case here, i consider the behaviour of gf's print to be a bug,
is [print] GridFlow or is [pd/print] GridFlow I'm totally confused now
which should be fixed (just like zexy's pack/unpack).
I'll make a note of this - thanks for the heads-up
however, i consider the inability of gf's [print] to print everything correctly a way less important problem that an object (like plugin~) that keeps crashing the entire system.
that crash only happened for me with an old version of the Gem library and seemed to go away once I compiled the new version and loaded it into usr/lib/pd/extra/Gem
and of course what do we make of things like zexy's [tabread4] and [wrap] objects? (i just use zexy because i know it well; i'm sure it applies to a number of libs)
I have yet to explore the zexy lib I'm still trying to get [plugin~] sorted out so I can finish the FOSS chapter on hosting plugins
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwSvxQACgkQkX2Xpv6ydvSnzACgyDfjr0GD2HW0VfFEuOQLom55 iocAn2xymReyRFY15iMQIGbKcZvTJU8y =50ul -----END PGP SIGNATURE-----
Kim Cascone wrote:
IOhannes m zmölnig wrote:
On 06/11/2010 08:50 PM, Kim Cascone wrote:
[print] = standard object ships with both Pd-vanilla and extended [gf_print] = print object shipped with the GridFlow libraries and _only_ called when [gf_print] is instantiated in a patch
why would it. (i guess that) gf's [print] is meant as a fully compatible [print], with some added features.
yes but collision in name space is really confusing for the user
Yes it's like which [democracy] is the one in effect today? I made an object [which] that tries to tell you but it seems unstable.
Martin
IOhannes m zmölnig wrote:
most users should never notice (unless in a pleasant way).
if you instantiate a [print] object and don't know whether you are loading a buggy GridFlow [print] object or a working Pd [print] object then how is this logical, clear or concise?
doesn't it make more sense to differentiate the two by calling one [gf_print] and the other [print]?
wouldn't this be more (in your words) 'imperative' behavior?
this way if I want to use a property of the GridFlow [print] object for some reason I know I can call it using its name
true, only someone wanting to take over should override some basic pd objects no?
that's not bad spirit really, that's the shit where we are, everybody wanting to be the kalif hey ?
you can understand why there's no pd community
salaaam, sevy
Kim Cascone wrote:
IOhannes m zmölnig wrote:
most users should never notice (unless in a pleasant way).
if you instantiate a [print] object and don't know whether you are loading a buggy GridFlow [print] object or a working Pd [print] object then how is this logical, clear or concise?
doesn't it make more sense to differentiate the two by calling one [gf_print] and the other [print]?
wouldn't this be more (in your words) 'imperative' behavior?
this way if I want to use a property of the GridFlow [print] object for some reason I know I can call it using its name
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
patko wrote:
Patrice Colet - 06 32 66 03 57
----- ydegoyon@gmail.com a écrit :
true, only someone wanting to take over should override some basic pd objects no?
Because some pd basic objects doesn't work very good. We often experience this.
and so what? because your objects work better? it's just not civilized to overwrite any other's object in my opinion then you'll understand what is social engineering and respecting people in a community right?
ciao, sevy
ydegoyon@gmail.com wrote:
patko wrote:
Patrice Colet - 06 32 66 03 57 ----- ydegoyon@gmail.com a écrit :
true, only someone wanting to take over should override some basic pd objects no?
Because some pd basic objects doesn't work very good. We often experience this.
and so what? because your objects work better? it's just not civilized to overwrite any other's object in my opinion then you'll understand what is social engineering and respecting people in a community right?
ciao, sevy
to me, the pd commuity has become as a rat race since 3 years at least, when it was said it could replace MAX, but for 'free' not freedom of thought note...
well exactly and become a competitive professional tool, it's just loosing all the spirit of open source here...
ciao, sevy
Le 12/06/2010 06:13, patko a écrit :
Patrice Colet - 06 32 66 03 57
----- ydegoyon@gmail.com a écrit :
true, only someone wanting to take over should override some basic pd objects no?
Because some pd basic objects doesn't work very good.
?????? which one?
We often experience this.
i don't. c
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 11 Jun 2010, Kim Cascone wrote:
wouldn't this be more (in your words) 'imperative' behavior?
afaik, the word "imperative" is almost only ever used to mean that the programme revolves around modifying data using a series of steps for which the order is very important.
it's opposed to several other words such as "purely functional", in which the required ordering of the operations is as little as possible, and there is no stored data, as every piece of data is a parameter being passed around.
"declarative" is more vague and refers to anything in which it doesn't look like the programme is doing something, but instead is used as a kind of data processed by a "doer". It's a quite subjective notion. But usually it's used for much more sophisticated cases than ".pdsettings", which by usual standards would be just called a configuration file rather than a programme. For example, PROLOG is often called a declarative language, as you are programming by stating facts (and you can get damn far that way).
The Pd/MAX language family is quite special in being almost the only dataflow languages that are also quite highly imperative.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On 2010-06-12 01:23, Kim Cascone wrote:
IOhannes m zmölnig wrote:
most users should never notice (unless in a pleasant way).
if you instantiate a [print] object and don't know whether you are loading a buggy GridFlow [print] object or a working Pd [print] object then how is this logical, clear or concise?
most discussion here is very centered around the patching process. please don't forget about just loading a patch (and about using premade abstractions for that matter).
so if you load a patch with 87 [print]'s in there, what information do you get if Pd prints 86 times "dear user, you are using matju's special [print], which has problems with parens". and how do you relate one of these warnings to a specific object? (luckily the warning mentions [print] in my example) and what happened to the 1 object that had no printout?
and if it only should print once (as somebody suggested on the list): this should actually be done by Pd anyhow.
e.g. zexy comes with a version of "wrap" that is (imo) superior to the one that comes with Pd-vanilla. (and no, i will not remove "wrap" from zexy. it has been there for ages). whenever you load zexy's wrap (which is normally simply done by loading "zexy", but in PdX it might be very complicated), then zexy will overwrite the built-in wrap by it's own. Pd will then print: "warning: class 'wrap' overwritten; old one renamed 'wrap_aliased'"
so you have been warned.
most likely the same happens when you load gridflow (unless matju has done some weird hacking)
doesn't it make more sense to differentiate the two by calling one [gf_print] and the other [print]?
it would offload the task for correctly printing a message from Pd to the user. computers are mainly thought of as devices to offload tasks from the user rather than towards the user (though this often fails)
this way if I want to use a property of the GridFlow [print] object for some reason I know I can call it using its name
why would you?
why don't you think just fixing the obvious bug in GF's print won't help you more?
if you don't want to use GF's [print], then you probably don't want to use GF as well. in this case you probably don't want to load GF at all, which will magically evaporate the problem.
On Tue, 15 Jun 2010, IOhannes m zmoelnig wrote:
most likely the same happens when you load gridflow (unless matju has done some weird hacking)
I find the [objectmaker] class entry that says "print" and I modify the function-pointer variable in it. Pd doesn't get to know about it in any way.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
The key different between your Gem example and the GF vs. Pd [print]
is that you are talking about objects within the same library. The
[print] issue is about a library versus core. Overriding core objects
in a library seems like a bad idea, especially when its so simple to
call it something different.
.hc
On Jun 15, 2010, at 4:07 AM, IOhannes m zmoelnig wrote:
On 2010-06-12 01:23, Kim Cascone wrote:
IOhannes m zmölnig wrote:
most users should never notice (unless in a pleasant way).
if you instantiate a [print] object and don't know whether you are loading a buggy GridFlow [print]
object or a working Pd [print] object then how is this logical, clear or concise?most discussion here is very centered around the patching process. please don't forget about just loading a patch (and about using
premade abstractions for that matter).so if you load a patch with 87 [print]'s in there, what information do you get if Pd prints 86 times "dear user, you are using matju's
special [print], which has problems with parens". and how do you relate one of these warnings to a specific object? (luckily the warning mentions [print] in my example) and what happened to the 1 object that had no printout?and if it only should print once (as somebody suggested on the list): this should actually be done by Pd anyhow.
e.g. zexy comes with a version of "wrap" that is (imo) superior to the one that comes with Pd-vanilla. (and no, i will not remove "wrap" from zexy. it has been there for ages). whenever you load zexy's wrap
(which is normally simply done by loading "zexy", but in PdX it might be very complicated), then zexy will overwrite the built-in wrap by it's own. Pd will then print: "warning: class 'wrap' overwritten; old one renamed 'wrap_aliased'"so you have been warned.
most likely the same happens when you load gridflow (unless matju has done some weird hacking)
doesn't it make more sense to differentiate the two by calling one [gf_print] and the other [print]?
it would offload the task for correctly printing a message from Pd to the user. computers are mainly thought of as devices to offload tasks from the user rather than towards the user (though this often fails)
this way if I want to use a property of the GridFlow [print] object
for some reason I know I can call it using its namewhy would you?
why don't you think just fixing the obvious bug in GF's print won't
help you more?if you don't want to use GF's [print], then you probably don't want to use GF as well. in this case you probably don't want to load GF at
all, which will magically evaporate the problem.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
On Tue, 15 Jun 2010, Hans-Christoph Steiner wrote:
Overriding core objects in a library seems like a bad idea, especially when its so simple to call it something different.
It's so that patches that don't know about extra atomtypes can still handle extra atomtypes. Calling it something different doesn't work in that case.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Fri, 11 Jun 2010, IOhannes m zmölnig wrote:
(i guess that) gf's [print] is meant as a fully compatible [print], with some added features. most users should never notice (unless in a pleasant way). in the specific case here, i consider the behaviour of gf's print to be a bug, which should be fixed (just like zexy's pack/unpack).
An update on this : since then, I corrected some other discrepancies between GF's [print] and Pd's [print]. I also introduced the CLASS_NOPARENS flag (in GF's class declarations) to say that [print] shouldn't parse () in arguments as being nested-lists.
Only the biggest problem is remaining, which is about () in messages going to [print]. Back when we were having this discussion, I thought about having a flag for () in messages too, but in the end, I decided to just remove the whole ()-parsing business from objects, as it's really underused, and is going to become even less used. But as of 9.12's release last friday (still not announced on pd-list...) I still haven't done that. I suppose I could do that for 9.13, perhaps even this week.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Fri, 11 Jun 2010, Kim Cascone wrote:
coming from Max-landia it would most likely be done as follows: [print] = standard object ships with both Pd-vanilla and extended [gf_print] = print object shipped with the GridFlow libraries and _only_ called when [gf_print] is instantiated in a patch
I would have done it like this if [print] was able to handle extra atom types. But they don't. So I made GridFlow edit the method-table of [objectmaker] at load time and get rid of [print] so that I don't fuck things up just trying to print messages.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Fri, 11 Jun 2010, Roman Haefeli wrote:
On Fri, 2010-06-11 at 11:34 -0700, Kim Cascone wrote:
I fully agree with you. I find replacing built-in vanilla object classes a rather bad habit and quite confusing. I don't see a valid reason for doing that.
I don't see a valid reason for passing A_POINTER atoms around that aren't proper t_gpointer pointers, and I don't see a valid reason for [print] to say "consistency check failed" when it just doesn't know an atom type, and I don't see a valid reason for avoiding the addition of custom atom types in 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 and 2010.
http://lists.puredata.info/pipermail/pd-list/2002-08/007854.html http://lists.puredata.info/pipermail/pd-dev/2007-06/008995.html http://lists.puredata.info/pipermail/pd-dev/2008-07/012058.html (and so on)
Since one needs to load 'gridflow' anyway to use GridfFlow, why not simply put a Gridflow specific print object when needed?
The goal is to replace [print]. If I just want a [print] but [print] can't be customised to work with the atom type I introduce, then the built-in [print] needs to be replaced. It should be as easy to understand as why we shouldn't need a [printfloat] to print floats, a [printsymbol] to print symbols, etc.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Matju, Does the most recent version of GF post an informative message to the console when the user first creates a [print] object? (In 9.8 on winxp it doesn't.) If not, it should.
Or, why don't you just call your object [post]? That way when it replaces [print] there will be one less character to type.
-Jonathan
From: Mathieu Bouchard matju@artengine.ca To: Roman Haefeli reduzierer@yahoo.de Cc: pd-list pd-list@iem.at; Kim Cascone kim@anechoicmedia.com; IOhannes m zmoelnig zmoelnig@iem.at Sent: Mon, June 14, 2010 1:41:25 PM Subject: Re: [PD] plugin~ external
On Fri, 11 Jun 2010, Roman Haefeli wrote:
On Fri, 2010-06-11 at 11:34 -0700, Kim Cascone wrote:
I fully agree with you. I find replacing built-in vanilla object classes a rather bad habit and quite confusing. I don't see a valid reason for doing that.
I don't see a valid reason for passing A_POINTER atoms around that aren't proper t_gpointer pointers, and I don't see a valid reason for [print] to say "consistency check failed" when it just doesn't know an atom type, and I don't see a valid reason for avoiding the addition of custom atom types in 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 and 2010.
http://lists.puredata.info/pipermail/pd-list/2002-08/007854.html http://lists.puredata.info/pipermail/pd-dev/2007-06/008995.html http://lists.puredata.info/pipermail/pd-dev/2008-07/012058.html (and so on)
Since one needs to load 'gridflow' anyway to use GridfFlow, why not simply put a Gridflow specific print object when needed?
The goal is to replace [print]. If I just want a [print] but [print] can't be customised to work with the atom type I introduce, then the built-in [print] needs to be replaced. It should be as easy to understand as why we shouldn't need a [printfloat] to print floats, a [printsymbol] to print symbols, etc.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On 2010-06-15 08:11, Jonathan Wilkes wrote:
Matju, Does the most recent version of GF post an informative message to the console when the user first creates a [print] object? (In 9.8 on winxp it doesn't.) If not, it should.
Or, why don't you just call your object [post]? That way when it replaces [print] there will be one less character to type.
this kind of defies one of the purposes of "dynamic libraries", no?
let's make a very simple Gem-centered example: as you all know, Gem is based on openGL. now openGL is a bit weirdish, since it will behave differently depending on the libraries installed on your computer. sometimes it will use hardware acceleration, but if the proper libraries cannot be found, it will simply resort to software rendering. the results will be different: sw-rendering will be magnitudes slower, but also the rendered image is not guaranteed to be identical. however, the standard guarantees that the difference are "sufficiently small". if Gem was doing like most of you suggest, there would need to have separate objects for hardware accelerated rendering and software rendering. e.g. [Gem.sw.cube] vs [Gem.hw.cube], [Gem.sw.translate] vs [Gem.hw.translate] and so on. now this might be interesting in some cases (i remember a feature request for sw-rendering in an environment with hw acceleration), but in general, i'm sure that i would not want to have to rewrite every single patch i developed on my prehistoric netbook to be able to run at the final target architecture. as a matter of fact, i think it is an advantage that the user has not to be aware of the underlying components so much (though with recent openGL this became a bit more complicated; however that's an entirely different story)
of course this openness sometimes leads to some problems. e.g. the user of Gem doesn't really know whether hw acceleration will be available. Gem does print something to the console when it detects DRI (on linux), but this info probably doesn't tell you enough (and it's linux only).
also, an openGL implementation might choose to not fully implement the standard and decide to drop the green color (as it's not needed anyhow). most people will probably see this as a bug, as they will get results they did not expect at all. they should write to the implementor and complain, so the bug will probably be fixed (or the implementor convinces all people that they really don't need green).
i personally think that GF's [print] implementation is buggy, as it is not able to print symbols with parenthesis correctly in some circumstances. this bug should be fixed (if this involves rewriting the entire parsing machine for nested lists, then this is unfortunate but cannot be helped; our openGL implementor probably had good reasons to leave out the green channel as well)
i also think that Pd's [print] implementation is buggy, as it doesn't deal correctly with simple characters like comma, semicolon and braces. it's even more buggy, as it will print a scary warning about "bug" and "inconsistency" whenever it encounters something it doesn't know about.
all in all i think it likely that GF's implementation is less buggy than the vanilla implementation.
fgmkasdr IOhannes
Thanks for changing the subject line.
In your example, why wouldn't the developer just add a method so the user can send a message to set hardware or software acceleration (or query to see if hw accel. is available) if they wish to do so explicitly?
Anyway, I think my [post] vs. [print] question is really beside the point. What I want to know is if [gf.print] is an improvement over the current [print], why doesn't it just get incorporated into Pd? It doesn't make sense that someone should have to download and install GF to get a less buggy [print] object.
I don't understand what you were talking about in that other thread when you wrote about 87 objects in a patch that post a message to the console 86 times. I've never seen this happen. Most objects that post a console message only do so when the first instance is created, whether by actively patching or by opening a file. (See [expr] for an example of this.)
-Jonathan
From: IOhannes m zmoelnig zmoelnig@iem.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Mathieu Bouchard matju@artengine.ca; Roman Haefeli reduzierer@yahoo.de; pd-list pd-list@iem.at; Kim Cascone kim@anechoicmedia.com Sent: Tue, June 15, 2010 12:39:19 AM Subject: overriding objects (was Re: [PD] plugin~ external)
On 2010-06-15 08:11, Jonathan Wilkes wrote:
Matju, Does the most recent version of GF post an informative message to the console when the user first creates a [print] object? (In 9.8 on winxp it doesn't.) If not, it should.
Or, why don't you just call your object [post]? That way when it replaces [print] there will be one less character to type.
this kind of defies one of the purposes of "dynamic libraries", no?
let's make a very simple Gem-centered example: as you all know, Gem is based on openGL. now openGL is a bit weirdish, since it will behave differently depending on the libraries installed on your computer. sometimes it will use hardware acceleration, but if the proper libraries cannot be found, it will simply resort to software rendering. the results will be different: sw-rendering will be magnitudes slower, but also the rendered image is not guaranteed to be identical. however, the standard guarantees that the difference are "sufficiently small". if Gem was doing like most of you suggest, there would need to have separate objects for hardware accelerated rendering and software rendering. e.g. [Gem.sw.cube] vs [Gem.hw.cube], [Gem.sw.translate] vs [Gem.hw.translate] and so on. now this might be interesting in some cases (i remember a feature request for sw-rendering in an environment with hw acceleration), but in general, i'm sure that i would not want to have to rewrite every single patch i developed on my prehistoric netbook to be able to run at the final target architecture. as a matter of fact, i think it is an advantage that the user has not to be aware of the underlying components so much (though with recent openGL this became a bit more complicated; however that's an entirely different story)
of course this openness sometimes leads to some problems. e.g. the user of Gem doesn't really know whether hw acceleration will be available. Gem does print something to the console when it detects DRI (on linux), but this info probably doesn't tell you enough (and it's linux only).
also, an openGL implementation might choose to not fully implement the standard and decide to drop the green color (as it's not needed anyhow). most people will probably see this as a bug, as they will get results they did not expect at all. they should write to the implementor and complain, so the bug will probably be fixed (or the implementor convinces all people that they really don't need green).
i personally think that GF's [print] implementation is buggy, as it is not able to print symbols with parenthesis correctly in some circumstances. this bug should be fixed (if this involves rewriting the entire parsing machine for nested lists, then this is unfortunate but cannot be helped; our openGL implementor probably had good reasons to leave out the green channel as well)
i also think that Pd's [print] implementation is buggy, as it doesn't deal correctly with simple characters like comma, semicolon and braces. it's even more buggy, as it will print a scary warning about "bug" and "inconsistency" whenever it encounters something it doesn't know about.
all in all i think it likely that GF's implementation is less buggy than the vanilla implementation.
fgmkasdr IOhannes
On 2010-06-15 12:32, Jonathan Wilkes wrote:
Thanks for changing the subject line.
In your example, why wouldn't the developer just add a method so the user can send a message to set hardware or software acceleration (or query to see if hw accel. is available) if they wish to do so explicitly?
because openGL does not allow you to set hw/sw rendering. it is the very concept of openGL, that the implementation (whether rendering is done in hw, sw or quantum dimensions) is abstracted away and you should not need to wory about that.
Anyway, I think my [post] vs. [print] question is really beside the point. What I want to know is if [gf.print] is an improvement over the current [print], why doesn't it just get incorporated into Pd? It doesn't make sense that someone should have to download and install GF to get a less buggy [print] object.
yes, but that's the nature of Pd's development model. furthermore, in reality i suspect GF's [print] to have dependencies on GF, so you would be unable to run this [print] without GF installed.
Most objects that post a console message only do so when the first instance is created, whether by actively patching or by opening a file. (See [expr] for an example of this.)
[expr] doesn't do that. it's only the way you use [expr] that makes you believe it does.
you get a splashscreen when you load the "expr"-library (that is the file "expr.pd_linux" on your linux-system), which happens to provide the [expr] class. normally you are loading the library when creating the first instance of [expr] (because that's one way of Pd to load a library) but you could force the loading of the expr-library by starting Pd with "-lib expr" (or add "expr" to the libraries loaded at startup), which will give you the message without having created a single [expr].
with GF it is a bit different, as you have to load the whole library first in order to create GF's [print] then. if matju used Pd's mechanics to override the class (sidenote: Pd provides infrastracture to override built-in classes; so it seems that while some consider this "bad practice", others are not so religious about this), Pd would print out a warning about the print-class being overriden (while loading GF).
this is "mainly" what was asked for, no?
fgmasdr IOhannes
On Tue, 15 Jun 2010, IOhannes m zmoelnig wrote:
yes, but that's the nature of Pd's development model. furthermore, in reality i suspect GF's [print] to have dependencies on GF, so you would be unable to run this [print] without GF installed.
Every class in GridFlow depends on a common piece of code that implements a partial abstraction layer over the Pd API, involving an extra preprocessor pretending to be SWIG, etc. Furthermore, GF's [print] depends on the grid subsystem and the code of [#print] (which is only able to print grids).
Ideally, Miller would fix atom_string() and I'd delete my [print]. But we don't live in that fairyland.
if matju used Pd's mechanics to override the class (sidenote: Pd provides infrastracture to override built-in classes;
Pd started providing infrastructure for overriding builtins at about the same time as I added [print]. I did not use that infrastructure in the overriding of [print] because it wouldn't work on older versions of pd (as used by pd-extended). So I came up with a hack that forcibly removes the older [print] no matter what Pd thinks of it.
so it seems that while some consider this "bad practice", others are not so religious about this),
I considered it to be ok because I figured out that I would be the only one to do so for any given class. If there started to be conflicts of overriding (or if we were about to have conflicts of overriding) then there would be a great incentive for talking about an actual fix to the builtin class, or a common external that would replace both overridings at once, or any other resolution.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On 2010-06-15 16:16, Mathieu Bouchard wrote:
On Tue, 15 Jun 2010, IOhannes m zmoelnig wrote:
yes, but that's the nature of Pd's development model. furthermore, in reality i suspect GF's [print] to have dependencies on GF, so you would be unable to run this [print] without GF installed.
Every class in GridFlow depends on a common piece of code that implements a partial abstraction layer over the Pd API, involving an extra preprocessor pretending to be SWIG, etc. Furthermore, GF's [print] depends on the grid subsystem and the code of [#print] (which is only able to print grids).
Ideally, Miller would fix atom_string() and I'd delete my [print]. But we don't live in that fairyland.
we've been discussing that at the LAC2008 in cologne, where i proposed an "atom registry" (similar to the class_addnew() concept), where devs could register new atom-types. the idea was to attach a symbolic name to an atom (e.g. "float" or "pdpackage") and in return receive a numeric id (atom.a_type), allowing for multiple externals to use the same atom without having to hardcode the numeric ID (assuming that symbolic names would be less susceptible to clashes than arbitrary numbers; e.g. one could use a dns-like name like "ca.gridflow.grid".
the developer could then also provide an atom2string()-callback, that would allow the atom_string() to make something more meaningful of the new atom, than printing "consistency check failed: atom_string" (without newline). in the worst case (if no callback was provided), atom_string() could at least print the atom-name, e.g. "gem_state at.iem.gem:state at.iem.gem:cache"
it was turned down, as it adds too much complexity to the code for too little advantages...
fgvmasdf IOhannes
On Tue, 15 Jun 2010, IOhannes m zmoelnig wrote:
we've been discussing that at the LAC2008 in cologne,
back when it happened, there was no full report about it on pd-dev nor pd-list. It was just stated that a decision had been taken. From that point it really looked like this topic was not open for discussion. But it's not like it looked really open for discussion ever before.
the idea was to attach a symbolic name to an atom (e.g. "float" or "pdpackage") and in return receive a numeric id (atom.a_type), allowing for multiple externals to use the same atom without having to hardcode the numeric ID (assuming that symbolic names would be less susceptible to clashes than arbitrary numbers; e.g. one could use a dns-like name like "ca.gridflow.grid".
This namesystem needs not be any more complex than the namesystem of pd object classes. No-one is naming stuff like [at.iem.iemmatrix.mtx_*] nor [at/iem/iemmatrix/mtx_*] so I don't know why you would try to make it different for an atom-type registry. It doesn't need that disease. If you make it look like such namespacing is the way to go.
the developer could then also provide an atom2string()-callback, that would allow the atom_string() to make something more meaningful of the new atom,
Yes, including saving it to a pd file, if it makes sense in such a context ([textfile] or other).
than printing "consistency check failed: atom_string" (without newline). in the worst case (if no callback was provided),
In that case I'd like a more appropriate error message than that, such as "unknown atom type" and/or "no way to print this type of atom"
atom_string() could at least print the atom-name, e.g. "gem_state at.iem.gem:state at.iem.gem:cache"
more like gemstate:083ba8c0 gemcache:083bafe8
it was turned down, as it adds too much complexity to the code for too little advantages...
So how come the advantages are too little ? What are the advantages that were actually listed ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Tue, 15 Jun 2010, Mathieu Bouchard wrote:
This namesystem needs not be any more complex than the namesystem of pd object classes. No-one is naming stuff like [at.iem.iemmatrix.mtx_*] nor [at/iem/iemmatrix/mtx_*] so I don't know why you would try to make it different for an atom-type registry. It doesn't need that disease. If you make it look like such namespacing is the way to go.
erratum : didn't finish this sentence. If you make it look like such namespacing is the way to go, it makes the whole concept of the atom type registry look more complicated than it really is... even if it's just symbols or parts of symbols.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Oh, I see, I didn't check about expr. Well, a better example of what I'm talking about would be [polymap] in ekext, as well as (older versions of) [pddplink]. Both post a message about the particular object, both post only once, and both do so by using post in the setup routine for that object. Neither messages are posted when you load the respective libraries. So I'm confused by your example of this hypothetical object posting 86 messages when a patch is loaded-- I've never seen that happen. Do you have an example of this behavior?
I think such an initial post to the console saying that the object the user just created/loaded is an alias for gf.print, and that the old print is now pd/print, would be nice. But like I said, I haven't used the most recent version of GF-- if there's already some such message when the library is loaded then that works, too.
So I guess you're using this complicated Gem example to say that the user doesn't need to worry about which [print] is being used since GF just loads its own when the necessity for printing grids arises (i.e., when the gridflow library is loaded). Setting aside the issue of bugs for the moment, how does Pd's development model deal with another developer releasing library x which, when loaded, uses [print] as an alias for yet another object so it can display its atom type? Seems like the user would be stuck in the place you're trying to avoid-- having to use gf.print for GF and x/print for x, and also figuring out which of the three prints are the least buggy to use with everything else.
-Jonathan
From: IOhannes m zmoelnig zmoelnig@iem.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Mathieu Bouchard matju@artengine.ca; Roman Haefeli reduzierer@yahoo.de; pd-list pd-list@iem.at; Kim Cascone kim@anechoicmedia.com Sent: Tue, June 15, 2010 6:57:14 AM Subject: Re: overriding objects
On 2010-06-15 12:32, Jonathan Wilkes wrote:
Thanks for changing the subject line.
In your example, why wouldn't the developer just add a method so the user can send a message to set hardware or software acceleration (or query to see if hw accel. is available) if they wish to do so explicitly?
because openGL does not allow you to set hw/sw rendering. it is the very concept of openGL, that the implementation (whether rendering is done in hw, sw or quantum dimensions) is abstracted away and you should not need to wory about that.
Anyway, I think my [post] vs. [print] question is really beside the point. What I want to know is if [gf.print] is an improvement over the current [print], why doesn't it just get incorporated into Pd? It doesn't make sense that someone should have to download and install GF to get a less buggy [print] object.
yes, but that's the nature of Pd's development model. furthermore, in reality i suspect GF's [print] to have dependencies on GF, so you would be unable to run this [print] without GF installed.
Most objects that post a console message only do so when the first instance is created, whether by actively patching or by opening a file. (See [expr] for an example of this.)
[expr] doesn't do that. it's only the way you use [expr] that makes you believe it does.
you get a splashscreen when you load the "expr"-library (that is the file "expr.pd_linux" on your linux-system), which happens to provide the [expr] class. normally you are loading the library when creating the first instance of [expr] (because that's one way of Pd to load a library) but you could force the loading of the expr-library by starting Pd with "-lib expr" (or add "expr" to the libraries loaded at startup), which will give you the message without having created a single [expr].
with GF it is a bit different, as you have to load the whole library first in order to create GF's [print] then. if matju used Pd's mechanics to override the class (sidenote: Pd provides infrastracture to override built-in classes; so it seems that while some consider this "bad practice", others are not so religious about this), Pd would print out a warning about the print-class being overriden (while loading GF).
this is "mainly" what was asked for, no?
fgmasdr IOhannes
On Tue, Jun 15, 2010 at 11:46:53AM -0700, Jonathan Wilkes wrote:
Oh, I see, I didn't check about expr. Well, a better example of what I'm talking about would be [polymap] in ekext, as well as (older versions of) [pddplink]. Both post a message about the particular object, both post only once, and both do so by using post in the setup routine for that object. Neither messages are posted when you load the respective libraries. So I'm confused by your example [...]
I rather think you're confused by the term "loading a library". In pd-extended lingo, the term "loading a library" has been misused to also mean setting a couple of "-path"s. The traditional use of the term describes what happens when you use the "-lib" flag or [declare -lib ...]. polymap prints its message, when it's loaded like that:
$ pd -lib polymap
...
|. . . . . . . . .polymap. . . . . . . . .|
|_- polyphonic chain reaction regulator -_|
| . . . . . .Edward Kelly 2006. . . . . . |
Ciao
Frank
IOhannes m zmoelnig escribió:
if Gem was doing like most of you suggest, there would need to have separate objects for hardware accelerated rendering and software rendering. e.g. [Gem.sw.cube] vs [Gem.hw.cube], [Gem.sw.translate] vs [Gem.hw.translate] and so on. now this might be interesting in some cases (i remember a feature request for sw-rendering in an environment with hw acceleration), but in general, i'm sure that i would not want to have to rewrite every single patch i developed on my prehistoric netbook to be able to run at the final target architecture.
Of course not. But what about a configuration option that allows you to choose sw rendering? Maybe a message to [gemwin], or some options you could set somewhere at startup?
e.g. the user of Gem doesn't really know whether hw acceleration will be available.
That's bad indeed. Sometimes it happened to me that on some machine the rendering was slow like hell, so most likely for some reason the hardware was not detected correctly and software rendering was being used, but I had no way to be sure of that.
Couldn't GEM simply print out a message telling whether hardware acceleration is available or not??
while it might be interesting for roman and kim, it might as well be not; i have removed them from the list of direct addressees.
On 2010-06-15 13:04, Matteo Sisti Sette wrote:
Of course not. But what about a configuration option that allows you to choose sw rendering? Maybe a message to [gemwin], or some options you could set somewhere at startup?
again: you misunderstand how openGL works. the user is not meant to have control about these kind of things.
Gem is openGL, and it fully adheres to this principle.
e.g. the user of Gem doesn't really know whether hw acceleration will be available.
That's bad indeed. Sometimes it happened to me that on some machine the rendering was slow like hell, so most likely for some reason the hardware was not detected correctly and software rendering was being used, but I had no way to be sure of that.
Couldn't GEM simply print out a message telling whether hardware acceleration is available or not??
simple: use linux, there you get at least a message whether DRI is used (which doesn't necessarily mean that rendering will be lightning fast)
obviously this ("change your OS") is not a good solution for many people.
fmgasdr IOhannes
On Mon, 2010-06-14 at 16:41 -0400, Mathieu Bouchard wrote:
On Fri, 11 Jun 2010, Roman Haefeli wrote:
On Fri, 2010-06-11 at 11:34 -0700, Kim Cascone wrote:
I fully agree with you. I find replacing built-in vanilla object classes a rather bad habit and quite confusing. I don't see a valid reason for doing that.
I don't see a valid reason for passing A_POINTER atoms around that aren't proper t_gpointer pointers, and I don't see a valid reason for [print] to say "consistency check failed" when it just doesn't know an atom type, and I don't see a valid reason for avoiding the addition of custom atom types in 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 and 2010.
http://lists.puredata.info/pipermail/pd-list/2002-08/007854.html http://lists.puredata.info/pipermail/pd-dev/2007-06/008995.html http://lists.puredata.info/pipermail/pd-dev/2008-07/012058.html (and so on)
Since one needs to load 'gridflow' anyway to use GridfFlow, why not simply put a Gridflow specific print object when needed?
The goal is to replace [print]. If I just want a [print] but [print] can't be customised to work with the atom type I introduce, then the built-in [print] needs to be replaced. It should be as easy to understand as why we shouldn't need a [printfloat] to print floats, a [printsymbol] to print symbols, etc.
As I see it, fixing the original vanilla class is the only way to go. And if the author refuses to include a patch that addresses issues with the original class, then the only way is to add a new class (instead of overriding it). From a moral point of view, overriding an object class to me seems like stealing a name, that belongs to another class. It's an uncivilized action. However, that is my personal feeling. I don't know how much it makes sense to talk about moral implications.
Another thing is: If I understand correctly, this can be done only once. As soon as some other library also tries to override [print], it's going to be messy. Which [print] you finally will have, will then depend on the order you load the libraries. So this definitely adds another (imho unnecessary) layer of complexity.
Also: Before this ability was added to Pd, class names were claimed by a simple rule: First come, first serve. When you loaded Gem first, [scale] would call Gem's scale class, no matter if you loaded maxlib or whatsoever after. Since built-in classes can be overriden, you have to deal with two rules at the same time. Depending on the situation, sometimes 'first come, first serve' applies, but in other cases 'last come, first serve'. How difficult will it be to write a patch, that works the same in many environments?
Another thing: If a certain class has bugs, I would like to be able to rely on those bug. I certainly wouldn't want to be surprised to see, that my patch is not working anymore, simply because for some reason I did not load gridflow or zexy anymore.
In no way I can see in what way overriding object classes would add the claimed (by IOhannes) transparency for the user.
Obviously, a lot of people (apparently also Miller himself) don't see a problem with the ability to override internal classes. However, I guess the fact that Pd allows to do that, doesn't invalidate my point. I still believe it was a mis-conception to add this functionality to Pd and wouldn't mind to see it removed.
Roman
On Fri, 11 Jun 2010, Kim Cascone wrote:
because I've been (unknowlingly) using the GridFlow [print] and I'm missing this info
BTW, I just fixed the problem with [print 42]. I misunderstood the problem and first thought that it was something with sending 42 to a [print] object under certain circumstances.
this is really confusing for people using [print] not knowing they are using the GridFlow external instead of the standard Pd version how do we disentangle this and make it obvious? and why isn't there a GridFlow [print] external called [gf_print] instead?
It's already called [gf.print] (to be renamed to [gf/print] later...) but [print] is an alias because the intent is to use it instead of the regular [print].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard wrote:
On Fri, 11 Jun 2010, Kim Cascone wrote:
because I've been (unknowlingly) using the GridFlow [print] and I'm missing this info
BTW, I just fixed the problem with [print 42]. I misunderstood the problem and first thought that it was something with sending 42 to a [print] object under certain circumstances.
good to hear and congrats on fixing! :)
this is really confusing for people using [print] not knowing they are using the GridFlow external instead of the standard Pd version how do we disentangle this and make it obvious? and why isn't there a GridFlow [print] external called [gf_print] instead?
It's already called [gf.print] (to be renamed to [gf/print] later...) but [print] is an alias because the intent is to use it instead of the regular [print].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
cyrille henry -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jonathan Wilkes -
Kim Cascone -
Martin Peach -
Mathieu Bouchard -
Matteo Sisti Sette -
patko -
Roman Haefeli -
ydegoyon＠gmail.com