From cuinjune at gmail.com Thu Jan 14 03:41:17 2021 From: cuinjune at gmail.com (Zack Lee) Date: Thu, 14 Jan 2021 03:41:17 -0500 Subject: [L2Ork-dev] PdWebParty v0.0.2 released Message-ID: PdWebParty now supports Sliders(vsl, hsl) and Radio Buttons(vradio, hradio). Changes: - Added Sliders(vsl, hsl) and Radio Buttons(vradio, hradio). - Supports reading hex color from the patch content or receiver. - Changed comment font size to match Pd-0.51-3 or higher. You can try the app from https://pdwebparty.herokuapp.com/ For more information, visit https://github.com/cuinjune/PdWebParty Best, Zack -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc at hacklava.net Sun Jan 24 07:38:12 2021 From: marc at hacklava.net (=?UTF-8?Q?Marc_Lavall=c3=a9e?=) Date: Sun, 24 Jan 2021 07:38:12 -0500 Subject: [L2Ork-dev] json? Message-ID: <06f01ff3-bd87-04ec-68bf-6e79f15e9295@hacklava.net> Hello, I've not use PD (therefore Purr-Data) for a long time, and now I need to parse a JSON string. Is there something like https://github.com/residuum/PuRestJson for Purr-Data? Or is Javascript available as a scripting language in Purr-Data (to build externals or abstractions)? Marc From marc at hacklava.net Sun Jan 24 10:06:18 2021 From: marc at hacklava.net (=?UTF-8?Q?Marc_Lavall=c3=a9e?=) Date: Sun, 24 Jan 2021 10:06:18 -0500 Subject: [L2Ork-dev] json? In-Reply-To: <06f01ff3-bd87-04ec-68bf-6e79f15e9295@hacklava.net> References: <06f01ff3-bd87-04ec-68bf-6e79f15e9295@hacklava.net> Message-ID: <19a14750-03d8-bec4-d6a2-2393dc5670f8@hacklava.net> Sadly for now I can't use Purr-Data because it doesn't seem to include an easy method to add and load externals. Maybe I don't understand something... Back to Pd Vanilla (0.50.2 from Ubuntu Studio); I installed Pd with all available external packages, all of them now living under /usr/lib/pd/extra in their own sub-folders, including the purest-json library. When I started Pd for the first time it proposed to create a user folder for patches and externals; it created a $HOME/Documents/Pd folder with en empty externals sub-folder. It also created : - a $HOME/.pdsettings file that includes a path1 entry (with $HOME/Documents/Pd/externals) - a $HOME/.config/Pd/org.puredata.pd.pd-gui folder with dekenpath.conf and docspath.conf I tried to add /usr/lib/pd/extra as a second path for externals, but it did not work because most (if not all) external are in subfolders... There's 96 items in /usr/lib/pd/extra (most of them are folders, some are symlinks), so to get access to all installed libraries I would have to add as many entries into Pd paths dialog? I refuse!! My quick and dirty solution: cd $HOME/Documents/Pd/externals find /usr/lib/pd/extra/ -type f -name "*.pd_linux" -exec ln -sf "{}" . \; It works! But frankly, in terms of usability, it's a mess, enough to incite most lambda users to prefer Max/MSP. I hoped that Purr-Data was a better alternative to Pd Vanilla. I wanted to use it in a workshop for people bringing their laptop running either Ubuntu, OSX or Windows. So if there's something I'm missing, any help would be appreciated. Marc Le 21-01-24 à 07 h 38, Marc Lavallée a écrit : > Hello, > > I've not use PD (therefore Purr-Data) for a long time, and now I need > to parse a JSON string. > > Is there something like https://github.com/residuum/PuRestJson for > Purr-Data? > > Or is Javascript available as a scripting language in Purr-Data (to > build externals or abstractions)? > > Marc > From jon.w.wilkes at gmail.com Sun Jan 24 11:22:50 2021 From: jon.w.wilkes at gmail.com (Jonathan Wilkes) Date: Sun, 24 Jan 2021 11:22:50 -0500 Subject: [L2Ork-dev] json? In-Reply-To: <19a14750-03d8-bec4-d6a2-2393dc5670f8@hacklava.net> References: <06f01ff3-bd87-04ec-68bf-6e79f15e9295@hacklava.net> <19a14750-03d8-bec4-d6a2-2393dc5670f8@hacklava.net> Message-ID: > There's 96 items in /usr/lib/pd/extra (most of them are folders, some are symlinks), so to get access to all installed libraries I would have to add as many entries into Pd paths dialog? 1. If you want to be able to load those libraries using [declare], just make sure you have /usr/lib/pd/extra in the startup path. 2. If you want to be able to load those libraries as [libname/objname]-- which I would recommend as good practice-- do the same as step 1. 3. If you really want to load every single library in /usr/lib/pd/extra automatically at startup, then you absolutely must add every one of those paths and libs in the way you've stated. That's a really bad practice-- it increases startup time for no gain, and probably creates all kinds of namespace clashes depending on the startup order you specified. (You're also betting that none of those externals have a crasher or memory error in the setup routine-- as someone who has tried to automate testing for Pd externals over the years I certainly wouldn't take that bet.) -Jonathan From marc at hacklava.net Sun Jan 24 11:29:39 2021 From: marc at hacklava.net (=?UTF-8?Q?Marc_Lavall=c3=a9e?=) Date: Sun, 24 Jan 2021 11:29:39 -0500 Subject: [L2Ork-dev] json? In-Reply-To: References: <06f01ff3-bd87-04ec-68bf-6e79f15e9295@hacklava.net> <19a14750-03d8-bec4-d6a2-2393dc5670f8@hacklava.net> Message-ID: Hi Jonathan, Thanks for the precisions. I feel like a Pd n00b again; so basically nothing really changed, and there's good reasons. So I'll create a carefully crafted $HOME/.pdsettings Marc Le 21-01-24 à 11 h 22, Jonathan Wilkes a écrit : >> There's 96 items in /usr/lib/pd/extra (most of them are folders, some > are symlinks), so to get access to all installed libraries I would have > to add as many entries into Pd paths dialog? > > 1. If you want to be able to load those libraries using [declare], > just make sure you have /usr/lib/pd/extra in the startup path. > > 2. If you want to be able to load those libraries as > [libname/objname]-- which I would recommend as good practice-- do the > same as step 1. > > 3. If you really want to load every single library in > /usr/lib/pd/extra automatically at startup, then you absolutely must > add every one of those paths and libs in the way you've stated. That's > a really bad practice-- it increases startup time for no gain, and > probably creates all kinds of namespace clashes depending on the > startup order you specified. (You're also betting that none of those > externals have a crasher or memory error in the setup routine-- as > someone who has tried to automate testing for Pd externals over the > years I certainly wouldn't take that bet.) > > -Jonathan > _______________________________________________ > L2Ork-dev mailing list > L2Ork-dev at disis.music.vt.edu > https://disis.music.vt.edu/listinfo/l2ork-dev From jon.w.wilkes at gmail.com Sun Jan 24 12:38:38 2021 From: jon.w.wilkes at gmail.com (Jonathan Wilkes) Date: Sun, 24 Jan 2021 12:38:38 -0500 Subject: [L2Ork-dev] json? In-Reply-To: References: <06f01ff3-bd87-04ec-68bf-6e79f15e9295@hacklava.net> <19a14750-03d8-bec4-d6a2-2393dc5670f8@hacklava.net> Message-ID: On Sun, Jan 24, 2021 at 11:30 AM Marc Lavallée wrote: > > Hi Jonathan, > > Thanks for the precisions. > > I feel like a Pd n00b again; so basically nothing really changed, and > there's good reasons. It's a bit complicated because Pd-extended autoloaded a ton of libraries. And there are *still* a lot of users who not only rely on old patches built with Pd-extended but even *still* download and install Pd-extended to make new patches! For that reason, we autoload the old Pd-extended patches at startup so that all those patches will continue to work by default. There's a special "libdir" loader we use that will just add the path for a given library rather than running all the setup routines. That reduces startup time and means we don't need to set a path for every Pd-extended lib. The cost is that this encourages users to rely on unprefixed external names. An object named "foo~" may appear in many different libraries, so the user is depending on Pd-extended load order to load the correct one. Worse, they probably don't even know that there are multiple, incompatible versions. They may even assume it is a core object and be surprised when their patch that worked in Pd-extended doesn't work in Vanilla (and have no idea which library to download to install it). You can see the Vanilla mailing list has been littered with questions over the years about which library holds which names, or confusion about core objects, etc. This is the reason for that. In short, we're trying to support old patches from an old, flawed system. And we inescapably inherit the same namespace clash problems for those autoloaded Pd-extended libraries by doing that. (Also notice, that we don't autoload *every* library we ship. Only the ones that autoloaded with Pd-extended.) So if you're not trying to maintain compatibility with an old, flawed system, I would recommend avoiding that autoloading pattern. You'll generate the same problems I mentioned above with no benefits. > > So I'll create a carefully crafted $HOME/.pdsettings Here's a tip-- when you right-click on an object and choose "Help", the title bar for the help patch should show the full path to the external. If you run into any problems, first check if you can instantiate the object. Then right click "Help" and check the path to make sure you're loading the correct one. The most recurring problem I've seen is that someone is loading a different version of an external than they think they are loading. For sanity, you can navigate to the directory that holds an external binary and start with "-noprefs" and "-nostdpath" flags. Now if you try to instantiate the binary it will *only* load from that directory. -Jonathan > > Marc > > Le 21-01-24 à 11 h 22, Jonathan Wilkes a écrit : > >> There's 96 items in /usr/lib/pd/extra (most of them are folders, some > > are symlinks), so to get access to all installed libraries I would have > > to add as many entries into Pd paths dialog? > > > > 1. If you want to be able to load those libraries using [declare], > > just make sure you have /usr/lib/pd/extra in the startup path. > > > > 2. If you want to be able to load those libraries as > > [libname/objname]-- which I would recommend as good practice-- do the > > same as step 1. > > > > 3. If you really want to load every single library in > > /usr/lib/pd/extra automatically at startup, then you absolutely must > > add every one of those paths and libs in the way you've stated. That's > > a really bad practice-- it increases startup time for no gain, and > > probably creates all kinds of namespace clashes depending on the > > startup order you specified. (You're also betting that none of those > > externals have a crasher or memory error in the setup routine-- as > > someone who has tried to automate testing for Pd externals over the > > years I certainly wouldn't take that bet.) > > > > -Jonathan > > _______________________________________________ > > L2Ork-dev mailing list > > L2Ork-dev at disis.music.vt.edu > > https://disis.music.vt.edu/listinfo/l2ork-dev > _______________________________________________ > L2Ork-dev mailing list > L2Ork-dev at disis.music.vt.edu > https://disis.music.vt.edu/listinfo/l2ork-dev From marc at hacklava.net Sun Jan 24 16:51:26 2021 From: marc at hacklava.net (=?UTF-8?Q?Marc_Lavall=c3=a9e?=) Date: Sun, 24 Jan 2021 16:51:26 -0500 Subject: [L2Ork-dev] json? In-Reply-To: References: <06f01ff3-bd87-04ec-68bf-6e79f15e9295@hacklava.net> <19a14750-03d8-bec4-d6a2-2393dc5670f8@hacklava.net> Message-ID: Le 21-01-24 à 12 h 38, Jonathan Wilkes a écrit : >> So I'll create a carefully crafted $HOME/.pdsettings > Here's a tip-- when you right-click on an object and choose "Help", > the title bar for the help patch should show the full path to the > external. > > If you run into any problems, first check if you can instantiate the > object. Then right click "Help" and check the path to make sure you're > loading the correct one. The most recurring problem I've seen is that > someone is loading a different version of an external than they think > they are loading. > > For sanity, you can navigate to the directory that holds an external > binary and start with "-noprefs" and "-nostdpath" flags. Now if you > try to instantiate the binary it will *only* load from that directory. > > -Jonathan Thanks for the tip, it will help with both Pd Vanilla and Purr-Data. I will build simple patches, not large projects, and once I'll know which extensions I need, I'll load them via a dedicated config. I was hoping to manage a large json file, but it'd be much better to do it from some other software. I was planning to use pyext (as I did in 2003), but sadly the latest version is not built with python3. I was also hoping to use the Purr-Data GUI like a web browser with HTML5, WebGL and all the rest, but I'm not sure it's possible. Marc From jon.w.wilkes at gmail.com Sun Jan 24 18:09:05 2021 From: jon.w.wilkes at gmail.com (Jonathan Wilkes) Date: Sun, 24 Jan 2021 18:09:05 -0500 Subject: [L2Ork-dev] json? In-Reply-To: References: <06f01ff3-bd87-04ec-68bf-6e79f15e9295@hacklava.net> <19a14750-03d8-bec4-d6a2-2393dc5670f8@hacklava.net> Message-ID: On Sun, Jan 24, 2021 at 4:51 PM Marc Lavallée wrote: > > Le 21-01-24 à 12 h 38, Jonathan Wilkes a écrit : > > >> So I'll create a carefully crafted $HOME/.pdsettings > > Here's a tip-- when you right-click on an object and choose "Help", > > the title bar for the help patch should show the full path to the > > external. > > > > If you run into any problems, first check if you can instantiate the > > object. Then right click "Help" and check the path to make sure you're > > loading the correct one. The most recurring problem I've seen is that > > someone is loading a different version of an external than they think > > they are loading. > > > > For sanity, you can navigate to the directory that holds an external > > binary and start with "-noprefs" and "-nostdpath" flags. Now if you > > try to instantiate the binary it will *only* load from that directory. > > > > -Jonathan > > Thanks for the tip, it will help with both Pd Vanilla and Purr-Data. > > I will build simple patches, not large projects, and once I'll know > which extensions I need, I'll load them via a dedicated config. > > I was hoping to manage a large json file, but it'd be much better to do > it from some other software. I was planning to use pyext (as I did in > 2003), but sadly the latest version is not built with python3. > > I was also hoping to use the Purr-Data GUI like a web browser with > HTML5, WebGL and all the rest, but I'm not sure it's possible. You can do that manually by going to "Help" and choosing "open DevTools". That will give you a console from which you can open a new window with whatever HTML you want. I don't have a menu option to open an html page, but it probably wouldn't be hard to add that. Anyway, in your web page you can just do a `pdgui = require("pdgui.js")` to use the little Purr Data gui node.js singleton context. To send messages use pdgui.pdsend("blah", "blah", blah"). To post, use pdgui.post("blah"). Unfortunately, Chromium tries to make untold numbers of random connections to the internet. So in Purr Data I had to block it completely and rely on node.js to send and receive between GUI<-->Pd. So if you want your html page to have net access (or if you want to load a page from the web), you have to go in to Purr Data's package.json and remove the proxy command in "--chromium-args" entry that blocks Chromium from chattering. (The package.json is in the same directory as pdgui.js, pd_canvas.js, etc.) Best, Jonathan > > Marc > > _______________________________________________ > L2Ork-dev mailing list > L2Ork-dev at disis.music.vt.edu > https://disis.music.vt.edu/listinfo/l2ork-dev From marc at hacklava.net Sun Jan 24 17:55:38 2021 From: marc at hacklava.net (=?UTF-8?Q?Marc_Lavall=c3=a9e?=) Date: Sun, 24 Jan 2021 17:55:38 -0500 Subject: [L2Ork-dev] json? In-Reply-To: References: <06f01ff3-bd87-04ec-68bf-6e79f15e9295@hacklava.net> <19a14750-03d8-bec4-d6a2-2393dc5670f8@hacklava.net> Message-ID: <684ac84e-dc66-21bf-d973-9d8f8414f775@hacklava.net> Le 21-01-24 à 18 h 09, Jonathan Wilkes a écrit : > Unfortunately, Chromium tries to make untold numbers of random > connections to the internet. So in Purr Data I had to block it > completely and rely on node.js to send and receive between GUI<-->Pd. > So if you want your html page to have net access (or if you want to > load a page from the web), you have to go in to Purr Data's > package.json and remove the proxy command in "--chromium-args" entry > that blocks Chromium from chattering. (The package.json is in the same > directory as pdgui.js, pd_canvas.js, etc.) > > Best, > Jonathan Could it be caused by telemetry and similar features? There's a https://github.com/Eloston/ungoogled-chromium fork; I suspect that it's basically Chromium without the "random connections". Could it be used for the Purr-Data gui? Marc From jon.w.wilkes at gmail.com Sun Jan 24 19:22:48 2021 From: jon.w.wilkes at gmail.com (Jonathan Wilkes) Date: Sun, 24 Jan 2021 19:22:48 -0500 Subject: [L2Ork-dev] json? In-Reply-To: <684ac84e-dc66-21bf-d973-9d8f8414f775@hacklava.net> References: <06f01ff3-bd87-04ec-68bf-6e79f15e9295@hacklava.net> <19a14750-03d8-bec4-d6a2-2393dc5670f8@hacklava.net> <684ac84e-dc66-21bf-d973-9d8f8414f775@hacklava.net> Message-ID: On Sun, Jan 24, 2021 at 5:55 PM Marc Lavallée wrote: > > Le 21-01-24 à 18 h 09, Jonathan Wilkes a écrit : > > > Unfortunately, Chromium tries to make untold numbers of random > > connections to the internet. So in Purr Data I had to block it > > completely and rely on node.js to send and receive between GUI<-->Pd. > > So if you want your html page to have net access (or if you want to > > load a page from the web), you have to go in to Purr Data's > > package.json and remove the proxy command in "--chromium-args" entry > > that blocks Chromium from chattering. (The package.json is in the same > > directory as pdgui.js, pd_canvas.js, etc.) > > > > Best, > > Jonathan > > Could it be caused by telemetry and similar features? There are some legitimate reasons for it to access the net before the user starts browsing. The problem is it's access is smeared across the codebase and isn't easily controlled through something like a single startup flag. So I'm forced to simply refuse all remote access from within the browser context. > > There's a https://github.com/Eloston/ungoogled-chromium fork; I suspect > that it's basically Chromium without the "random connections". Could it > be used for the Purr-Data gui? Yes, but the gui toolkit we use is nw.js which packages chromium/chrome with node.js plus some (buggy) convenience methods for things like application menus. It's not practical to switch out the chromium part with an alternative, for all supported architectures. -Jonathan > > Marc > > _______________________________________________ > L2Ork-dev mailing list > L2Ork-dev at disis.music.vt.edu > https://disis.music.vt.edu/listinfo/l2ork-dev From jon.w.wilkes at gmail.com Mon Jan 25 16:05:54 2021 From: jon.w.wilkes at gmail.com (Jonathan Wilkes) Date: Mon, 25 Jan 2021 16:05:54 -0500 Subject: [L2Ork-dev] soundfiler improvements Message-ID: Hi all, I just merged some soundfiler improvements into master: * ported the right inlet from Vanilla * added much better error reporting for the "read" and "write" flags of soundfiler, plus the "open" message for writesf~. Now you get actual information about which flag caused the error, and why. There's also a warning if the filename looks suspiciously like a flag without the dash, like "skip". * errors for read/write/open of soundfiler/writesf~ now report the *actual* message that triggered the error, along with the error report. This makes it much easier to figure out what went wrong. * all (or most) errors now properly report the corresponding object for proper error links so you can track down the problem. Proper class names and method names are also reported -Jonathan From jon.w.wilkes at gmail.com Mon Jan 25 16:18:56 2021 From: jon.w.wilkes at gmail.com (Jonathan Wilkes) Date: Mon, 25 Jan 2021 16:18:56 -0500 Subject: [L2Ork-dev] Windows Gem is broken in master Message-ID: Hi all, The windows build system under MSYS2 no longer ships libdl.dll which Gem apparently uses for its dynamic loading of dependencies. There's a big, fancy warning in the CI logs about this, which I pasted below. Fixing this problem probably requires caring about the following: * why MSYS2 no longer ships libdl.dll * libtool * Gem working under Windows If you have those cares, *and* you can fix the problem using only the dependencies available through pacman under MSYS2 (i.e., no hand-compiling extra bullshit just to get this library to work), please send a merge request and I'll have a look at it. In the meantime, Gem won't work under Windows if you check out the code from master. "Warning" is below. Best, Jonathan *** Warning: linker path does not have real file for library -ldl. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libdl and none of the candidates passed a file format test *** using a file magic. Last file checked: C:/msys64/mingw32/lib/libdl.a *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module Gem. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag.