Am 28. November 2021 05:59:55 MEZ schrieb Alexandre Torres Porres
:
>testing 0.52, I realize deken hides all but the latest release, and they
>all show when uncheck "hide foreign architecture".
>
>looks like a bug, right?
No.
Looks like intended behaviour.
Or did you uncheck the "Only show the
Following over dozen of new releases in the past 2 months, in the spirit of
thanksgiving, L2Ork (http://l2ork.music.vt.edu) is pleased to announce
latest release of Pd-L2Ork (dated 2021-11-21) for Linux, OSX, and Windows,
featuring a number of bug-fixes and community requests, including:
*Proper
testing 0.52, I realize deken hides all but the latest release, and they
all show when uncheck "hide foreign architecture".
looks like a bug, right?
Em dom., 28 de nov. de 2021 às 00:39, Alexandre Torres Porres <
por...@gmail.com> escreveu:
> Em sáb., 27 de nov. de 2021 às 21:33, Miller
Em sáb., 27 de nov. de 2021 às 21:33, Miller Puckette via Pd-list <
pd-list@lists.iem.at> escreveu:
> I don't know which way to go on this one... I think it's a bad
> idea to have a shortcut for "symbol" since it's more often hit
> by accident than on purpose - and it confuses people who make
Em sáb., 27 de nov. de 2021 às 21:59, Christof Ressi
escreveu:
> On 28.11.2021 01:29, Miller Puckette via Pd-list wrote:
>
> > I disagree with the "$0" in message box idea. Why not $1 then?
> > (Oh, because it already does something different...)
>
> But the same is true for canvas creation
I updated my file. It seems the only "tricky" message is 'coords', right?
I put a warning about it. So, does it settle it?
Em sáb., 27 de nov. de 2021 às 22:01, Christof Ressi
escreveu:
> I very much agree with your points.
>
> If we lump "user space" and "internal" messaging together in an
I think this is right. "pd dsp 1" is definitely public, and "watchdog"
isn't. Perhaps there should be two different destinations for the public
and non-public ones. but it would be cruel to change that just to clean
the situation up, when people are probably using some things that I
would think
I very much agree with your points.
If we lump "user space" and "internal" messaging together in an open
manual, then they should be clearly delineated with special placed on
emphasizing what things are more or less stable and what things are
not. Then the user can decide how they want to
On 28.11.2021 01:29, Miller Puckette via Pd-list wrote:
I disagree with the "$0" in message box idea. Why not $1 then?
(Oh, because it already does something different...)
But the same is true for canvas creation arguments! $0 is not a creation
argument after all, i.e. it is not part of
Em sáb., 27 de nov. de 2021 às 21:29, Miller Puckette
escreveu:
> I'll leave the "bang~ inlet there - I think it doesn't need to be
> documented because it doesn't do anything :)
>
we should document it does nothing then :) otherwise people can think it
does something that it was forgotten to
I don't know which way to go on this one... I think it's a bad
idea to have a shortcut for "symbol" since it's more often hit
by accident than on purpose - and it confuses people who make them
thinking they're making floats.
cheers
M
On Tue, Nov 23, 2021 at 10:00:47PM +0100, Roman Haefeli wrote:
I disagree with the "$0" in message box idea. Why not $1 then?
(Oh, because it already does something different...)
It would be interestnig to allow message boxes to access canvas creation
arguments somehow, but not that way.
Meanwhile I adopted the atan2 fix but then had to fix a compileer
Hmm.. I just finished fixing it to leave it turned off by default
(it bothers some people and pleases others, so the tiebreaker is to default
to previous behavior).
Meanwhile merging the no-select-text PR - I meant to do that
earlier but somehow missed it.
On Sun, Nov 28, 2021 at 12:25:41AM
Howdy all,
My feeling on this is:
1. Recognize that, despite using "private" or "unstable" internal APIs, people
have been using/abusing them for years. (So far, I feel we have been
recognizing this by being careful not to break things, more or less.)
2. We should document all internal
## Inactive Patch Coords
I think it should be on by default as I imagine more people could use it but it
should have a disable option somehow for those that don't. I might be wrong in
thinking that they are a minority though. Maybe there could be some sort of
experimental feature commanding
... I'm thinking now to leave it in but have it turned off by default -
that way it would be easy to add as a preference later.
M
On Wed, Nov 24, 2021 at 09:53:09PM +0100, Dan Wilcox wrote:
> Oh and I forgot:
>
> # Active Patch Cable Highlight
>
> I think greying out the active patch cable is
Oops, fixed now, thanks.
On Thu, Nov 25, 2021 at 12:34:39AM -0300, Alexandre Torres Porres wrote:
> hey, release notes says "libpd included as part of the Pd distribution. A
> test libpd project is included in ../pd/libpdtest." but I can't find this.
>
> Em qua., 24 de nov. de 2021 às 21:38,
On 27/11/2021 17:19, pd-list-requ...@lists.iem.at wrote:
ForwardedMessage.eml
Subject:
Re: [PD] documenting messages to/from Pd and dynamic patching
From:
Christof Ressi
Date:
27/11/2021 à 17:01
To:
Pd-List
Two examples that come to my mind:
1) [iemguts/canvasselect] allows to (de)select
just adding to my previous email below on how namecanvas talks about
abstractions. It actually already did talk before, but I made it more
clear, saying "*This is sometimes the only way to send a message to a
canvas when initializing graph-on-parent abstractions with local parameters
(using "$0"
if I remember correctly iemguts also adds the possibility of deleting
objects without the need to simulate a mouse select and a keyboard
stroke (cut? idk..)
Yes! [iemguts] adds a "delete" method to the canvas class so that you
can delete individual objects by index.
On 27.11.2021 17:25, José
You know, data structures explicitly use messages to subpatches, like
'clear' and 'read/write'. So at least these are official. And the
namecanvas help file had the example to make the patch create messages and
we can agree this is pretty stable and used in patches. Also, 'connect'
messages are
if I remember correctly iemguts also adds the possibility of deleting
objects without the need to simulate a mouse select and a keyboard stroke
(cut? idk..)
(I don't know, but I think there was something about deleting with mouse
emulation, but this was buggy too since you need to first bring the
Perhaps referring to this black magic library is something I could do in
the document.
Em sáb., 27 de nov. de 2021 às 13:18, Alexandre Torres Porres <
por...@gmail.com> escreveu:
> nice!
>
> Em sáb., 27 de nov. de 2021 às 13:04, Christof Ressi <
> i...@christofressi.com> escreveu:
>
>> Two
nice!
Em sáb., 27 de nov. de 2021 às 13:04, Christof Ressi
escreveu:
> Two examples that come to my mind:
>
> 1) [iemguts/canvasselect] allows to (de)select objects simply by index. No
> need to emulate mouse selection with "mouse" and "mouseup".
>
> 2) canvases/objects can be moved around with
Em sáb., 27 de nov. de 2021 às 08:23, João Pais
escreveu:
> It could also be clearly mentioned that subpatches receive messages sent
>> to pd-[subpatch], and abstractions are named [abstraction].pd (if I'm
>> recalling correctly) - unless there is a namecanvas used in those.
>>
>
> how isn't it
Two examples that come to my mind:
1) [iemguts/canvasselect] allows to (de)select objects simply by index.
No need to emulate mouse selection with "mouse" and "mouseup".
2) canvases/objects can be moved around with [iemguts/canvasposition]
resp. [iemguts/canvasobjectposition]
Are there any
Em sáb., 27 de nov. de 2021 às 11:59, Christof Ressi
escreveu:
> with [iemguts] there really is no reason to ever use
> "mouse" and "mouseup" again. Unfortunately, many people seem to prefer
> undocumented internal messages over a well tested external...
>
how exactly? please elaborate and give
(I forgot why they are "illegal"),
They are not "illegal", they are private. As I tried to explain in the
last mail, messages like "donecanvasdialog" or "mouseup" are used for Pd
core <-> GUI communication. The only reason why they exist in the first
place is because Pd core and GUI live in
but I've been using them for more than 15 years with no big issues.
Well, a few years ago Miller changed the [donecanvasdialog( message. I
noticed that it will break dynamic patching and asked him to use a
workaround. He was nice enough to do it. So you were just lucky ;-)
Note that the
If any of these methods is cut, then my patches won't work anymore -
hopefully someone else's as well.
You are using private APIs. Nobody made a guarantee that it would work
forever.
That being said, we try not to change - let alone remove - those methods
unless absolutely necessary.
but
Em sex., 26 de nov. de 2021 às 20:19, João Pais
escreveu:
I don't see a mention to these messages: mouse, mouseup, mousedown,
relocate. And also all other messages related to gui stuff.
yeah, I didn't put it. It felt like something hard to document and for
more extreme cases. And
31 matches
Mail list logo
