From msp at ucsd.edu Mon Jul 1 03:41:56 2019 From: msp at ucsd.edu (Miller Puckette) Date: Sun, 30 Jun 2019 18:41:56 -0700 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: References: <20190630040538.GF27582@ucsd.edu> Message-ID: <20190701014156.GD17705@ucsd.edu> The gotcha is that I can't find a way to typeset equations in native HTML... and properly documenting even osc~ is going to require some. Perhaps it would work to have basic doc in HTML and detailed doc (theory of operation level stuff) in either markdown or latex. cheers M On Mon, Jul 01, 2019 at 01:22:40AM +0000, Lucas Cordiviola wrote: > On 6/30/2019 1:05 AM, Miller Puckette wrote: > > > Any advice would be very helpful! > > > Stay in the HTML format. > > Following https://www.w3schools.com/html/html_basic.asp anyone can come > up with an object documentation. > > HTML is the way to go. No need for latex, md, or whatever. HTML is > really simple and works on any computer and is very straightforward to > maintain and enhance. Most importantly it does not add compiling dependency. > > ************************************* > > > > > > > >

big heading

h2 smaller heading

> >

paragraph > >

paragraph 2 > > > > > ********************************* > > > Having the ability to open local or remote URLs?? is a total Pd enhancer. > > > :) > > > Mensaje telepatico asistido por maquinas. > From lucarda27 at hotmail.com Mon Jul 1 04:13:10 2019 From: lucarda27 at hotmail.com (Lucas Cordiviola) Date: Mon, 1 Jul 2019 02:13:10 +0000 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: <20190701014156.GD17705@ucsd.edu> References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> Message-ID: On 6/30/2019 10:41 PM, Miller Puckette wrote: > The gotcha is that I can't find a way to typeset equations in native HTML... How about making the rendered image (of the math equation) with https://www.codecogs.com/latex/eqneditor.php and include the image in the HTML doc. (isn't this is what Latex do when it generates an HTML output ?) ? Mensaje telepatico asistido por maquinas. From brbrofsvl at gmail.com Mon Jul 1 04:18:19 2019 From: brbrofsvl at gmail.com (Matt Barber) Date: Sun, 30 Jun 2019 22:18:19 -0400 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: <20190701014156.GD17705@ucsd.edu> References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> Message-ID: There may be a way not to reinvent the wheel and also maintain some use previous use cases other patchers and developers have used. Consider e.g. the reflection classes in purr data, like [canvasinfo], which has a [dir( method. Likewise pddp/pddplink etc. can open files in the native OS, and they are used a ton in documentation for externals, for instance. I'm not saying that either of these specifically needs to be included in vanilla, but these are problems that have already been solved in various ways and it could be worthwhile to see what exists. On Sun, Jun 30, 2019 at 9:44 PM Miller Puckette wrote: > The gotcha is that I can't find a way to typeset equations in native > HTML... > and properly documenting even osc~ is going to require some. > > Perhaps it would work to have basic doc in HTML and detailed doc (theory of > operation level stuff) in either markdown or latex. > > cheers > M > > On Mon, Jul 01, 2019 at 01:22:40AM +0000, Lucas Cordiviola wrote: > > On 6/30/2019 1:05 AM, Miller Puckette wrote: > > > > > Any advice would be very helpful! > > > > > > Stay in the HTML format. > > > > Following https://www.w3schools.com/html/html_basic.asp anyone can come > > up with an object documentation. > > > > HTML is the way to go. No need for latex, md, or whatever. HTML is > > really simple and works on any computer and is very straightforward to > > maintain and enhance. Most importantly it does not add compiling > dependency. > > > > ************************************* > > > > > > > > > > > > > > > >

big heading

> >

h2 smaller heading

> > > >

paragraph > > > >

paragraph 2 > > > > > > > > > > ********************************* > > > > > > Having the ability to open local or remote URLs?? is a total Pd enhancer. > > > > > > :) > > > > > > Mensaje telepatico asistido por maquinas. > > > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucarda27 at hotmail.com Mon Jul 1 03:22:40 2019 From: lucarda27 at hotmail.com (Lucas Cordiviola) Date: Mon, 1 Jul 2019 01:22:40 +0000 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: <20190630040538.GF27582@ucsd.edu> References: <20190630040538.GF27582@ucsd.edu> Message-ID: On 6/30/2019 1:05 AM, Miller Puckette wrote: > Any advice would be very helpful! Stay in the HTML format. Following https://www.w3schools.com/html/html_basic.asp anyone can come up with an object documentation. HTML is the way to go. No need for latex, md, or whatever. HTML is really simple and works on any computer and is very straightforward to maintain and enhance. Most importantly it does not add compiling dependency. *************************************

big heading

h2 smaller heading

paragraph

paragraph 2 ********************************* Having the ability to open local or remote URLs is a total Pd enhancer. :) Mensaje telepatico asistido por maquinas. From zmoelnig at iem.at Mon Jul 1 10:46:46 2019 From: zmoelnig at iem.at (IOhannes m zmoelnig) Date: Mon, 1 Jul 2019 10:46:46 +0200 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> Message-ID: On 01.07.19 04:13, Lucas Cordiviola wrote: > On 6/30/2019 10:41 PM, Miller Puckette wrote: > >> The gotcha is that I can't find a way to typeset equations in native HTML... > > How about making the rendered image (of the math equation) with > https://www.codecogs.com/latex/eqneditor.php and include the image in > the HTML doc. (isn't this is what Latex do when it generates an HTML > output ?) no, LaTeX doesn't rely on a 3rd party service eating all your data in order to create nifty images. i *strongly* suggest to - have **all** the sources (for *anything* generated, including images) in the git-repository - allow to build all artifacts automatically¹ (via the build-system) i'd prefer if the repository *only* contained the sources (and no artifacts), but understand that it is sometimes impractical. fgmasdr IOhannes ¹ unless *you* volunteer to become a build-bot waiting to upload LaTeX sources to whatever webservice to create images in a timely manner. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From zmoelnig at iem.at Mon Jul 1 10:52:19 2019 From: zmoelnig at iem.at (IOhannes m zmoelnig) Date: Mon, 1 Jul 2019 10:52:19 +0200 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: <20190630202448.GI27582@ucsd.edu> References: <20190630040538.GF27582@ucsd.edu> <37f876af-9a42-06e3-2195-0f1b1f483711@iem.at> <20190630202448.GI27582@ucsd.edu> Message-ID: On 30.06.19 22:24, Miller Puckette wrote: >>> But I don't think it's a good idea to put latex compilation in the Pd >>> compile chain, >> why? >> > ATM I can (and do) compile Pd using only "make", "cc" and "ln" - trying to > keep the dependencies to an absolute minimum. > hence my suggestion to make the building of the documentation optional. however, it nevertheless needs to be built at least once, and if you want to keep your *release workflow* to tools like "ln" (and "cp" and "mkdir" :-)), the documentation artifacts probably have to be kept in the repository. in any case, i'd like to be able to create a bit-by-bit identical documentation using automated tools from the doc's source-code. fgmasdr IOhannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From christof.ressi at gmx.at Mon Jul 1 11:36:54 2019 From: christof.ressi at gmx.at (Christof Ressi) Date: Mon, 1 Jul 2019 11:36:54 +0200 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> Message-ID: One the one hand I agree with IOhannes that it's good to have the sources, on the other hand I also agree with Lucas that HTML suits itself very well for documentation. As he said, things like formulas can be included as images - which can be shipped as pre-built artifacts, or built from source, or both. I would even go a bit further and say that it would be great if *all* Pd documentation was also available in HTML so it can be viewed in the browser and put on the homepage. IIRC, there is some plugin which converts Pd patches to SVG graphics, so that could be one way to go. In Supercollider, for example, all documentation is HTML, so you can read everything online: http://doc.sccode.org/. They also have their own small markup language for easy generation of class documentation. This is maybe not so relevant for Pd, as help files are just patches, but we could think about adding meta information to help files (e.g. short description, creation arguments, inlets, outlets), so we can autogenerate a short HTML reference/summary. Just thinking out loud. I have to say I really appreciate the documentation style of Supercollider and I think Pd could adapt some ideas. Christof > Gesendet: Montag, 01. Juli 2019 um 10:46 Uhr > Von: "IOhannes m zmoelnig" > An: pd-dev at lists.iem.at > Betreff: Re: [PD-dev] formatting HTML doc in Pd distro? > > On 01.07.19 04:13, Lucas Cordiviola wrote: > > On 6/30/2019 10:41 PM, Miller Puckette wrote: > > > >> The gotcha is that I can't find a way to typeset equations in native HTML... > > > > How about making the rendered image (of the math equation) with > > https://www.codecogs.com/latex/eqneditor.php and include the image in > > the HTML doc. (isn't this is what Latex do when it generates an HTML > > output ?) > > no, LaTeX doesn't rely on a 3rd party service eating all your data in > order to create nifty images. > > i *strongly* suggest to > - have **all** the sources (for *anything* generated, including images) > in the git-repository > - allow to build all artifacts automatically¹ (via the build-system) > > i'd prefer if the repository *only* contained the sources (and no > artifacts), but understand that it is sometimes impractical. > > > fgmasdr > IOhannes > > > ¹ unless *you* volunteer to become a build-bot waiting to upload LaTeX > sources to whatever webservice to create images in a timely manner. > > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > From giuliomoro at yahoo.it Mon Jul 1 12:53:03 2019 From: giuliomoro at yahoo.it (Giulio Moro) Date: Mon, 1 Jul 2019 10:53:03 +0000 (UTC) Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> Message-ID: <106287381.1146404.1561978383794@mail.yahoo.com> > IIRC, there is some plugin which converts Pd patches to SVG graphics, so that could be one way to go. You may be talking of pd-fileutils? https://github.com/sebpiq/pd-fileutils/ There are a number of drawbacks with that: - you cannot view subpatches (which are very often used in help patches), or use GOP - the number of inlets/outlets displayed is based uniquely on the number of connected patch cords, and does not necessarily reflects the characteristics of the objects - some of the core GUI objects are not supported (and clearly none of the GUI externals) Because of the way the Pd GUI works, most of these issues would be exactly the same with any other rendering engine that does not fully re-implement Pd's backend. The only way I can think of to batch generate raster (or perhaps even vectorial?) renders of a Pd patch is to use some Tcl/Tk functionality (but I know nothing about Tcl/Tk), or perhaps use Purr-data as a rendering engine, which may be easier to tame and make scriptable. On Monday, 1 July 2019, 10:37:47 BST, Christof Ressi wrote: One the one hand I agree with IOhannes that it's good to have the sources, on the other hand I also agree with Lucas that HTML suits itself very well for documentation. As he said, things like formulas can be included as images - which can be shipped as pre-built artifacts, or built from source, or both. I would even go a bit further and say that it would be great if *all* Pd documentation was also available in HTML so it can be viewed in the browser and put on the homepage. IIRC, there is some plugin which converts Pd patches to SVG graphics, so that could be one way to go. In Supercollider, for example, all documentation is HTML, so you can read everything online: http://doc.sccode.org/. They also have their own small markup language for easy generation of class documentation. This is maybe not so relevant for Pd, as help files are just patches, but we could think about adding meta information to help files (e.g. short description, creation arguments, inlets, outlets), so we can autogenerate a short HTML reference/summary. Just thinking out loud. I have to say I really appreciate the documentation style of Supercollider and I think Pd could adapt some ideas. Christof > Gesendet: Montag, 01. Juli 2019 um 10:46 Uhr > Von: "IOhannes m zmoelnig" > An: pd-dev at lists.iem.at > Betreff: Re: [PD-dev] formatting HTML doc in Pd distro? > > On 01.07.19 04:13, Lucas Cordiviola wrote: > > On 6/30/2019 10:41 PM, Miller Puckette wrote: > > > >> The gotcha is that I can't find a way to typeset equations in native HTML... > > > > How about making the rendered image (of the math equation) with > > https://www.codecogs.com/latex/eqneditor.php and include the image in > > the HTML doc. (isn't this is what Latex do when it generates an HTML > > output ?) > > no, LaTeX doesn't rely on a 3rd party service eating all your data in > order to create nifty images. > > i *strongly* suggest to > - have **all** the sources (for *anything* generated, including images) > in the git-repository > - allow to build all artifacts automatically¹ (via the build-system) > > i'd prefer if the repository *only* contained the sources (and no > artifacts), but understand that it is sometimes impractical. > > > fgmasdr > IOhannes > > > ¹ unless *you* volunteer to become a build-bot waiting to upload LaTeX > sources to whatever webservice to create images in a timely manner. > > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > _______________________________________________ Pd-dev mailing list Pd-dev at lists.iem.at https://lists.puredata.info/listinfo/pd-dev From christof.ressi at gmx.at Mon Jul 1 13:27:19 2019 From: christof.ressi at gmx.at (Christof Ressi) Date: Mon, 1 Jul 2019 13:27:19 +0200 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: <106287381.1146404.1561978383794@mail.yahoo.com> References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> <106287381.1146404.1561978383794@mail.yahoo.com> Message-ID: > There are a number of drawbacks with that I already feared that... > is to use some Tcl/Tk functionality seems like you can save a Tcl/Tk canvas in various formats: https://wiki.tcl-lang.org/page/Exporting+a+canvas+to+other+formats https://wiki.tcl-lang.org/page/canvas#0360548f7e52d1d73a26464df08c34beabfea972b80fd57555ca4ca6a79ff106 https://wiki.tcl-lang.org/page/Canvas+to+SVG Christof > Gesendet: Montag, 01. Juli 2019 um 12:53 Uhr > Von: "Giulio Moro" > An: pd-dev , "Christof Ressi" > Betreff: Re: [PD-dev] formatting HTML doc in Pd distro? > > > IIRC, there is some plugin which converts Pd patches to SVG graphics, so that could be one way to go. > > You may be talking of pd-fileutils? https://github.com/sebpiq/pd-fileutils/ > > There are a number of drawbacks with that: > - you cannot view subpatches (which are very often used in help patches), or use GOP > - the number of inlets/outlets displayed is based uniquely on the number of connected patch cords, and does not necessarily reflects the characteristics of the objects > - some of the core GUI objects are not supported (and clearly none of the GUI externals) > > Because of the way the Pd GUI works, most of these issues would be exactly the same with any other rendering engine that does not fully re-implement Pd's backend. The only way I can think of to batch generate raster (or perhaps even vectorial?) renders of a Pd patch is to use some Tcl/Tk functionality (but I know nothing about Tcl/Tk), or perhaps use Purr-data as a rendering engine, which may be easier to tame and make scriptable. > > > On Monday, 1 July 2019, 10:37:47 BST, Christof Ressi wrote: > > > One the one hand I agree with IOhannes that it's good to have the sources, on the other hand I also agree with Lucas that HTML suits itself very well for documentation. As he said, things like formulas can be included as images - which can be shipped as pre-built artifacts, or built from source, or both. > > I would even go a bit further and say that it would be great if *all* Pd documentation was also available in HTML so it can be viewed in the browser and put on the homepage. IIRC, there is some plugin which converts Pd patches to SVG graphics, so that could be one way to go. > > In Supercollider, for example, all documentation is HTML, so you can read everything online: http://doc.sccode.org/. They also have their own small markup language for easy generation of class documentation. This is maybe not so relevant for Pd, as help files are just patches, but we could think about adding meta information to help files (e.g. short description, creation arguments, inlets, outlets), so we can autogenerate a short HTML reference/summary. Just thinking out loud. I have to say I really appreciate the documentation style of Supercollider and I think Pd could adapt some ideas. > > Christof > > > Gesendet: Montag, 01. Juli 2019 um 10:46 Uhr > > Von: "IOhannes m zmoelnig" > > An: pd-dev at lists.iem.at > > Betreff: Re: [PD-dev] formatting HTML doc in Pd distro? > > > > On 01.07.19 04:13, Lucas Cordiviola wrote: > > > On 6/30/2019 10:41 PM, Miller Puckette wrote: > > > > > >> The gotcha is that I can't find a way to typeset equations in native HTML... > > > > > > How about making the rendered image (of the math equation) with > > > https://www.codecogs.com/latex/eqneditor.php and include the image in > > > the HTML doc. (isn't this is what Latex do when it generates an HTML > > > output ?) > > > > no, LaTeX doesn't rely on a 3rd party service eating all your data in > > order to create nifty images. > > > > i *strongly* suggest to > > - have **all** the sources (for *anything* generated, including images) > > in the git-repository > > - allow to build all artifacts automatically¹ (via the build-system) > > > > i'd prefer if the repository *only* contained the sources (and no > > artifacts), but understand that it is sometimes impractical. > > > > > > fgmasdr > > IOhannes > > > > > > ¹ unless *you* volunteer to become a build-bot waiting to upload LaTeX > > sources to whatever webservice to create images in a timely manner. > > > > _______________________________________________ > > Pd-dev mailing list > > Pd-dev at lists.iem.at > > https://lists.puredata.info/listinfo/pd-dev > > > > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > From zmoelnig at iem.at Mon Jul 1 13:37:10 2019 From: zmoelnig at iem.at (IOhannes m zmoelnig) Date: Mon, 1 Jul 2019 13:37:10 +0200 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: <106287381.1146404.1561978383794@mail.yahoo.com> References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> <106287381.1146404.1561978383794@mail.yahoo.com> Message-ID: <592ee8f6-66a5-2130-2c22-02fbff503b32@iem.at> On 01.07.19 12:53, Giulio Moro via Pd-dev wrote: >> IIRC, there is some plugin which converts Pd patches to SVG graphics, so that could be one way to go. > > You may be talking of pd-fileutils? https://github.com/sebpiq/pd-fileutils/ the other one being my patch2svg GUI plugin (see deken), which uses the tcl/tk engine to create a snapshot from a running patch, rather than trying to re-implement the GUI engine of Pd. i'm using the pd-fileutils for our Pd-enabled pastebin [1], but in general i prefer the much more accurate rendering of the patch2svg plugin (GUI-objects, GOPs,...) [1] pastie.iem.at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From christof.ressi at gmx.at Mon Jul 1 13:41:59 2019 From: christof.ressi at gmx.at (Christof Ressi) Date: Mon, 1 Jul 2019 13:41:59 +0200 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: <592ee8f6-66a5-2130-2c22-02fbff503b32@iem.at> References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> <106287381.1146404.1561978383794@mail.yahoo.com> <592ee8f6-66a5-2130-2c22-02fbff503b32@iem.at> Message-ID: ha, thanks! have to try it out! > Gesendet: Montag, 01. Juli 2019 um 13:37 Uhr > Von: "IOhannes m zmoelnig" > An: pd-dev at lists.iem.at > Betreff: Re: [PD-dev] formatting HTML doc in Pd distro? > > On 01.07.19 12:53, Giulio Moro via Pd-dev wrote: > >> IIRC, there is some plugin which converts Pd patches to SVG graphics, so that could be one way to go. > > > > You may be talking of pd-fileutils? https://github.com/sebpiq/pd-fileutils/ > > the other one being my patch2svg GUI plugin (see deken), which uses the > tcl/tk engine to create a snapshot from a running patch, rather than > trying to re-implement the GUI engine of Pd. > > i'm using the pd-fileutils for our Pd-enabled pastebin [1], but in > general i prefer the much more accurate rendering of the patch2svg > plugin (GUI-objects, GOPs,...) > > > [1] pastie.iem.at > > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > From giuliomoro at yahoo.it Mon Jul 1 14:09:59 2019 From: giuliomoro at yahoo.it (Giulio Moro) Date: Mon, 1 Jul 2019 12:09:59 +0000 (UTC) Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: <592ee8f6-66a5-2130-2c22-02fbff503b32@iem.at> References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> <106287381.1146404.1561978383794@mail.yahoo.com> <592ee8f6-66a5-2130-2c22-02fbff503b32@iem.at> Message-ID: <2002404396.1226354.1561982999803@mail.yahoo.com> > the other one being my patch2svg GUI plugin (see deken), which uses the tcl/tk engine to create a snapshot from a running patch, rather than trying to re-implement the GUI engine of Pd. I seemed to remember there had been some discussion around this ... definitely a much better option than external "visualizers", so apologies for the noise. IOhannes, we have made a few fixes to pd-fileutils, but never got around to making a pull request to sebpiq (aslo because we only changed the ""compliled"" file, and not the source). They fix a number of issue (e.g.: comments starting with numbers, wrong display of IP addresses, issue with [declare], and some escaping stuff). Feel free to grab them from here: https://github.com/BelaPlatform/Bela/commits/master/IDE/public/js/pd-fileutils.js On Monday, 1 July 2019, 12:37:48 BST, IOhannes m zmoelnig wrote: On 01.07.19 12:53, Giulio Moro via Pd-dev wrote: >> IIRC, there is some plugin which converts Pd patches to SVG graphics, so that could be one way to go. > > You may be talking of pd-fileutils? https://github.com/sebpiq/pd-fileutils/ the other one being my patch2svg GUI plugin (see deken), which uses the tcl/tk engine to create a snapshot from a running patch, rather than trying to re-implement the GUI engine of Pd. i'm using the pd-fileutils for our Pd-enabled pastebin [1], but in general i prefer the much more accurate rendering of the patch2svg plugin (GUI-objects, GOPs,...) [1] pastie.iem.at _______________________________________________ Pd-dev mailing list Pd-dev at lists.iem.at https://lists.puredata.info/listinfo/pd-dev From abonnements at revolwear.com Mon Jul 1 15:53:32 2019 From: abonnements at revolwear.com (Max) Date: Mon, 1 Jul 2019 15:53:32 +0200 Subject: [PD-dev] Graphical paste (was: Re: formatting HTML doc in Pd distro?) In-Reply-To: <592ee8f6-66a5-2130-2c22-02fbff503b32@iem.at> References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> <106287381.1146404.1561978383794@mail.yahoo.com> <592ee8f6-66a5-2130-2c22-02fbff503b32@iem.at> Message-ID: <6d8307bd-220b-c26b-3a00-c24f441851ae@revolwear.com> On 01.07.19 13:37, IOhannes m zmoelnig wrote: > i'm using the pd-fileutils for our Pd-enabled pastebin [1], but in > general i prefer the much more accurate rendering of the patch2svg > plugin (GUI-objects, GOPs,...) > > > [1] pastie.iem.at This is genius, I am going to write a feature-request to add this to the pd menu help -> share... -> pastie.iem.at S2 From lucarda27 at hotmail.com Tue Jul 2 09:11:35 2019 From: lucarda27 at hotmail.com (Lucas Cordiviola) Date: Tue, 2 Jul 2019 07:11:35 +0000 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> Message-ID: On 7/1/2019 5:46 AM, IOhannes m zmoelnig wrote: > i*strongly* suggest to > - have **all** the sources (for*anything* generated, including images) > in the git-repository > - allow to build all artifacts automatically¹ (via the build-system) I fail to see anything we can do to auto-generate single image files from 1 or more LaTex file/s. This should be carefully and manually handled by the author or the maintainer. There could be one master LaTex file containing the code for each image if the source is to be stored: '' figure 0.1.0 $saras \$whatever ... figure 0.1.1 $ssgdsdg \$whatever ... '' Since this is not automatic Miller should probably be in favor (and I understand) of just writing everything on LaTex files instead of html. Since I don't know how many "math formulas" are needed I don't know what to say. :) Mensaje telepatico asistido por maquinas. From msp at ucsd.edu Tue Jul 2 16:13:31 2019 From: msp at ucsd.edu (Miller Puckette) Date: Tue, 2 Jul 2019 07:13:31 -0700 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> Message-ID: <20190702141331.GG31976@ucsd.edu> Looks like the best thing will be to use either latex or markdown, and include both the latex/markdown source and an HTML compiled version of the doc in the git repo. The doc will doubtless contain images of patch fragments, taken from the help files, in a way similar to my book (http://msp.ucsd.edu/techniques.htm). cheers M for the images. (Unless it's feasible to unify that with the help On Tue, Jul 02, 2019 at 07:11:35AM +0000, Lucas Cordiviola wrote: > > On 7/1/2019 5:46 AM, IOhannes m zmoelnig wrote: > > i*strongly* suggest to > > - have **all** the sources (for*anything* generated, including images) > > in the git-repository > > - allow to build all artifacts automatically?? (via the build-system) > > I fail to see anything we can do to auto-generate single image files > from 1 or more LaTex file/s. This should be carefully and manually > handled by the author or the maintainer. There could be one master LaTex > file containing the code for each image if the source is to be stored: > > '' > figure 0.1.0 > $saras \$whatever ... > figure 0.1.1 > $ssgdsdg \$whatever ... > '' > > Since this is not automatic Miller should probably be in favor (and I > understand) of just writing everything on LaTex files instead of html. > Since I don't know how many "math formulas" are needed I don't know what > to say. > > > > :) > > > Mensaje telepatico asistido por maquinas. > > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev From lucarda27 at hotmail.com Wed Jul 3 08:14:03 2019 From: lucarda27 at hotmail.com (Lucas Cordiviola) Date: Wed, 3 Jul 2019 06:14:03 +0000 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: <20190702141331.GG31976@ucsd.edu> References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> <20190702141331.GG31976@ucsd.edu> Message-ID: If the only show stopper for HTML is "typeset equations in native HTML" there's a workaround: https://www.mathjax.org/ https://github.com/mathjax/MathJax the only gotcha is that the "typeset equations" wont render on an offline browser. Works by just including : in the of the document. Its fully documented and looks it is going to be there. (if for some reason we need the local files it takes 40Mb) It might be just what we want. ? IOhannes ? Test code: '''''''

big heading

h2 smaller heading

paragraph ... when $ x < y $ we have ...

paragraph 2 .. \[ \sum a b \]

paragraph 3 .. $\sum a b $ '''''''' Mensaje telepatico asistido por maquinas. On 7/2/2019 11:13 AM, Miller Puckette wrote: Looks like the best thing will be to use either latex or markdown, and include both the latex/markdown source and an HTML compiled version of the doc in the git repo. The doc will doubtless contain images of patch fragments, taken from the help files, in a way similar to my book (http://msp.ucsd.edu/techniques.htm). cheers M for the images. (Unless it's feasible to unify that with the help On Tue, Jul 02, 2019 at 07:11:35AM +0000, Lucas Cordiviola wrote: On 7/1/2019 5:46 AM, IOhannes m zmoelnig wrote: i*strongly* suggest to - have **all** the sources (for*anything* generated, including images) in the git-repository - allow to build all artifacts automatically?? (via the build-system) I fail to see anything we can do to auto-generate single image files from 1 or more LaTex file/s. This should be carefully and manually handled by the author or the maintainer. There could be one master LaTex file containing the code for each image if the source is to be stored: '' figure 0.1.0 $saras \$whatever ... figure 0.1.1 $ssgdsdg \$whatever ... '' Since this is not automatic Miller should probably be in favor (and I understand) of just writing everything on LaTex files instead of html. Since I don't know how many "math formulas" are needed I don't know what to say. :) Mensaje telepatico asistido por maquinas. _______________________________________________ Pd-dev mailing list Pd-dev at lists.iem.at https://lists.puredata.info/listinfo/pd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From porres at gmail.com Thu Jul 4 00:20:20 2019 From: porres at gmail.com (Alexandre Torres Porres) Date: Wed, 3 Jul 2019 19:20:20 -0300 Subject: [PD-dev] what's the maximum list size? Message-ID: how big of a list xcan we have in Pd? How many elements can a t_atom have? cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmoelnig at iem.at Thu Jul 4 10:21:53 2019 From: zmoelnig at iem.at (IOhannes m zmoelnig) Date: Thu, 4 Jul 2019 10:21:53 +0200 Subject: [PD-dev] what's the maximum list size? In-Reply-To: References: Message-ID: On 04.07.19 00:20, Alexandre Torres Porres wrote: > how big of a list xcan we have in Pd? i don't think there's a limit. i've just successfully created a list of about 690.000.000 elements (all floats) with [list store], which happens to consume ~50% (according to htop) of my memory (32GB RAM); whenever i output the list (e.g. to measure its length with [list length]) the system starts to swap. the ideal representation of such a list would take 2.5GB of memory (an array of single precision floats), however, due to Pd's t_atom type it should take about 10GB on a 64bit system. whenever you bang [list store], it creates two copies of the stored list (amounting to about 30GB) which probably explains why it takes so long to type this email. > How many elements can a t_atom have? given that a t_atom is a scalar: one. (or: i don't understand the question; what do you mean with "element"?) gnas+ IOhannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jamie at jamiebullock.com Thu Jul 4 10:53:56 2019 From: jamie at jamiebullock.com (Jamie Bullock) Date: Thu, 4 Jul 2019 09:53:56 +0100 Subject: [PD-dev] what's the maximum list size? In-Reply-To: References: Message-ID: <801CEF3A-6B81-4DA3-9844-99BE7351EB52@jamiebullock.com> > On 4 Jul 2019, at 09:21, IOhannes m zmoelnig wrote: > > On 04.07.19 00:20, Alexandre Torres Porres wrote: >> how big of a list xcan we have in Pd? > > i don't think there's a limit. Since Pd’s argc for passing list vectors is an int, isn’t the maximum list size bound by INT_MAX, so something in the order of 2x10^9 ? Jamie From zmoelnig at iem.at Thu Jul 4 11:29:48 2019 From: zmoelnig at iem.at (IOhannes m zmoelnig) Date: Thu, 4 Jul 2019 11:29:48 +0200 Subject: [PD-dev] what's the maximum list size? In-Reply-To: <801CEF3A-6B81-4DA3-9844-99BE7351EB52@jamiebullock.com> References: <801CEF3A-6B81-4DA3-9844-99BE7351EB52@jamiebullock.com> Message-ID: On 04.07.19 10:53, Jamie Bullock wrote: >> On 4 Jul 2019, at 09:21, IOhannes m zmoelnig wrote: >> >> On 04.07.19 00:20, Alexandre Torres Porres wrote: >>> how big of a list xcan we have in Pd? >> >> i don't think there's a limit. > > Since Pd’s argc for passing list vectors is an int, isn’t the maximum list size bound by INT_MAX, so something in the order of 2x10^9 ? +2147483648 :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From abonnements at revolwear.com Thu Jul 4 12:04:24 2019 From: abonnements at revolwear.com (Max) Date: Thu, 4 Jul 2019 12:04:24 +0200 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: <20190702141331.GG31976@ucsd.edu> References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> <20190702141331.GG31976@ucsd.edu> Message-ID: <5746620a-5311-19fe-e5fb-834fd2d81822@revolwear.com> On 02.07.19 16:13, Miller Puckette wrote: > The doc will doubtless contain images of > patch fragments, taken from the help files, in a way similar to my > book (http://msp.ucsd.edu/techniques.htm). It would be nice if those patches were vector graphics which should be possible thanks to IOhannes patch2svg exporter. pd patch -> svg -> pdf -> placed in latex -> pdf From jamie at jamiebullock.com Thu Jul 4 12:24:50 2019 From: jamie at jamiebullock.com (Jamie Bullock) Date: Thu, 4 Jul 2019 11:24:50 +0100 Subject: [PD-dev] what's the maximum list size? In-Reply-To: References: <801CEF3A-6B81-4DA3-9844-99BE7351EB52@jamiebullock.com> Message-ID: > On 4 Jul 2019, at 10:29, IOhannes m zmoelnig wrote: > > On 04.07.19 10:53, Jamie Bullock wrote: >>> On 4 Jul 2019, at 09:21, IOhannes m zmoelnig wrote: >>> >>> On 04.07.19 00:20, Alexandre Torres Porres wrote: >>>> how big of a list xcan we have in Pd? >>> >>> i don't think there's a limit. >> >> Since Pd’s argc for passing list vectors is an int, isn’t the maximum list size bound by INT_MAX, so something in the order of 2x10^9 ? > +2147483648 :-) Ha yeah! Wrote that in a rush, of course I meant 2^31 :*) J From porres at gmail.com Thu Jul 4 18:19:10 2019 From: porres at gmail.com (Alexandre Torres Porres) Date: Thu, 4 Jul 2019 13:19:10 -0300 Subject: [PD-dev] what's the maximum list size? In-Reply-To: References: <801CEF3A-6B81-4DA3-9844-99BE7351EB52@jamiebullock.com> Message-ID: but that's 2ˆ30 ;) Em qui, 4 de jul de 2019 às 07:32, Jamie Bullock escreveu: > > > > On 4 Jul 2019, at 10:29, IOhannes m zmoelnig wrote: > > > > On 04.07.19 10:53, Jamie Bullock wrote: > >>> On 4 Jul 2019, at 09:21, IOhannes m zmoelnig wrote: > >>> > >>> On 04.07.19 00:20, Alexandre Torres Porres wrote: > >>>> how big of a list xcan we have in Pd? > >>> > >>> i don't think there's a limit. > >> > >> Since Pd’s argc for passing list vectors is an int, isn’t the maximum > list size bound by INT_MAX, so something in the order of 2x10^9 ? > > +2147483648 :-) > > Ha yeah! Wrote that in a rush, of course I meant 2^31 :*) > > J > > > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reduzent at gmail.com Thu Jul 4 18:48:02 2019 From: reduzent at gmail.com (Roman Haefeli) Date: Thu, 04 Jul 2019 18:48:02 +0200 Subject: [PD-dev] what's the maximum list size? In-Reply-To: References: <801CEF3A-6B81-4DA3-9844-99BE7351EB52@jamiebullock.com> Message-ID: <5ae681c2a2961f012c15b6b7cec02d0ec98d934c.camel@gmail.com> >>> +2147483648 :-) >> Ha yeah! Wrote that in a rush, of course I meant 2^31 :*) > but that's 2ˆ30 ;) You sure? Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From jancsika at yahoo.com Thu Jul 4 18:39:08 2019 From: jancsika at yahoo.com (Jonathan Wilkes) Date: Thu, 4 Jul 2019 16:39:08 +0000 (UTC) Subject: [PD-dev] what's the maximum list size? In-Reply-To: References: Message-ID: <366738921.1923126.1562258348553@mail.yahoo.com> > On Thursday, July 4, 2019, 3:35:14 AM EDT, Alexandre Torres Porres wrote: > how big of a list xcan we have in Pd? 100 > How many elements can a t_atom have? 1000 For best results, no bigger than: 5 All assuming the Pd user needs to hit low latency soft realtime deadlines. -Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From megrimm at gmail.com Thu Jul 4 21:25:04 2019 From: megrimm at gmail.com (me.grimm) Date: Thu, 4 Jul 2019 15:25:04 -0400 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: <5746620a-5311-19fe-e5fb-834fd2d81822@revolwear.com> References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> <20190702141331.GG31976@ucsd.edu> <5746620a-5311-19fe-e5fb-834fd2d81822@revolwear.com> Message-ID: >> IOhannes patch2svg exporter. btw the autoexport.pd patch crashes pd when I open it (macOs 10.14.5 pd 0.49.1). thats from the deken repo thingy. here is output running from cli with -verbose: w .x100330c60 wname autoexport.pd name autoexport.pd.x100330c60.svg template %s%x.svg just a heads up on that. m On Thu, Jul 4, 2019 at 6:05 AM Max wrote: > On 02.07.19 16:13, Miller Puckette wrote: > > The doc will doubtless contain images of > > patch fragments, taken from the help files, in a way similar to my > > book (http://msp.ucsd.edu/techniques.htm). > > It would be nice if those patches were vector graphics which should be > possible thanks to IOhannes patch2svg exporter. > > pd patch -> svg -> pdf -> placed in latex -> pdf > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > -- ____________________ m.e.grimm, m.f.a, ed.m. cornell u., tc3 megrimm.net ____________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmoelnig at iem.at Fri Jul 5 00:00:39 2019 From: zmoelnig at iem.at (=?UTF-8?Q?IOhannes_m_zm=c3=b6lnig?=) Date: Fri, 5 Jul 2019 00:00:39 +0200 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> <20190702141331.GG31976@ucsd.edu> <5746620a-5311-19fe-e5fb-834fd2d81822@revolwear.com> Message-ID: <40a8086e-a86e-9a0f-1b60-e02e46bc6642@iem.at> On 7/4/19 9:25 PM, me.grimm wrote: >>> IOhannes patch2svg exporter. > > > btw the autoexport.pd patch crashes pd when I open it (macOs 10.14.5 pd > 0.49.1). l are you sure it crashes? > > here is output running from cli with -verbose: > > > w .x100330c60 > > wname autoexport.pd > > name autoexport.pd.x100330c60.svg > > template %s%x.svg which looks good to me. you might notice that after opening the patch, you suddenly have a couple of .svg files in your directory. the autoexport.pd patch is just a demonstration on how one could use the patch2svg plugin to fully automate the conversion of Pd patches to SVGs (without user interaction; e.g. from a script). i admit that it is somewhat unexpected (and undocumented) for a patch, that it shuts down Pd without a warning gfmasdr IOhannes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From williamahuston at gmail.com Fri Jul 5 00:21:55 2019 From: williamahuston at gmail.com (William Huston) Date: Thu, 4 Jul 2019 18:21:55 -0400 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: <20190630040538.GF27582@ucsd.edu> References: <20190630040538.GF27582@ucsd.edu> Message-ID: I wish there was a way to include in the standard build a rendering of *all* supplied docs as PDF or HTML, so I can look something up if I am mobile and not near a machine with PD installed. The existing x1.html (etc) files are great, but there's a lot of stuff missing. thanks On Jun 30, 2019 1:52 AM, "Miller Puckette" wrote: To pd dev - I'm struggling to finish the design of a slew-limiting low-pass filter (slop~) to add to Pd vanilla to make ti easier to make dynamics processors and soft limiters (and hopefully other stuff). The usual help window scheme isn't adequate to describe how to use it, so I want to make some way to format Latex documentation and link to it from Pd help files. My current plan is: Make Pd able to open files in the native OS (maybe via a new "pdcontrol" object that would issue system commands and be extensible to get various notifications in the future). Put detailed, latex-compiled documentation somewhere in the Pd distro, probably in 1.manual as HTML files, but perhaps as PDFs in addition or instead. But I don't think it's a good idea to put latex compilation in the Pd compile chain, so I _think_ the practical way to do this is to put both latex xources and HTML targets in the Pd distro. This would be ugly (having to check latex output into the git repo as if it were source) but I don't see any good way to do otherwise without making it very difficult for others to compile Pd using the autotools and/or the plain makefiles in pd/src. For the moment I'm planning to just put an attempt at documentation for slop~ on my own page and point to it from the slop~ help file (which will require fixing Pd to be able to open URLs). But eventually I want to be able to include the full doc int eh Pd release. Any advice would be very helpful! cheers Miller _______________________________________________ Pd-dev mailing list Pd-dev at lists.iem.at https://lists.puredata.info/listinfo/pd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From porres at gmail.com Fri Jul 5 00:42:27 2019 From: porres at gmail.com (Alexandre Torres Porres) Date: Thu, 4 Jul 2019 19:42:27 -0300 Subject: [PD-dev] what's the maximum list size? In-Reply-To: <5ae681c2a2961f012c15b6b7cec02d0ec98d934c.camel@gmail.com> References: <801CEF3A-6B81-4DA3-9844-99BE7351EB52@jamiebullock.com> <5ae681c2a2961f012c15b6b7cec02d0ec98d934c.camel@gmail.com> Message-ID: Em qui, 4 de jul de 2019 às 13:54, Roman Haefeli escreveu: > > >>> +2147483648 :-) > >> Ha yeah! Wrote that in a rush, of course I meant 2^31 :*) > > but that's 2ˆ30 ;) > > You sure? > no, but a google search led me to this: http://potenciasde2.blogspot.com/ 2ˆ30 = 2 147 483 648 :/ so I assumed int goes from -2147483648 to +2147483647 for being in a range of 2ˆ31 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch at chnry.net Fri Jul 5 08:32:25 2019 From: ch at chnry.net (cyrille henry) Date: Fri, 5 Jul 2019 08:32:25 +0200 Subject: [PD-dev] what's the maximum list size? In-Reply-To: References: <801CEF3A-6B81-4DA3-9844-99BE7351EB52@jamiebullock.com> <5ae681c2a2961f012c15b6b7cec02d0ec98d934c.camel@gmail.com> Message-ID: a calculator gives : 2ˆ30 = 1073741824. The webpage is wrong. (you can see it problem between 2^23 and 2^24) a int is obviouslly from range -(2^31)-1 to (2^31)-1 this is about from -2*10^9 to 2*10^9 cheers Le 05/07/2019 à 00:42, Alexandre Torres Porres a écrit : > > > Em qui, 4 de jul de 2019 às 13:54, Roman Haefeli > escreveu: > > > >>> +2147483648 :-) > >> Ha yeah! Wrote that in a rush, of course I meant 2^31 :*) > > but that's 2ˆ30 ;) > > You sure? > > > no, but a google search led me to this: http://potenciasde2.blogspot.com/ > > 2ˆ30 = 2 147 483 648 > > :/ > > so I assumed int goes from -2147483648 to +2147483647 for being in a range of 2ˆ31 > > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > From mfbrandi at outlook.com Fri Jul 5 10:36:02 2019 From: mfbrandi at outlook.com (matthew brandi) Date: Fri, 5 Jul 2019 08:36:02 +0000 Subject: [PD-dev] what's the maximum list size? In-Reply-To: References: <801CEF3A-6B81-4DA3-9844-99BE7351EB52@jamiebullock.com> <5ae681c2a2961f012c15b6b7cec02d0ec98d934c.camel@gmail.com> Message-ID: On 04/07/2019 23:42, Alexandre Torres Porres wrote: no, but a google search led me to this: http://potenciasde2.blogspot.com/ 2ˆ30 = 2 147 483 648 Yeah, but they have the obviously incorrect: 2ˆ23 = 8 388 608 2ˆ24 = 33 554 432 -- matthew brandi | 020 8882 4616 -------------- next part -------------- An HTML attachment was scrubbed... URL: From megrimm at gmail.com Fri Jul 5 14:39:29 2019 From: megrimm at gmail.com (me.grimm) Date: Fri, 5 Jul 2019 08:39:29 -0400 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> <20190702141331.GG31976@ucsd.edu> <5746620a-5311-19fe-e5fb-834fd2d81822@revolwear.com> <40a8086e-a86e-9a0f-1b60-e02e46bc6642@iem.at> Message-ID: im really just firing emails off too quick this morn without really knowing whats going on.... permission denied error. i assume because it is trying to export to ~/Applications/Pd.app/Content/Resources with the [; pd plugin-dispatch ::patch2svg::exportall{ message anyway to save to patch directory with message? exporting to SVG: svg-export.pd.x10045eb00.svg (Tcl) UNHANDLED ERROR: couldn't open "svg-export.pd.x10045eb00.svg": permission denied while executing "open $path w" (procedure "can2svg::canvas2file" line 14) invoked from within "can2svg::canvas2file [tkcanvas_name $mytoplevel] $filename" (procedure "export" line 2) invoked from within "export $w $name" (procedure "::patch2svg::exportall" line 16) invoked from within "$callback [ lrange $args 1 end ]" ("foreach" body line 2) invoked from within "foreach callback $::pd_connect::plugin_dispatch_receivers($receiver) { $callback [ lrange $args 1 end ] }" invoked from within "if [ info exists ::pd_connect::plugin_dispatch_receivers($receiver) ] { foreach callback $::pd_connect::plugin_dispatch_receivers($receiver) { ..." (procedure "pdtk_plugin_dispatch" line 3) invoked from within "pdtk_plugin_dispatch ::patch2svg::exportall" ("uplevel" body line 1) invoked from within "uplevel #0 $docmds" On Fri, Jul 5, 2019 at 8:23 AM me.grimm wrote: > >> couple of .svg files in your directory. > > I assume in the patch2svg-plugin directory? And no... no *.svg's > > >> that it shuts down Pd without a warning > > ha tricky... :) yeah i didnt see that. > > I was though getting a tcl error that I got a screen shot of but am no > longer able to reproduce for some reason. i think the flash of pink before > closing led me to believe pd crashed rather than the [; pd quit{ message. > > attached. > > > m > > On Thu, Jul 4, 2019 at 6:01 PM IOhannes m zmölnig wrote: > >> On 7/4/19 9:25 PM, me.grimm wrote: >> >>> IOhannes patch2svg exporter. >> > >> > >> > btw the autoexport.pd patch crashes pd when I open it (macOs 10.14.5 pd >> > 0.49.1). >> l >> are you sure it crashes? >> >> > >> > here is output running from cli with -verbose: >> > >> > >> > w .x100330c60 >> > >> > wname autoexport.pd >> > >> > name autoexport.pd.x100330c60.svg >> > >> > template %s%x.svg >> >> which looks good to me. >> you might notice that after opening the patch, you suddenly have a >> couple of .svg files in your directory. >> >> the autoexport.pd patch is just a demonstration on how one could use the >> patch2svg plugin to fully automate the conversion of Pd patches to SVGs >> (without user interaction; e.g. from a script). >> >> i admit that it is somewhat unexpected (and undocumented) for a patch, >> that it shuts down Pd without a warning >> >> gfmasdr >> IOhannes >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev at lists.iem.at >> https://lists.puredata.info/listinfo/pd-dev >> > > > -- > ____________________ > m.e.grimm, m.f.a, ed.m. > cornell u., tc3 > megrimm.net > ____________________ > -- ____________________ m.e.grimm, m.f.a, ed.m. cornell u., tc3 megrimm.net ____________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From porres at gmail.com Fri Jul 5 18:44:47 2019 From: porres at gmail.com (Alexandre Torres Porres) Date: Fri, 5 Jul 2019 13:44:47 -0300 Subject: [PD-dev] what's the maximum list size? In-Reply-To: References: <801CEF3A-6B81-4DA3-9844-99BE7351EB52@jamiebullock.com> <5ae681c2a2961f012c15b6b7cec02d0ec98d934c.camel@gmail.com> Message-ID: yeah, I know, I was just pointing how I got misled :/ next time: don't be lazy to use a calculator Em sex, 5 de jul de 2019 às 06:03, cyrille henry escreveu: > a calculator gives : 2ˆ30 = 1073741824. The webpage is wrong. (you can see > it problem between 2^23 and 2^24) > > a int is obviouslly from range -(2^31)-1 to (2^31)-1 > this is about from -2*10^9 to 2*10^9 > > cheers > > Le 05/07/2019 à 00:42, Alexandre Torres Porres a écrit : > > > > > > Em qui, 4 de jul de 2019 às 13:54, Roman Haefeli > escreveu: > > > > > > >>> +2147483648 :-) > > >> Ha yeah! Wrote that in a rush, of course I meant 2^31 :*) > > > but that's 2ˆ30 ;) > > > > You sure? > > > > > > no, but a google search led me to this: > http://potenciasde2.blogspot.com/ > > > > 2ˆ30 = 2 147 483 648 > > > > :/ > > > > so I assumed int goes from -2147483648 to +2147483647 for being in a > range of 2ˆ31 > > > > _______________________________________________ > > Pd-dev mailing list > > Pd-dev at lists.iem.at > > https://lists.puredata.info/listinfo/pd-dev > > > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch at chnry.net Fri Jul 5 19:02:09 2019 From: ch at chnry.net (cyrille henry) Date: Fri, 5 Jul 2019 19:02:09 +0200 Subject: [PD-dev] what's the maximum list size? In-Reply-To: References: <801CEF3A-6B81-4DA3-9844-99BE7351EB52@jamiebullock.com> <5ae681c2a2961f012c15b6b7cec02d0ec98d934c.camel@gmail.com> Message-ID: sorry, I should not reply to this list so early in the morning. Le 05/07/2019 à 18:44, Alexandre Torres Porres a écrit : > yeah, I know, I was just pointing how I got misled :/ > > next time: don't be lazy to use a calculator > > Em sex, 5 de jul de 2019 às 06:03, cyrille henry > escreveu: > > a calculator gives : 2ˆ30 = 1073741824. The webpage is wrong. (you can see it problem between 2^23 and 2^24) > > a int is obviouslly from range -(2^31)-1 to (2^31)-1 > this is about from -2*10^9 to 2*10^9 > > cheers > > Le 05/07/2019 à 00:42, Alexandre Torres Porres a écrit : > > > > > > Em qui, 4 de jul de 2019 às 13:54, Roman Haefeli >> escreveu: > > > > > > >>> +2147483648 :-) > > >> Ha yeah! Wrote that in a rush, of course I meant 2^31 :*) > > > but that's 2ˆ30 ;) > > > > You sure? > > > > > > no, but a google search led me to this: http://potenciasde2.blogspot.com/ > > > > 2ˆ30 = 2 147 483 648 > > > > :/ > > > > so I assumed int goes from -2147483648 to +2147483647 for being in a range of 2ˆ31 > > > > _______________________________________________ > > Pd-dev mailing list > > Pd-dev at lists.iem.at > > https://lists.puredata.info/listinfo/pd-dev > > > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > > > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > From zmoelnig at iem.at Fri Jul 5 21:45:51 2019 From: zmoelnig at iem.at (zmoelnig at iem.at) Date: Fri, 05 Jul 2019 19:45:51 +0000 Subject: [PD-dev] formatting HTML doc in Pd distro? In-Reply-To: References: <20190630040538.GF27582@ucsd.edu> <20190701014156.GD17705@ucsd.edu> <20190702141331.GG31976@ucsd.edu> <5746620a-5311-19fe-e5fb-834fd2d81822@revolwear.com> <40a8086e-a86e-9a0f-1b60-e02e46bc6642@iem.at> Message-ID: <20190705194551.Horde._woP_UCJdM-gcZYp-XPyVzZ@webmail.iem.at> Quoting "me.grimm" : >>> couple of .svg files in your directory. > > I assume in the patch2svg-plugin directory? And no... no *.svg's in the "current" directory... mfgnrd IOhannes From porres at gmail.com Fri Jul 5 21:48:08 2019 From: porres at gmail.com (Alexandre Torres Porres) Date: Fri, 5 Jul 2019 16:48:08 -0300 Subject: [PD-dev] what's the maximum list size? In-Reply-To: References: <801CEF3A-6B81-4DA3-9844-99BE7351EB52@jamiebullock.com> <5ae681c2a2961f012c15b6b7cec02d0ec98d934c.camel@gmail.com> Message-ID: hmm? > next time: don't be lazy to use a calculator anyway, I was talking about me, just to make sure :) Em sex, 5 de jul de 2019 às 16:29, cyrille henry escreveu: > sorry, I should not reply to this list so early in the morning. > > > Le 05/07/2019 à 18:44, Alexandre Torres Porres a écrit : > > yeah, I know, I was just pointing how I got misled :/ > > > > next time: don't be lazy to use a calculator > > > > Em sex, 5 de jul de 2019 às 06:03, cyrille henry ch at chnry.net>> escreveu: > > > > a calculator gives : 2ˆ30 = 1073741824. The webpage is wrong. (you > can see it problem between 2^23 and 2^24) > > > > a int is obviouslly from range -(2^31)-1 to (2^31)-1 > > this is about from -2*10^9 to 2*10^9 > > > > cheers > > > > Le 05/07/2019 à 00:42, Alexandre Torres Porres a écrit : > > > > > > > > > Em qui, 4 de jul de 2019 às 13:54, Roman Haefeli < > reduzent at gmail.com >> escreveu: > > > > > > > > > >>> +2147483648 :-) > > > >> Ha yeah! Wrote that in a rush, of course I meant 2^31 :*) > > > > but that's 2ˆ30 ;) > > > > > > You sure? > > > > > > > > > no, but a google search led me to this: > http://potenciasde2.blogspot.com/ > > > > > > 2ˆ30 = 2 147 483 648 > > > > > > :/ > > > > > > so I assumed int goes from -2147483648 to +2147483647 for being > in a range of 2ˆ31 > > > > > > _______________________________________________ > > > Pd-dev mailing list > > > Pd-dev at lists.iem.at > > > https://lists.puredata.info/listinfo/pd-dev > > > > > > > > > > > _______________________________________________ > > Pd-dev mailing list > > Pd-dev at lists.iem.at > > https://lists.puredata.info/listinfo/pd-dev > > > > > > _______________________________________________ > > Pd-dev mailing list > > Pd-dev at lists.iem.at > > https://lists.puredata.info/listinfo/pd-dev > > > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From porres at gmail.com Thu Jul 11 20:41:31 2019 From: porres at gmail.com (Alexandre Torres Porres) Date: Thu, 11 Jul 2019 15:41:31 -0300 Subject: [PD-dev] hint on drawing exponential curves in tcl/tk Message-ID: Howdy, I just implemented exponential lines for my [else/envgen~] object and I'm hoping to also provide this in a GUI object for visualization. Drawing straight lines for the envelope is trivial with "create line" < https://www.tutorialspoint.com/tcl-tk/tk_canvas_line.htm>. But how about drawing exponential curves, like being able to give it an exponential factor. For instance, "2", which would be raising to the power of 2, then the vertical distance from point 'a' to 'b' would be normalized to "1" and a curve from 0 to 1 would be raised to the power of 2. hints? thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From danomatika at gmail.com Mon Jul 15 00:21:49 2019 From: danomatika at gmail.com (Dan Wilcox) Date: Mon, 15 Jul 2019 00:21:49 +0200 Subject: [PD-dev] Pd hangs on exit on macOS Message-ID: <943D4D80-C788-47D5-A617-4B940E4BBB5B@gmail.com> Is anyone noticing that the Pd core seems to hang on macOS? You can close the GUI but sometimes the "pd" core process spins in the background sucking up CPU or the GUI freezes on exit as well? It seems to be spinning in the port audio ring buffer s_audio_paring.c line 130. Both index and rbuf->bufferSize are 0 and it's stuck in the while loop, although this is after sys_close audio should have happened. Maybe it's a thread race condition? I don't remember this happening before macOS 101.4 so I wonder if it's something lower level as there has been the general push towards AudioUnit V3. Ugg. -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bostjan at japina.eu Tue Jul 16 14:59:14 2019 From: bostjan at japina.eu (Japina) Date: Tue, 16 Jul 2019 14:59:14 +0200 Subject: [PD-dev] How is buffer (block) used in the puredata (internals) Message-ID: <0EBFACF7-9935-45AD-9E00-CF181D1F9708@japina.eu> Hi, I am working on the porting puredata diagram to ARM based microcontroller. During writing the code some questions popped up. As far as I know there is a default buffer or block with a size of 64 bytes. Sampling frequency is 44.100 Hz, but what I wonder is how the block is used. If I have a list of commands - is every command use on the whole block or are all commands used for every element of the block. Hopefully it is clear what I am asking. Thanks. Bostjan -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From msndohenri at hotmail.com Tue Jul 16 16:51:09 2019 From: msndohenri at hotmail.com (Henri Augusto Bisognini) Date: Tue, 16 Jul 2019 14:51:09 +0000 Subject: [PD-dev] First complete keyboard navigation prototype In-Reply-To: References: <5F2A5CE9-1D8E-47CF-9A29-F2FF226BAE6F@gmail.com> <20190612034824.GS24398@ucsd.edu> <26e9ae06-1669-b97e-a31b-da5d47f081b9@iem.at> , Message-ID: Okay, just help me check if i got it right. At first i was thinking that when externals, for any reason, used the size of the canvas struct (or any other) it would do so in real time. Like calling sizeof() and stuff. But it appears that actually the size of the struct is deduced while compiling. So if you write an external it is going to think the canvas struct is the same size as it was in the pd header files that were used during compilation. Is that it? I don't think i quite get something. When using the pointer to implementation idiom, wouldn't the pointer itself change the size of the struct? You've said something about that not being a problem when you add it as the last member of the struct but i don't understand why and how that would work. (I don't have a formal background on programming so forgive me if thats obvious or something.) ________________________________ De: Christof Ressi Enviado: sábado, 15 de junho de 2019 17:11 Para: Henri Augusto Bisognini Cc: pd-dev at lists.iem.at Assunto: Aw: Re: [PD-dev] First complete keyboard navigation prototype Hi, as IOhannes said, "g_canvas.h" is semi-public in a sense that some externals use it (e.g. iemguts). So unless it is absolutely necessary, we should avoid breaking binary compatibility. If the e_kbdnav member is only conditionally enabled with an #ifdef, existing externals (or those not compiled with key-nav-support) will see a different size of t_editor. This is not much of a problem as long as e_kbdnav is the last member of t_editor, but as soon as we add another member, we might run into problems, since this last field will be at a different offset. I think the solution is simple: just add a "void *e_private" member which points to some private data where we can put all stuff which we don't want to expose the header. (This is called the "PIMPL idiom"). e_kbdnav would be the first member of such private data. IOhannes actually did this with the "gl_privatedata" member in t_canvas to hide the undo queue implemention. The "t_canvas_private" struct currently only has a "t_undo" member but it's possible to add/remove/rearrange members at will without having to think about binary compatibility issues because it's not in a header file. Christof Gesendet: Samstag, 15. Juni 2019 um 19:58 Uhr Von: "Henri Augusto Bisognini" An: "pd-dev at lists.iem.at" Betreff: Re: [PD-dev] First complete keyboard navigation prototype Please excuse my ignorance on that matter but could you give me a brief explanation of the problem at hand? ________________________________ De: Pd-dev em nome de IOhannes m zmölnig Enviado: sexta-feira, 14 de junho de 2019 04:37 Para: pd-dev at lists.iem.at Assunto: Re: [PD-dev] First complete keyboard navigation prototype On 6/13/19 7:34 PM, Henri Augusto Bisognini wrote: > Also, in g_canvas.h, inside the "struct _editor" there is a "struct _kbdnav" member. This is the struct that contains the data used in the keyboard navigation. > i haven't looked at the actual code, but what you describe here, is that you are actually changing the size of a quasi-public struct and thus the memory layout as presented to externals. which means that a version of Pd that has the keyboard-navigation enabled is (partly) *binary-incompatible* with a version of Pd that does not have the keyboard-navigation enabled. bummer :-( gfmadr IOhannes _______________________________________________ Pd-dev mailing list Pd-dev at lists.iem.at https://lists.puredata.info/listinfo/pd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From christof.ressi at gmx.at Tue Jul 16 19:32:04 2019 From: christof.ressi at gmx.at (Christof Ressi) Date: Tue, 16 Jul 2019 19:32:04 +0200 Subject: [PD-dev] First complete keyboard navigation prototype In-Reply-To: References: <5F2A5CE9-1D8E-47CF-9A29-F2FF226BAE6F@gmail.com> <20190612034824.GS24398@ucsd.edu> <26e9ae06-1669-b97e-a31b-da5d47f081b9@iem.at> Message-ID: An HTML attachment was scrubbed... URL: From danomatika at gmail.com Wed Jul 17 02:20:07 2019 From: danomatika at gmail.com (Dan Wilcox) Date: Wed, 17 Jul 2019 02:20:07 +0200 Subject: [PD-dev] Pd hangs on exit on macOS In-Reply-To: References: Message-ID: <080425FC-074A-4EBC-A9DF-0151C513990C@gmail.com> A simple follow up: toggling DSP on & off results in Pd freezing in the same manner on my system. Anyone have any insight why Pd might get stuck in a port audio buffer write loop? I'm wondering if this is only on my system (configuration issue), macOS 10.14 (OS deprecation/change), or for all macOS versions (Pd src/compiler issue)? > On Jul 15, 2019, at 12:00 PM, pd-dev-request at lists.iem.at wrote: > > Date: Mon, 15 Jul 2019 00:21:49 +0200 > From: Dan Wilcox > > To: pd-dev > > Subject: [PD-dev] Pd hangs on exit on macOS > Message-ID: <943D4D80-C788-47D5-A617-4B940E4BBB5B at gmail.com > > Content-Type: text/plain; charset="utf-8" > > Is anyone noticing that the Pd core seems to hang on macOS? You can close the GUI but sometimes the "pd" core process spins in the background sucking up CPU or the GUI freezes on exit as well? > > It seems to be spinning in the port audio ring buffer s_audio_paring.c line 130. Both index and rbuf->bufferSize are 0 and it's stuck in the while loop, although this is after sys_close audio should have happened. Maybe it's a thread race condition? I don't remember this happening before macOS 101.4 so I wonder if it's something lower level as there has been the general push towards AudioUnit V3. Ugg. -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch at chnry.net Wed Jul 17 09:23:14 2019 From: ch at chnry.net (cyrille henry) Date: Wed, 17 Jul 2019 09:23:14 +0200 Subject: [PD-dev] How is buffer (block) used in the puredata (internals) In-Reply-To: <0EBFACF7-9935-45AD-9E00-CF181D1F9708@japina.eu> References: <0EBFACF7-9935-45AD-9E00-CF181D1F9708@japina.eu> Message-ID: hello Bostjan, Wow, that would be huge! sorry, I don't understand your question, but I have questions for you... all tilde objects accepts blocks (the source code of this objects are in files starting by d_). They perform a fuction on every elements of a single block. What kind of arm microcontroller are you working on? Do you also plan to work on the hardware, or use a standard board? How can I follow your work? Cheers Cyrille Le 16/07/2019 à 14:59, Japina a écrit : > Hi, > > I am working on the porting puredata diagram to ARM based microcontroller. > > During writing the code some questions popped up. As far as I know there is a default buffer or block with a size of 64 bytes. Sampling frequency is 44.100 Hz, but what I wonder > is how the block is used. > If I have a list of commands - is every command use on the whole block or are all commands used for every element of the block. > > Hopefully it is clear what I am asking. > > Thanks. > > Bostjan > > > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > From porres at gmail.com Fri Jul 19 23:17:39 2019 From: porres at gmail.com (Alexandre Torres Porres) Date: Fri, 19 Jul 2019 18:17:39 -0300 Subject: [PD-dev] issues compiling Pd in macOS mojave In-Reply-To: References: <20190527175024.GB4318@ucsd.edu> Message-ID: Em ter, 28 de mai de 2019 às 07:41, Dan Wilcox escreveu: > Miller's Wish is now integrated in the `updates/0.50` branch on Github. > Running "make app" on my 10.14 system results in a working Pd app. Please > test if you have the time. > damn, it didn't work for me :/ I'm getting this attached instead 10.14.5 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2019-07-19 at 18.16.58.png Type: image/png Size: 127458 bytes Desc: not available URL: From porres at gmail.com Sat Jul 20 22:45:33 2019 From: porres at gmail.com (Alexandre Torres Porres) Date: Sat, 20 Jul 2019 17:45:33 -0300 Subject: [PD-dev] issues compiling Pd in macOS mojave In-Reply-To: References: <20190527175024.GB4318@ucsd.edu> Message-ID: forget about it, now that miller merged and included several new commits, I could build it just fine :) Yay, this [slop~] object seems pretty cool! So does [pdcontrol] Em sex, 19 de jul de 2019 às 18:17, Alexandre Torres Porres < porres at gmail.com> escreveu: > > > Em ter, 28 de mai de 2019 às 07:41, Dan Wilcox > escreveu: > >> Miller's Wish is now integrated in the `updates/0.50` branch on Github. >> Running "make app" on my 10.14 system results in a working Pd app. Please >> test if you have the time. >> > > damn, it didn't work for me :/ > > I'm getting this attached instead > > 10.14.5 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danomatika at gmail.com Sun Jul 21 18:44:36 2019 From: danomatika at gmail.com (Dan Wilcox) Date: Sun, 21 Jul 2019 18:44:36 +0200 Subject: [PD-dev] issues compiling Pd in macOS mojave In-Reply-To: References: <20190527175024.GB4318@ucsd.edu> Message-ID: <2A9BB780-694C-4DBB-8883-EEAA6A02A1AA@gmail.com> In your previous test, you probably forgot to check out the correct branch with the actual changes. They were not yet merged to master. Now that they are, it works. enohp ym morf tnes ----------- Dan Wilcox danomatika.com robotcowboy.com > On Jul 20, 2019, at 10:45 PM, Alexandre Torres Porres wrote: > > I could build it just fine From porres at gmail.com Sun Jul 21 18:58:35 2019 From: porres at gmail.com (Alexandre Torres Porres) Date: Sun, 21 Jul 2019 13:58:35 -0300 Subject: [PD-dev] issues compiling Pd in macOS mojave In-Reply-To: <2A9BB780-694C-4DBB-8883-EEAA6A02A1AA@gmail.com> References: <20190527175024.GB4318@ucsd.edu> <2A9BB780-694C-4DBB-8883-EEAA6A02A1AA@gmail.com> Message-ID: yeah, seems i screwed up somehow, though i was positive i picked 0.50/updates or whatever, but who knows :) anyway, thanks for solving this! cheers Em dom, 21 de jul de 2019 às 13:44, Dan Wilcox escreveu: > In your previous test, you probably forgot to check out the correct branch > with the actual changes. They were not yet merged to master. Now that they > are, it works. > > enohp ym morf tnes > ----------- > Dan Wilcox > danomatika.com > robotcowboy.com > > > > On Jul 20, 2019, at 10:45 PM, Alexandre Torres Porres > wrote: > > > > I could build it just fine > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danomatika at gmail.com Tue Jul 23 23:26:22 2019 From: danomatika at gmail.com (Dan Wilcox) Date: Tue, 23 Jul 2019 23:26:22 +0200 Subject: [PD-dev] Pd hangs on exit on macOS In-Reply-To: <080425FC-074A-4EBC-A9DF-0151C513990C@gmail.com> References: <080425FC-074A-4EBC-A9DF-0151C513990C@gmail.com> Message-ID: <99CCA4AE-ED50-4FB8-8A56-982CBA50F4F8@gmail.com> Since the release cycle is underway, can someone test this on their newer macOS machine? I'm still not sure if there is something wrong on my system or there is an underlying bug in Pd/portaudio. > On Jul 17, 2019, at 2:20 AM, Dan Wilcox wrote: > > A simple follow up: toggling DSP on & off results in Pd freezing in the same manner on my system. > > Anyone have any insight why Pd might get stuck in a port audio buffer write loop? I'm wondering if this is only on my system (configuration issue), macOS 10.14 (OS deprecation/change), or for all macOS versions (Pd src/compiler issue)? > >> On Jul 15, 2019, at 12:00 PM, pd-dev-request at lists.iem.at wrote: >> >> Date: Mon, 15 Jul 2019 00:21:49 +0200 >> From: Dan Wilcox > >> To: pd-dev > >> Subject: [PD-dev] Pd hangs on exit on macOS >> Message-ID: <943D4D80-C788-47D5-A617-4B940E4BBB5B at gmail.com > >> Content-Type: text/plain; charset="utf-8" >> >> Is anyone noticing that the Pd core seems to hang on macOS? You can close the GUI but sometimes the "pd" core process spins in the background sucking up CPU or the GUI freezes on exit as well? >> >> It seems to be spinning in the port audio ring buffer s_audio_paring.c line 130. Both index and rbuf->bufferSize are 0 and it's stuck in the while loop, although this is after sys_close audio should have happened. Maybe it's a thread race condition? I don't remember this happening before macOS 101.4 so I wonder if it's something lower level as there has been the general push towards AudioUnit V3. Ugg. > > -------- > Dan Wilcox > @danomatika > danomatika.com > robotcowboy.com > > > -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From msp at ucsd.edu Wed Jul 24 00:14:44 2019 From: msp at ucsd.edu (Miller Puckette) Date: Tue, 23 Jul 2019 15:14:44 -0700 Subject: [PD-dev] Pd release plans (0.50 August / 0.51 December) Message-ID: <20190723221444.GD16160@ucsd.edu> To Pd dev: I realizd I forgot to make my release plans clear... I'm going to try to get a mainly bug-fix release out in Augist (0.50) in time for Fall classes in the US (idealy Aug 15 to give admins & profs a couple of weeks to get ready for school, which in some places seems to get underway Sept 1-ish. That leaves only enough time to do some polishing, no big new stuff. So I think I should aim to make another release in December to allow time for whatever improvements don't make it in by mid August. My own priority is to try to make zooming apply to data structures. (Way overdue!) cheers Miller From danomatika at gmail.com Wed Jul 24 12:13:27 2019 From: danomatika at gmail.com (Dan Wilcox) Date: Wed, 24 Jul 2019 12:13:27 +0200 Subject: [PD-dev] Pd release plans (0.50 August / 0.51 December) In-Reply-To: References: Message-ID: > To Pd dev: > > I realizd I forgot to make my release plans clear... I'm going to try to get > a mainly bug-fix release out in Augist (0.50) in time for Fall classes in the > US (idealy Aug 15 to give admins & profs a couple of weeks to get ready for > school, which in some places seems to get underway Sept 1-ish. > > That leaves only enough time to do some polishing, no big new stuff. So > I think I should aim to make another release in December to allow time for > whatever improvements don't make it in by mid August. That sounds good. Interested parties can help test in the fall for work which is slated for December. We are, in some ways, polishing the edges off the features and updates in the last few versions anyway. I'd like to propose the net objects update branch for 0.50, but we need to finalize and test it first. If there is not enough time, we can formalize it for 0.51. > My own priority is to try to make zooming apply to data structures. (Way > overdue!) There has been some work in this area: https://github.com/pure-data/pure-data/pull/563 -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfonso.santimone at gmail.com Thu Jul 25 12:11:32 2019 From: alfonso.santimone at gmail.com (alfonso santimone) Date: Thu, 25 Jul 2019 12:11:32 +0200 Subject: [PD-dev] Pd release plans (0.50 August / 0.51 December) In-Reply-To: References: Message-ID: Great! Is double precision planned for 0.50? best a. www.elgallorojorecords.com soundcloud.com/alfonsosantimone www.facebook.com/alfonsosantimone On Wed, Jul 24, 2019 at 12:15 PM Dan Wilcox wrote: > > To Pd dev: > > I realizd I forgot to make my release plans clear... I'm going to try to > get > a mainly bug-fix release out in Augist (0.50) in time for Fall classes in > the > US (idealy Aug 15 to give admins & profs a couple of weeks to get ready for > school, which in some places seems to get underway Sept 1-ish. > > That leaves only enough time to do some polishing, no big new stuff. So > I think I should aim to make another release in December to allow time for > whatever improvements don't make it in by mid August. > > > That sounds good. Interested parties can help test in the fall for work > which is slated for December. We are, in some ways, polishing the edges off > the features and updates in the last few versions anyway. > > I'd like to propose the net objects update branch for 0.50, but we need to > finalize and test it first. If there is not enough time, we can formalize > it for 0.51. > > My own priority is to try to make zooming apply to data structures. (Way > overdue!) > > > There has been some work in this area: > https://github.com/pure-data/pure-data/pull/563 > > -------- > Dan Wilcox > @danomatika > danomatika.com > robotcowboy.com > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From porres at gmail.com Sun Jul 28 11:18:33 2019 From: porres at gmail.com (Alexandre Torres Porres) Date: Sun, 28 Jul 2019 06:18:33 -0300 Subject: [PD-dev] Pd release plans (0.50 August / 0.51 December) In-Reply-To: References: Message-ID: 0.50 is a special release mark (halfway through 1.0!) My gift to the Pd community is a painstaking revision of the documentation, just finished it, hope it makes into the next release https://github.com/pure-data/pure-data/pull/608 It's mostly just reorganizing, realigning cords, make sure wires don't cross, standardize font size and a few other stuff/fixes. cheers Em qui, 25 de jul de 2019 às 07:20, alfonso santimone < alfonso.santimone at gmail.com> escreveu: > Great! Is double precision planned for 0.50? > best > a. > www.elgallorojorecords.com > soundcloud.com/alfonsosantimone > www.facebook.com/alfonsosantimone > > > On Wed, Jul 24, 2019 at 12:15 PM Dan Wilcox wrote: > >> >> To Pd dev: >> >> I realizd I forgot to make my release plans clear... I'm going to try to >> get >> a mainly bug-fix release out in Augist (0.50) in time for Fall classes in >> the >> US (idealy Aug 15 to give admins & profs a couple of weeks to get ready >> for >> school, which in some places seems to get underway Sept 1-ish. >> >> That leaves only enough time to do some polishing, no big new stuff. So >> I think I should aim to make another release in December to allow time for >> whatever improvements don't make it in by mid August. >> >> >> That sounds good. Interested parties can help test in the fall for work >> which is slated for December. We are, in some ways, polishing the edges off >> the features and updates in the last few versions anyway. >> >> I'd like to propose the net objects update branch for 0.50, but we need >> to finalize and test it first. If there is not enough time, we can >> formalize it for 0.51. >> >> My own priority is to try to make zooming apply to data structures. (Way >> overdue!) >> >> >> There has been some work in this area: >> https://github.com/pure-data/pure-data/pull/563 >> >> -------- >> Dan Wilcox >> @danomatika >> danomatika.com >> robotcowboy.com >> >> >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev at lists.iem.at >> https://lists.puredata.info/listinfo/pd-dev >> > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From x37v.alex at gmail.com Tue Jul 30 17:49:36 2019 From: x37v.alex at gmail.com (x nor) Date: Tue, 30 Jul 2019 08:49:36 -0700 Subject: [PD-dev] Pure Rust Pure Data Externals Message-ID: This is very much still a work in progress, but recently I've been working on writing pure data externals in Rust and I figured I'd share: https://github.com/x37v/puredata-rust Rust can create dynamic libraries that can be loaded in C based projects without the need for any external build tools, building simply uses rusts `cargo` build system (and package manager). I've setup the automatic binding to `m_pd.h` (puredata-sys), some ease of use classes for creating externals, and a macro that generates a bunch of boiler plate code so you don't have to. With this I've created Rust versions of the 4 example externals from the HOWTO: https://github.com/pure-data/externals-howto https://github.com/x37v/puredata-rust/tree/develop/examples With the help of a macro and attributes, beyond the dependency setup, this is all you need to write a signal external: https://github.com/x37v/puredata-rust/blob/develop/examples/xfade/src/lib.rs or a control external: https://github.com/x37v/puredata-rust/blob/develop/examples/complex_counter/src/lib.rs Anyways, I figured I'd share in case anyone else is interested, maybe wants to contribute or just use it themselves. I'm tired/done with c/c++ and Rust has presented itself as a great alternative for a lot of situations. It was fun to discover that I can generate pure data externals with Rust and its build system. --Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From osamupang at gmail.com Wed Jul 31 10:31:05 2019 From: osamupang at gmail.com (Tsz Kiu Pang) Date: Wed, 31 Jul 2019 18:31:05 +1000 Subject: [PD-dev] a new object/functionality similar to max's [if] Message-ID: Hi all, Alexandre has recently requested a new object/functionality similar to max's [if] on github: https://github.com/pure-data/pure-data/issues/663 So I was looking it for a while, and came up with a list of things that have to be modified/added in order to accommodate the new object, as discussed on github. I guess the main question is that I feel like this is quite a big change to the expr family since no class has been added to it for the past 19/20 years, so I am just wondering whether my approach (adding a new class to the [expr], [expr~], [fexpr~] mix) is correct, and whether this functionality is something that we need. I will probably put in a pull request soon if there is no objection... Kind regards, TK -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbeezez at gmail.com Wed Jul 31 11:06:17 2019 From: jbeezez at gmail.com (Julian Brooks) Date: Wed, 31 Jul 2019 10:06:17 +0100 Subject: [PD-dev] Pure Rust Pure Data Externals In-Reply-To: References: Message-ID: Nice work Alex, Look fwd to digging through these on my return from holidays. All the best, Julian On Tue, 30 Jul 2019 at 16:57, x nor wrote: > This is very much still a work in progress, but recently I've been working > on writing pure data externals in Rust and I figured I'd share: > > https://github.com/x37v/puredata-rust > > Rust can create dynamic libraries that can be loaded in C based projects > without the need for any external build tools, building simply uses rusts > `cargo` build system (and package manager). > I've setup the automatic binding to `m_pd.h` (puredata-sys), some ease of > use classes for creating externals, and a macro that generates a bunch of > boiler plate code so you don't have to. > > With this I've created Rust versions of the 4 example externals from the > HOWTO: > https://github.com/pure-data/externals-howto > https://github.com/x37v/puredata-rust/tree/develop/examples > > With the help of a macro and attributes, beyond the dependency setup, this > is all you need to write a signal external: > > https://github.com/x37v/puredata-rust/blob/develop/examples/xfade/src/lib.rs > or a control external: > > https://github.com/x37v/puredata-rust/blob/develop/examples/complex_counter/src/lib.rs > > Anyways, I figured I'd share in case anyone else is interested, maybe > wants to contribute or just use it themselves. > I'm tired/done with c/c++ and Rust has presented itself as a great > alternative for a lot of situations. > It was fun to discover that I can generate pure data externals with Rust > and its build system. > > --Alex > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfbrandi at outlook.com Wed Jul 31 13:46:37 2019 From: mfbrandi at outlook.com (matthew brandi) Date: Wed, 31 Jul 2019 11:46:37 +0000 Subject: [PD-dev] a new object/functionality similar to max's [if] In-Reply-To: References: Message-ID: On 31/07/2019 09:31, Tsz Kiu Pang wrote: > Alexandre has recently requested a new object/functionality similar > to max's [if] … I am just wondering whether my approach (adding a > new class to the [expr], [expr~], [fexpr~] mix) is correct, and > whether this functionality is something that we need. I will > probably put in a pull request soon if there is no objection Dear TK and Alexandre I have no objection, but I do have a couple of naïve questions: [a] In the message case, I am struggling to see the point, as all you need to do is control a [spigot] with the truth value of the test. Or you can assign the false condition a value unused in the true case (if there is any such) and feed the output to [route] or [select]. Or … well doubtless there are many — and likely better — ways to skin this cat. Is it just for convenience, then, or am I missing something? [b] If a parallel audio case is envisaged, what would it do? Best m -- matthew brandi | 020 8882 4616 -------------- next part -------------- A non-text attachment was scrubbed... Name: 2019-07-31_if-then_example.pd Type: text/x-puredata Size: 651 bytes Desc: 2019-07-31_if-then_example.pd URL: From porres at gmail.com Wed Jul 31 18:25:32 2019 From: porres at gmail.com (Alexandre Torres Porres) Date: Wed, 31 Jul 2019 13:25:32 -0300 Subject: [PD-dev] a new object/functionality similar to max's [if] In-Reply-To: References: Message-ID: Em qua, 31 de jul de 2019 às 08:46, matthew brandi escreveu: > On 31/07/2019 09:31, Tsz Kiu Pang wrote: > > Alexandre has recently requested a new object/functionality similar > > to max's [if] … I am just wondering whether my approach (adding a > > new class to the [expr], [expr~], [fexpr~] mix) is correct, and > > whether this functionality is something that we need. I will > > probably put in a pull request soon if there is no objection > > > Dear TK and Alexandre > > I have no objection, but I do have a couple of naïve questions: > > [a] In the message case, I am struggling to see the point > yup, the point is convenience, and I'd say part of the convenience is that all the ground is already laid out. In fact, my firs suggestion was to add a new "ifthen" function to the expr family, but got an objection that closed the request https://github.com/pure-data/pure-data/issues/662 > [b] If a parallel audio case is envisaged, what would it do? > there'd no [if~] object -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfbrandi at outlook.com Wed Jul 31 18:50:09 2019 From: mfbrandi at outlook.com (matthew brandi) Date: Wed, 31 Jul 2019 16:50:09 +0000 Subject: [PD-dev] a new object/functionality similar to max's [if] In-Reply-To: References: Message-ID: On 31/07/2019 17:25, Alexandre Torres Porres wrote: yup, the point is convenience, and I'd say part of the convenience is that all the ground is already laid out. Thanks for the clarification. Best m -- matthew brandi -------------- next part -------------- An HTML attachment was scrubbed... URL: From x37v.alex at gmail.com Wed Jul 31 20:06:26 2019 From: x37v.alex at gmail.com (x nor) Date: Wed, 31 Jul 2019 11:06:26 -0700 Subject: [PD-dev] Pure Rust Pure Data Externals In-Reply-To: References: Message-ID: Thanks Julian, Hopefully it will be even more full featured at that point! -Alex On Wed, Jul 31, 2019 at 2:06 AM Julian Brooks wrote: > Nice work Alex, > > Look fwd to digging through these on my return from holidays. > > All the best, > > Julian > > On Tue, 30 Jul 2019 at 16:57, x nor wrote: > >> This is very much still a work in progress, but recently I've been >> working on writing pure data externals in Rust and I figured I'd share: >> >> https://github.com/x37v/puredata-rust >> >> Rust can create dynamic libraries that can be loaded in C based projects >> without the need for any external build tools, building simply uses rusts >> `cargo` build system (and package manager). >> I've setup the automatic binding to `m_pd.h` (puredata-sys), some ease of >> use classes for creating externals, and a macro that generates a bunch of >> boiler plate code so you don't have to. >> >> With this I've created Rust versions of the 4 example externals from the >> HOWTO: >> https://github.com/pure-data/externals-howto >> https://github.com/x37v/puredata-rust/tree/develop/examples >> >> With the help of a macro and attributes, beyond the dependency setup, >> this is all you need to write a signal external: >> >> https://github.com/x37v/puredata-rust/blob/develop/examples/xfade/src/lib.rs >> or a control external: >> >> https://github.com/x37v/puredata-rust/blob/develop/examples/complex_counter/src/lib.rs >> >> Anyways, I figured I'd share in case anyone else is interested, maybe >> wants to contribute or just use it themselves. >> I'm tired/done with c/c++ and Rust has presented itself as a great >> alternative for a lot of situations. >> It was fun to discover that I can generate pure data externals with Rust >> and its build system. >> >> --Alex >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev at lists.iem.at >> https://lists.puredata.info/listinfo/pd-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msp at ucsd.edu Wed Jul 31 23:54:05 2019 From: msp at ucsd.edu (Miller Puckette) Date: Wed, 31 Jul 2019 14:54:05 -0700 Subject: [PD-dev] Pd hangs on exit on macOS In-Reply-To: <99CCA4AE-ED50-4FB8-8A56-982CBA50F4F8@gmail.com> References: <080425FC-074A-4EBC-A9DF-0151C513990C@gmail.com> <99CCA4AE-ED50-4FB8-8A56-982CBA50F4F8@gmail.com> Message-ID: <20190731215405.GA14421@ucsd.edu> Turns out the department here has a 10.14 machine I can squat on. I'll go try things out and see what I can see. I guess this can be mad to happen just using the mac's internal audio device, yes? cheers M On Tue, Jul 23, 2019 at 11:26:22PM +0200, Dan Wilcox wrote: > Since the release cycle is underway, can someone test this on their newer macOS machine? I'm still not sure if there is something wrong on my system or there is an underlying bug in Pd/portaudio. > > > On Jul 17, 2019, at 2:20 AM, Dan Wilcox wrote: > > > > A simple follow up: toggling DSP on & off results in Pd freezing in the same manner on my system. > > > > Anyone have any insight why Pd might get stuck in a port audio buffer write loop? I'm wondering if this is only on my system (configuration issue), macOS 10.14 (OS deprecation/change), or for all macOS versions (Pd src/compiler issue)? > > > >> On Jul 15, 2019, at 12:00 PM, pd-dev-request at lists.iem.at wrote: > >> > >> Date: Mon, 15 Jul 2019 00:21:49 +0200 > >> From: Dan Wilcox > > >> To: pd-dev > > >> Subject: [PD-dev] Pd hangs on exit on macOS > >> Message-ID: <943D4D80-C788-47D5-A617-4B940E4BBB5B at gmail.com > > >> Content-Type: text/plain; charset="utf-8" > >> > >> Is anyone noticing that the Pd core seems to hang on macOS? You can close the GUI but sometimes the "pd" core process spins in the background sucking up CPU or the GUI freezes on exit as well? > >> > >> It seems to be spinning in the port audio ring buffer s_audio_paring.c line 130. Both index and rbuf->bufferSize are 0 and it's stuck in the while loop, although this is after sys_close audio should have happened. Maybe it's a thread race condition? I don't remember this happening before macOS 101.4 so I wonder if it's something lower level as there has been the general push towards AudioUnit V3. Ugg. > > > > -------- > > Dan Wilcox > > @danomatika > > danomatika.com > > robotcowboy.com > > > > > > > > -------- > Dan Wilcox > @danomatika > danomatika.com > robotcowboy.com > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev at lists.iem.at > https://lists.puredata.info/listinfo/pd-dev