hello,
i'm using latest pd test version on miller website. depending on my screen(s) resolution the size of pd font change a lot. see : http://nusmuk.free.fr/pd_font/
cyrille
Hmm, didn't think of checking on that... I'll give it a try. Thanks for the warning.
Miller
On Fri, Nov 23, 2007 at 12:33:29AM +0100, cyrille henry wrote:
hello,
i'm using latest pd test version on miller website. depending on my screen(s) resolution the size of pd font change a lot. see : http://nusmuk.free.fr/pd_font/
cyrille
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ok, try test 08 :)
M
On Fri, Nov 23, 2007 at 07:31:57AM -0800, Miller Puckette wrote:
Hmm, didn't think of checking on that... I'll give it a try. Thanks for the warning.
Miller
On Fri, Nov 23, 2007 at 12:33:29AM +0100, cyrille henry wrote:
hello,
i'm using latest pd test version on miller website. depending on my screen(s) resolution the size of pd font change a lot. see : http://nusmuk.free.fr/pd_font/
cyrille
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
hello,
test 08 is better, but not perfect :
- the font of the objects are the same whatever the screen size -> ok
- the font size of text in the main pd window is still change
- the font size of the comment (canvas label) that i use in the _gemwin gop abstraction are also changing.
should i upload new snapshot?
thanks, Cyrille
Miller Puckette a écrit :
Ok, try test 08 :)
M
On Fri, Nov 23, 2007 at 07:31:57AM -0800, Miller Puckette wrote:
Hmm, didn't think of checking on that... I'll give it a try. Thanks for the warning.
Miller
On Fri, Nov 23, 2007 at 12:33:29AM +0100, cyrille henry wrote:
hello,
i'm using latest pd test version on miller website. depending on my screen(s) resolution the size of pd font change a lot. see : http://nusmuk.free.fr/pd_font/
cyrille
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
Hm, those will take longer to figure out (because all the IEM horrorshow will be affected too).
cheers Miller
On Fri, Nov 23, 2007 at 07:04:25PM +0100, cyrille henry wrote:
hello,
test 08 is better, but not perfect :
- the font of the objects are the same whatever the screen size -> ok
- the font size of text in the main pd window is still change
- the font size of the comment (canvas label) that i use in the _gemwin gop
abstraction are also changing.
should i upload new snapshot?
thanks, Cyrille
Miller Puckette a ?crit :
Ok, try test 08 :)
M
On Fri, Nov 23, 2007 at 07:31:57AM -0800, Miller Puckette wrote:
Hmm, didn't think of checking on that... I'll give it a try. Thanks for the warning.
Miller
On Fri, Nov 23, 2007 at 12:33:29AM +0100, cyrille henry wrote:
hello,
i'm using latest pd test version on miller website. depending on my screen(s) resolution the size of pd font change a lot. see : http://nusmuk.free.fr/pd_font/
cyrille
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
FYI: in Pd-extended, the IEM guis and the Pd fonts are the same sizes
on all platforms.
One key part of it is: "tk scaling 1", perhaps the resolution
changing the font size is related to that.
.hc
On Nov 23, 2007, at 4:28 PM, Miller Puckette wrote:
Hm, those will take longer to figure out (because all the IEM horrorshow will be affected too).
cheers Miller
On Fri, Nov 23, 2007 at 07:04:25PM +0100, cyrille henry wrote:
hello,
test 08 is better, but not perfect :
- the font of the objects are the same whatever the screen size -> ok
- the font size of text in the main pd window is still change
- the font size of the comment (canvas label) that i use in the
_gemwin gop abstraction are also changing.
should i upload new snapshot?
thanks, Cyrille
Miller Puckette a ?crit :
Ok, try test 08 :)
M
On Fri, Nov 23, 2007 at 07:31:57AM -0800, Miller Puckette wrote:
Hmm, didn't think of checking on that... I'll give it a try.
Thanks for the warning.Miller
On Fri, Nov 23, 2007 at 12:33:29AM +0100, cyrille henry wrote:
hello,
i'm using latest pd test version on miller website. depending on my screen(s) resolution the size of pd font change
a lot. see : http://nusmuk.free.fr/pd_font/cyrille
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith
On Fri, 23 Nov 2007, Hans-Christoph Steiner wrote:
FYI: in Pd-extended, the IEM guis and the Pd fonts are the same sizes on all platforms. One key part of it is: "tk scaling 1", perhaps the resolution changing the font size is related to that.
Also, as I've said before, using negative font sizes bypasses the scaling, because then the units are pixels instead of points. "tk scaling 1" makes this easier if all you ever want is pixel fonts, but if you want both points and pixels for any reason, then you have to use negative font sizes.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Nov 23, 2007, at 5:41 PM, Mathieu Bouchard wrote:
On Fri, 23 Nov 2007, Hans-Christoph Steiner wrote:
FYI: in Pd-extended, the IEM guis and the Pd fonts are the same
sizes on all platforms. One key part of it is: "tk scaling 1",
perhaps the resolution changing the font size is related to that.Also, as I've said before, using negative font sizes bypasses the
scaling, because then the units are pixels instead of points. "tk
scaling 1" makes this easier if all you ever want is pixel fonts,
but if you want both points and pixels for any reason, then you
have to use negative font sizes.
pd-vanilla isn't using the tk scaling stuff at all, so it makes IMHO
to turn it off, in effect, by forcing it to be 1.
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
I favor the negative-font-size approach since it makes it possible for future extesions to control their own behavior.
cheers Miller
On Fri, Nov 23, 2007 at 06:35:12PM -0500, Hans-Christoph Steiner wrote:
On Nov 23, 2007, at 5:41 PM, Mathieu Bouchard wrote:
On Fri, 23 Nov 2007, Hans-Christoph Steiner wrote:
FYI: in Pd-extended, the IEM guis and the Pd fonts are the same
sizes on all platforms. One key part of it is: "tk scaling 1",
perhaps the resolution changing the font size is related to that.Also, as I've said before, using negative font sizes bypasses the
scaling, because then the units are pixels instead of points. "tk
scaling 1" makes this easier if all you ever want is pixel fonts,
but if you want both points and pixels for any reason, then you
have to use negative font sizes.pd-vanilla isn't using the tk scaling stuff at all, so it makes IMHO
to turn it off, in effect, by forcing it to be 1..hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
tk scaling is a global setting for the application. I think it makes
sense to either use tk scaling thruout, or ignore it. A half
implemented feature is worse than none at all, IMHO.
.hc
On Nov 24, 2007, at 11:38 AM, Miller Puckette wrote:
I favor the negative-font-size approach since it makes it possible for future extesions to control their own behavior.
cheers Miller
On Fri, Nov 23, 2007 at 06:35:12PM -0500, Hans-Christoph Steiner
wrote:On Nov 23, 2007, at 5:41 PM, Mathieu Bouchard wrote:
On Fri, 23 Nov 2007, Hans-Christoph Steiner wrote:
FYI: in Pd-extended, the IEM guis and the Pd fonts are the same sizes on all platforms. One key part of it is: "tk scaling 1", perhaps the resolution changing the font size is related to that.
Also, as I've said before, using negative font sizes bypasses the scaling, because then the units are pixels instead of points. "tk scaling 1" makes this easier if all you ever want is pixel fonts, but if you want both points and pixels for any reason, then you have to use negative font sizes.
pd-vanilla isn't using the tk scaling stuff at all, so it makes IMHO to turn it off, in effect, by forcing it to be 1.
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
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
excuse me, if this is already was mentioned and i missed it, but the different-fontsizes-with-different-display-resolution-problem was not introduced with 0.41. at least it exists already in 0.40.
roman
On Sat, 2007-11-24 at 08:38 -0800, Miller Puckette wrote:
I favor the negative-font-size approach since it makes it possible for future extesions to control their own behavior.
cheers Miller
On Fri, Nov 23, 2007 at 06:35:12PM -0500, Hans-Christoph Steiner wrote:
On Nov 23, 2007, at 5:41 PM, Mathieu Bouchard wrote:
On Fri, 23 Nov 2007, Hans-Christoph Steiner wrote:
FYI: in Pd-extended, the IEM guis and the Pd fonts are the same
sizes on all platforms. One key part of it is: "tk scaling 1",
perhaps the resolution changing the font size is related to that.Also, as I've said before, using negative font sizes bypasses the
scaling, because then the units are pixels instead of points. "tk
scaling 1" makes this easier if all you ever want is pixel fonts,
but if you want both points and pixels for any reason, then you
have to use negative font sizes.pd-vanilla isn't using the tk scaling stuff at all, so it makes IMHO
to turn it off, in effect, by forcing it to be 1..hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
OK.... test09, hopefully, fixes it :)
I've got a long list of bugs to try to fix... otherwise I'm probably not going to try to add any more "features" to this release before canning it.
cheers Miller
On Fri, Nov 23, 2007 at 07:04:25PM +0100, cyrille henry wrote:
hello,
test 08 is better, but not perfect :
- the font of the objects are the same whatever the screen size -> ok
- the font size of text in the main pd window is still change
- the font size of the comment (canvas label) that i use in the _gemwin gop abstraction are also changing.
should i upload new snapshot?
thanks, Cyrille
hello, yes, test 09 look good. whatever the screen resolution is. (at least on my ubuntu computer) thanks Cyrille
Miller Puckette a écrit :
OK.... test09, hopefully, fixes it :)
I've got a long list of bugs to try to fix... otherwise I'm probably not going to try to add any more "features" to this release before canning it.
cheers Miller
On Fri, Nov 23, 2007 at 07:04:25PM +0100, cyrille henry wrote:
hello,
test 08 is better, but not perfect :
- the font of the objects are the same whatever the screen size -> ok
- the font size of text in the main pd window is still change
- the font size of the comment (canvas label) that i use in the _gemwin gop abstraction are also changing.
should i upload new snapshot?
thanks, Cyrille
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Miller Puckette wrote:
OK.... test09, hopefully, fixes it :)
I've got a long list of bugs to try to fix... otherwise I'm probably not going to try to add any more "features" to this release before canning it.
i have jut assigned you some more patches in the patchtracker at sourceforge...;-)
so this basically means that we will get a new pd-version soon? great!
fmfadt. IOhannes
Well, not much has happened, but the test version is stable enough it seems better to work toward a "stable" version of teh present state than to try to add all the features I want to put in next :)
M
On Fri, Dec 07, 2007 at 01:17:19AM +0100, IOhannes m zmoelnig wrote:
Miller Puckette wrote:
OK.... test09, hopefully, fixes it :)
I've got a long list of bugs to try to fix... otherwise I'm probably not going to try to add any more "features" to this release before canning it.
i have jut assigned you some more patches in the patchtracker at sourceforge...;-)
so this basically means that we will get a new pd-version soon? great!
fmfadt. IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Miller Puckette wrote:
Well, not much has happened, but the test version is stable enough it seems better to work toward a "stable" version of teh present state than to try to add all the features I want to put in next :)
that sounds even better!
i'll get my wishlist engine running before soon with stuff like:
- user defined atom-types
- a better saving hook including
- somehow moving "open abstraction" into sys_loadlib chain
- 64bit-pd (that is, not just run pd on an amd64; but have
t_float/t_sample be *large*)
- ..
- and all rest i cannot think of right now
fg,adf IOhannes
On Fri, 2007-12-07 at 01:26 +0100, IOhannes m zmoelnig wrote:
i'll get my wishlist engine running before soon with stuff like:
- 64bit-pd (that is, not just run pd on an amd64; but have
t_float/t_sample be *large*)
does that mean, that every float in pd on an 64bit machine will have 64bit precision? and each sample in a table uses 8 byte ram? does it also mean, that there will be less [tabread4~] floating point rounding issues (in other words: [tabread4~] sounds 'good' up to x minutes?)
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Fri, 7 Dec 2007, Roman Haefeli wrote:
On Fri, 2007-12-07 at 01:26 +0100, IOhannes m zmoelnig wrote:
i'll get my wishlist engine running before soon with stuff like:
- 64bit-pd (that is, not just run pd on an amd64; but have
t_float/t_sample be *large*)
does that mean, that every float in pd on an 64bit machine will have 64bit precision? and each sample in a table uses 8 byte ram? does it also mean, that there will be less [tabread4~] floating point rounding issues (in other words: [tabread4~] sounds 'good' up to x minutes?)
A day of mono 96000 Hz sound at 64 bits per sample would take 61.8 gigs of RAM. This takes 33 bits of precision to address. This leaves 19 bits of between-samples precision for interpolation by [tabread4]. The precision of float64 is 52 bits, thus the number of significant bits is 53, still not counting the sign. Thus float64 completely includes uint53 and int54. This raises the counter problem's threshold to 9007199254740992.
And yes, it would use twice more RAM everywhere. This includes the cache, so it may cause slowdown in some situations. I would enjoy it if [table] and its friends supported int16 (mere CD quality) for example. I believe that in float64 mode, pd could benefit from a float32 option on [table] too.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Dec 6, 2007, at 11:43 PM, Mathieu Bouchard wrote:
On Fri, 7 Dec 2007, Roman Haefeli wrote:
On Fri, 2007-12-07 at 01:26 +0100, IOhannes m zmoelnig wrote:
i'll get my wishlist engine running before soon with stuff like:
- 64bit-pd (that is, not just run pd on an amd64; but have
t_float/t_sample be *large*)
does that mean, that every float in pd on an 64bit machine will have 64bit precision? and each sample in a table uses 8 byte ram? does it also mean, that there will be less [tabread4~] floating point
rounding issues (in other words: [tabread4~] sounds 'good' up to x minutes?)A day of mono 96000 Hz sound at 64 bits per sample would take 61.8
gigs of RAM. This takes 33 bits of precision to address. This
leaves 19 bits of between-samples precision for interpolation by
[tabread4]. The precision of float64 is 52 bits, thus the number of
significant bits is 53, still not counting the sign. Thus float64
completely includes uint53 and int54. This raises the counter
problem's threshold to 9007199254740992.And yes, it would use twice more RAM everywhere. This includes the
cache, so it may cause slowdown in some situations. I would enjoy
it if [table] and its friends supported int16 (mere CD quality) for
example. I believe that in float64 mode, pd could benefit from a
float32 option on [table] too.
I believe IEM has a suite of tools for using 16-bit samples called
"iem16".
.hc
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
On Fri, 7 Dec 2007, Hans-Christoph Steiner wrote:
On Dec 6, 2007, at 11:43 PM, Mathieu Bouchard wrote:
And yes, it would use twice more RAM everywhere. This includes the cache, so it may cause slowdown in some situations. I would enjoy it if [table] and its friends supported int16 (mere CD quality) for example. I believe that in float64 mode, pd could benefit from a float32 option on [table] too.
I believe IEM has a suite of tools for using 16-bit samples called "iem16".
Right, but I believe it would be better if it were all integrated together so that it would be easy to recompile any existing externals with support for any extra types added... e.g. if I add a new array element type in m_pd.h would just be a plain recompile away (a recompile of all externals). (This is possible with macros, even without any C++ features)
It makes it harder to keep binary compatibility, but then switching pd to float64 also is doubling the number of binaries to make, unless float64 is really only used in 64-bit mode and float32 only used in 32-bit mode.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
cyrille henry -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
Miller Puckette -
Roman Haefeli