purr-data issueshttps://git.purrdata.net/jwilkes/purr-data/-/issues2020-08-28T04:37:25Zhttps://git.purrdata.net/jwilkes/purr-data/-/issues/678Data dialog issues2020-08-28T04:37:25ZIvica BukvicData dialog issuesData dialog should auto-update when the data structure is manipulated directly. This includes vars and the vector.
The second issue is not entirely clear to me. When editing vector data, are we allowed to add new data or only edit exist...Data dialog should auto-update when the data structure is manipulated directly. This includes vars and the vector.
The second issue is not entirely clear to me. When editing vector data, are we allowed to add new data or only edit existing? If we should be able to add new data, then this is impossible since enter is mapped to the dialog's OK button and this should be fixed. A common way of addressing this is (e.g. via social media platforms) when trying to send a multiline comment, one presses shift+return(or shift+enter) which gives them a newline without sending the message.https://git.purrdata.net/jwilkes/purr-data/-/issues/677Adjusting font size back and forth at a zoom level than default (100%) distor...2020-08-27T05:04:25ZIvica BukvicAdjusting font size back and forth at a zoom level than default (100%) distorts location of objects in gop-enabled subpatches and toplevelsResized GOP windows suddenly lose visibility of its contents (which is expected if it is a subpatch whose font is tied to the parent patch). However, resetting font size does not restore original position. Sometimes objects remain stale ...Resized GOP windows suddenly lose visibility of its contents (which is expected if it is a subpatch whose font is tied to the parent patch). However, resetting font size does not restore original position. Sometimes objects remain stale outside the GOP window and one cannot get rid of them.https://git.purrdata.net/jwilkes/purr-data/-/issues/676Subpatch data scalar toplevel window should rescale its scalars when the wind...2020-08-27T05:02:23ZIvica BukvicSubpatch data scalar toplevel window should rescale its scalars when the window is rescaledOpen disis_wiimote-help.pd and the subpatch for either blobs or joystick and resize it and note that the data scalar does note rescale accordingly.Open disis_wiimote-help.pd and the subpatch for either blobs or joystick and resize it and note that the data scalar does note rescale accordingly.https://git.purrdata.net/jwilkes/purr-data/-/issues/675Selection boxes of data scalars in the GOP-enabled subpatch window are way of...2020-08-27T05:01:23ZIvica BukvicSelection boxes of data scalars in the GOP-enabled subpatch window are way off and correlate to the distance from the top-left corner of the patch windowOpen disis_wiimote-help.pd and open the subpatch with blobs, go to edit mode and try selecting and moving the 4 blobs. This may be related to #647Open disis_wiimote-help.pd and open the subpatch with blobs, go to edit mode and try selecting and moving the 4 blobs. This may be related to #647https://git.purrdata.net/jwilkes/purr-data/-/issues/674Clicking on the resize text object that is not a GOP still offers a diagonal ...2021-03-29T14:11:19ZIvica BukvicClicking on the resize text object that is not a GOP still offers a diagonal resize in the bottom right corner that results in an error: canvas: no method for '_click_for_resizing'https://git.purrdata.net/jwilkes/purr-data/-/issues/673Rogue cord issue2020-08-22T18:32:45ZPaul PignonRogue cord issuePut two number boxes, # 1, # 2 and a multiplier
Connect # 1 to input 0 of the multiplier
Connect # 2 to input 1 of the multiplier.
Thereupon a third cord appears at the output of # 2, and cannot be removed. It follows the cursor everywhe...Put two number boxes, # 1, # 2 and a multiplier
Connect # 1 to input 0 of the multiplier
Connect # 2 to input 1 of the multiplier.
Thereupon a third cord appears at the output of # 2, and cannot be removed. It follows the cursor everywhere, even in the menu bar.
It can only be removed by saving, closing and reopening the file.
I have reproduced this behaviour a number of times, always the same.
[Note also that Ctrl+W does not close the file, it asks whether to save changes, but then does not close the file. Ctrl+W has to be done a second time.]
I am running pd-l2ork version 20200802.
uname -a Linux velikiHP 5.6.0-0.bpo.2-amd64 #1 SMP Debian 5.6.14-2~bpo10+1 (2020-06-09) x86_64 GNU/Linux
KDE desktop
Paul Pignon![Screenshot_haywire](/uploads/d4e376287e9a510e0417de6e8f5bd103/Screenshot_haywire.png)https://git.purrdata.net/jwilkes/purr-data/-/issues/672Issue with [moonlib/mknob] in Purr-data 2.13.02023-01-25T23:10:39ZZigmhountIssue with [moonlib/mknob] in Purr-data 2.13.0Hi!
As I raised [on the Pd forum](https://forum.pdpatchrepo.info/topic/12990/issue-with-moonlib-mknob-in-purr-data-2-13-0), I've had crashes with Purr-data 2.13.0 when trying to save patches containing an [mknob]. This is the case both f...Hi!
As I raised [on the Pd forum](https://forum.pdpatchrepo.info/topic/12990/issue-with-moonlib-mknob-in-purr-data-2-13-0), I've had crashes with Purr-data 2.13.0 when trying to save patches containing an [mknob]. This is the case both for patches that were working before, as well as for new, empty patches in which I put only a [moonlib/mknob] object and save. I've had this both on OpenSuse 15.2 and Debian 9.0 with `Pd-L2Ork version 2.13.0 (20200802-rev.70066071)` installed from https://download.opensuse.org/repositories/home:aggraef.
When running `purr-data -d 3` and saving such a patch with only one mknob in it I get only this:
```
<- pd watchdog;
<- x563e8f831110 savetofile mknob.pd /home/zig/PureData 0;
-> gui_post "warning: saving iemgui colors as hex symbol. These colors are readable in Pd Vanilla since 0.47, but they are not readable in Purr Data version 2.12.0 or earlier. If you need to remain compatible with older versions of Purr Data please run in compatibility mode with Vanilla version 0.47 like this:
"
-> gui_post "
"
-> gui_post "[compatibility 0.47(
"
-> gui_post "|
"
-> gui_post "[send pd]
"
-> gui_post "
"Pd: signal 6
```
It seemed to work find with the previous version, but I'll downgrade tomorrow because I've had to make changes in patches containing mknob and I can't use them anymore.
Let me know if you need more details.https://git.purrdata.net/jwilkes/purr-data/-/issues/671Gem library failed to load2020-09-03T20:40:11Z60-hzGem library failed to loadAll [Gem] objets fail to load on my Windows10 machine with 2.13.0.
- NO Gem splash screen at start
- Help browser => any Gem exemple lead to "couldn't create" red messages.
- The library paths and declaration are ok in the preferences p...All [Gem] objets fail to load on my Windows10 machine with 2.13.0.
- NO Gem splash screen at start
- Help browser => any Gem exemple lead to "couldn't create" red messages.
- The library paths and declaration are ok in the preferences panel.
I wonder, since Gem 0.94 build is only for 64bits systems, is the Gem library included ready for 32bits PurrData?https://git.purrdata.net/jwilkes/purr-data/-/issues/670key missing in [key] and [keyname]2020-08-19T05:05:15Z60-hzkey missing in [key] and [keyname]The following key reports have problems with [keyname] object (same with [key]):
Space: nothing return
Return: only keydown/keyup but no name with [keyname]
cmd: nothing return
Caps_lock: nothing return
Shift_L: only "Shift" (no info Sh...The following key reports have problems with [keyname] object (same with [key]):
Space: nothing return
Return: only keydown/keyup but no name with [keyname]
cmd: nothing return
Caps_lock: nothing return
Shift_L: only "Shift" (no info Shift_L / Shift_R)
Super_L: nothing returnhttps://git.purrdata.net/jwilkes/purr-data/-/issues/669nw.js 0.46/0.47 issues2020-09-06T08:11:55ZAlbert Gräfnw.js 0.46/0.47 issuesDocument regressions with respect to the latest nw.js versions here.Document regressions with respect to the latest nw.js versions here.https://git.purrdata.net/jwilkes/purr-data/-/issues/668ci: Cache downloaded nw.js tarball2020-09-17T17:43:59ZSam Thursfieldci: Cache downloaded nw.js tarballWe can persist files between builds in the `/cache` folder, provided it's enabled in the .gitlab-ci.yml config. (Details at https://docs.gitlab.com/ee/ci/caching/)
For the CI script to do this, it needs to know the nw.js filename for th...We can persist files between builds in the `/cache` folder, provided it's enabled in the .gitlab-ci.yml config. (Details at https://docs.gitlab.com/ee/ci/caching/)
For the CI script to do this, it needs to know the nw.js filename for the current platform. This info is currently determined in the `tar_em_up.sh` script. I propose that we move that code into a separate `nwjs_version_for_platform` shell script which we could then call both from `tar_em_up.sh` and from `.gitlab-ci.yml`.https://git.purrdata.net/jwilkes/purr-data/-/issues/667Use autoconf cache to speed up CI2020-08-06T18:21:16ZSam ThursfieldUse autoconf cache to speed up CIThe CI spends a long time running `configure` scripts of each subproject. We might use [autoconf cache files](https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Cache-Files.html) to reduce the amount of ti...The CI spends a long time running `configure` scripts of each subproject. We might use [autoconf cache files](https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Cache-Files.html) to reduce the amount of time spent.https://git.purrdata.net/jwilkes/purr-data/-/issues/666ci logs are too long for GitLab CI2020-09-17T19:37:10ZSam Thursfieldci logs are too long for GitLab CIgit.purrdata.net has a limit of 4194304 bytes for CI logs and this is sometimes exceeded by CI jobs, e.g. https://git.purrdata.net/jwilkes/purr-data/-/jobs/18898 and https://git.purrdata.net/jwilkes/purr-data/-/jobs/18862
Here are some ...git.purrdata.net has a limit of 4194304 bytes for CI logs and this is sometimes exceeded by CI jobs, e.g. https://git.purrdata.net/jwilkes/purr-data/-/jobs/18898 and https://git.purrdata.net/jwilkes/purr-data/-/jobs/18862
Here are some things to investigate to reduce the size of logs:
- [x] Enable Automake's [silent mode](https://www.gnu.org/software/automake/manual/html_node/Automake-Silent-Rules.html) so compiler/linker commandlines are only shown when an error occurs
- [ ] fix the many `dpkg-shlibdeps` warnings that occur
- [x] modify the tests to only show output when there's a problem (i don't know how the tests work, but maybe it's simple to do)https://git.purrdata.net/jwilkes/purr-data/-/issues/665Use ccache to speed up build times2020-09-17T20:02:41ZSam ThursfieldUse ccache to speed up build timesWe can speed up the CI by installing [ccache](https://ccache.dev/) on all of the GitLab CI runners, and using [GitLab CI caching](https://docs.gitlab.com/ee/ci/caching/index.html) to share the `$CCACHE_DIR` between jobs.
For the Linux r...We can speed up the CI by installing [ccache](https://ccache.dev/) on all of the GitLab CI runners, and using [GitLab CI caching](https://docs.gitlab.com/ee/ci/caching/index.html) to share the `$CCACHE_DIR` between jobs.
For the Linux runners we can install the ccache package inside the containers. For OSX and Windows the admin of those machines will need to install it in the host.
It's also important that the GitLab CI machines have a reasonable about of disk space dedicated to the CI cache -- at least large enough to fit all the .o files from a build of PD.https://git.purrdata.net/jwilkes/purr-data/-/issues/664pd-lua dynamic linking woes on Debian/Ubuntu2020-09-06T08:11:55ZAlbert Gräfpd-lua dynamic linking woes on Debian/UbuntuAs @Joseph reported, at least on Linux Mint 20 pd-lua is broken (doesn't load) OOTB because liblua.so.5.3 is missing. (This doesn't seem to happen on a stock Ubuntu install, apparently by sheer luck it has this library in the default ins...As @Joseph reported, at least on Linux Mint 20 pd-lua is broken (doesn't load) OOTB because liblua.so.5.3 is missing. (This doesn't seem to happen on a stock Ubuntu install, apparently by sheer luck it has this library in the default installation, or as a dependency of some package in the default install.)
This dependency isn't auto-detected for some reason when building Debian/Ubuntu packages using the debuild stuff (e.g., on the OBS), so it needs to be added explicitly to the runtime dependencies of the package.Albert GräfAlbert Gräfhttps://git.purrdata.net/jwilkes/purr-data/-/issues/663Current HEAD doesn't launch on Linux2020-07-29T22:26:34ZAlbert GräfCurrent HEAD doesn't launch on LinuxThis is an absolute showstopper for the upcoming release:
```shell
$ purr-data
guidir is /opt/purr-data/lib/pd-l2ork/bin
priority 6 scheduling enabled.
sh: /home/user/purr-data/pd/nw/nw/nw: No such file or directory
```
Apparently that...This is an absolute showstopper for the upcoming release:
```shell
$ purr-data
guidir is /opt/purr-data/lib/pd-l2ork/bin
priority 6 scheduling enabled.
sh: /home/user/purr-data/pd/nw/nw/nw: No such file or directory
```
Apparently that's a leftover from some local testing session. See https://git.purrdata.net/jwilkes/purr-data/-/commit/ecb92e6da9812b1b47e5c23c01af2c3f1fa66f33#c87ff469445676635e6f85a3e27583d0b7a38557_24_24.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/662[list store] not optimal for building gigantic messages2020-07-26T19:30:06ZJonathan Wilkes[list store] not optimal for building gigantic messagesIf you try to accumulate a large list with [list store], reallocation time becomes a major factor on Windows.
Can easily improve realloc times by overallocating using a simple doubling algorithm.
There's already a related "quick-and-di...If you try to accumulate a large list with [list store], reallocation time becomes a major factor on Windows.
Can easily improve realloc times by overallocating using a simple doubling algorithm.
There's already a related "quick-and-dirty" algorithm like that in unpost_printhook to fill in for C++ iostream from matju's original C++ implementation. So we probably want to put an interface in m_memory.c for general use.
However, we'd need to be careful to document this interface as inappropriate for realtime computation. While it can vastly improve average performance it doesn't guarantee worst-case performance. (And in fact better average perf can *hide* worst-case perf from the user, which is a strange but very real usability problem in soft realtime environments like this.)
In fact, we may consider adding something like [list storeupto 100] to initialize max size to 100 and error out above that. This would avoid realloc altogether and *could* be realtime safe if we handle gpointers efficiently.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/661"inlet: expected x but got y" should name the object that owns it2021-04-21T09:57:28ZJonathan Wilkes"inlet: expected x but got y" should name the object that owns itreplace it with:
"inlet of z: expected x but got y"
where z is the classnamereplace it with:
"inlet of z: expected x but got y"
where z is the classnamehttps://git.purrdata.net/jwilkes/purr-data/-/issues/660Vertical viewport size regression in Ico's branch (nw.js 0.24.4)2020-07-30T18:01:43ZAlbert GräfVertical viewport size regression in Ico's branch (nw.js 0.24.4)@ico, unfortunately, it seems that I have found another, less obvious, "old-nw.js" regression in your branch. Using nw.js 0.24.4 on Linux (Manjaro), the viewport of a fully visible canvas (i.e., without scrollbars, and with the entire ca...@ico, unfortunately, it seems that I have found another, less obvious, "old-nw.js" regression in your branch. Using nw.js 0.24.4 on Linux (Manjaro), the viewport of a fully visible canvas (i.e., without scrollbars, and with the entire canvas fitting well into the visible area) seems slightly too large (at least in the vertical direction). The observable result is that, even though the window has no scrollbars, you can wiggle the mousewheel and have the window scroll a little amount in the vertical direction. You can easily reproduce this using the "about" window with the current master (rev. dd632b2d294969e2740b6fad91ff7ba6bb26fb1f) built against nw.js 0.22.4. The following little screencast shows what I mean:
![vertical-viewport-wiggle](/uploads/7b60140b5826e0b8c7d1350f05d40b49/vertical-viewport-wiggle.gif)
I can make this go away by going back to rev. 11f6610d31c8e656e3e593701e83337368cdbd91 (before your branch got merged back in). The problem also goes away with the current master, when using nw.js 0.47.0-beta1 instead of our baseline 0.24.4. So it seems fairly obvious to me that it's in fact a regression in your branch with respect to nw.js 0.24.4.Ivica BukvicIvica Bukvichttps://git.purrdata.net/jwilkes/purr-data/-/issues/659Better touchscreen support2020-07-17T21:09:19ZAlbert GräfBetter touchscreen supportOur current OOTB experience on touch screens is not very good, to put it kindly. :) You can select menu entries and click on objects, that's about it. But if you're using a touchscreen, you also want to be able to operate GUI objects, dr...Our current OOTB experience on touch screens is not very good, to put it kindly. :) You can select menu entries and click on objects, that's about it. But if you're using a touchscreen, you also want to be able to operate GUI objects, drag around objects, draw a rubberband to select a range of objects, etc., which currently doesn't work at all with the default touch support that the OS and/or nw.js offer.
This probably isn't straightforward, because mouse event handling needs to be modified in our GUI code. But having proper touch support would certainly be a big improvement, if not a killer feature, especially when running Purr Data on convertibles, as well as in teaching on a digital whiteboard (I actually have one of those in our MIDI lab, which works without a hitch on Linux). So can we please have a go at this?
I have no idea how to do this myself, but over at my Purr Data Github mirror, spidercatnat has submitted a [pull request](https://github.com/agraef/purr-data/pull/15), still WIP, which already has the basics implemented. ATM, this still has some bugs and is based on a pretty old (around 2.10.0) revision, but it rebases easily on the current master, you can find that in my [copy of spidercatnat's branch](https://github.com/agraef/purr-data/tree/touch-support-master) on Github (of course, I can pull that over to Gitlab if anyone here wants to play around with it).
It would be great if someone who knows this stuff better than me could lend spidercatnat a helping hand, so that we can make this work. (I suspect that it's Ico's branch which gives trouble trying to merge spidercatnat's work with HEAD right now. But that's hopefully not a big deal. I'm willing to do the grunt integration work, with a bit of help from Ico if needed.)Albert GräfAlbert Gräf