purr-data issueshttps://git.purrdata.net/jwilkes/purr-data/-/issues2021-05-19T07:31:47Zhttps://git.purrdata.net/jwilkes/purr-data/-/issues/701Missing alt text in img element2021-05-19T07:31:47ZPrakhar AgarwalMissing alt text in img elementWe should include alt text in img element. Currently, this line is present in index.html file
`<img src="https://agraef.github.io/purr-data-intro/purr.png">`We should include alt text in img element. Currently, this line is present in index.html file
`<img src="https://agraef.github.io/purr-data-intro/purr.png">`https://git.purrdata.net/jwilkes/purr-data/-/issues/700Fixing typo in readme file2021-05-19T07:30:30ZPrakhar AgarwalFixing typo in readme fileThere is a typo in [readme.md](https://git.purrdata.net/jwilkes/purr-data/-/blob/emscripten/emscripten/project/purr-data/README.md) file
`Make the work storable and sharable between users.`
this should be
`Make the work storable and s...There is a typo in [readme.md](https://git.purrdata.net/jwilkes/purr-data/-/blob/emscripten/emscripten/project/purr-data/README.md) file
`Make the work storable and sharable between users.`
this should be
`Make the work storable and shareable between users.`https://git.purrdata.net/jwilkes/purr-data/-/issues/692Overhaul / cleanup of fluid~'s soundfont search, MIDI message interface2020-11-02T19:50:42ZAlbert GräfOverhaul / cleanup of fluid~'s soundfont search, MIDI message interfaceOur version of fluid~ is a plain C port of Frank Barknecht's [original version](https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/footils/fluid), which serves the basic purpose of interfacing to fluidsynth, but still has ...Our version of fluid~ is a plain C port of Frank Barknecht's [original version](https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/footils/fluid), which serves the basic purpose of interfacing to fluidsynth, but still has some annoying usability issues which should be easy to fix:
- fluid~ doesn't search for the soundfont file in the directory of the patch and the Pd search path, which makes it really cumbersome to use, because soundfonts need to be specified using absolute paths.
- fluid~'s interface for passing MIDI messages doesn't cover all MIDI messages, and has the arguments in the wrong order (in particular, the MIDI channel comes first, causing issues with Pd's MIDI input objects which have them on the rightmost outlet). We should replace this with something more comprehensive such as my own [SMMF](https://bitbucket.org/agraef/pd-smmf) a.k.a. "Simple MIDI Message Format".
SMMF offers the following advantages over the ad-hoc message interface that fluid~ currently uses:
- It covers all MIDI voice messages, as well as system exclusive and the most important system realtime messages. (Note that sysex support is particularly interesting in the context of fluidsynth because it allows to pass octave-based temperaments using sysex messages following the MIDI Tuning Standard (MTS), which fluidsynth readily supports.)
- It enforces a close 1-1 correspondence between the Pd MIDI objects and the message format (it uses the same basenames as message selectors, and has the arguments in the right order to easily interface with the Pd MIDI objects).
- It is is readily supported by some helper abstractions ([midi-input.pd](https://bitbucket.org/agraef/pd-smmf/src/master/midi-input.pd) and [midi-output.pd](https://bitbucket.org/agraef/pd-smmf/src/master/midi-output.pd), available at https://bitbucket.org/agraef/pd-smmf).
- Last but not least, it is compatible with [pd-faust](https://agraef.github.io/pure-docs/pd-faust.html) and [pd-faustgen2](https://github.com/agraef/pd-faustgen) which makes it very easy to integrate Faust- and soundfont-based synthesis in Pd.
I think that both issues should be rather easy to fix (MR is in the works), and that this will improve the usability of this important external a lot. I will also make an attempt to preserve the old message interface as much as possible, so that most existing patches using fluid~ should continue to work without too much fiddling.2.15.1Albert GräfAlbert Gräfhttps://git.purrdata.net/jwilkes/purr-data/-/issues/690fluid~ broken (again) on Windows since 2.11.02022-08-03T14:48:28ZAlbert Gräffluid~ broken (again) on Windows since 2.11.0We've been through this before (cf. #540). This time it's a new dependency on libopus in libsndfile which we don't currently include in the Windows installer, and the fix is simply to include libopus (analogous to !300).We've been through this before (cf. #540). This time it's a new dependency on libopus in libsndfile which we don't currently include in the Windows installer, and the fix is simply to include libopus (analogous to !300).2.15.1Albert GräfAlbert Gräfhttps://git.purrdata.net/jwilkes/purr-data/-/issues/688Spontaneous crashing2020-11-05T21:43:31ZDave RiedstraSpontaneous crashingFor the past few days PD has been spontaneously crashing after an inconsistent amount of time. I can't tie it to any action that I'm taking while using it, except that it doesn't seem related to DSP.
Here's the crash in my system log:
...For the past few days PD has been spontaneously crashing after an inconsistent amount of time. I can't tie it to any action that I'm taking while using it, except that it doesn't seem related to DSP.
Here's the crash in my system log:
```
Pd: signal 6
extensions::nw.Window:145
return sendRequest.sendRequestSync('nw.currentWindowInternal.getZoom', arguments, this.definition.parameters, {})[0];
^
TypeError: Cannot read property '0' of undefined
at Object.<anonymous> (extensions::nw.Window:145:118)
at Object.handleRequest (extensions::binding:63:27)
at Object.<anonymous> (extensions::binding:425:32)
at NWWindow.get (extensions::nw.Window:580:40)
Error: async hook stack has become corrupted (actual: 22132, expected: 22133)
```
STDOUT and STDERR from purr-data:
```
guidir is /opt/purr-data/lib/pd-l2ork/bin
priority 6 scheduling enabled.
[0928/093816.251824:WARNING:chrome_main_delegate.cc(590)] final extension:
[85712:85736:0928/093816.439612:ERROR:nss_util.cc(802)] After loading Root Certs, loaded==false: NSS error code: -8018
[85745:85745:0928/093816.533929:ERROR:sandbox_linux.cc(346)] InitializeSandbox() called with multiple threads in process gpu-process.
priority 8 scheduling enabled.
priority 8 scheduling enabled.
/etc/pd/gem.conf: No such file or directory
/home/dried/.config/pure-data/gem.conf: No such file or directory
./gem.conf: No such file or directory
load plugins 'film' in '/opt/purr-data/lib/pd-l2ork/extra/Gem/'
pattern : /opt/purr-data/lib/pd-l2ork/extra/Gem/gem_film*.so
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_filmAVIPLAY.so'!
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_filmGMERLIN.so'!
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_filmMPEG3.so'!
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_filmQT4L.so'!
load plugins 'image' in '/opt/purr-data/lib/pd-l2ork/extra/Gem/'
pattern : /opt/purr-data/lib/pd-l2ork/extra/Gem/gem_image*.so
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_imageJPEG.so'!
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_imageMAGICK.so'!
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_imageSGI.so'!
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_imageSTB.so'!
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_imageTIFF.so'!
not reloading 'image' plugins (already 5 loaded)
load plugins 'image' in '/opt/purr-data/lib/pd-l2ork/extra/Gem/'
pattern : /opt/purr-data/lib/pd-l2ork/extra/Gem/gem_image*.so
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_imageJPEG.so'!
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_imageMAGICK.so'!
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_imageSGI.so'!
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_imageSTB.so'!
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_imageTIFF.so'!
load plugins 'model' in '/opt/purr-data/lib/pd-l2ork/extra/Gem/'
pattern : /opt/purr-data/lib/pd-l2ork/extra/Gem/gem_model*.so
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_modelOBJ.so'!
load plugins 'record' in '/opt/purr-data/lib/pd-l2ork/extra/Gem/'
pattern : /opt/purr-data/lib/pd-l2ork/extra/Gem/gem_record*.so
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_recordQT4L.so'!
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_recordV4L.so'!
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_recordV4L2.so'!
load plugins 'video' in '/opt/purr-data/lib/pd-l2ork/extra/Gem/'
pattern : /opt/purr-data/lib/pd-l2ork/extra/Gem/gem_video*.so
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_videoDC1394.so'!
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_videoDV4L.so'!
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_videoV4L.so'!
dylib loading file '/opt/purr-data/lib/pd-l2ork/extra/Gem/gem_videoV4L2.so'!
[85745:85745:0928/094114.854108:ERROR:buffer_manager.cc(453)] [.DisplayCompositor-0x558b3ee0ba00]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
[85745:85745:0928/094121.612973:ERROR:buffer_manager.cc(453)] [.DisplayCompositor-0x558b3ee0ba00]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
Pd: signal 6
[85712:85712:0928/094916.644150:ERROR:extension_function_dispatcher.cc(594)] Permission denied for nw.App.quit
```
Strangely, the crash is not logged in the system log when purr-data is started from the console. (I normally start from ulauncher.)
* purr-data: `Pd-l2ork-2.14.2 20200922-rev.c4495143` using `Pd-0.48.0`
* OS: `Pop!_OS 20.04` with Gnome 3.36.3 desktop on Wayland
* jackd: `1.9.12`https://git.purrdata.net/jwilkes/purr-data/-/issues/687iemgui dialogs are not capturing new hex colors correctly in their color pick...2020-09-25T20:33:57ZIvica Bukviciemgui dialogs are not capturing new hex colors correctly in their color pickers for bfl colorsThis is likely a regression since we adopted the new colors and is hopefully not a major one.This is likely a regression since we adopted the new colors and is hopefully not a major one.https://git.purrdata.net/jwilkes/purr-data/-/issues/685Double-clicking on a patch while having purrdata already running does not any...2020-10-06T19:21:07ZIvica BukvicDouble-clicking on a patch while having purrdata already running does not any more open the patchTested on Win10 with the latest version of the master branch. I seem to recall this working ok recently.Tested on Win10 with the latest version of the master branch. I seem to recall this working ok recently.https://git.purrdata.net/jwilkes/purr-data/-/issues/679nw.js 0.47.x: Preferences don't close with Ok or Close2020-09-02T11:25:14ZAlbert Gräfnw.js 0.47.x: Preferences don't close with Ok or CloseI can reproduce this (on Linux) as follows: Open the prefs dialog, change something, press Ok. The dialog will close alright the first time. Do it again => Ok still commits the changes, but doesn't close the dialog anymore, neither does ...I can reproduce this (on Linux) as follows: Open the prefs dialog, change something, press Ok. The dialog will close alright the first time. Do it again => Ok still commits the changes, but doesn't close the dialog anymore, neither does the Close button. I have to close the window from the window manager using the x button to get rid of the window.
With 0.22.4 this works every time, so this seems to be a regression for the latest nw.js versions that I've been using lately (0.46+). Also happens on Windows (with nw.js 0.47.3).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/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/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/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äfhttps://git.purrdata.net/jwilkes/purr-data/-/issues/654metro / delay help files outdated (tempo message missing)2020-07-05T12:53:56ZAlexandre Porresmetro / delay help files outdated (tempo message missing)Hi, as of 0.45, metro, delay and timer take a "tempo" message. These have been implemented in purr data but are still missing in the help file of metro and delay (timer has it). I'd suggest a revision of the docs to find/fix more issues....Hi, as of 0.45, metro, delay and timer take a "tempo" message. These have been implemented in purr data but are still missing in the help file of metro and delay (timer has it). I'd suggest a revision of the docs to find/fix more issues. Cheers.https://git.purrdata.net/jwilkes/purr-data/-/issues/645The bar graph array scalars inside a subpatch (topwindow) look like a flat li...2020-06-17T19:06:37ZIvica BukvicThe bar graph array scalars inside a subpatch (topwindow) look like a flat line out of which bars grow out of both up and down, rather than appearing from the bottom of the windowI will look into this eventually. I wonder though, if having Jonathan do this since the bargraph is his baby may be easier. Please also note the issue #643 that is also related to this bug but should be fixed globally for all plots in a ...I will look into this eventually. I wonder though, if having Jonathan do this since the bargraph is his baby may be easier. Please also note the issue #643 that is also related to this bug but should be fixed globally for all plots in a separate merge request.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/issues/644The bar graph array scalars inside a subpatch (topwindow) look like a flat li...2020-06-09T01:38:31ZIvica BukvicThe bar graph array scalars inside a subpatch (topwindow) look like a flat line out of which bars grow out of both up and down, rather than appearing from the bottom of the windowI will look into this eventually. I wonder though, if having Jonathan do this since the bargraph is his baby may be easier. Please also note the issue #643 that is also relevant to this bug but should be fixed globally for all plots.I will look into this eventually. I wonder though, if having Jonathan do this since the bargraph is his baby may be easier. Please also note the issue #643 that is also relevant to this bug but should be fixed globally for all plots.