wn
>>>> machine and crash Pd... that's half the fun for such activities anyway
>>>> (learning).
>>>>
>>>> 3. We should get a poll of which internal messages are currently in use
>>>> and consider which of these could be moved into "user s
y useful even if
clunky through the current workarounds. Even with
[clone] there are still many use cases...
On Nov 28, 2021, at 12:25 AM,
pd-list-requ...@lists.iem.at wrote:
Message: 1
Date: Sat, 27 Nov 2021 20:20:4
rash Pd... that's half the fun for such activities anyway
>>> (learning).
>>>
>>> 3. We should get a poll of which internal messages are currently in use
>>> and consider which of these could be moved into "user space" and/or
>>> re
s. Even with [clone] there are
still many use cases...
On Nov 28, 2021, at 12:25 AM, pd-list-requ...@lists.iem.at
wrote:
Message: 1
Date: Sat, 27 Nov 2021 20:20:49 +0100
From: Jean-Yves Gratius
To:pd-list@lists.iem.at
Subject: Re: [PD] documenti
d/or
>> replaced by a better API. I believe this thread is already providing a good
>> list...
>>
>> 4. Open a technical discussion on supporting "dynamic patching"
>> officially. It's clearly very useful even if clunky through the current
>> workar
I realize now how this can be useful and important to make abstractions
fire a loabdang if they are created via dynamic patching!
Well, I added this information then, with examples.
Em dom., 28 de nov. de 2021 às 17:30, Alexandre Torres Porres <
por...@gmail.com> escreveu:
>
>
> Em dom., 28 de
Em dom., 28 de nov. de 2021 às 16:33, João Pais
escreveu:
> I think you didn't understand - if you have an abstraction called "abs1"
> used in the patch, sending messages to pd-abs1 won't work. They need to be
> sent to pd-abs1.pd - and that could be clearly named in the documentation.
>
Oh, I se
The first one is mentioned in [pd Dynamic-Patching], although it
might be easier to understand if there is an example immediately
under the text.
what do you mean by "immediately under the text"?
just a couple of objects under the paragraph where it explains it. then
it's more di
. It's clearly very useful even if clunky through the current
> workarounds. Even with [clone] there are still many use cases...
>
> On Nov 28, 2021, at 12:25 AM, pd-list-requ...@lists.iem.at wrote:
>
> Message: 1
> Date: Sat, 27 Nov 2021 20:20:49 +0100
> From: Jean-Y
ng "dynamic patching"
> > officially. It's clearly very useful even if clunky through the current
> > workarounds. Even with [clone] there are still many use cases...
> >
> > > On Nov 28, 2021, at 12:25 AM, pd-list-requ...@lists.iem.at wr
workarounds. Even with [clone] there are still many use cases...
On Nov 28, 2021, at 12:25 AM, pd-list-requ...@lists.iem.at wrote:
Message: 1
Date: Sat, 27 Nov 2021 20:20:49 +0100
From: Jean-Yves Gratius
To:pd-list@lists.iem.at
Subject: Re: [PD] documenting messages to/from Pd and dynamic patch
;
>
> On 27/11/2021 17:19, pd-list-requ...@lists.iem.at
> <mailto:pd-list-requ...@lists.iem.at> wrote:
>> ForwardedMessage.eml
>>
>> Subject:
>> Re: [PD] documenting messages to/from Pd and dynamic patching
>> From:
>> Christof Ressi mailto:i...@c
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" to
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é d
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 use
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 exampl
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 c
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 dif
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 mes
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 I'
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 n
+1 to having them in the docs but clearly labelled as something along the
lines of "not in the public API - may change without notice". That kind of
stuff is really helpful to people coming up on the whole system to better
understand how it all works.
my two cents Canadian. :-)
On Fri, Nov 26, 20
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 now that
I don't see a mention to these messages: mouse, mouseup, mousedown,
relocate. And also all other messages related to gui stuff.
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) -
Em sex., 26 de nov. de 2021 às 17:18, Christof Ressi
escreveu:
> don't advertize "coords" (at least you didn't mention "donecanvasdialog")
> because that one should really be replaced by
> https://github.com/pure-data/pure-data/pull/627 (hopefully in the next Pd
> release :-)
>
yeah, makes sense
> In particular, please don't include any GUI dialog messages
which are they all?
anyway, I felt I was crossing a line, hence I'm waving here to the judges
:)
For instance, [namecanvas] did include a 'msg' message to canvas. I count
that as a modest dynamic patch documentation.
Also, many of us
I think there are definitely many "official" messages (e.g. "dsp",
"fast-forward", "quit", etc.) that need to be documented properly, so in
principle I very much welcome this effort.
However, I'm rather sceptical about including any "dynamic patching"
messages in the official documentation as
new commit, forgot about 'dirty'
https://github.com/pure-data/pure-data/pull/1455/commits/8fe7ff12419c797bf33e6ff0409798d089dfba25
patch attached
Em sex., 26 de nov. de 2021 às 17:05, Alexandre Torres Porres <
por...@gmail.com> escreveu:
> the reason I ask for revisions here is that I'm not an e
the reason I ask for revisions here is that I'm not an expert on this dark
magic, so I'm not 100% sure about things. I can revert the commit in the PR
and keep it on the fridge for the next release update if the real wizards
see problems on it.
Em sex., 26 de nov. de 2021 às 16:59, Alexandre Torre
People, I'm on a roll here, updating much of the help files and
documentation.
I just hit an important new addition, documenting "Messages to/from Pd" and
"Dynamic Patching"
I'd like you people to revise it.
Here's the commit =>
https://github.com/pure-data/pure-data/pull/1455/commits/0ec5429629
35 matches
Mail list logo
