This is a regression introduced with the nw.js update on Linux and
Windows (Mac seems to be fine), presumably because nw.js prefers IPv6
now, while the C engine still "talks" IPv4. The symptom is that if the
user tries to open a patch through a secondary purr-data instance,
opening the socket on "localhost" in the primary instance fails with a
"connection refused" error.

We now work around this by first calling dns.setDefaultResultOrder (if
it exists; earlier versions at least up to 0.42.0 don't have it) to
ensure that IPv4 addresses are preferred in any case.

In addition, we now print an error message if the connection attempt in
the primary instance fails for some other reason, so that the user at
least knows that something went wrong. The error message will be
somewhat cryptic, but decipherable by any network expert. :)

I wonder how this ever worked, probably it didn't. Thus the help index
was never removed and hence never rebuilt when changing the browser
options in the GUI preferences. This is fixed now.

*Reimplemented next/prev patch window feature to make it work with newer nw.js. Should also work with older ones.
*Fixed issue where prev/next window from the main Pd window did not work on Windows and Linux.

Also fixed gui_raise_pd_window() (Ctrl+R) after the nw.js version change.

Thanks Ico!

See:

https://github.com/pd-l2ork/pd-l2ork/commit/557e372
https://github.com/pd-l2ork/pd-l2ork/commit/c2a3879
https://github.com/pd-l2ork/pd-l2ork/commit/ef920c9

* Added mic/camera permissions request to the Info.plist (OSX).
* Added OSX code signing, which should also fix the inability to access microphone and camera on Catalina or newer OSs.

Thanks Ico and MovementGH!

See:

https://github.com/pd-l2ork/pd-l2ork/commit/4dd114f
https://github.com/pd-l2ork/pd-l2ork/commit/5a99fac

(Edited pd-l2ork -> purr-data branding.)

Backport from vanilla:
https://github.com/pure-data/pure-data/commit/b00725132b

This is merely a work-around, to make the source compile again on
mingw64. An update of portmidi and portaudio is due some time in the
next vanilla release, we should probably follow suit when that happens.

Compilation fixes

See merge request !864

MacOS 11 a.k.a. Big Sur is the last version supported on older MacBooks,
so we stick to that for now. (This is already deprecated on GH CI, so we
might have to move to macOS 12 or 13 in the future.)

- Bugfixes (g_numbox.c, pdgui.js, dialog_search.html).

- Various fixes for better vanilla compatibility (please check the
  commit log for details).

- Added new PURR_DATA and PD_FLAVOR symbols to m_pd.h to make it easier
  for 3rd party externals to check which Pd flavor they're working with.

- Updated pd-lua to 0.11.6 (tutorial updates).

- Revised README (updated some outdated information, removed some l2ork
  branding, fixed some typos and formatting glitches).

In the latest msys2/mingw, libssp-0.dll has gone missing, which was
previously needed for libfluidsynth. Also, libsnfile has a new
dependency on libmpg123-0.dll.

Albert Gräf authored 2 years ago and Albert Gräf committed 1 year ago

Gem has been included in the Mac version for quite some time now, so we
remove the "(Windows and Linux only)" text from the corresponding
section descriptions in the help browser.

The problem that we're trying to solve here is that there is no reliable
way for objects to be notified when the edit mode status of their canvas
changes. This problem exists across various flavors, but is made worse
in Purr Data because it uses an ancient version of the canvas_editmode
method which interprets a zero argument to mean "toggle", not "off".

This makes it virtually impossible for 3rd party objects to observe edit
mode changes while they are still in progress, as they simply cannot
know whether the edit mode bit has already been flipped or not.

The solution: Killing two birds with one stone, we first refactor
existing gui notifications about edit mode changes in various places so
that they now all go through a single function canvas_announce_editmode.
This function then goes on to call the new canvas_dispatch_editmode
function which takes care of notifying all receivers on the C side,
after which the gui gets notified as before.

This also makes sure that the new edit mode status is announced in both
temporary run mode (set in the key handler) and calls to
canvas_editmode and canvas_query_editmode (both direct and through the
message interface), which should cover all relevant cases.

NOTE: The receiver symbol is canvas-specific and takes the form
<canvas>#editmode where <canvas> is the canvas id (hex code), so that
presumably only objects on the specific canvas will receive the message.

[declare -legacy] enables legacy positioning as with the global -legacy
flag, but on a canvas-local basis. If not set in a patch, the flag
defaults to its global counterpart. Note that there is no argument, so
you can only enable this, not disable it. Moreover, once set, the flag
is inherited by all subpatches.

This declaration allows you to use vanilla subpatches in Purr Data where
iemguis are positioned in a slightly different way, which may cause gop
patches created in vanilla to be rendered incorrectly.

Adding [declare -legacy] to the vanilla subpatch gets rid of these
issues, while the rest of your patch is rendered as usual. Note that the
global -legacy startup option will affect *all* patches loaded by Purr
Data, which doesn't help if only some subpatches must be rendered in a
vanilla-like fashion.

Previously we only had fwd (from GSoC 2020).

Backport from:
https://github.com/pure-data/pure-data/commit/a5a8a3ba
https://github.com/pure-data/pure-data/commit/377f1947

This is for the benefit of 3rd party external libraries which may need
to know which Pd flavor they're working with. We've had the PDL2ORK
symbol in m_pd.h for a while, but with DISIS Pd-l2ork 2 that's no longer
unambiguous, so we added the PURR_DATA symbol now.

We also added a new PD_FLAVOR symbol which is defined to be a string
describing the Pd flavor. This is currently only present in Purr Data's
m_pd.h header, of course, but it might conceivably be picked up by other
active flavors such as plugdata in the future.