See: https://github.com/pure-data/pure-data/commit/46c2a342

This one change is inconsequential since it's just a demo object that
doesn't actually get compiled, but we should also have the examples
use the correct code.

This adds some features that purr-data still lacked:
- multi-channel support (0.54)
- pd fast-forward support (0.53)

This changeset is quite large, but fortunately pd-l2ork just recently
backported these features from vanilla Pd, so thanks are due to
MovementGH and Ico Bukvic again. See:
https://github.com/pd-l2ork/pd-l2ork/pull/53
https://github.com/pd-l2ork/pd-l2ork/commit/be5183c2
https://github.com/pd-l2ork/pd-l2ork/commit/6fd93d21

Please note that I pulled g_io.c straight from vanilla instead (see the
previous commit), since pd-l2ork currently lacks some vanilla features
that were already added in purr-data.

This adds multi-channel support.

We pull this one straight from vanilla, since pd-l2ork currently lacks
some updates (resampling, inlet~ message forwarding) that purr-data
already ported a while ago.

Revert the changes to m_private_utils.h in rev. eac22a49.
Added the required -DPD_INTERNAL compilation flag in configure.ac.

Backport from https://github.com/pd-l2ork/pd-l2ork/commit/5397ff79.
Thanks MovementGH!

Backport from https://github.com/pd-l2ork/pd-l2ork/commit/afd5cb77.
Thanks MovementGH!

Backport from pd-l2ork, see:
https://github.com/pd-l2ork/pd-l2ork/commit/9b2c6ec4

Also see the previous commit for details.

In particular, this adds IPv6 support. This was added already in Pd 0.51
by Dan Wilcox, Christof Ressi, and IOhannes Zmoelnig, thanks!

Also thanks to Ico for backporting these to pd-l2ork, which is where I
grabbed this changeset. See:
https://github.com/pd-l2ork/pd-l2ork/commit/9b2c6ec4

Made the algorithm a lot more flexible by applying some heuristics to
estimate whether the selected objects are primarily layed out in a
vertical (row-based) or in a horizontal (column-based) configuration.

Thus, in addition to the common case of vertical connections, the
algorithm now also deals with horizontal arrangements which occur in
some use cases such as ladder structures.

Furthermore, the algorithm tries to cope with situations where the
target object comes *before* the source object, by reversing the order
of the primary coordinate. E.g., this will allow you to make back
connections running from bottom to top instead of the usual
downward-pointing connections.

This means that mode 4 offers more possibilities for connections now,
which comes at the cost of permitting some corner cases where the
results are less predictable. But the results should still be a lot more
predictable than with the old implementation.

Fixed a few more bugs in the multi-connect fan-out and fan-in modes.

Also added a third option to do parallel connections, which is activated
by holding the ctrl key while doing the initial connection. (This was
previously used to reverse the fan-out / fan-in choice, so this
functionality is not available anymore. But it was largely obsolete with
the new algorithm anyway, while the new parallel connection feature
provides genuinely useful new functionality.)

Parallel connections quite simply connect as many selected object pairs
as possible, going left to right starting at the initial y1-y2 pair, and
using the same outlet and inlet numbers as in the initial connection:

y1 y1' y1'' ...
|  |   |
y2 y2' y2'' ...

I have always missed this feature. It's very basic, but useful in so
many situations. While this isn't a multi-connect operation in the same
sense as the fan-out and fan-in operations in mode 4, it uses the same
basic interface and visual top-to-bottom and left-to-right selection
order, so it was most convenient to add it there.

This is the multi-connect mode where you select 3 or more objects,
connect any two of them, and then hope for the best. ;-)

This never worked for me. You know that there's something wrong if a
feature needs more than a few lines of text to explain it. The outcomes
were often unpredictable, and I always considered the visual order being
used (left-to-right then top-to-bottom) to be the wrong one.

I corrected this now, so that a top-to-bottom then left-to-right order
of the selection is used, and the choice of connections is more limited:
if y1--y2 is the initial connection, then only sources to the right of
y1 and targets to the right of y2 will be considered, and the operation
will just fail if y2 comes before y1 in the visual order. This also
makes it much easier to paint a mental image of the operation in terms
of two rows of objects, the source row containing y1 above, and the
target row containing y2 below it.

I think that this works in a more intuitive fashion, and while the
possible connections are more limited, they are also much more
predictable. The operation still does either fan-out or fan-in, based
on what will give you the most connections, breaking ties in favor of
fan-outs. It also still reverses the choice if you hold ctrl while
connecting, but it seems that the operation will now do the right thing
most of the time without that crutch.

This is still a bit experimental, but for starters it works reasonably
well already. Formatting is done by adding certain formatting tags to
the input, please check the help patch for details. Note that there's no
WYSIWYG editing of the formatting at present, this may still be added in
the future.

Obviously, this won't replace your word processor anytime soon, and
entering all the formatting tags can get a bit tedious without any GUI
support. But at least it provides you with some useful formatting
options for comments to improve their readability and make them visually
more appealing.

The same caveats apply as with explicit line breaks in comments. That
is, none of the formatting tags will work in vanilla Pd at present,
instead you will see the text as shown while editing the comment box.
Which doesn't look great, TBH, thus rich text formatting is best avoided
in patches that you plan to use with vanilla Pd.

This was an ill-fated attempt to employ variable-length lookback in
order to make the regex "count" the parity of consecutive backslashes
preceding trailing whitespace, like the Pd binbuf parser does. But that
doesn't work with the JS RE engine at least, so I removed those bits
again.

What this means is that trailing whitespace will be kept in some cases
where the binbuf parser might have removed it, which shouldn't have any
grave consequences (fingers crossed). The important thing here is that
escaped trailing whitespace is kept and does not suddenly disappear when
editing an object, and that still works with the simplified regexes.