purr-data merge requestshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests2023-07-25T21:39:56Zhttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/8612.19.3 final release2023-07-25T21:39:56ZAlbert Gräf2.19.3 final releaseThanks for merging the previous MRs!
This just bumps the version number and removes some obsolete notes about Gem not being available on Mac in the help browser.
Once you merge this, our repos will be in sync again, so that I can go ah...Thanks for merging the previous MRs!
This just bumps the version number and removes some obsolete notes about Gem not being available on Mac in the help browser.
Once you merge this, our repos will be in sync again, so that I can go ahead and tag the final 2.19.3 release on GH (this is only available as a pre-release right now).Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/859Update pd-lua to 0.11.6 (tutorial updates).2023-07-19T02:49:43ZAlbert GräfUpdate pd-lua to 0.11.6 (tutorial updates).https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/857Update README2023-07-19T02:48:50ZAlbert GräfUpdate READMEUpdated some outdated information, removed some L2ork branding, fixed some typos and formatting glitches.Updated some outdated information, removed some L2ork branding, fixed some typos and formatting glitches.https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/856Improved vanilla API compatibility2023-07-19T02:47:39ZAlbert GräfImproved vanilla API compatibilityThis fixes some glitches in our API to improve compatibility with vanilla. Specifically:
- Added the missing obj_findsignalscalar declaration to m_imp.h.
- Purr Data's glist_grab function has an extra argument, so I renamed it to glist...This fixes some glitches in our API to improve compatibility with vanilla. Specifically:
- Added the missing obj_findsignalscalar declaration to m_imp.h.
- Purr Data's glist_grab function has an extra argument, so I renamed it to glist_grabx and provided a vanilla-compatible glist_grab function that can be used by bundled and 3rd party externals. There are precisely two instances in g_numbox.c and g_text.c where the extra argument is actually needed, these use glist_grabx now. While I was at it, I also fixed a bug in g_numbox.c related to glist_grabx and slashed some gcc warnings in src/pd.
- I also removed some public class definitions from g_canvas.h which might clash with 3rd party externals (ELSE, in particular). Checking for these classes is all the functionality needed across the internals, so I provided suitable predicate functions instead.
With this, I can now build Alexandre's ELSE against Purr Data. Here's a screenshot which shows one of ELSE's help patches purring happily. :smirk_cat:
![image](/uploads/f963ac2aae962abc3163ec448295ef61/image.png)
So in principle adding ELSE to purr-data/externals as a submodule and building it in externals/Makefile will be as easy as pie now. I can submit another MR for that if wanted. But there still are two roadblocks on that avenue:
- There's the legacy gui stuff (lots of it) in ELSE that needs to be ported to nw.js.
- ELSE uses vanilla's new listbox in some of the help patches, so it would be good have that ported first. *hint* :trophy:https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/855Fix ubuntu build in github-ci, 2nd attempt.2023-02-07T23:43:06ZAlbert GräfFix ubuntu build in github-ci, 2nd attempt.The `apt-get install` in the ubuntu build keeps breaking for no good reason. :( This change should dance around the Azure connectivity issues that I've been seeing lately.The `apt-get install` in the ubuntu build keeps breaking for no good reason. :( This change should dance around the Azure connectivity issues that I've been seeing lately.https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/854Version 2.19.2.2023-02-03T04:00:15ZAlbert GräfVersion 2.19.2.Implements the gui features for the cyclone "hammereditor", replacing legacy tcl/tk calls, so that the cyclone objects utilizing the editor
(capture, coll, seq, etc.) will now function properly in Purr Data.
This is in part a backport f...Implements the gui features for the cyclone "hammereditor", replacing legacy tcl/tk calls, so that the cyclone objects utilizing the editor
(capture, coll, seq, etc.) will now function properly in Purr Data.
This is in part a backport from DISIS Pd-l2ork (thanks, Ico!), cf. https://github.com/pd-l2ork/pd-l2ork/commit/8a93fa83. However, our version is essentially a complete overhaul in order to minimize the impact on Purr Data's existing text dialog interface, and we also fixed some bugs along the way.
Some related regressions in the vanilla text, qlist, and textfile objects have also been ironed out.
Last but not least, pd-lua was updated to 0.11.5 (bugfix release).https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/853github-ci: Fix ubuntu build, must run apt-get update.2023-02-01T23:01:03ZAlbert Gräfgithub-ci: Fix ubuntu build, must run apt-get update.Fixed a glitch in the github-ci (ubuntu builds were failing due to upstream updates).Fixed a glitch in the github-ci (ubuntu builds were failing due to upstream updates).https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/852Fix the cyclone file i/o features2023-02-01T23:00:16ZAlbert GräfFix the cyclone file i/o featuresFix the cyclone file i/o features (coll, hammereditor). Replaces non-functioning legacy (tcl/tk) calls. Backport from DISIS Pd-l2ork, cf. https://github.com/pd-l2ork/pd-l2ork/commit/8a93fa83. This needed quite some editing to apply clean...Fix the cyclone file i/o features (coll, hammereditor). Replaces non-functioning legacy (tcl/tk) calls. Backport from DISIS Pd-l2ork, cf. https://github.com/pd-l2ork/pd-l2ork/commit/8a93fa83. This needed quite some editing to apply cleanly to our codebase and to get rid of whitespace glitches obfuscating the real changes. But that's (mostly) cosmetic, functionally it works the same.
Also found and fixed some glitches in the seq help patch.https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/851Version 2.19.1.2023-01-31T02:51:33ZAlbert GräfVersion 2.19.1.- Backported some GUI regression fixes from DISIS Pd-l2ork.
- Better icons for win32 and win64 inno (converted from the png icons).
The ones we had looked dated and terribly blurry on modern hi-dpi
displays.
- Cleaned up linux_make...- Backported some GUI regression fixes from DISIS Pd-l2ork.
- Better icons for win32 and win64 inno (converted from the png icons).
The ones we had looked dated and terribly blurry on modern hi-dpi
displays.
- Cleaned up linux_make: Got rid of some obsolete stuff and removed some
of the l2ork branding.https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/850linux_make: cleanup2023-01-29T04:17:19ZAlbert Gräflinux_make: cleanupRemove some really old cruft from the Linux package that hopefully nobody uses any more. Also remove the l2ork branding as much as we can in icons, desktop files, etc., while ensuring that a straight `make && make install` from source st...Remove some really old cruft from the Linux package that hopefully nobody uses any more. Also remove the l2ork branding as much as we can in icons, desktop files, etc., while ensuring that a straight `make && make install` from source still does the right thing. Adjust the debuild accordingly.https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/849Some GUI regression fixes backported from DISIS Pd-l2ork.2023-01-29T20:54:03ZAlbert GräfSome GUI regression fixes backported from DISIS Pd-l2ork.I have noticed these, too. They are really annoying, but Ico's downstream has them fixed, so we can just adopt the relevant parts of these commits. See:
- https://github.com/pd-l2ork/pd-l2ork/commit/3be1bac4
- https://github.com/pd-l2ork...I have noticed these, too. They are really annoying, but Ico's downstream has them fixed, so we can just adopt the relevant parts of these commits. See:
- https://github.com/pd-l2ork/pd-l2ork/commit/3be1bac4
- https://github.com/pd-l2ork/pd-l2ork/commit/37153fa4
- https://github.com/pd-l2ork/pd-l2ork/commit/b7f94f4f
The first two are Mac-specific, the third bug applies to all platforms.
- Cmd+Q not actually quitting after replying "no" to a save prompt. This is at odds with the behavior on other platforms. We need to actually call pdgui.menu_quit() in the appropriate handler after the last patch window was closed and we're about to quit. (That call doesn't seem to be needed on Linux and Windows, but it doesn't seem to do any harm there either.)
- Patch window growing vertically after each save. There was actually code in place to mitigate this, but it was explicitly disabled on macOS (probably because on the Mac we have the global menu, and thus there is no menu bar on the canvas?). Reenabling it makes this bug go away, though. Maybe this is due to a bug in nw.js which is still present in the latest nw.js 0.71 release?
- Subpatch window forgets its geometry when closed and re-opened. Fixed by calling canvas_check_geometry in the close event and menu option, as we already do in the save and saveas menu options.
NB: The second change with the menu offset hack seems a little dubious to me, this probably needs revisiting. Why would we account for the menu offset in canvas_check_geometry on the Mac, when we don't do this in index.js:gui.Window.open? Nevertheless, this change makes the Mac-only grow-on-save bug go away, so we want to keep this for now.https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/848Version 2.19.0.2023-01-26T02:22:28ZAlbert GräfVersion 2.19.0.Hi Jonathan, I've just synced up the GH master, release and testing branches to gitlab, including your most recent fix-knob-crasher MR, and I'm ready to finally release this as 2.19.0 proper now. Which is what this MR is about (it's just...Hi Jonathan, I've just synced up the GH master, release and testing branches to gitlab, including your most recent fix-knob-crasher MR, and I'm ready to finally release this as 2.19.0 proper now. Which is what this MR is about (it's just a version bump). Note that I already released 2.18.0 and 2.18.1 last week, so the bump goes to 2.19.0 instead. Which looks a bit odd, since those earlier bumps to 2.18.x aren't in any of the current branches any more, but hey, we're advancing by leaps and bounds :smile:, and this will let me keep those earlier releases which is a good thing IMHO.https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/847use symbol colors for iemgui_save in externals to prevent crasher2023-01-25T23:10:37ZJonathan Wilkesuse symbol colors for iemgui_save in externals to prevent crasherFixes #672Fixes #672Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/846Github CI, MacOS and Mingw build fixes2023-01-25T02:43:40ZAlbert GräfGithub CI, MacOS and Mingw build fixesThe first commit "add github ci" is obviously for my own convenience, but the MR also adds two little source changes to fix issues with our current macos and mingw builds I encountered:
- "macos build": I found that on GitHub at least, ...The first commit "add github ci" is obviously for my own convenience, but the MR also adds two little source changes to fix issues with our current macos and mingw builds I encountered:
- "macos build": I found that on GitHub at least, the CI would fail with a timeout while trying to execute `hdiutil detach` during construction of the dmg. So I added two retries in order to make that go through. This doesn't affect manual builds and shouldn't do any harm in the gitlab ci either, because if the first `hdiutil detach` succeeds without timing out, then of course the retries won't be run.
- "mingw build": In the latest msys2, the version of libpcre pulled in while installing the mingw build dependencies isn't libpcre any more, it's libpcre2. This causes the build to fail in a pristine build environment since libpcre-1.dll doesn't exist in the build environment any more (and it's the wrong dll to include anyway). Therefore I adjusted the inno Makefiles so that they copy the right dll, which now is libpcre2-8-0.dll.
It goes without saying that having macos and mingw builds as well as releases fully automated on the GitHub mirror makes my life much much easier now. :) Therefore I'd really appreciate it very much if this MR could go in, so that I can keep the GH mirror in perfect sync with your gitlab in the future. Thanks!https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/845Mac and Windows packaging changes2023-01-25T02:42:12ZAlbert GräfMac and Windows packaging changesIf you've seen the recent discussion about the Purr Data / Pd-l2ork name confusion on the DISIS mailing list then you already know what this is about. This comes up time and again, so I wanted to settle this once and for all.
The change...If you've seen the recent discussion about the Purr Data / Pd-l2ork name confusion on the DISIS mailing list then you already know what this is about. This comes up time and again, so I wanted to settle this once and for all.
The changes in this PR are:
- Mac: Renamed the app to Purr-Data and the name of the prefs file to org.puredata.purr-data. This makes it possible to have Purr Data and the DISIS fork to work happily together on the Mac. This is for the benefit of those people who use Purr Data and DISIS Pd-l2ork on the same system.
- Windows: Renamed the inno package so that it's more GitHub-friendly. This is for my own benefit, so that I don't have to manually rename the files each time I'm doing a release on GitHub. :smile:
I already have a 2.19.0 pre-release up for this at https://github.com/agraef/purr-data/releases/tag/2.19.0.
Here's proof that it works, wolf and lamb living together. :)
![image](/uploads/a2b913adc8a33237f6380d77ac40019f/image.png)https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/844pd-lua update to 0.11.42023-01-25T02:40:16ZAlbert Gräfpd-lua update to 0.11.4This updates pd-lua to 0.11.4, cf. https://github.com/agraef/pd-lua/releases/.
pd-lua now uses the latest pd-lib-builder and includes lua as a submodule, so building it as a part of purr-data becomes a lot easier. Most notably, Lua 5.4 ...This updates pd-lua to 0.11.4, cf. https://github.com/agraef/pd-lua/releases/.
pd-lua now uses the latest pd-lib-builder and includes lua as a submodule, so building it as a part of purr-data becomes a lot easier. Most notably, Lua 5.4 is linked statically from lua/onelua.c, so Lua isn't needed as a build or runtime dependency any more and the resulting external will use exactly the same Lua version across different platforms.
Also, the latest pd-lua sports various important bugfixes and documentation updates.https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/843Keep track of the actual device names in the audio and MIDI prefs2023-01-03T22:40:19ZAlbert GräfKeep track of the actual device names in the audio and MIDI prefsThis fixes one of my pet peeves with the device prefs, namely that audio and midi devices get messed up if new devices get plugged in or existing devices unplugged between invocations. Currently only the device indices are kept in the pr...This fixes one of my pet peeves with the device prefs, namely that audio and midi devices get messed up if new devices get plugged in or existing devices unplugged between invocations. Currently only the device indices are kept in the prefs, but these indices keep changing all the time as the device list is changing. This affects, in particular, the ALSA audio, portaudio and portmidi backends. (The Jack audio and ALSA MIDI backends don't really suffer from this as only the number of input and output ports is configurable in these cases.)
We resolve this by keeping track of the actual device names in addition to the device indices. This enables us to remap device indices on the fly during startup, so that the right devices are opened. More precisely, when reading the device indices from the prefs, it is checked whether a corresponding device name has been saved. If so, then the device name is used to find the actual index for that device. If no device name was saved (old prefs), or if the name doesn't exist any more (presumably because the device was unplugged), then we fall back to the previous behavior of using the saved device index as is -- which will give fairly random results depending on what's currently in the device list, but then we can't help it.
Note that this doesn't provide hotplugging support, which is really what we'd like to have, but is currently impossible due to backend limitations. That is, you still can't plug or unplug devices and have Purr Data pick up the new device list while it keeps running. But at least Purr Data will not connect to the wrong devices on relaunch any more, which is a major annoyance when hotplugging audio or MIDI devices during a session (which is pretty common in this day and age).Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/842Apple Silicon support2023-01-03T22:39:45ZAlbert GräfApple Silicon supportI found that previous Intel builds on macOS did not work on new Apple Silicon (M1, M2) Macs, mainly due to GUI issues, and the source wouldn't compile on my M1 Air either, so I set out to do a proper port which includes the following com...I found that previous Intel builds on macOS did not work on new Apple Silicon (M1, M2) Macs, mainly due to GUI issues, and the source wouldn't compile on my M1 Air either, so I set out to do a proper port which includes the following compilation fixes and updates required to make Purr Data work on that platform:
- nw.js updated to 0.71.0 (macOS only)
- bundled portaudio updated to the latest stable release ([19.7.0](https://github.com/PortAudio/portaudio/releases/tag/v19.7.0))
- fixes to scripts and Makefiles required to make the source compile properly on Apple Silicon Macs
- backported some macOS arm64 related fixes from vanilla
**NOTES:**
- The full native arm64 build doesn't work yet. It crashes in seemingly random places during launch. I haven't been able to sort those out yet, maybe someone else who is more proficient with macOS arm64 will be more lucky.
- **For the time being, use the Intel build from this branch instead, it works fine on arm64 via Rosetta 2.** The native arm64 _light_ build seems to work fine, too.
- While nw.js 0.71.0 appears to work fine on macOS, I couldn't get it to work properly on Linux, and thus the Linux and Windows builds still use the tried and tested 0.28.3. (Slight version bump from 0.28.1 to 0.28.3 there, which is the final point release in the 0.28 series which we've been using for some years now.)
- There's no official native macOS arm64 build of nw.js yet, so we use the Intel one, which reportedly works fine via Rosetta 2.
Tested on macOS (Intel Big Sur 11.7.2, M1 Ventura 13.1) with the latest Xcode and Homebrew, as well as on Linux and Windows.
Test builds of this branch (at rev. e0562d0bdbfaf5ddd8bb9a668d69c52293c2ae3e) for macOS (full Intel build, as well as arm64 light) and Windows can be found on my university seafile: https://seafile.rlp.net/d/befe61ce07d34d36b5d6/
Test builds of the same revision for various Linux systems can be found on the OBS: https://build.opensuse.org/package/show/home:aggraef:test/purr-data
See below for some notes on how to do an Intel build on Mac M1/M2, if you want to roll your own.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/841Get rid of the python2 build dependency.2022-11-18T04:29:52ZAlbert GräfGet rid of the python2 build dependency.Python 2 has been EOL since 2019, and has recently been removed from the Arch repositories, so continuing to support it has become a major
hassle for me, especially on the OBS. The quick and dirty fix is to just build the DISIS cwiid lib...Python 2 has been EOL since 2019, and has recently been removed from the Arch repositories, so continuing to support it has become a major
hassle for me, especially on the OBS. The quick and dirty fix is to just build the DISIS cwiid library without it, which seems to be the only part of the source which at present still depends on Python 2 at build time. This lets us keep the DISIS externals as they are, while also getting rid of the python2 build dependency.
TBH, I'm not sure whether the disis_wiimote external requires the cwiid Python interface in any way. FWIW, I can't find any Python references in the DISIS external source, so I think that it should be fine without it. But I couldn't actually test this since the disis_wiimote object stopped working for me ever since bluez 5 (i.e., a long time ago).
I've run test builds of this branch on the OBS, all fine on Arch, Debian, Fedora, Raspbian, and Ubuntu. The proposed changeset should only affect Linux systems, but I also made sure that the source still compiles and runs on Mac and Windows anyway.Jonathan WilkesJonathan Wilkeshttps://git.purrdata.net/jwilkes/purr-data/-/merge_requests/840fixes to get Purr building on catalina2022-09-12T20:37:03ZJonathan Wilkesfixes to get Purr building on catalinaThis *should* get Purr Data building correctly on OSX Catalina.
Mostly just implicit declarations in various old external libraries.
Did have to remove `[apple/keyboard_layout]`, though. I can't find those carbon.h function calls anywh...This *should* get Purr Data building correctly on OSX Catalina.
Mostly just implicit declarations in various old external libraries.
Did have to remove `[apple/keyboard_layout]`, though. I can't find those carbon.h function calls anywhere on the web.