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
Em dom, 30 de jun de 2019 às 02:52, Miller Puckette msp@ucsd.edu escreveu:
To pd dev -
I'm struggling to finish the design of a slew-limiting low-pass filter (slop~) to add to Pd vanilla
Yay!
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).
Yay! x 2
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).
This is what I don't get. How would you "fix Pd" to open URLs? With the new [pdcontrol] object?
cheers
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).
This is what I don't get. How would you "fix Pd" to open URLs? With the new [pdcontrol] object?
cheers
Yep. At the moment, I'm thinking of having it take an "open" message to open a file in the OS, a "fetch" or "httpget" or something to open a URL, and a "system" to run a program asynchronously and return its standard output as Pd messages. Maybe also a message to open a program and keep it open so that Pd can send it stuff as input and collect the output. All this would be kicked up to teh Tcl/Tk layer, so none of it would be "real-time".
Also high time to be able to get the patch's containing directory using only Pd vanilla. I think there are 10 or 20 other things this object should eventually do!
cheers M
and a "system" to run a program asynchronously and return its standard output as Pd messages. Maybe also a message to open a program and keep it open so that Pd can send it stuff as input and collect the output. All this would be kicked up to teh Tcl/Tk layer, so none of it would be "real-time".
Also high time to be able to get the patch's containing directory using only Pd vanilla. I think there are 10 or 20 other things this object should eventually do!
this sounds very promising :-)
Christof
Gesendet: Sonntag, 30. Juni 2019 um 18:24 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Alexandre Torres Porres" porres@gmail.com Cc: pd-dev@iem.at Betreff: Re: [PD-dev] formatting HTML doc in Pd distro?
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).
This is what I don't get. How would you "fix Pd" to open URLs? With the new [pdcontrol] object?
cheers
Yep. At the moment, I'm thinking of having it take an "open" message to open a file in the OS, a "fetch" or "httpget" or something to open a URL, and a "system" to run a program asynchronously and return its standard output as Pd messages. Maybe also a message to open a program and keep it open so that Pd can send it stuff as input and collect the output. All this would be kicked up to teh Tcl/Tk layer, so none of it would be "real-time".
Also high time to be able to get the patch's containing directory using only Pd vanilla. I think there are 10 or 20 other things this object should eventually do!
cheers M
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 6/30/19 6:05 AM, Miller Puckette wrote:
Any advice would be very helpful!
personally, i'd go for markdown as the source format and use pandoc to compile it to the final documentation.
reasons: - the source document is human readable (with a somewhat meaningful visual layout, as opposed to LaTeX) - can be compiled to LaTeX (and can include LaTeX-snippets, e.g. for complicated formulae).
thus, the repository *could* only contain the source-code of the documentation (md), which would still be a meaningful (although not as nicely laid out) documentation for the power-user who uses a git clone. the documentation would still need to be compiled during the release phase though (which i don't see as a big problem; i'd make this step optional though).
But I don't think it's a good idea to put latex compilation in the Pd compile chain,
why?
Make Pd able to open files in the native OS (maybe via a new "pdcontrol" object that would issue system commands
afaik, the way to "open files" (using the default application, which is what we really want here), is highly system specific. e.g. cf the `::pd_menucommands::menu_openfile` (in tcl/pd_menucommands.tcl) which (kind of) implements this already, and which i would probably use *as is*.
gfmdsar IOhannes
On Sun, Jun 30, 2019 at 08:30:40PM +0200, IOhannes m zm??lnig wrote:
On 6/30/19 6:05 AM, Miller Puckette wrote:
Any advice would be very helpful!
personally, i'd go for markdown as the source format and use pandoc to compile it to the final documentation.
reasons:
- the source document is human readable (with a somewhat meaningful
visual layout, as opposed to LaTeX)
- can be compiled to LaTeX (and can include LaTeX-snippets, e.g. for
complicated formulae).
thus, the repository *could* only contain the source-code of the documentation (md), which would still be a meaningful (although not as nicely laid out) documentation for the power-user who uses a git clone. the documentation would still need to be compiled during the release phase though (which i don't see as a big problem; i'd make this step optional though).
Cool, I'll investigate this. It might be cleaner than latex2html. Meanwhile, the original reason I made the "manual" in HTML was so that it could be easy to browse. Now that PDF readers are universally available and PDFs can contain links, it might be better to distribute the doc in PDF. This would be possible either via latex or (I guess) pandoc.
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.
Make Pd able to open files in the native OS (maybe via a new "pdcontrol" object that would issue system commands
afaik, the way to "open files" (using the default application, which is what we really want here), is highly system specific. e.g. cf the `::pd_menucommands::menu_openfile` (in tcl/pd_menucommands.tcl) which (kind of) implements this already, and which i would probably use *as is*.
Yep. Just needs to be available from within Pd vanilla :)
gfmdsar IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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
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.
*************************************
<!DOCTYPE html> <html> <head> </head> <body>
<h1> big heading </h1> <h2> h2 smaller heading </h2>
<p> paragraph
<p> paragraph 2
</body> </html>
*********************************
Having the ability to open local or remote URLs is a total Pd enhancer.
:)
Mensaje telepatico asistido por maquinas.
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.
<!DOCTYPE html>
<html> <head> </head> <body>
<h1> big heading </h1> <h2> h2 smaller heading </h2>
<p> paragraph
<p> paragraph 2
</body> </html>
Having the ability to open local or remote URLs?? is a total Pd enhancer.
:)
Mensaje telepatico asistido por maquinas.
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.
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.
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" zmoelnig@iem.at An: pd-dev@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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 christof.ressi@gmx.at 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" zmoelnig@iem.at An: pd-dev@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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#0360548f7e52d1d73a26464df08c34beabfea9... https://wiki.tcl-lang.org/page/Canvas+to+SVG
Christof
Gesendet: Montag, 01. Juli 2019 um 12:53 Uhr Von: "Giulio Moro" giuliomoro@yahoo.it An: pd-dev pd-dev@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at 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 christof.ressi@gmx.at 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" zmoelnig@iem.at An: pd-dev@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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
ha, thanks! have to try it out!
Gesendet: Montag, 01. Juli 2019 um 13:37 Uhr Von: "IOhannes m zmoelnig" zmoelnig@iem.at An: pd-dev@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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-fileuti...
On Monday, 1 July 2019, 12:37:48 BST, IOhannes m zmoelnig zmoelnig@iem.at 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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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
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.
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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
If the only show stopper for HTML is "typeset equations in native HTML" there's a workaround:
https://www.mathjax.org/https://www.mathjax.org/#gettingstarted
https://github.com/mathjax/MathJax
the only gotcha is that the "typeset equations" wont render on an offline browser.
Works by just including :
<script src='https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.5/latest.js?config=TeX-MML-AM_CHTML' async></script>
in the <head> 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:
'''''''
<!DOCTYPE html> <html> <head> <script src='https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.5/latest.js?config=TeX-MML-AM_CHTML' async></script>
</head> <body>
<h1>big heading </h1> <h2> h2 smaller heading </h2>
<p> paragraph ... when ( x < y ) we have ...
<p> paragraph 2 .. [ \sum a b ]
<p> paragraph 3 .. (\sum a b ) </body> </html>
''''''''
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@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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
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 abonnements@revolwear.com 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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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
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 msp@ucsd.edu 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.
<!DOCTYPE html>
<html> <head> </head> <body>
<h1> big heading </h1> <h2> h2 smaller heading </h2>
<p> paragraph
<p> paragraph 2
</body> </html>
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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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" msp@ucsd.edu 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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Alexandre Torres Porres -
Christof Ressi -
Giulio Moro -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Lucas Cordiviola -
Matt Barber -
Max -
me.grimm -
Miller Puckette -
William Huston