I just finished a big, long-overdue reorg of the http://puredata.info/docs/developer section of the website.
- Its now a "wiki folder" so it acts like a regular wiki, not like a
weird plone mix of things. It also allows email subscripts to wiki
pages.
I purged old pages and redirected them to the new versions
I cleaned up the formatting on the front page
I updated references to CVS, etc.
I purged a couple very out-of-date things
Let me know what you think, and please contribute where you can! :-D
.hc
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
On Sat, Jul 2, 2011 at 20:41, Hans-Christoph Steiner hans@at.or.at wrote:
I just finished a big, long-overdue reorg of the http://puredata.info/docs/**developerhttp://puredata.info/docs/developersection of the website.
- Its now a "wiki folder" so it acts like a regular wiki, not like a weird
plone mix of things. It also allows email subscripts to wiki pages.
I purged old pages and redirected them to the new versions
I cleaned up the formatting on the front page
I updated references to CVS, etc.
I purged a couple very out-of-date things
Let me know what you think, and please contribute where you can! :-D
.hc
IMHO the whole GUI Plugins stuff could go under Developer.
Andras
On Jul 3, 2011, at 10:04 AM, András Murányi wrote:
On Sat, Jul 2, 2011 at 20:41, Hans-Christoph Steiner hans@at.or.at
wrote:I just finished a big, long-overdue reorg of the http://puredata.info/docs/developer section of the website.
- Its now a "wiki folder" so it acts like a regular wiki, not like
a weird plone mix of things. It also allows email subscripts to
wiki pages.
I purged old pages and redirected them to the new versions
I cleaned up the formatting on the front page
I updated references to CVS, etc.
I purged a couple very out-of-date things
Let me know what you think, and please contribute where you can! :-D
.hc
IMHO the whole GUI Plugins stuff could go under Developer.
One goal for me is to make it easy enough for all Pd users to write
their own GUI plugins. Honestly, I think we can make GUI plugins
replace the idea of preferences. A simple set of preferences is very
easy to understand. But many people find a simple set limiting, so
you see many programs implementing huge preferences systems that
mystify most users (think Photoshop, MS Office, OpenOffice, etc.) I
think with a well designed scripting/plugin system, it would work
better than preferences.
.hc
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
2011/7/3 Hans-Christoph Steiner hans@at.or.at
On Jul 3, 2011, at 10:04 AM, András Murányi wrote:
On Sat, Jul 2, 2011 at 20:41, Hans-Christoph Steiner hans@at.or.atwrote:
I just finished a big, long-overdue reorg of the http://puredata.info/docs/**developerhttp://puredata.info/docs/developersection of the website.
- Its now a "wiki folder" so it acts like a regular wiki, not like a
weird plone mix of things. It also allows email subscripts to wiki pages.
I purged old pages and redirected them to the new versions
I cleaned up the formatting on the front page
I updated references to CVS, etc.
I purged a couple very out-of-date things
Let me know what you think, and please contribute where you can! :-D
.hc
IMHO the whole GUI Plugins stuff could go under Developer.
One goal for me is to make it easy enough for all Pd users to write their own GUI plugins. Honestly, I think we can make GUI plugins replace the idea of preferences. A simple set of preferences is very easy to understand. But many people find a simple set limiting, so you see many programs implementing huge preferences systems that mystify most users (think Photoshop, MS Office, OpenOffice, etc.) I think with a well designed scripting/plugin system, it would work better than preferences.
.hc
Understood. However, I think plugins can never replace preferences as they are two different things. Plugins need to save their data somewhere too, and that somewhere is the preferences. If the file format of preferences was something programmatic (ie. not "loadlib9: moonlib" but "variable loadlib9 'moonlib'" or something like that) there would be more change for a convergence, but at the same time the format would be less easy to parse/write/etc. So at the end, preferences are data, and plugins are programs, and that's how it's good. But, I understand and agree that you want to bring plugins closer to the users and that that's why plugin docs won't go under developer docs.
Andras
On Wed, 06 Jul 2011 15:32 +0200, "András Murányi" muranyia@gmail.com wrote:
2011/7/3 Hans-Christoph Steiner hans@at.or.at
On Jul 3, 2011, at 10:04 AM, András Murányi wrote:
On Sat, Jul 2, 2011 at 20:41, Hans-Christoph Steiner hans@at.or.atwrote:
I just finished a big, long-overdue reorg of the http://puredata.info/docs/**developerhttp://puredata.info/docs/developersection of the website.
- Its now a "wiki folder" so it acts like a regular wiki, not like a
weird plone mix of things. It also allows email subscripts to wiki pages.
I purged old pages and redirected them to the new versions
I cleaned up the formatting on the front page
I updated references to CVS, etc.
I purged a couple very out-of-date things
Let me know what you think, and please contribute where you can! :-D
.hc
IMHO the whole GUI Plugins stuff could go under Developer.
One goal for me is to make it easy enough for all Pd users to write their own GUI plugins. Honestly, I think we can make GUI plugins replace the idea of preferences. A simple set of preferences is very easy to understand. But many people find a simple set limiting, so you see many programs implementing huge preferences systems that mystify most users (think Photoshop, MS Office, OpenOffice, etc.) I think with a well designed scripting/plugin system, it would work better than preferences.
.hc
Understood. However, I think plugins can never replace preferences as they are two different things. Plugins need to save their data somewhere too, and that somewhere is the preferences. If the file format of preferences was something programmatic (ie. not "loadlib9: moonlib" but "variable loadlib9 'moonlib'" or something like that) there would be more change for a convergence, but at the same time the format would be less easy to parse/write/etc. So at the end, preferences are data, and plugins are programs, and that's how it's good. But, I understand and agree that you want to bring plugins closer to the users and that that's why plugin docs won't go under developer docs.
Andras
In the context of a programming environment, I don't see a lot of reason to have a separate preferences system. Things like configuring the audio and MIDI interface are usually best handled in the patch, and that should be as easy as possible. IOhannes has made big progress there with the 'mediasettings' library. Things like loading libraries should definitely be done in the patch and not globally. Just look at python, ruby, java, C++, C, etc. etc. etc for examples there.
What I'd like to see is a standard Pd patch that is loaded in the place of preferences. Then you could configure your Pd setup using a Pd patch. Any Pd user is going to know how to make a patch, so if you can configure Pd with a Pd patch, then you don't need to learn any new preferences file format or system.
hc
2011/7/6 Hans-Christoph Steiner hans@at.or.at
On Wed, 06 Jul 2011 15:32 +0200, "András Murányi" muranyia@gmail.com wrote:
2011/7/3 Hans-Christoph Steiner hans@at.or.at
On Jul 3, 2011, at 10:04 AM, András Murányi wrote:
On Sat, Jul 2, 2011 at 20:41, Hans-Christoph Steiner <hans@at.or.at
wrote:
I just finished a big, long-overdue reorg of the http://puredata.info/docs/**developer<
http://puredata.info/docs/developer%3Esection of the website.
- Its now a "wiki folder" so it acts like a regular wiki, not like a
weird plone mix of things. It also allows email subscripts to wiki
pages.
I purged old pages and redirected them to the new versions
I cleaned up the formatting on the front page
I updated references to CVS, etc.
I purged a couple very out-of-date things
Let me know what you think, and please contribute where you can! :-D
.hc
IMHO the whole GUI Plugins stuff could go under Developer.
One goal for me is to make it easy enough for all Pd users to write
their
own GUI plugins. Honestly, I think we can make GUI plugins replace the
idea
of preferences. A simple set of preferences is very easy to
understand.
But many people find a simple set limiting, so you see many programs implementing huge preferences systems that mystify most users (think Photoshop, MS Office, OpenOffice, etc.) I think with a well designed scripting/plugin system, it would work better than preferences.
.hc
Understood. However, I think plugins can never replace preferences as they are two different things. Plugins need to save their data somewhere too, and that somewhere is the preferences. If the file format of preferences was something programmatic (ie. not "loadlib9: moonlib" but "variable loadlib9 'moonlib'" or something like that) there would be more change for a convergence, but at the same time the format would be less easy to parse/write/etc. So at the end, preferences are data, and plugins are programs, and that's how it's good. But, I understand and agree that you want to bring plugins closer to the users and that that's why plugin docs won't go under developer docs.
Andras
In the context of a programming environment, I don't see a lot of reason to have a separate preferences system. Things like configuring the audio and MIDI interface are usually best handled in the patch, and that should be as easy as possible. IOhannes has made big progress there with the 'mediasettings' library. Things like loading libraries should definitely be done in the patch and not globally. Just look at python, ruby, java, C++, C, etc. etc. etc for examples there.
What I'd like to see is a standard Pd patch that is loaded in the place of preferences. Then you could configure your Pd setup using a Pd patch. Any Pd user is going to know how to make a patch, so if you can configure Pd with a Pd patch, then you don't need to learn any new preferences file format or system.
hc
OK, sounds good. But let's just remember the use case when we want pd to remember which plugins to load and which not. As plugins load before any patch, and they couldn't really be enabled/disabled per patch, their preferences will have to be stored somewhere else. We agreed before that the "/disabled" folders method is no good, and that we (probably me) will code up a logic which stores this in preferences (via ::pd_guiprefs). I'm interested in further brainstorming but right now I feel that good old preferences is something we'll have to live with for a longer time. We'll have to make a distinction between global stuff (plugins, global prefs) and those things which are better handled per patch, from inside patches.
Andras
On Wed, 06 Jul 2011 18:52 +0200, "András Murányi" muranyia@gmail.com wrote:
2011/7/6 Hans-Christoph Steiner hans@at.or.at
On Wed, 06 Jul 2011 15:32 +0200, "András Murányi" muranyia@gmail.com wrote:
2011/7/3 Hans-Christoph Steiner hans@at.or.at
On Jul 3, 2011, at 10:04 AM, András Murányi wrote:
On Sat, Jul 2, 2011 at 20:41, Hans-Christoph Steiner <hans@at.or.at
wrote:
I just finished a big, long-overdue reorg of the http://puredata.info/docs/**developer<
http://puredata.info/docs/developer%3Esection of the website.
- Its now a "wiki folder" so it acts like a regular wiki, not like a
weird plone mix of things. It also allows email subscripts to wiki
pages.
I purged old pages and redirected them to the new versions
I cleaned up the formatting on the front page
I updated references to CVS, etc.
I purged a couple very out-of-date things
Let me know what you think, and please contribute where you can! :-D
.hc
IMHO the whole GUI Plugins stuff could go under Developer.
One goal for me is to make it easy enough for all Pd users to write
their
own GUI plugins. Honestly, I think we can make GUI plugins replace the
idea
of preferences. A simple set of preferences is very easy to
understand.
But many people find a simple set limiting, so you see many programs implementing huge preferences systems that mystify most users (think Photoshop, MS Office, OpenOffice, etc.) I think with a well designed scripting/plugin system, it would work better than preferences.
.hc
Understood. However, I think plugins can never replace preferences as they are two different things. Plugins need to save their data somewhere too, and that somewhere is the preferences. If the file format of preferences was something programmatic (ie. not "loadlib9: moonlib" but "variable loadlib9 'moonlib'" or something like that) there would be more change for a convergence, but at the same time the format would be less easy to parse/write/etc. So at the end, preferences are data, and plugins are programs, and that's how it's good. But, I understand and agree that you want to bring plugins closer to the users and that that's why plugin docs won't go under developer docs.
Andras
In the context of a programming environment, I don't see a lot of reason to have a separate preferences system. Things like configuring the audio and MIDI interface are usually best handled in the patch, and that should be as easy as possible. IOhannes has made big progress there with the 'mediasettings' library. Things like loading libraries should definitely be done in the patch and not globally. Just look at python, ruby, java, C++, C, etc. etc. etc for examples there.
What I'd like to see is a standard Pd patch that is loaded in the place of preferences. Then you could configure your Pd setup using a Pd patch. Any Pd user is going to know how to make a patch, so if you can configure Pd with a Pd patch, then you don't need to learn any new preferences file format or system.
hc
OK, sounds good. But let's just remember the use case when we want pd to remember which plugins to load and which not. As plugins load before any patch, and they couldn't really be enabled/disabled per patch, their preferences will have to be stored somewhere else. We agreed before that the "/disabled" folders method is no good, and that we (probably me) will code up a logic which stores this in preferences (via ::pd_guiprefs). I'm interested in further brainstorming but right now I feel that good old preferences is something we'll have to live with for a longer time. We'll have to make a distinction between global stuff (plugins, global prefs) and those things which are better handled per patch, from inside patches.
Yes, I agree. For things that affect the editor and not the patch itself, then preferences makes more sense.
.hc
Hello,
I also agree with the idea to abolish the .pd* config files in homedirectory.
Instead there should be a default settings patch, i.e. ~/.pd-settings.pd or ~/.pd/init.pd or something of that nature. Probably it's a good idea to use have ~/.pd/ to start with, so one could put gui pluggins there and other things. Though there should be a shortcut in the menu to edit open the init patch.
Earlier I have had an idea that the configs should be done in Tcl instead of the format that they have, but if one uses pd without gui, Tcl scrips cannot be interpreted.
The #purest idea would be to use patches for setting.
Cheers,
Ilya
On Wed, Jul 06, 2011 at 01:43:33PM -0400, Hans-Christoph Steiner wrote:
OK, sounds good. But let's just remember the use case when we want pd to remember which plugins to load and which not. As plugins load before any patch, and they couldn't really be enabled/disabled per patch, their preferences will have to be stored somewhere else. We agreed before that the "/disabled" folders method is no good, and that we (probably me) will code up a logic which stores this in preferences (via ::pd_guiprefs). I'm interested in further brainstorming but right now I feel that good old preferences is something we'll have to live with for a longer time. We'll have to make a distinction between global stuff (plugins, global prefs) and those things which are better handled per patch, from inside patches.
Yes, I agree. For things that affect the editor and not the patch itself, then preferences makes more sense.
.hc
Having a list of plugins would be probably the best cross-platform solution.
However, it may be a good idea to have plugin sets, if one needs to start-up in kiosk mode or something else at times :)
Perhaps the file with plugin list should supplied as an argument.
Cheers,
Ilya
On 07/06/2011 10:53 PM, errordeveloper@gmail.com wrote:
We agreed before that the "/disabled" folders method is no good, and that we (probably me) will code up a logic which stores this in preferences (via ::pd_guiprefs). I'm interested in further brainstorming but right now I feel that good old preferences is something we'll have to live with for a longer time. We'll have to make a distinction between global stuff (plugins, global prefs) and those things which are better handled per patch, from inside patches.
Yes, I agree. For things that affect the editor and not the patch itself, then preferences makes more sense.
Having a list of plugins would be probably the best cross-platform solution.
However, it may be a good idea to have plugin sets, if one needs to start-up in kiosk mode or something else at times :)
Perhaps the file with plugin list should supplied as an argument.
why not using ::pd-guiprefs for plugins: http://www.mail-archive.com/pd-list@iem.at/msg44236.html
0.02$, _y
On Thu, Jul 7, 2011 at 02:14, yvan volochine yvan.pd@gmail.com wrote:
On 07/06/2011 10:53 PM, errordeveloper@gmail.com wrote:
We agreed before that the
"/disabled" folders method is no good, and that we (probably me) will code up a logic which stores this in preferences (via ::pd_guiprefs). I'm interested in further brainstorming but right now I feel that good old preferences is something we'll have to live with for a longer time. We'll have to make a distinction between global stuff (plugins, global prefs) and those things which are better handled per patch, from inside patches.
Yes, I agree. For things that affect the editor and not the patch itself, then preferences makes more sense.
Having a list of plugins would be probably the best cross-platform solution.
However, it may be a good idea to have plugin sets, if one needs to start-up in kiosk mode or something else at times :)
Perhaps the file with plugin list should supplied as an argument.
why not using ::pd-guiprefs for plugins: http://www.mail-archive.com/**pd-list@iem.at/msg44236.htmlhttp://www.mail-archive.com/pd-list@iem.at/msg44236.html
0.02$, _y
Bingo Yvan, that very post is which I have on my todo list, and which I have referred saying "we (probably me) will code up a logic which stores this in preferences (via ::pd_guiprefs)" :o)
Andras
On Wed, 6 Jul 2011, Hans-Christoph Steiner wrote:
What I'd like to see is a standard Pd patch that is loaded in the place of preferences. Then you could configure your Pd setup using a Pd patch. Any Pd user is going to know how to make a patch, so if you can configure Pd with a Pd patch, then you don't need to learn any new preferences file format or system.
From what you had said, it wasn't clear whether you wanted something
involving pd patches. "make GUI plugins replace[...]" sounds like it would all be handled by new tcl files, possibly lots of them, and it doesn't sound like something that would involve any pd patch at all.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Jul 10, 2011, at 11:10 AM, Mathieu Bouchard wrote:
On Wed, 6 Jul 2011, Hans-Christoph Steiner wrote:
What I'd like to see is a standard Pd patch that is loaded in the
place of preferences. Then you could configure your Pd setup using
a Pd patch. Any Pd user is going to know how to make a patch, so
if you can configure Pd with a Pd patch, then you don't need to
learn any new preferences file format or system.From what you had said, it wasn't clear whether you wanted something
involving pd patches. "make GUI plugins replace[...]" sounds like it
would all be handled by new tcl files, possibly lots of them, and it
doesn't sound like something that would involve any pd patch at all.
I don't know how it will really take shape. Pd prefs should probably
be in Pd syntax. The GUI is written in Tcl, so it makes sense to keep
the GUI stuff in Tcl. But one or multiple files, or which language or
syntax is all up in the air in my book. I've been working to provide
the raw elements for people to work with and hopefully Pd people will
shape this system in a way that works best. That seems the most Pd-
ish to me.
.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 Sun, 3 Jul 2011, Hans-Christoph Steiner wrote:
One goal for me is to make it easy enough for all Pd users to write their own GUI plugins. Honestly, I think we can make GUI plugins replace the idea of preferences.
Don't overestimate the users' capacity to (or will to) deal with Tcl syntax. Chances are that they will be editing such files for the first time in their lives and will need a Tcl tutorial to get going. Then they will only do the most basic things.
Most prefs are only simple data such as someflag=1 or bgcolor=#0055aa.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Sun, 7/10/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] reorg of puredata.info/docs/developer To: "Hans-Christoph Steiner" hans@at.or.at Cc: "PD List" pd-list@iem.at Date: Sunday, July 10, 2011, 5:05 PM On Sun, 3 Jul 2011, Hans-Christoph Steiner wrote:
One goal for me is to make it easy enough for all Pd
users to write their own GUI plugins. Honestly, I think we can make GUI plugins replace the idea of preferences.
Don't overestimate the users' capacity to (or will to) deal with Tcl syntax. Chances are that they will be editing such files for the first time in their lives and will need a Tcl tutorial to get going. Then they will only do the most basic things.
Most prefs are only simple data such as someflag=1 or bgcolor=#0055aa.
I really like the idea of the prefs being a pd patch which gets loaded as a hidden patch like pd-_float (but doesn't get destroyed if you happen to "vis" it then close it so that one can view it from a menubutton). It could start out as something as simple as some explanatory comments and the following:
[loadbang] | [canvas_colors 1 2 3 4 etc.( <- canvas_bg obj_inner obj_border wires etc. | [s pd]
Then you can open up development/design of the preferences patch to a larger audience (i.e., not just people who know or are willing to learn an additional language like tcl).
This would require designing a clear and consistent interface for sending preference messages to "pd", but I think it would be worth it. Something as simple as getting white text on a black background without leaving the pd message system would be a great benefit to users.
-jonathan
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Jul 10, 2011, at 1:39 PM, Jonathan Wilkes wrote:
--- On Sun, 7/10/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] reorg of puredata.info/docs/developer To: "Hans-Christoph Steiner" hans@at.or.at Cc: "PD List" pd-list@iem.at Date: Sunday, July 10, 2011, 5:05 PM On Sun, 3 Jul 2011, Hans-Christoph Steiner wrote:
One goal for me is to make it easy enough for all Pd
users to write their own GUI plugins. Honestly, I think we can make GUI plugins replace the idea of preferences.
Don't overestimate the users' capacity to (or will to) deal with Tcl syntax. Chances are that they will be editing such files for the first time in their lives and will need a Tcl tutorial to get going. Then they will only do the most basic things.
Most prefs are only simple data such as someflag=1 or bgcolor=#0055aa.
I really like the idea of the prefs being a pd patch which gets
loaded as a hidden patch like pd-_float (but doesn't get destroyed
if you happen to "vis" it then close it so that one can view it from
a menubutton). It could start out as something as simple as some
explanatory comments and the following:[loadbang] | [canvas_colors 1 2 3 4 etc.( <- canvas_bg obj_inner obj_border wires
etc. | [s pd]Then you can open up development/design of the preferences patch to
a larger audience (i.e., not just people who know or are willing to
learn an additional language like tcl).This would require designing a clear and consistent interface for
sending preference messages to "pd", but I think it would be worth
it. Something as simple as getting white text on a black background
without leaving the pd message system would be a great benefit to
users.-jonathan
'pd-gui' already sends only Pd messages to 'pd', so that API is fully
available in patches, and reasonably documented (see pd-msg). Then
there is [sys_gui] for sending Tcl to the GUI. That's direct access
to the current state of things. Its a bit weird, but that's how it
happens on the inside. Really I suppose we should be making an API
for 'pd-gui', and make 'pd' talk to 'pd-gui' using only Pd messages.
That's a big project, but I'd like to see that happen.
.hc
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
On Sun, 10 Jul 2011, Jonathan Wilkes wrote:
I really like the idea of the prefs being a pd patch which gets loaded as a hidden patch like pd-_float (but doesn't get destroyed if you happen to "vis" it then close it so that one can view it from a menubutton).
Sending "vis 0" to a toplevel canvas-object doesn't "close" the patch in the way you might imagine : then the patch still runs, but the window is closed AND not listed in the Window menus. It can be a useful trick. The canvas can still be reached if you know its symbol and can be brought back using a "vis 1". Thus it could be summoned from any patch.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Jul 16, 2011, at 12:44 PM, Mathieu Bouchard wrote:
On Sun, 10 Jul 2011, Jonathan Wilkes wrote:
I really like the idea of the prefs being a pd patch which gets
loaded as a hidden patch like pd-_float (but doesn't get destroyed
if you happen to "vis" it then close it so that one can view it
from a menubutton).Sending "vis 0" to a toplevel canvas-object doesn't "close" the
patch in the way you might imagine : then the patch still runs, but
the window is closed AND not listed in the Window menus. It can be a
useful trick. The canvas can still be reached if you know its symbol
and can be brought back using a "vis 1". Thus it could be summoned
from any patch.
I think he means more than it doesn't show up like a regular patch
window. I think the default prefs patch window could be embedded in
the Pd window, perhaps. Or just callable from a menu.
.hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
--- On Sat, 7/16/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] reorg of puredata.info/docs/developer To: "Mathieu Bouchard" matju@artengine.ca Cc: "Jonathan Wilkes" jancsika@yahoo.com, "PD List" pd-list@iem.at Date: Saturday, July 16, 2011, 11:00 PM
On Jul 16, 2011, at 12:44 PM, Mathieu Bouchard wrote:
On Sun, 10 Jul 2011, Jonathan Wilkes wrote:
I really like the idea of the prefs being a pd
patch which gets loaded as a hidden patch like pd-_float (but doesn't get destroyed if you happen to "vis" it then close it so that one can view it from a menubutton).
Sending "vis 0"
Yeah, I meant closing it by clicking the "x" on that window. That closes the patch.
to a toplevel canvas-object doesn't
"close" the patch in the way you might imagine : then the patch still runs, but the window is closed AND not listed in the Window menus. It can be a useful trick. The canvas can still be reached if you know its symbol and can be brought back using a "vis 1". Thus it could be summoned from any patch.
I think he means more than it doesn't show up like a regular patch window. I think the default prefs patch window could be embedded in the Pd window, perhaps. Or just callable from a menu.
.hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
On Sat, 16 Jul 2011, Jonathan Wilkes wrote:
Yeah, I meant closing it by clicking the "x" on that window. That closes the patch.
If you want such a patch to be permanent, make it a subpatch of an otherwise-empty toplevel patch on which you do "vis 0". In such a case, clicking the X never unloads the file.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Thanks for doing this! I was just trying to compile pd-extended a week or two ago, and was pretty lost in the old instructions. I had actually been meaning to try to clean them up myself, but it appears my procrastination paid off :-).
-- Jacob Lee artdent@gmail.com
On Sat, Jul 2, 2011 at 6:41 PM, Hans-Christoph Steiner hans@at.or.at wrote:
I just finished a big, long-overdue reorg of the http://puredata.info/docs/developer section of the website.
* Its now a "wiki folder" so it acts like a regular wiki, not like a weird plone mix of things. It also allows email subscripts to wiki pages.
* I purged old pages and redirected them to the new versions
* I cleaned up the formatting on the front page
* I updated references to CVS, etc.
* I purged a couple very out-of-date things
Let me know what you think, and please contribute where you can! :-D
.hc
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Since this is fresh on your mind, please do check out the update
section to see if I actually improved the situation. I know I did
remove a bunch of out-of-date info, but hopefully I replaced it with
useful, up-to-date info ;).
.hc
On Jul 4, 2011, at 5:51 PM, Jacob Lee wrote:
Thanks for doing this! I was just trying to compile pd-extended a week or two ago, and was pretty lost in the old instructions. I had actually been meaning to try to clean them up myself, but it appears my procrastination paid off :-).
-- Jacob Lee artdent@gmail.com
On Sat, Jul 2, 2011 at 6:41 PM, Hans-Christoph Steiner
hans@at.or.at wrote:I just finished a big, long-overdue reorg of the http://puredata.info/docs/developer section of the website.
- Its now a "wiki folder" so it acts like a regular wiki, not like
a weird plone mix of things. It also allows email subscripts to wiki pages.
I purged old pages and redirected them to the new versions
I cleaned up the formatting on the front page
I updated references to CVS, etc.
I purged a couple very out-of-date things
Let me know what you think, and please contribute where you can! :-D
.hc
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"We have nothing to fear from love and commitment." - New York Senator
Diane Savino, trying to convince the NY Senate to pass a gay marriage
bill
I should, there is a specific question of whether these two are still
needed:
http://puredata.info/docs/developer/64BitLinux http://puredata.info/docs/developer/BuildingPdExtended64bitUbuntuIntrepid
0.43 should work fine on all 64-bit systems (never tested Windows tho).
.hc
On Jul 4, 2011, at 6:08 PM, Hans-Christoph Steiner wrote:
Since this is fresh on your mind, please do check out the update
section to see if I actually improved the situation. I know I did
remove a bunch of out-of-date info, but hopefully I replaced it with
useful, up-to-date info ;)..hc
On Jul 4, 2011, at 5:51 PM, Jacob Lee wrote:
Thanks for doing this! I was just trying to compile pd-extended a
week or two ago, and was pretty lost in the old instructions. I had actually been meaning to try to clean them up myself, but it appears my procrastination paid off :-).-- Jacob Lee artdent@gmail.com
On Sat, Jul 2, 2011 at 6:41 PM, Hans-Christoph Steiner
hans@at.or.at wrote:I just finished a big, long-overdue reorg of the http://puredata.info/docs/developer section of the website.
- Its now a "wiki folder" so it acts like a regular wiki, not like
a weird plone mix of things. It also allows email subscripts to wiki pages.
I purged old pages and redirected them to the new versions
I cleaned up the formatting on the front page
I updated references to CVS, etc.
I purged a couple very out-of-date things
Let me know what you think, and please contribute where you can! :-D
.hc
Computer science is no more related to the computer than astronomy
is related to the telescope. -Edsger Dykstra
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"We have nothing to fear from love and commitment." - New York
Senator Diane Savino, trying to convince the NY Senate to pass a gay
marriage bill
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
Trying to compile PureData, SVN, on Ubuntu 11.04 AMD64, following the instruction from the page http://puredata.info/docs/developer, I did:
1.- rsync from the auto-build farm (from http://puredata.info/docs/developer/GettingPdSource) rsync -av --delete rsync://128.238.56.50/distros/pd-extended/ pd-extended/
2.- Preparing Ubuntu: http://puredata.info/docs/developer/UbuntuMaverick
3.- Building PD-Extended: http://puredata.info/docs/developer/BuildingPdExtended
But there's no .tar.bz2 or .deb on
pure-data/packages/linux-make/build... These are the last lines while
compilling. What should I do? I don't understand...
/[...]
/bin/bash ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
-I. -I../../src -I../../src -DPD -I/home/mario/pd-extended/pd/src
-DHAVE_S_STUFF_H -O2 -freg-struct-return -O3 -falign-loops
-falign-functions -falign-jumps -funroll-loops -ffast-math -mmmx -MT
libGem_la-SynchedWorkerThread.lo -MD -MP -MF
.deps/libGem_la-SynchedWorkerThread.Tpo -c -o
libGem_la-SynchedWorkerThread.lo test -f 'SynchedWorkerThread.cpp' || echo './'SynchedWorkerThread.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src -DPD
-I/home/mario/pd-extended/pd/src -DHAVE_S_STUFF_H -O2
-freg-struct-return -O3 -falign-loops -falign-functions -falign-jumps
-funroll-loops -ffast-math -mmmx -MT libGem_la-SynchedWorkerThread.lo
-MD -MP -MF .deps/libGem_la-SynchedWorkerThread.Tpo -c
SynchedWorkerThread.cpp -fPIC -DPIC -o
.libs/libGem_la-SynchedWorkerThread.o
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src -DPD
-I/home/mario/pd-extended/pd/src -DHAVE_S_STUFF_H -O2
-freg-struct-return -O3 -falign-loops -falign-functions -falign-jumps
-funroll-loops -ffast-math -mmmx -MT libGem_la-SynchedWorkerThread.lo
-MD -MP -MF .deps/libGem_la-SynchedWorkerThread.Tpo -c
SynchedWorkerThread.cpp -o libGem_la-SynchedWorkerThread.o >/dev/null 2>&1
mv -f .deps/libGem_la-SynchedWorkerThread.Tpo
.deps/libGem_la-SynchedWorkerThread.Plo
/bin/bash ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
-I. -I../../src -I../../src -DPD -I/home/mario/pd-extended/pd/src
-DHAVE_S_STUFF_H -O2 -freg-struct-return -O3 -falign-loops
-falign-functions -falign-jumps -funroll-loops -ffast-math -mmmx -MT
libGem_la-WorkerThread.lo -MD -MP -MF .deps/libGem_la-WorkerThread.Tpo
-c -o libGem_la-WorkerThread.lo test -f 'WorkerThread.cpp' || echo './'WorkerThread.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src -DPD
-I/home/mario/pd-extended/pd/src -DHAVE_S_STUFF_H -O2
-freg-struct-return -O3 -falign-loops -falign-functions -falign-jumps
-funroll-loops -ffast-math -mmmx -MT libGem_la-WorkerThread.lo -MD -MP
-MF .deps/libGem_la-WorkerThread.Tpo -c WorkerThread.cpp -fPIC -DPIC -o
.libs/libGem_la-WorkerThread.o
WorkerThread.cpp: In member function 'bool
gem::thread::WorkerThread::PIMPL::start()':
WorkerThread.cpp:135:22: error: aggregate
'gem::thread::WorkerThread::PIMPL::start()::timeval sleep' has
incomplete type and cannot be defined
WorkerThread.cpp:139:28: error: 'select' was not declared in this scope
make[6]: *** [libGem_la-WorkerThread.lo] Error 1
make[6]: se sale del directorio
«/home/mario/pd-extended/externals/Gem/src/Gem»
make[5]: *** [all-recursive] Error 1
make[5]: se sale del directorio «/home/mario/pd-extended/externals/Gem/src»
make[4]: *** [all] Error 2
make[4]: se sale del directorio «/home/mario/pd-extended/externals/Gem/src»
make[3]: *** [all-recursive] Error 1
make[3]: se sale del directorio «/home/mario/pd-extended/externals/Gem»
make[2]: *** [/home/mario/pd-extended/externals/Gem/Gem.pd_linux] Error 2
make[2]: se sale del directorio «/home/mario/pd-extended/externals»
make[1]: *** [externals_install] Error 2
make[1]: se sale del directorio «/home/mario/pd-extended/packages»
make: *** [install] Error 2
ls: no se puede acceder a
/home/mario/pd-extended/packages/linux_make/./Pd*.deb: No existe el
fichero o el directorio
upload specs linux_make . deb
Uploading
Unexpected local arg: debian
If arg is a remote file/dir, prefix it with a colon (:).
rsync error: syntax or usage error (code 1) at main.c(1236) [Receiver=3.0.7]
mario@Mario-PK3D:~$
/
Gem is currently broken on GNU/Linux and IOhannes is on vacation. To
make a build, remove 'gem' from LIB_TARGETS in pd-extended/externals/
Makefile and the rest should build.
.hc
On Jul 4, 2011, at 11:47 PM, Mario Mey wrote:
Trying to compile PureData, SVN, on Ubuntu 11.04 AMD64, following
the instruction from the page http://puredata.info/docs/developer, I
did:1.- rsync from the auto-build farm (from http://puredata.info/docs/developer/GettingPdSource) rsync -av --delete rsync://128.238.56.50/distros/pd-extended/ pd- extended/
2.- Preparing Ubuntu: http://puredata.info/docs/developer/UbuntuMaverick
3.- Building PD-Extended: http://puredata.info/docs/developer/BuildingPdExtended
But there's no .tar.bz2 or .deb on pure-data/packages/linux-make/ build... These are the last lines while compilling. What should I
do? I don't understand...[...] /bin/bash ../../libtool --tag=CXX --mode=compile g++ - DHAVE_CONFIG_H -I. -I../../src -I../../src -DPD -I/home/mario/pd- extended/pd/src -DHAVE_S_STUFF_H -O2 -freg-struct-return -O3 - falign-loops -falign-functions -falign-jumps -funroll-loops -ffast- math -mmmx -MT libGem_la-SynchedWorkerThread.lo -MD -MP -MF .deps/ libGem_la-SynchedWorkerThread.Tpo -c -o libGem_la- SynchedWorkerThread.lo
test -f 'SynchedWorkerThread.cpp' || echo './'SynchedWorkerThread.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src - DPD -I/home/mario/pd-extended/pd/src -DHAVE_S_STUFF_H -O2 -freg- struct-return -O3 -falign-loops -falign-functions -falign-jumps - funroll-loops -ffast-math -mmmx -MT libGem_la-SynchedWorkerThread.lo
-MD -MP -MF .deps/libGem_la-SynchedWorkerThread.Tpo -c
SynchedWorkerThread.cpp -fPIC -DPIC -o .libs/libGem_la- SynchedWorkerThread.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src - DPD -I/home/mario/pd-extended/pd/src -DHAVE_S_STUFF_H -O2 -freg- struct-return -O3 -falign-loops -falign-functions -falign-jumps - funroll-loops -ffast-math -mmmx -MT libGem_la-SynchedWorkerThread.lo
-MD -MP -MF .deps/libGem_la-SynchedWorkerThread.Tpo -c
SynchedWorkerThread.cpp -o libGem_la-SynchedWorkerThread.o >/dev/ null 2>&1 mv -f .deps/libGem_la-SynchedWorkerThread.Tpo .deps/libGem_la- SynchedWorkerThread.Plo /bin/bash ../../libtool --tag=CXX --mode=compile g++ - DHAVE_CONFIG_H -I. -I../../src -I../../src -DPD -I/home/mario/pd- extended/pd/src -DHAVE_S_STUFF_H -O2 -freg-struct-return -O3 - falign-loops -falign-functions -falign-jumps -funroll-loops -ffast- math -mmmx -MT libGem_la-WorkerThread.lo -MD -MP -MF .deps/libGem_la- WorkerThread.Tpo -c -o libGem_la-WorkerThread.lotest -f 'WorkerThread.cpp' || echo './'WorkerThread.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src - DPD -I/home/mario/pd-extended/pd/src -DHAVE_S_STUFF_H -O2 -freg- struct-return -O3 -falign-loops -falign-functions -falign-jumps - funroll-loops -ffast-math -mmmx -MT libGem_la-WorkerThread.lo -MD - MP -MF .deps/libGem_la-WorkerThread.Tpo -c WorkerThread.cpp -fPIC - DPIC -o .libs/libGem_la-WorkerThread.o WorkerThread.cpp: In member function ‘bool
gem::thread::WorkerThread::PIMPL::start()’: WorkerThread.cpp:135:22: error: aggregate
‘gem::thread::WorkerThread::PIMPL::start()::timeval sleep’ has
incomplete type and cannot be defined WorkerThread.cpp:139:28: error: ‘select’ was not declared in this
scope make[6]: *** [libGem_la-WorkerThread.lo] Error 1 make[6]: se sale del directorio «/home/mario/pd-extended/externals/ Gem/src/Gem» make[5]: *** [all-recursive] Error 1 make[5]: se sale del directorio «/home/mario/pd-extended/externals/ Gem/src» make[4]: *** [all] Error 2 make[4]: se sale del directorio «/home/mario/pd-extended/externals/ Gem/src» make[3]: *** [all-recursive] Error 1 make[3]: se sale del directorio «/home/mario/pd-extended/externals/ Gem» make[2]: *** [/home/mario/pd-extended/externals/Gem/Gem.pd_linux]
Error 2 make[2]: se sale del directorio «/home/mario/pd-extended/externals» make[1]: *** [externals_install] Error 2 make[1]: se sale del directorio «/home/mario/pd-extended/packages» make: *** [install] Error 2 ls: no se puede acceder a /home/mario/pd-extended/packages/ linux_make/./Pd*.deb: No existe el fichero o el directorio upload specs linux_make . deb Uploading Unexpected local arg: debian If arg is a remote file/dir, prefix it with a colon (:). rsync error: syntax or usage error (code 1) at main.c(1236)
[Receiver=3.0.7] mario@Mario-PK3D:~$
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone." --Bjarne Stroustrup (creator of C++)
Hi,
Mario Mey wrote:
Trying to compile PureData, SVN, on Ubuntu 11.04 AMD64, following the instruction from the page http://puredata.info/docs/developer, I did:
1.- rsync from the auto-build farm (from http://puredata.info/docs/developer/GettingPdSource) rsync -av --delete rsync://128.238.56.50/distros/pd-extended/ pd-extended/
2.- Preparing Ubuntu: http://puredata.info/docs/developer/UbuntuMaverick
3.- Building PD-Extended: http://puredata.info/docs/developer/BuildingPdExtended
But there's no .tar.bz2 or .deb on pure-data/packages/linux-make/build... These are the last lines while compilling. What should I do? I don't understand... /[...] CUT [...] WorkerThread.cpp: In member function ‘bool gem::thread::WorkerThread::PIMPL::start()’: WorkerThread.cpp:135:22: error: aggregate ‘gem::thread::WorkerThread::PIMPL::start()::timeval sleep’ has incomplete type and cannot be defined WorkerThread.cpp:139:28: error: ‘select’ was not declared in this scope /
I also encountered exactly that error (on debian wheezy amd64).
Quick super-hackish-politically-un-correct work-around whgo through the compile (but not sure if then everything will work):
- cd to ./externals/Gem/src/Gem/ within the pd-extended dir
- edit the file WorkerThread.cpp and add #include <sys/time.h> at around
line 43 (after #include <iostream>)
- Save file
- cd to the scrips dir again
- edit pd-extended-release-auto-builder.sh
- comment out the line rsync_distro "$auto_build_root_dir" (line 42 here)
#rsync_distro "$auto_build_root_dir"
- start the script:
./pd-extended-release-auto-builder.sh
- go get a cup of coffee ... go get dinner ... go get a bath ... :-)
- build should get through and you should have the deb including gem and
gem related
But it seems Pd has some problem with standard objects (maybe due to previous versions)
Lorenzo
On Jul 8, 2011, at 1:58 PM, Lorenzo Sutton wrote:
Hi,
Mario Mey wrote:
Trying to compile PureData, SVN, on Ubuntu 11.04 AMD64, following
the instruction from the page http://puredata.info/docs/developer,
I did:1.- rsync from the auto-build farm (from http://puredata.info/docs/developer/GettingPdSource) rsync -av --delete rsync://128.238.56.50/distros/pd-extended/ pd- extended/
2.- Preparing Ubuntu: http://puredata.info/docs/developer/UbuntuMaverick
3.- Building PD-Extended: http://puredata.info/docs/developer/BuildingPdExtended
But there's no .tar.bz2 or .deb on pure-data/packages/linux-make/ build... These are the last lines while compilling. What should I
do? I don't understand... /[...] CUT [...] WorkerThread.cpp: In member function ‘bool
gem::thread::WorkerThread::PIMPL::start()’: WorkerThread.cpp:135:22: error: aggregate
‘gem::thread::WorkerThread::PIMPL::start()::timeval sleep’ has
incomplete type and cannot be defined WorkerThread.cpp:139:28: error: ‘select’ was not declared in this
scope /I also encountered exactly that error (on debian wheezy amd64).
Quick super-hackish-politically-un-correct work-around whgo through
the compile (but not sure if then everything will work):
- cd to ./externals/Gem/src/Gem/ within the pd-extended dir
- edit the file WorkerThread.cpp and add #include <sys/time.h> at
around line 43 (after #include <iostream>)
- Save file
- cd to the scrips dir again
- edit pd-extended-release-auto-builder.sh
- comment out the line rsync_distro "$auto_build_root_dir" (line 42
here) #rsync_distro "$auto_build_root_dir"
- start the script:
./pd-extended-release-auto-builder.sh
- go get a cup of coffee ... go get dinner ... go get a bath ... :-)
- build should get through and you should have the deb including gem
and gem related
But it seems Pd has some problem with standard objects (maybe due to
previous versions)Lorenzo
This is totally legit for dev builds, I do it all the time :-) But
just an FYI, since you used ./pd-extended-release-auto-builder.sh
that should build the previous final release (0.42.5). Using ./pd-
extended-auto-builder.sh for the current dev build. I think Mario is
building the 0.43 dev.
.hc
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-08 19:58, Lorenzo Sutton wrote:
- edit the file WorkerThread.cpp and add #include <sys/time.h> at around
line 43 (after #include <iostream>)
fixed now in current Gem SVN, so it should compile again.
fgamsdr IOhannes
On Tue, Jul 5, 2011 at 00:12, Hans-Christoph Steiner hans@at.or.at wrote:
I should, there is a specific question of whether these two are still needed:
http://puredata.info/docs/**developer/64BitLinuxhttp://puredata.info/docs/developer/64BitLinux http://puredata.info/docs/**developer/**BuildingPdExtended64bitUbuntuI** ntrepidhttp://puredata.info/docs/developer/BuildingPdExtended64bitUbuntuIntrepid
0.43 should work fine on all 64-bit systems (never tested Windows tho).
.hc
Well, do these apply to to 0.42 in any way? If not any more, they can go. However, it could be nice to have a short writeup on the history of 64-bit in Pd, most importantly stating the version from which it does not make a difference any more.
Andras
On Wed, 06 Jul 2011 15:36 +0200, "András Murányi" muranyia@gmail.com wrote:
On Tue, Jul 5, 2011 at 00:12, Hans-Christoph Steiner hans@at.or.at wrote:
I should, there is a specific question of whether these two are still needed:
http://puredata.info/docs/**developer/64BitLinuxhttp://puredata.info/docs/developer/64BitLinux http://puredata.info/docs/**developer/**BuildingPdExtended64bitUbuntuI** ntrepidhttp://puredata.info/docs/developer/BuildingPdExtended64bitUbuntuIntrepid
0.43 should work fine on all 64-bit systems (never tested Windows tho).
.hc
Well, do these apply to to 0.42 in any way? If not any more, they can go. However, it could be nice to have a short writeup on the history of 64-bit in Pd, most importantly stating the version from which it does not make a difference any more.
Andras
That's a good idea. As far as I know, Pd vanilla 0.42.5 was the first version that was fully usable on 64-bit. Pd-extended 0.43 is the first version where the all the libs are expected to run on 64-bit (at least on GNU/Linux, still no Gem on Mac OS X). Here's my quick stab at this page and I don't even have a 64-bit OS. Can the 64-bit people add and edit this to something useful :-D
http://puredata.info/docs/64BitSupport
.hc
2011/7/6 Hans-Christoph Steiner hans@at.or.at
On Wed, 06 Jul 2011 15:36 +0200, "András Murányi" muranyia@gmail.com wrote:
On Tue, Jul 5, 2011 at 00:12, Hans-Christoph Steiner hans@at.or.at wrote:
I should, there is a specific question of whether these two are still needed:
http://puredata.info/docs/developer/64BitLinux%3E
http://puredata.info/docs/**developer/**BuildingPdExtended64bitUbuntuI**
ntrepid<
http://puredata.info/docs/developer/BuildingPdExtended64bitUbuntuIntrepid%3E
0.43 should work fine on all 64-bit systems (never tested Windows tho).
.hc
Well, do these apply to to 0.42 in any way? If not any more, they can go. However, it could be nice to have a short writeup on the history of 64-bit in Pd, most importantly stating the version from which it does not make a difference any more.
Andras
That's a good idea. As far as I know, Pd vanilla 0.42.5 was the first version that was fully usable on 64-bit. Pd-extended 0.43 is the first version where the all the libs are expected to run on 64-bit (at least on GNU/Linux, still no Gem on Mac OS X). Here's my quick stab at this page and I don't even have a 64-bit OS. Can the 64-bit people add and edit this to something useful :-D
http://puredata.info/docs/64BitSupport
.hc
Cool! Now, I'd add some notes on the practical implications of this... what about you moving the two previously mentioned pages under this new one (sorry i'm not confident moving pages in the wiki... i've messed things up before) and me adding the context? (Also, someone could make this "an XXX bits float can store a YYY bits integer" a bit more clear as I personally still don't really understand it. I also remember vaguely some criticism of this system, that it is not very efficient? Matju? If you guys explain it here on the list I'll be happy to add it to the wiki.)
Andras
On Wed, 06 Jul 2011 18:22 +0200, "András Murányi" muranyia@gmail.com wrote:
2011/7/6 Hans-Christoph Steiner hans@at.or.at
On Wed, 06 Jul 2011 15:36 +0200, "András Murányi" muranyia@gmail.com wrote:
On Tue, Jul 5, 2011 at 00:12, Hans-Christoph Steiner hans@at.or.at wrote:
I should, there is a specific question of whether these two are still needed:
http://puredata.info/docs/developer/64BitLinux%3E
http://puredata.info/docs/**developer/**BuildingPdExtended64bitUbuntuI**
ntrepid<
http://puredata.info/docs/developer/BuildingPdExtended64bitUbuntuIntrepid%3E
0.43 should work fine on all 64-bit systems (never tested Windows tho).
.hc
Well, do these apply to to 0.42 in any way? If not any more, they can go. However, it could be nice to have a short writeup on the history of 64-bit in Pd, most importantly stating the version from which it does not make a difference any more.
Andras
That's a good idea. As far as I know, Pd vanilla 0.42.5 was the first version that was fully usable on 64-bit. Pd-extended 0.43 is the first version where the all the libs are expected to run on 64-bit (at least on GNU/Linux, still no Gem on Mac OS X). Here's my quick stab at this page and I don't even have a 64-bit OS. Can the 64-bit people add and edit this to something useful :-D
http://puredata.info/docs/64BitSupport
.hc
Cool! Now, I'd add some notes on the practical implications of this... what about you moving the two previously mentioned pages under this new one (sorry i'm not confident moving pages in the wiki... i've messed things up before) and me adding the context?
It seems the other 64-bit pages in the developer section are about building Pd on 64-bit GNU/Linux platforms. I think that those instructions are no longer needed for 0.43, so perhaps they should be archived or at least marked as only relevant to old versions.
(Also, someone could make this "an XXX bits float can store a YYY bits integer" a bit more clear as I personally still don't really understand it. I also remember vaguely some criticism of this system, that it is not very efficient? Matju? If you guys explain it here on the list I'll be happy to add it to the wiki.)
Andras
With a 32-bit float, some of the bits go to representing the exponent part, therefore there is not the full 32-bits available to represent an integer. http://en.wikipedia.org/wiki/Significand
.hc
(Also, someone could make this "an XXX bits float can store a YYY bits integer" a bit more clear as I personally still don't really understand it. I also remember vaguely some criticism of this system, that it is not very efficient? Matju? If you guys explain it here on the list I'll be happy to add it to the wiki.)
Andras
With a 32-bit float, some of the bits go to representing the exponent part, therefore there is not the full 32-bits available to represent an integer. http://en.wikipedia.org/wiki/Significand
It's worse than that though. Pd uses the %g format specifier when it writes out the pd patch (e.g. printf("%g", number)), so floats get simplified. It's possible to use a high precision number by entering it in the patch but when you reopen the patch it will have been simplified.
Martin
On Wed, 6 Jul 2011, Hans-Christoph Steiner wrote:
Yes, it does loose a bit with the %g. AFAIK, the %g just simplifies a little bit, i.e. down to 6 decimal digits while the actual number format can represent about 6.5 decimal digits.
log10(16777216) = about 7.22 decimal digits.
log10(8388608) = about 6.92 decimal digits.
However, the top bit is normally counted in those circumstances : it's the only bit to be significant even though it can't be a zero and it doesn't have to be recorded. It's just like the first decimal digit has to be between 1 and 10 because it can't be a zero.
So the answer is 7.22 decimal digits.
(Yes, Pd could have used 7 decimal digits but uses 6 instead)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Wed, 6 Jul 2011, Martin Peach wrote:
(Also, someone could make this "an XXX bits float can store a YYY bits integer" a bit more clear as I personally still don't really understand it.
Numbers in pd's binary float format are made of three parts :
an int between 8388608 and 16777215 ;
a scale factor that is a power of two, such as 16, 8, 4, 2, 1, ½, ¼, ⅛, 1/16, etc ;
a sign which is either -1 or +1.
They all get multiplied together.
Thus if you have a number that is at least 1 but less than 2, it has to have a scale factor of 1/8388608 (that is, downscaling by 23 levels). Thus there are 8388608 float fractions from 1 to 2 (again not including 2).
A number from 8388608 to 16777215 has a scale factor of 1, thus there are no fractions in that range. From 16777216 to 33554430 there are no odd numbers anymore, and in the next range, there are only multiples of 4, etc.
It's worse than that though. Pd uses the %g format specifier when it writes out the pd patch (e.g. printf("%g", number)), so floats get simplified.
Numbers in pd's decimal float format are made of three parts :
an int between 100000 and 999999 ;
a scale factor that is a power of ten, such as 1000, 100, 10, 1, 1/10, 1/100, 1/1000, etc ;
a sign that is either -1 or +1.
Thus for floats between 100000 and 999999 there are only integers, and beyond that, you have only multiples of ten. Between 1 and 10, there are 900000 numbers (not including 10 itself).
Other binary and decimal float formats mostly only differ by number of digits in the «first» part of the number. So-called «double» floats use ints between 4503599627370496 and 9007199254740991, but this amount of precision is not available as part of pd messages.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-
András Murányi -
error developer -
errordeveloper＠gmail.com
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jacob Lee -
Jonathan Wilkes -
Lorenzo Sutton -
Mario Mey -
Martin Peach -
Mathieu Bouchard -
yvan volochine