or knob instead of dial

and can i still install it through the apt-get update through puredata.info repository

On 30/01/2013 13:46, Nicolas Montgermont wrote:

a few comments though, (sorry if I miss previous discussions):

• is is possible to get rid of the french localization?

rename or trash the /po and /extra/search-plugin/po folders. That's how I do it. ;)

• how do I load a gui plugin?

http://puredata.info/docs/guiplugins/GUIPlugins/

and a few ideas:

• one menu with all the preferences
• possibility to choose between different config file.

maybe these are doable as gui plugins?

Best, n

Le 30/01/13 10:17, Roman Haefeli a écrit :

...

Hi Hans

On Die, 2013-01-29 at 15:36 -0500, Hans-Christoph Steiner wrote:

...

Its time to announce the next big Pd-extended release, 0.43.4!

Congrats! Despite expressing many times how limited your time is (and probably even more so with a family), the new release really is a milestone. Great achievement! Impressive list of improvements, bug fixes, new features. Many thanks to you and everyone involved.

Personally, I welcome many of your decisions like not loading libraries per default, requiring a maintainer for each lib, removing unmaintained libs. In my experience it was never so easy to write portable patches between pd + libs and pd-extended. It's a huge goal to provide a consistent experience across platforms, but from what I saw in recent times this goal is largely satisfied. It is really comfortable to tell people: "You just need to install Pd-extended for running this patch" and they don't have to bother with any special settings or configurations.

Keep up the good work! Roman

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On 01/30/2013 08:11 AM, IOhannes m zmoelnig wrote:

...

On 30/01/2013 13:46, Nicolas Montgermont wrote:

...

and a few ideas: - one menu with all the preferences - possibility to choose between different config file.

maybe these are doable as gui plugins?

yes for the "one menu with all preferences".

unlikely for "config file chooser": the problem here is, that once you have started Pd, it's configuration will already be active, and you cannot undo that (e.g. you cannot unload libraries). the only thing that could be done (and probably as a GUI-plugin) would be: "save this config as" and "restore chosen saveconfig to be used as the default on next startup"

Yeah, you'd have to do it in the default/restart method IOhannes outlined above. Here's how:

• store the config files each with a unique name
• make the config chooser UI copy the chosen uniquely-named config file to

the default config faile name

• restart and pd will find the newly copied config file in the default location

.hc

sorry for the french, that was mean to be a private mail. c

Le 30/01/2013 21:09, Cyrille Henry a écrit :

Le 30/01/2013 12:46, Nicolas Montgermont a écrit :

...

• possibility to choose between different config file.

ds le cas generique, j'ai pas de solution, mais si c'est juste les path et les lib a charger, alors je pense que le mieux serait de ne rien declarer ds les prfs de pd. mais d'utiliser declare pour tout les patch (comme c'est fait ds tout les autres langguages de programation). on peux envisager d'ouvrir des model qui correspondent a diferentes configs qui sont en fait des patchs contenant juste les bon declare.

ca te semble pas pertinent?

c

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

I agree, the libraries should be loaded in the patch. However I'm kind of dreaming of an option line in the preferences to choose your preference file for two reasons:

• it make visible the name of the file loaded
• it allows to switch easily between different audio/midi/others settings

These settings are one of the only thing you must reconfigure when you travel a patch between computer, and as there is only one solution, it's not so easy to keep special configuration for beginners. It's usual to see people having problem to have sound just because their audio settings are still with 6 output and the audio card is not plug anymore.

n

Le 30/01/13 22:40, Hans-Christoph Steiner a écrit :

On 01/30/2013 04:09 PM, Cyrille Henry wrote:

...

Le 30/01/2013 12:46, Nicolas Montgermont a écrit :

...

• possibility to choose between different config file.

ds le cas generique, j'ai pas de solution, mais si c'est juste les path et les lib a charger, alors je pense que le mieux serait de ne rien declarer ds les prfs de pd. mais d'utiliser declare pour tout les patch (comme c'est fait ds tout les autres langguages de programation). on peux envisager d'ouvrir des model qui correspondent a diferentes configs qui sont en fait des patchs contenant juste les bon declare.

ca te semble pas pertinent?

A quick internet translations makes me think that I agree with what cyrille is saying. The preferences shouldn't be used for loading libraries, as they have been in pd and especially Pd-extended for a long time. Pd-extended no longer lets you set libraries to load from the preferences, this is one step to get us on the right direction. I've been thinking about other things as well, here's how I'm thinking:

• new standard library that is larger and more consistent than what's in

vanilla, things like all math and logic objects both message and signal included, rather than needed to load a library (i.e. zexy) for some of them. It would prioritize correctness and consistency over backwards compatibility.

• no libraries but the standard library loaded by default.

• the possibility to load "distro profiles" for compatibility with Pd-vanilla

and Pd-extended

• all of Pd-vanilla's objects as a separate 'vanilla' library.

.hc

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2013-01-30 22:40, Hans-Christoph Steiner wrote:

A quick internet translations makes me think that I agree with what cyrille is saying. The preferences shouldn't be used for loading libraries, as they have been in pd and especially Pd-extended for a long time. Pd-extended no longer lets you set libraries to load from the preferences, this is one step to get us on the right direction. I've been thinking about other things as well,

i'm still very skeptic about the possibility that there is "one" right direction.

here's how I'm thinking:

• new standard library that is larger and more consistent than

what's in vanilla, things like all math and logic objects both message and signal included, rather than needed to load a library (i.e. zexy) for some of them.

i'm not sure i really understand the sentence. but i guess it is mainly suggesting to move objects of general value to a so called "standard library" that provides the basic needs.

one question os of course, what a "basic" need is. e.g. personally i would vote for a minimum set of math-like operators, rather than high-level user-friendly objects. e.g. [>~] but not [moog~]. others might think very differently about this.

It would prioritize correctness and consistency over backwards compatibility.

i agree, that a so called "standard library" is a *must*.

• no libraries but the standard library loaded by default.

note that many languages (including C and python) don't automatically load their standard libraries. however, they do have a standard library. and they provide primitives that allows you to use the language even without any standard library.

from the users's perspective it's probably a good "default" to load a stdlib, but one could easily introduce a "-nostdlib" flag to override that.

• all of Pd-vanilla's objects as a separate 'vanilla' library.

how would that be different from the standard library? i guess the stdlib most likely will contain more objects than vanilla, and some objectclasses would not be part of stdlib or under another name ([makefilename] springs to my mind).

----- Original Message -----

From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Cc: Sent: Wednesday, January 30, 2013 4:40 PM Subject: Re: [PD] [PD-announce] Pd-extended 0.43.4 released!

[...]

• new standard library that is larger and more consistent than what's in

vanilla, things like all math and logic objects both message and signal included, rather than needed to load a library (i.e. zexy) for some of them. It would prioritize correctness and consistency over backwards compatibility.

That's a royal waste of your time.  I'm certain you wouldn't advocate _moving_ objects from various libs to one standard lib-- as that would break backwards compatability-- so you must be advocating copying them.  Both would have the direct affect of confusing users-- the former by _breaking_ all kinds of help docs, tutorials, and lots else that's more or less part of the "standard" Pd world at this point; and the latter by returning two results in a search for an object that happens to be in the standard library.  Either is also a royal waste of the users' time.

If there are specific objects inside zexy or hans that need to be superceded by an object with a better design in order to get more consistency, or if there are objects that haven't been created yet that would add needed functionality, let's talk about those cases.  But [import hans zexy lib_to_be_coded] is a perfectly reasonable interface for loading 90% of what the user needs, so let's not go breaking stuff for the sake of theoretical consistency.  For the other 10% it's just fine for the user to search for that functionality and use the prefix that is shown in the search results, or click the "info" icon to read about the relevant library, or use [import], or do all three.

• no libraries but the standard library loaded by default.

• the possibility to load "distro profiles" for compatibility with

Pd-vanilla and Pd-extended

• all of Pd-vanilla's objects as a separate 'vanilla' library.

In the search plugin I'm judging vanilla objects based on whether the help patch is inside 5.reference, and returning them first in the results.  I asked you awhile back if the subdirs in "doc" are subject to change and you said they were a standard part of Pd that wasn't likely to change. If want the "vanilla" lib for the sake of consistency, you won't get it because the vanilla help patches must remain in 5.reference.  If you copy them to vanilla/ again you would create UX problems as a search will return two results for every vanilla object.

-Jonathan

.hc

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On 01/31/2013 11:45 AM, Jonathan Wilkes wrote:

----- Original Message -----

...

From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Cc: Sent: Wednesday, January 30, 2013 4:40 PM Subject: Re: [PD] [PD-announce] Pd-extended 0.43.4 released!

[...]

...

• new standard library that is larger and more consistent than what's in

vanilla, things like all math and logic objects both message and signal included, rather than needed to load a library (i.e. zexy) for some of them. It would prioritize correctness and consistency over backwards compatibility.

That's a royal waste of your time. I'm certain you wouldn't advocate _moving_ objects from various libs to one standard lib-- as that would break backwards compatability-- so you must be advocating copying them. Both would have the direct affect of confusing users-- the former by _breaking_ all kinds of help docs, tutorials, and lots else that's more or less part of the "standard" Pd world at this point; and the latter by returning two results in a search for an object that happens to be in the standard library. Either is also a royal waste of the users' time.

If there are specific objects inside zexy or hans that need to be superceded by an object with a better design in order to get more consistency, or if there are objects that haven't been created yet that would add needed functionality, let's talk about those cases. But [import hans zexy lib_to_be_coded] is a perfectly reasonable interface for loading 90% of what the user needs, so let's not go breaking stuff for the sake of theoretical consistency. For the other 10% it's just fine for the user to search for that functionality and use the prefix that is shown in the search results, or click the "info" icon to read about the relevant library, or use [import], or do all three.

Yes, it'll be a chunk of work, but I strongly believe it'll be worthwhile. Python3 is a good example of this kind of thing. All the existing libraries would remain as they are, so backwards compatibility would be fully available.

I agree theoretical consistency is not a worthy goal, that's not the point here at all. [import zexy] is a good example. Let's say a user is looking for objects to make and manipulate symbols, how about calling tat library "symboltricks" or something descriptive, rather than an arbitrary name 'zexy'. In python, if I want to work with URLs, I load a 'urllib' or maybe 'urllib2'.

The point is that the old way of organizing libraries was around the author, not what the library does, like zexy. Newer libs like iemguts, pmpd, log, etc. are organized around a topic, and that makes much more sense. That's a very widely established paradigm for libraries across basically all languages.

Honestly, in the long run I think this will be less work than maintaining the system as it is now. There are so many exceptions and quirks that is really is hard to make progress because some forgotten quirk comes back and bites you.

...

• no libraries but the standard library loaded by default.

• the possibility to load "distro profiles" for compatibilityYes, it'll be a chunk of work, but I strongly believe it'll be worthwhile. Python3 is a good example of this kind of thing. All the existing libraries would remain as they are, so backwards compatibility would be fully available. with

Pd-vanilla and Pd-extended

• all of Pd-vanilla's objects as a separate 'vanilla' library.

In the search plugin I'm judging vanilla objects based on whether the help patch is inside 5.reference, and returning them first in the results. I asked you awhile back if the subdirs in "doc" are subject to change and you said they were a standard part of Pd that wasn't likely to change. If want the "vanilla" lib for the sake of consistency, you won't get it because the vanilla help patches must remain in 5.reference. If you copy them to vanilla/ again you would create UX problems as a search will return two results for every vanilla object.

-Jonathan

I think it'll be worthwhile to fix that quirk, and only have a single method that applies for all bjects and libraries, including 'vanilla'. This points to exactly what I'm talking about: this is a random, unneeded exception that's there because of historical reasons, but is not useful in its own right.

Most of the objects in this new standard library would likely change only slightly so the help can be taken from PDDP and tweaked.

As for changing the tutorial sections in doc, I did not want to take on the maintenance of modified version, but I always thought it would be nice to have improved versions of them. You've started that project, so I plan on using your work there. You've already created massive improvements in the general help system, I expect no less with your effort on the included tutorials. :-D no pressure... ;)

.hc

On 02/01/2013 08:55 AM, Ed Kelly wrote:

OK, so Pd-extended doesn't load any libs by default (except Gem of course).

There is some confusion there since all of the version/loading messages no longer show by default. The same libraries are all still being loaded by default, and the messages are still being posted to the Pd window, but at the 'debug' level.

I'd like to suggest a fix for a problem I've encountered, especially when moving patches.

Would there be a reverse way of finding out what libs are missing from a patch? Even just to generate a file, it would be a good idea to be able to search the libs and find out what you need to [import] to get a patch made on pre 0.43 Pd-extended to work.

Perhaps it could be an adaptation of the search plugin (nice work Jonathan ;-)

That probably could be done with a GUI plugin, but it wouldn't be 100% accurate since you can't get the canvas-local [import] and [path] info in a GUI plugin. It would be something like this:

• find all tk 'text' widgets with the tag 'obj'
• read the contents of the text widget to get the object name. It would be

the first word, except for [list prepend], etc. Those are the first two words.

• search the standard path for that object

.hc

Ta, Ed

Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/

...

---

From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Thursday, 31 January 2013, 17:42 Subject: Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)

On 01/31/2013 11:45 AM, Jonathan Wilkes wrote:

...

----- Original Message -----

...

From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Cc: Sent: Wednesday, January 30, 2013 4:40 PM Subject: Re: [PD] [PD-announce] Pd-extended 0.43.4 released!

[...]

...

• new standard library that is larger and more consistent than what's in

vanilla, things like all math and logic objects both message and signal included, rather than needed to load a library (i.e. zexy) for some of them. It would prioritize correctness and consistency over backwards compatibility.

That's a royal waste of your time. I'm certain you wouldn't advocate _moving_ objects from various libs to one standard lib-- as that would break backwards compatability-- so you must be advocating copying them. Both would have the direct affect of confusing users-- the former by _breaking_ all kinds of help docs, tutorials, and lots else that's more or less part of the "standard" Pd world at this point; and the latter by returning two results in a search for an object that happens to be in the standard library. Either is also a royal waste of the users' time.

If there are specific objects inside zexy or hans that need to be superceded by an object with a better design in order to get more consistency, or if there are objects that haven't been created yet that would add needed functionality, let's talk about those cases. But [import hans zexy lib_to_be_coded] is a perfectly reasonable interface for loading 90% of what the user needs, so let's not go breaking stuff for the sake of theoretical consistency. For the other 10% it's just fine for the user to search for that functionality and use the prefix that is shown in the search results, or click the "info" icon to read about the relevant library, or use [import], or do all three.

Yes, it'll be a chunk of work, but I strongly believe it'll be worthwhile. Python3 is a good example of this kind of thing. All the existing libraries would remain as they are, so backwards compatibility would be fully available.

I agree theoretical consistency is not a worthy goal, that's not the point here at all. [import zexy] is a good example. Let's say a user is looking for objects to make and manipulate symbols, how about calling tat library "symboltricks" or something descriptive, rather than an arbitrary name 'zexy'. In python, if I want to work with URLs, I load a 'urllib' or maybe 'urllib2'.

The point is that the old way of organizing libraries was around the author, not what the library does, like zexy. Newer libs like iemguts, pmpd, log, etc. are organized around a topic, and that makes much more sense. That's a very widely established paradigm for libraries across basically all languages.

Honestly, in the long run I think this will be less work than maintaining the system as it is now. There are so many exceptions and quirks that is really is hard to make progress because some forgotten quirk comes back and bites you.

...

...

• no libraries but the standard library loaded by default.

• the possibility to load "distro profiles" for compatibilityYes, it'll be a chunk of work, but I strongly believe it'll be worthwhile. Python3 is a good example of this kind of thing. All the existing libraries would remain as they are, so backwards compatibility would be fully available. with

Pd-vanilla and Pd-extended

• all of Pd-vanilla's objects as a separate 'vanilla' library.

In the search plugin I'm judging vanilla objects based on whether the help patch is inside 5.reference, and returning them first in the results. I asked you awhile back if the subdirs in "doc" are subject to change and you said they were a standard part of Pd that wasn't likely to change. If want the "vanilla" lib for the sake of consistency, you won't get it because the vanilla help patches must remain in 5.reference. If you copy them to vanilla/ again you would create UX problems as a search will return two results for every vanilla object.

-Jonathan

I think it'll be worthwhile to fix that quirk, and only have a single method that applies for all bjects and libraries, including 'vanilla'. This points to exactly what I'm talking about: this is a random, unneeded exception that's there because of historical reasons, but is not useful in its own right.

Most of the objects in this new standard library would likely change only slightly so the help can be taken from PDDP and tweaked.

As for changing the tutorial sections in doc, I did not want to take on the maintenance of modified version, but I always thought it would be nice to have improved versions of them. You've started that project, so I plan on using your work there. You've already created massive improvements in the general help system, I expect no less with your effort on the included tutorials. :-D no pressure... ;)

.hc

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

----- Original Message -----

From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Thursday, January 31, 2013 12:42 PM Subject: Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)

On 01/31/2013 11:45 AM, Jonathan Wilkes wrote:

...

----- Original Message -----

...

From: Hans-Christoph Steiner hans@at.or.at   To: pd-list@iem.at   Cc:   Sent: Wednesday, January 30, 2013 4:40 PM   Subject: Re: [PD] [PD-announce] Pd-extended 0.43.4 released!

[...]

I agree theoretical consistency is not a worthy goal, that's not the point here at all. [import zexy] is a good example.  Let's say a user is looking for objects to make and manipulate symbols,

That user can click the search-plugin category link "symbol_op". The result will be a user-friendly list of everything that would be in a symbol-oriented library, prefixed with the lib name, followed by an icon that links to lib info.  If those results don't include everything, someone can go in and add the keyword "symbol_op" to the help patch for the object that needs to be included.  Also, if "symbol_op" is too obscure, someone can change the text of that link on the search plugin home page to be something more descriptive.  All of those tasks are extremely cheap to carry out in Pd's current form, and there won't be long threads of discussion since categories aren't mutually exclusive.

how about calling tat library "symboltricks" or something descriptive, rather than an arbitrary name 'zexy'. In python, if I want to work with URLs, I load a 'urllib' or maybe 'urllib2'.

I agree that aptly-named libraries built around a specific domain or a logical grouping will improve the user experience, but not nearly to the degree that implementing cross-platform doc search functionality has.  It will mostly facilitate memorizing the prefixes (libs) of commonly used externals and reinforcing their shared attributes that relate directly to that specific library name.  But libraries don't overlap, and _standard_ libraries are (hopefully) static and are difficult to amend once set in place.  Tags are the opposite of all that, and are already implemented.

The point is that the old way of organizing libraries was around the author, not what the library does, like zexy.  Newer libs like iemguts, pmpd, log, etc. are organized around a topic, and that makes much more sense.  That's a very widely established paradigm for libraries across basically all languages.

Honestly, in the long run I think this will be less work than maintaining the system as it is now.  There are so many exceptions and quirks that is really is hard to make progress because some forgotten quirk comes back and bites you.

What are the maintenance problems solved by copying binaries into new directories?

Also-- you will end up with objects that have different licenses in the same lib. Is there a precedent for that in any programming language?

-Jonathan

----- Original Message -----

From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Saturday, February 2, 2013 8:35 PM Subject: Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)

[...]

...

What are the maintenance problems solved by copying binaries into new directories?

The point is to reduce complexity and exceptions to consistency.  Once example where just copying an external would reduce complexity is taking an object out of zexy.  Zexy has a very complicated build system because it has a huge array of objects, many of which will not build on every system, things like [lpt]. Therefore the build system needs to configure itself based on what is available.

A standard library would only have things that build on every system, so a much simpler build system can be used (like the library template).

But you're evidently keeping zexy for compatibility reasons, so how would this create less maintenance for you?

...

Also-- you will end up with objects that have different licenses in the

same lib.

...

Is there a precedent for that in any programming language?

You will be able to consider the whole GPLv3+.

You are wrong-- there are libraries currently under GPLv2, some under GPLv3, some GPLv2+, some 3-clause BSD, some Tcl/Tk license, and maybe a few others.

You cannot automagically change the GPLv2 and GPLv3 to GPLv3+, and if you change the 3-clause BSD to GPLv3+ it needs to be explicit-- i.e., changing it in the pd META patch.  For the other versions of the GPL someone would need to contact all the original authors and get them to release it under GPLv3+.

(Btw-- please don't start a thread on licenses here.  If you don't understand the problems then email the fsf and they can explain it, and you can paste their response here.)

These changes will turn into a lot of documentation work, not to mention changing existing docs to point to the standard libs instead of the legacy ones where possible, and changing FLOSS manual stuff and Pd manual stuff as well as any other extant tutorials widely used by the Pd community to clearly explain the new libs so that new users don't get stuck learning half legacy stuff and half new lib stuff (thus making it even more difficult to get around in the language).  Not to mention documenting the legacy stuff and its relationship to the new stuff, while making the new stuff more easily discoverable in the docs and the search plugin. (Oh, and contacting legacy lib devs and seeing who is willing to relicense under GPLv3+.)

If you want I can put together a Kickstarter campaign that outlines all of this doc work that will be needed.  I suspect it'd be about two or three months of full-time work.  If people are willing to pay me to make these changes I'm happy to do them.  As my resume I offer my work on PDDP, in which I contacted lib authors to accept my revisions, updated core docs, reworked the FLOSS manual to be consistent with core docs, and wrote a search plugin to make use of all the changes.  (As well as testing that the results worked across platforms.)

-Jonathan

There will need to be other copyirght notices from BSD licensed code, but that's manageable.

.hc

----- Original Message -----

From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Sunday, February 3, 2013 1:41 PM Subject: Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)

[...]

...

If you want I can put together a Kickstarter campaign that outlines all of this doc work that will be needed.  I suspect it'd be about two or three months of full-time work.  If people are willing to pay me to make these changes I'm happy to do them.  As my resume I offer my work on PDDP, in which I contacted lib authors to accept my revisions, updated core docs, reworked the FLOSS manual to be consistent with core docs, and wrote a search plugin to make use of all the changes.  (As well as testing that the results worked across platforms.)

-Jonathan

These things are all true, I think its worth it. I think you might be thinking that there will be more changed than there need to be.  Most of the objects would not need documentation changes, or just small changes.

Here's the doc work:

1. search plugin - for classes that are copied into the new libs, don't show

duplicate results from the legacy library (which is only there for backwards compatability).  Probably the best way to do this is add a "legacy" tag to the old lib stuff. 2) Change the relative pddp links for all 200+ PDDP help patches that points to stuff outside of 5.reference/ (probably can automate much of this process) 3) Find and change all the pddplinks and comments in docs of externals that refer to 5.reference (absolute and relative).  (Somewhat automated) 4) Make a good faith effort to amend FLOSS references and other common PD learning materials to document new libs.  (Otherwise new users read about legacy stuff while using new stuff, get confused, and write to the list to ask about why the same exact objects get different prefixes in different docs.) 5) Lots of iterative changes to places in the documentation that make a distinction between "internal" and "external" objects, including the search plugin, "all about Pd" patches, tutorials, the Pd manual, and probably a lot else that I'm not thinking of at the moment. 6) Create new documentation to explain _exactly_ how to use standard libs, explaining how to a) get the old behavior of just loading all libs in Pd-extended, b) how to use [import], c) how to use the lib prefix, and d) any other ways of loading libs and the benefits/drawbacks of those approaches. 7) Making a user-friendly doc or patch about legacy libs that explains the legacy author-oriented approach for new (and old) users, focusing esp. on the most popular legacy libs.  Without this a lot of documentation on puredata.info-- and esp. on the user and dev list-- becomes difficult to understand and follow. 8) Find entry points into the common Pd learning materials and inject a note about the move from the legacy approach to the new approach, with a link to the doc from #7. 9) Keep a list of all easily translatable sources of documentation on this change, so that translations of the new approach can happen as soon as possible. 10) Check for cross-platform compatibility, to make sure none of the core doc changes or search-plugin changes introduce weirdness somewhere.

However, after doing some initial research I see there's a bigger issue before any of this could even happen.  Let's say I put up a Kickstarter for a month's worth of doc work on this.  I'd have to schedule it for a date after the work is done deciding what names the standard libs should get and what code goes in those libs.

That process will probably turn into bikeshedding where none of the real work actually gets done-- I can say this because _substantial_ preliminary discussions for this work already took place 4 years ago on the dev list and we don't have standard libs today.

So here's my proposition: I'll work on compiling a list of classes that should have been included in vanilla but aren't yet.  I'll exclude objects which are currently in a maintained, "aptly-named" library build around classes that share some core functionality in common, as those libraries are already "standard libraries".  I should end up with a list of classes which, in conjunction with the vanilla classes, make it possible to get substantially more work done without relying on hacks or workarounds.  We can worry about libname and relationship with vanilla later-- the main point will be that these "core" objects can all be typed into an object box in Pd extended, without any namespace prefixes, and as long as nothing has been [import]ed or [declare]d it should all just work.  If it goes the way I think it will, there won't be any need to have a bunch of new libs, just one that adds long-desired functionality to "vanilla" that's been missing for so long.   None of this initial work requires any discussion whatsoever, since it all exists already on the user and dev lists.  So this way we can avoid the bikeshedding.   BTW-- I assume copying the classes to the new "standard lib" will be automated with a script. Or are you proposing keeping copies of the code in two locations?   -Jonathan

Hi m

Jep we've been working with the 64bit version - thanks for pointing this out!

ø

On 03/18/2013 04:58 PM, me.grimm wrote:

hi olsen

did you install the 64bit version of pd-extended? At the moment Gem is broken in that version. Try the 32bit version.

m

On Mon, Mar 18, 2013 at 11:43 AM, olsenraumkundschafter@hasa-labs.org wrote:

...

Hi Hans

I just got my hands on an OSX 10.7.5 and a 10.6.8 system and with 0.43.4 there seems to be a problem with Gem - e.g. opening the help of [pix_film] gives me the following error:

[pix_film] now mogie decoding backends found gemglutwindow ... couldn't create

any idea?

thanks& salutis Olsen

On 01/29/2013 09:36 PM, Hans-Christoph Steiner wrote:

...

Its time to announce the next big Pd-extended release, 0.43.4! This release has the most new features of any release before, so many annoyances are gone, many new tools help you patch, and. There will be more updates to cover some of the new features here, in the form of news items on puredata.info, blog posts, screencasts and more.

Download here for all platforms (Debian, Mac OS X, Mint, Raspbian, Ubuntu, Windows, and of course the source code): http://puredata.info/downloads/pd-extended/releases/0.43.4

For Debian/Ubuntu/Mint/etc., you can add an apt source by following the instructions at the top of the page here: http://puredata.info/docs/faq/debian

ChangeLog

Here you can get a good overview in what has changed, so you know where to find out more.

changes since 0.43.1

• search-plugin included by default
• improved audio performance on Mac and Windows, Mac now uses half the CPU when idle (portaudio update)
• (Windows) full unicode support
• support full unicode MIDI device names (portmidi)
• many completed translations
• many bugfixes

changes since 0.42.5

== changes to the editor ==

• GUI Plugins! can customize a wide array of features of the editor
• Autotips in Edit Mode to get information about inlets, outlets, and

objects

• Magic Glass to snoop on messages as they pass thru connections
• Search everything! Thanks to Jonathan Wilkes' search plugin, now

included by default

• full Unicode support throughout Pd (there are still some layout issues with right-to-left alphabets and character-based languages)
• fully localizable GUI, with full translations for French, German,

Japanese, Italian, and Greek

• full interface translations with limited search translation for

Catalan, Chinese (China), Chinese (Taiwan), Danish, German, Hungarian, Korean, Portuguese (Brazil), Slovak, Spanish, Spanish (Mexico)

• partial translations for: Russian, Turkish
• contribute to translations:

https://www.transifex.com/projects/p/puredata/

• paths are no longer saved in the preferences. Use the [path] or [declare -path] objects, or use the standard global install locations
• complete Tcl/Tk 8.5 support and integration
• drastically improved Pd window logging/print performance (1000

lines/sec and you can still patch)

• Ctrl-click/Cmd-click error messages in Pd window to find the object

with the error

• five log levels and dynamic filtering of Pd window log ('fatal, error, normal, debug, all')
• library loading printed to Pd window at level 'debug' so the Pd window is blank when Pd-extended starts
• hierarchical display of open subpatches/abstractions in Window menu: http://puredata.info/dev/NextRelease/window_hierarchy.png
• generate complete Pd window log using 'File->Save As..' when on the Pd window
• 'File->New' creates the new patch in the folder of the current patch
• 'File->Print' now prints the entire canvas rather than just the

visible part (thanks Trevor Fancher)

• 'File->Save As...', 'Edit->Copy', and 'Edit->Select All' now work on the Pd window
• Ctrl/Cmd< and> cycle through open windows
• added Autopatch, Autotips, and Perf Mode control on the Edit menu
• improved handling of multiple monitors
• (GNU/Linux) realtime mode enabled by default (-rt)
• (GNU/Linux) window placement logic can be handled in plugin for better support of many Window Managers (pdtk_canvas_place_window)
• (GNU/Linux and Mac OS X) [comport] no longer crashes Pd when open USB-serial devices are unplugged
• (GNU/Linux and Windows) !TkDND drag-n-drop support for dropping files onto Pd and patch windows
• (GNU/Linux and Windows) added Alt shortcuts to menus
• (GNU/Linux and Windows) Navigate menus with arrow keys
• (GNU/Linux and Windows) Pd window and patchses now have a Pd icon when Alt-Tabbing
• (Windows) zip-only distro with pd-extended.bat to run without

installing

== updates to the core ==

• updated to latest stable portaudio v19-20110326
• free methods always called on quit, so cameras, network sockets, etc. are properly freed
• GUI objects no longer send pointless draw updates, reducing GUI load
• (Windows) external libraries can now include DLLs in a library folder
• [loadbang] has a convenience inlet
• sys_open() / sys_close() and sys_fopen() / sys_fclose() functions in m_pd.h for full UTF-8 support in externals that use files

== updates to libraries and objects ==

• added all lowercase aliases to cyclone for Max/MSP>= 4.6 compatibility
• fix type-punned pointer issues in most externals so everything is

built using auto-vectorization optimization on all platforms

• [sys_gui] now outputs a bang when the command completes
• [canvas_name] can query based on inlet, using float as depth and

symbol for canvas name

• [tabplay~] can play up to 13.5 hour long tables accurately (up from 6

mins)

• (Windows) fixed 'unauthorized' GUI objects [playlist], [cooled~], etc.

== newly included libraries ==

• 'pdlua' for loading objects written in Lua like regular objects
• 'tclpd' for loading objects written in Tcl like regular objects
• 'log' library for logging to the Pd window at different levels
• 'iemguts' library for controlling abstractions and patches from Pd
• 'mediasettings' library for controlling the Audio/MIDI device

preferences

• 'pduino' library for controlling Arduino boards via the Firmata

protocol

• 'syslog' added IEM's object for logging to syslog (GNU/Linux and Mac

OS X)

== removed libraries ==

• remove unsupported, unmaintained libraries: controctopus, Externals-HOWTO, flashserver, flatspace, flib, gyre, keyboardkeys, memento, memento-p, nqpoly4, nqpoly~, nusmuk, pixeltango, puremeasurement, rradical, toxy see: [http://puredata.info/docs/LibrariesInPdExtended
• pidip removed because of license conflicts

For more details, check the complete changelog, see the bottom of the release page: http://puredata.info/downloads/pd-extended/releases/0.43.4/

More Details

• the Mac OS X PowerPC builds are a bit out of date because the PowerPC build machine died at the end of December. We're trying to get it back up so we can have up-to-date Mac OS X PowerPC builds!

• the Raspbian build is barely tested, please try it and report back so we can improve things on Raspbian.

---

Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/listinfo/pd-announce

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-- ETs DNA will not be televised http://hasa-labs.org

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list