I think that Pd should startup with a blank Pd window, just like a blank canvas. The new log levels makes this easy to accomplish. Gem is the last library in Pd-extended that still uses post() for its version message. I propose using the new 0.43 logpost(NULL, 3, "Gem version);. Then by default, the Pd window is blank, but people can easily see all the version posts if they want to.
.hc
----------------------------------------------------------------------------
kill your television
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-09-27 02:39, Hans-Christoph Steiner wrote:
I think that Pd should startup with a blank Pd window, just like a blank canvas. The new log levels makes this easy to accomplish. Gem is the last library in Pd-extended that still uses post() for its version message. I propose using the new 0.43 logpost(NULL, 3, "Gem version);. Then by default, the Pd window is blank, but people can easily see all the version posts if they want to.
i don't see a point in using logpost() as is, for two reasons: - - logpost() is there since 0.43, i want the Gem binaries to work on 0.42 and possibly 0.41 this is not a big problem for PdX, where you ensure that the pd binary is accompanied by "matching" externals, but it is a problem if you distribute binary builds of the external. - - logpost() is mainly there to post verbose information that is attached to an object. the Gem version is not attached to any object.
apart from that, i don't see much harm done in seeing a 10 line splashscreen. on the contrary, i really think that people should be made aware that they have loaded Gem. and people could use a lower log level to suppress these messages.
but feel free to report a feature request.
fgmasdr IOhannes
On Sep 27, 2011, at 3:05 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-09-27 02:39, Hans-Christoph Steiner wrote:
I think that Pd should startup with a blank Pd window, just like a blank canvas. The new log levels makes this easy to accomplish. Gem is the last library in Pd-extended that still uses post() for its version message. I propose using the new 0.43 logpost(NULL, 3, "Gem version);. Then by default, the Pd window is blank, but people can easily see all the version posts if they want to.
i don't see a point in using logpost() as is, for two reasons:
- logpost() is there since 0.43, i want the Gem binaries to work
on 0.42 and possibly 0.41 this is not a big problem for PdX, where you ensure that the pd binary is accompanied by "matching" externals, but it is a problem if you distribute binary builds of the external.
This can easily support any Pd version with an #ifdef, I'll add that.
- logpost() is mainly there to post verbose information that is
attached to an object. the Gem version is not attached to any object.
I wrote logpost() to do both. Just set the object to NULL and it just posts.
apart from that, i don't see much harm done in seeing a 10 line splashscreen. on the contrary, i really think that people should be made aware that they have loaded Gem. and people could use a lower log level to suppress these messages.
but feel free to report a feature request.
It is a specific complaint I have heard from many people starting out with Pd. They find it intimidating and confusing that the first thing they see is a window full of text that they don't understand. That's one reason. Another reason affects all Pd users, when you hit File-
New, you get a blank window. Following this tradition in Pd, the Pd
window should also start out blank, unless there is an error. The new log window allows the best of both worlds, just change to log level 3 if you want to see all the version messages. And log level 2, you only see important messages.
The only disadvantage that I can see is that there will be a little #ifdef in the code, but I am sure Gem has many, so this is a small thing. I'm about to submit a patch, look for it in the pd-gem tracker.
.hc
----------------------------------------------------------------------------
kill your television
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-09-27 21:37, Hans-Christoph Steiner wrote:
and possibly 0.41 this is not a big problem for PdX, where you ensure that the pd binary is accompanied by "matching" externals, but it is a problem if you distribute binary builds of the external.
This can easily support any Pd version with an #ifdef, I'll add that.
i'm talking about runtim compatibility, not compile time compatibility. an #ifdef patch will most likely not going to make it before Pd-0.45
(there might be some old code in Gem that indeed uses #ifdef for these kind of things but i want to make it fade out (unless the Pd-version tested for has been there for a number of years)
- logpost() is mainly there to post verbose information that is
attached to an object. the Gem version is not attached to any object.
I wrote logpost() to do both. Just set the object to NULL and it just posts.
i thought i did :-), but indeed this is your work.
nevertheless, verbose() offers the same functionality as logpost(NULL,) and works with older version of pd.
sdfmt IOhannes
On Sep 28, 2011, at 3:12 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-09-27 21:37, Hans-Christoph Steiner wrote:
and possibly 0.41 this is not a big problem for PdX, where you ensure that the pd binary is accompanied by "matching" externals, but it is a problem if you distribute binary builds of the external.
This can easily support any Pd version with an #ifdef, I'll add that.
i'm talking about runtim compatibility, not compile time compatibility. an #ifdef patch will most likely not going to make it before Pd-0.45
(there might be some old code in Gem that indeed uses #ifdef for these kind of things but i want to make it fade out (unless the Pd-version tested for has been there for a number of years)
Ah, I see. Are there any runtime tests for the Pd version in Gem?
- logpost() is mainly there to post verbose information that is
attached to an object. the Gem version is not attached to any object.
I wrote logpost() to do both. Just set the object to NULL and it just posts.
i thought i did :-), but indeed this is your work.
nevertheless, verbose() offers the same functionality as logpost(NULL,) and works with older version of pd.
I'm perfectly happy if you want to use verbose() instead of logpost(). I didn't use it because I can't remember what level it posts at, there is something about +4.
.hc
----------------------------------------------------------------------------
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/28/2011 03:05 PM, Hans-Christoph Steiner wrote:
Ah, I see. Are there any runtime tests for the Pd version in Gem?
how it that supposed to help?
I'm perfectly happy if you want to use verbose() instead of logpost(). I didn't use it because I can't remember what level it posts at, there is something about +4.
so you are saying that there is a loglevel between post() and verbose(0)? how come?
fgmasdr IOhannes
On Sep 29, 2011, at 2:59 AM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/28/2011 03:05 PM, Hans-Christoph Steiner wrote:
Ah, I see. Are there any runtime tests for the Pd version in Gem?
how it that supposed to help?
I'm perfectly happy if you want to use verbose() instead of logpost(). I didn't use it because I can't remember what level it posts at, there is something about +4.
so you are saying that there is a loglevel between post() and verbose(0)? how come?
Because that's the way it is, and that the way that you insisted it be against Miller and my objections. You insisted that verbose() post with a +4 on the log level. Try it for yourself:
log level 2 post("post mycobject: %f", f);
log level 3 verbose(-1, "verbose -1 mycobject: %f", f);
log level 4 verbose(0, "verbose 0 mycobject: %f", f);
.hc
----------------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-09-29 17:05, Hans-Christoph Steiner wrote:
so you are saying that there is a loglevel between post() and verbose(0)? how come?
Because that's the way it is, and that the way that you insisted it be against Miller and my objections. You insisted that verbose() post with a +4 on the log level.
since i cannot remember such a thing (even after reading up the discussion on verbose() again), i would very much like you to give a reference for my "insistance" and your (and miller's ) objections.
what i do remember, is that i i wanted verbose(3) to be more important than verbose(5), and that verbose(0) is less important than post().
the latter is probably the reason for "+4" [1], but my intention would never have been to have a _gap_ between post() and verbose(0).
post() should be verbose(-1), and not verbose(-2).
the problem probably came from removing some named error loglevel, and due to the confusion between named loglevels and numbered loglevels.
ffgasmdr IOhannes
[1] http://lists.puredata.info/pipermail/pd-dev/2011-02/016578.html
On Sep 29, 2011, at 11:23 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-09-29 17:05, Hans-Christoph Steiner wrote:
so you are saying that there is a loglevel between post() and verbose(0)? how come?
Because that's the way it is, and that the way that you insisted it be against Miller and my objections. You insisted that verbose() post with a +4 on the log level.
since i cannot remember such a thing (even after reading up the discussion on verbose() again), i would very much like you to give a reference for my "insistance" and your (and miller's ) objections.
what i do remember, is that i i wanted verbose(3) to be more important than verbose(5), and that verbose(0) is less important than post().
the latter is probably the reason for "+4" [1], but my intention would never have been to have a _gap_ between post() and verbose(0).
post() should be verbose(-1), and not verbose(-2).
the problem probably came from removing some named error loglevel, and due to the confusion between named loglevels and numbered loglevels.
I think the numbering in verbose() is weird. What you propose makes a little more sense than the current thing, but I think there should just be one numbering scheme at the interface, i.e. logpost(3) should post at the same level as verbose(3) and they both should be the same numbers as what are in the Pd window. I completely avoid verbose() because it means I have to look up or test how its numbers work. With ogpost(), I just think about log level menu, which I use a lot.
.hc
----------------------------------------------------------------------------
Mistrust authority - promote decentralization. - the hacker ethic