Re: [PD] documenting messages to/from Pd and dynamic patching
well, done, removed. Now, one last message isn't documented yet, the "sort" message, used in Data Structures. This comes up first at example 7.sequencer in the data structures examples, but we don't have any explanation why it happens. And the message is called multiple times, maybe in redundancy. This message should be explained in the Data Structures examples and in my pd-messages files under the Data Structure examples. Now, what exactly does it do and why is it needed in this example? Oh, it's also used in the 14.partial-tracckng example thanks cheers Em qua., 1 de dez. de 2021 às 18:14, Christof Ressi escreveu: > If you don't send [map 0, map 1( to the parent canvas, the graph will > still contain previous graphical elements. You don't notice this if you use > a mycanvas in the background, though. > On 01.12.2021 22:04, Alexandre Torres Porres wrote: > > yeah, I'll just take the 'coords' message out and keep the rest > > but it's not like it always needs map 0/1, does it? > > Em qua., 1 de dez. de 2021 às 18:03, Christof Ressi < > i...@christofressi.com> escreveu: > >> The problem with [coords( is that you also need to do [map 0, map1( to >> force a redraw of the parent canvas. This means you would have to document >> [map( as well. >> >> I would say don't document it for now and instead let's hope that we will >> *finally* get https://github.com/pure-data/pure-data/pull/627 (this PR >> is now already 2 1/2 years old...) >> >> Christof >> On 01.12.2021 20:24, Alexandre Torres Porres wrote: >> >> sorry to insist, but this has been already committed to my documentation >> branch and it's the only big change that I really worry about. So let's >> settle this before it's too late :) >> >> thanks >> >> Em sáb., 27 de nov. de 2021 às 22:28, Alexandre Torres Porres < >> por...@gmail.com> escreveu: >> >>> 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 < >>> i...@christofressi.com> escreveu: >>> >>>> 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 proceed. >>>> >>>> As you say, it's better to document all of it and at the same time make >>>> it clear what is public and what is private. And figure out how to deal >>>> with the large gray area in between :-) >>>> >>>> Christof >>>> On 28.11.2021 00:37, Dan Wilcox wrote: >>>> >>>> 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 messaging, at least for the sake of >>>> developer documentation. 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 proceed. I don't >>>> see a problem if people want to play with the internals on their own >>>> 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 space" and/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 >>>> 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
Re: [PD] documenting messages to/from Pd and dynamic patching
If you don't send [map 0, map 1( to the parent canvas, the graph will
still contain previous graphical elements. You don't notice this if you
use a mycanvas in the background, though.
On 01.12.2021 22:04, Alexandre Torres Porres wrote:
yeah, I'll just take the 'coords' message out and keep the rest
but it's not like it always needs map 0/1, does it?
Em qua., 1 de dez. de 2021 às 18:03, Christof Ressi
escreveu:
The problem with [coords( is that you also need to do [map 0,
map1( to force a redraw of the parent canvas. This means you would
have to document [map( as well.
I would say don't document it for now and instead let's hope that
we will *finally* get
https://github.com/pure-data/pure-data/pull/627 (this PR is now
already 2 1/2 years old...)
Christof
On 01.12.2021 20:24, Alexandre Torres Porres wrote:
sorry to insist, but this has been already committed to my
documentation branch and it's the only big change that I really
worry about. So let's settle this before it's too late :)
thanks
Em sáb., 27 de nov. de 2021 às 22:28, Alexandre Torres Porres
escreveu:
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 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 proceed.
As you say, it's better to document all of it and at the
same time make it clear what is public and what is
private. And figure out how to deal with the large gray
area in between :-)
Christof
On 28.11.2021 00:37, Dan Wilcox wrote:
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 messaging, at least
for the sake of developer documentation. 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 proceed. I don't see a problem
if people want to play with the internals on their own
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 space" and/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 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 patching
Message-ID:
Content-Type: text/plain; charset="windows-1252";
Format="flowed"
On 27/11/2021 17:19,pd-list-requ...@lists.iem.atwrote:
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 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 other use cases for "mouse" and "mouseup"?
Hi. My 2 cents
Personally
Re: [PD] documenting messages to/from Pd and dynamic patching
yeah, I'll just take the 'coords' message out and keep the rest but it's not like it always needs map 0/1, does it? Em qua., 1 de dez. de 2021 às 18:03, Christof Ressi escreveu: > The problem with [coords( is that you also need to do [map 0, map1( to > force a redraw of the parent canvas. This means you would have to document > [map( as well. > > I would say don't document it for now and instead let's hope that we will > *finally* get https://github.com/pure-data/pure-data/pull/627 (this PR is > now already 2 1/2 years old...) > > Christof > On 01.12.2021 20:24, Alexandre Torres Porres wrote: > > sorry to insist, but this has been already committed to my documentation > branch and it's the only big change that I really worry about. So let's > settle this before it's too late :) > > thanks > > Em sáb., 27 de nov. de 2021 às 22:28, Alexandre Torres Porres < > por...@gmail.com> escreveu: > >> 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 < >> i...@christofressi.com> escreveu: >> >>> 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 proceed. >>> >>> As you say, it's better to document all of it and at the same time make >>> it clear what is public and what is private. And figure out how to deal >>> with the large gray area in between :-) >>> >>> Christof >>> On 28.11.2021 00:37, Dan Wilcox wrote: >>> >>> 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 messaging, at least for the sake of >>> developer documentation. 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 proceed. I don't >>> see a problem if people want to play with the internals on their own >>> 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 space" and/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 >>> 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 patching >>> Message-ID: >>> Content-Type: text/plain; charset="windows-1252"; Format="flowed" >>> >>> 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 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 other use cases for "mouse" and "mouseup"? >>> >>> Hi
Re: [PD] documenting messages to/from Pd and dynamic patching
The problem with [coords( is that you also need to do [map 0, map1( to
force a redraw of the parent canvas. This means you would have to
document [map( as well.
I would say don't document it for now and instead let's hope that we
will *finally* get https://github.com/pure-data/pure-data/pull/627 (this
PR is now already 2 1/2 years old...)
Christof
On 01.12.2021 20:24, Alexandre Torres Porres wrote:
sorry to insist, but this has been already committed to my
documentation branch and it's the only big change that I really worry
about. So let's settle this before it's too late :)
thanks
Em sáb., 27 de nov. de 2021 às 22:28, Alexandre Torres Porres
escreveu:
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 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 proceed.
As you say, it's better to document all of it and at the same
time make it clear what is public and what is private. And
figure out how to deal with the large gray area in between :-)
Christof
On 28.11.2021 00:37, Dan Wilcox wrote:
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 messaging, at least for
the sake of developer documentation. 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
proceed. I don't see a problem if people want to play with
the internals on their own 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 space" and/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 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 patching
Message-ID:
Content-Type: text/plain; charset="windows-1252";
Format="flowed"
On 27/11/2021 17:19,pd-list-requ...@lists.iem.atwrote:
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 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 other use cases for "mouse" and "mouseup"?
Hi. My 2 cents
Personally, I use mouse and mouseup messages to forward
multitouch
events into the patch, received? from my multitouch linux
laptop.
If those messages were blocked, all my multitouch ecosystem
would be out
of order :-) .
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com>
robotcowboy.com <http://robotcowboy.com>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management
->https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-mana
Re: [PD] documenting messages to/from Pd and dynamic patching
sorry to insist, but this has been already committed to my documentation branch and it's the only big change that I really worry about. So let's settle this before it's too late :) thanks Em sáb., 27 de nov. de 2021 às 22:28, Alexandre Torres Porres < por...@gmail.com> escreveu: > 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 < > i...@christofressi.com> escreveu: > >> 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 proceed. >> >> As you say, it's better to document all of it and at the same time make >> it clear what is public and what is private. And figure out how to deal >> with the large gray area in between :-) >> >> Christof >> On 28.11.2021 00:37, Dan Wilcox wrote: >> >> 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 messaging, at least for the sake of >> developer documentation. 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 proceed. I don't >> see a problem if people want to play with the internals on their own >> 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 space" and/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 >> 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 patching >> Message-ID: >> Content-Type: text/plain; charset="windows-1252"; Format="flowed" >> >> 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 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 other use cases for "mouse" and "mouseup"? >> >> Hi. My 2 cents >> >> Personally, I use mouse and mouseup messages to forward multitouch >> events into the patch, received? from my multitouch linux laptop. >> >> If those messages were blocked, all my multitouch ecosystem would be out >> of order :-) . >> >> >> >> Dan Wilcox >> @danomatika <http://twitter.com/danomatika> >> danomatika.com >> robotcowboy.com >> >> >> >> >> ___pd-l...@lists.iem.at mailing >> list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> >> ___ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 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 see! Yes, there's a very good reason I didn't put that in the > documentation: I had no idea that's how it works :) > > >> It is a quite peculiar situation,anyway. >> > > Then I'll just add the remark that abstractions need ".pd", but you should > most probably just use [namecanvas]. > > thanks > > Pd-messages.pd Description: Binary data namecanvas-help.pd Description: Binary data ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 see! Yes, there's a very good reason I didn't put that in the documentation: I had no idea that's how it works :) > It is a quite peculiar situation,anyway. > Then I'll just add the remark that abstractions need ".pd", but you should most probably just use [namecanvas]. thanks ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 didactical - although the whole patch is full of such examples, anyway. The second isn't mentioned at all, the search results for "abstraction" and ".pd" return elements in other types of contexts. You can see I also mentioned, in the same way as subpatches, that you can communicate with Pd patches, and I also have examples for that case so people could 'deduce' if I hadn't mentioned. I guess I can be more clear that an abstraction is a Pd file, but that seemed obvious to me. I also didn't want to give an explicit example with an abstraction cause then I'd have to create yet another file. But this might be a good thing to call them both in th help file of namecanvas and this pd-message file. 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. But I also made it clear how [namecanvas] is useful for abstractions in its help file, that I emphatically tell people to check for reference. And I don't think it makes sense to talk to an abstraction using its filename, cause you can't just communicate with a single abstraction. I also don't know of a use case that from a parent patch you need to send messages to abstractions like that. Seems like the sane way to communicate with abstractions is via inlets. I have an abstraction which is a midiroll-type of score with more than 35000 structs. As this is calculated dynamically when the main patch opens, so that I don't have to overload pd when programming. This is used only for the graphical display, so there are no other objects besides the structs. It is a quite peculiar situation,anyway. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 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 proceed. > > As you say, it's better to document all of it and at the same time make it > clear what is public and what is private. And figure out how to deal with > the large gray area in between :-) > > Christof > On 28.11.2021 00:37, Dan Wilcox wrote: > > 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 messaging, at least for the sake of > developer documentation. 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 proceed. I don't > see a problem if people want to play with the internals on their own > 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 space" and/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 > 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 patching > Message-ID: > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > 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 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 other use cases for "mouse" and "mouseup"? > > Hi. My 2 cents > > Personally, I use mouse and mouseup messages to forward multitouch > events into the patch, received? from my multitouch linux laptop. > > If those messages were blocked, all my multitouch ecosystem would be out > of order :-) . > > > > Dan Wilcox > @danomatika <http://twitter.com/danomatika> > danomatika.com > robotcowboy.com > > > > > ___pd-l...@lists.iem.at mailing > list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > Pd-messages.pd Description: Binary data ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 are private. cheers M On Sun, Nov 28, 2021 at 01:59:41AM +0100, Christof Ressi wrote: > 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 proceed. > As you say, it's better to document all of it and at the same time make it > clear what is public and what is private. And figure out how to deal with > the large gray area in between :-) > > Christof > > On 28.11.2021 00:37, Dan Wilcox wrote: > > 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 messaging, at least for the sake of > > developer documentation. 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 proceed. I don't see a problem if people want to play with the > > internals on their own 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 space" and/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 > > 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 patching > > > Message-ID: > > > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > > > > > On 27/11/2021 17:19,pd-list-requ...@lists.iem.atwrote: > > > > 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 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 other use cases for "mouse" and "mouseup"? > > > > > > > Hi. My 2 cents > > > > > > Personally, I use mouse and mouseup messages to forward multitouch > > > events into the patch, received? from my multitouch linux laptop. > > > > > > If those messages were blocked, all my multitouch ecosystem would be out > > > of order :-) . > > > > > > Dan Wilcox > > @danomatika > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_danomatika=DwICaQ=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=3S8AaMzeCf3L_b1ohfx7v5Vmbm9QKO8A6nogjGWv3Z3Enk15cmpKEduaMe33gBua=_ljqlgS1WWqMvkzRJQq_wfhezcRNCrDfMaHL5qQyNn8= > > > > > danomatika.com > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__danomatika.com=DwICaQ=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=3S8AaMzeCf3L_b1ohfx7v5Vmb
Re: [PD] documenting messages to/from Pd and dynamic patching
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 proceed. As you say, it's better to document all of it and at the same time make it clear what is public and what is private. And figure out how to deal with the large gray area in between :-) Christof On 28.11.2021 00:37, Dan Wilcox wrote: 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 messaging, at least for the sake of developer documentation. 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 proceed. I don't see a problem if people want to play with the internals on their own 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 space" and/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 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 patching Message-ID: Content-Type: text/plain; charset="windows-1252"; Format="flowed" On 27/11/2021 17:19,pd-list-requ...@lists.iem.atwrote: 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 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 other use cases for "mouse" and "mouseup"? Hi. My 2 cents Personally, I use mouse and mouseup messages to forward multitouch events into the patch, received? from my multitouch linux laptop. If those messages were blocked, all my multitouch ecosystem would be out of order :-) . Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com> robotcowboy.com <http://robotcowboy.com> ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 messaging, at least for the sake of developer documentation. 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 proceed. I don't see a problem if people want to play with the internals on their own 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 space" and/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 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 mailto:j...@gumo.fr>> > To: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> > Subject: Re: [PD] documenting messages to/from Pd and dynamic patching > Message-ID: <mailto:f41bab20-e831-3f04-52fb-ba273b1e0...@gumo.fr>> > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > 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...@christofressi.com>> >> Date: >> 27/11/2021 ? 17:01 >> >> To: >> Pd-List mailto:pd-list@lists.iem.at>> >> >> >> 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 other use cases for "mouse" and "mouseup"? >> > Hi. My 2 cents > > Personally, I use mouse and mouseup messages to forward multitouch > events into the patch, received? from my multitouch linux laptop. > > If those messages were blocked, all my multitouch ecosystem would be out > of order :-) . Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 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 other use cases for "mouse" and "mouseup"? Hi. My 2 cents Personally, I use mouse and mouseup messages to forward multitouch events into the patch, received from my multitouch linux laptop. If those messages were blocked, all my multitouch ecosystem would be out of order :-) . ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 give it a local name).*" It's not that all too clear, but then, but I guess this is all a good reference that belongs in the documentation. It'll never replacce a dynamic patching tutorial, and maybe we need that too to make all things clear, but that's for later, and maybe ccan be achieved by third party tutorials, like my "Live Electronics Tutorial" that I'm also expanding to include tutorials on Data Structures and stuff... Em sáb., 27 de nov. de 2021 às 13:18, Alexandre Torres Porres < por...@gmail.com> escreveu: > > > 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 clearly mentioned? >> >> 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"? > > As you can see, I have two categories in this documentation file, both > highlighted and separated. They are: *"Messages to Pd"* (even though I > also document a couple of messages *"from"* Pd, > namely: pd-dsp-started/stopped). > > The other section is "*Messages you can send to Pd files and canvases*", > so yeah, this is where I document this, cause this is its category and it > only makes sense. And I clearly document all that you say here right in the > first paragraph. Quoting my text "*You can communicate with a Pd window > by sending messages to the name of the file (which communicates to the main > window). You can also commucate with a subpatch's window by sending > messages to the subpatch's name. In both cases you need to preceed the send > name with 'pd-'. Alternatively you can name a main window or a subpatch > with [namecanvas].*" You can see then that I ask people to check the > help file of [namecanvas], which has also been quite updated and also gives > the same information and uses some examples and refers back to this > document. > > But there are enough examples of [s pd-] in the patch anyway to deduce >> it. >> > 'deduce' it? Well, if you read that text, there's nothing to deduce :) > > The second isn't mentioned at all, the search results for "abstraction" >> and ".pd" return elements in other types of contexts. >> > You can see I also mentioned, in the same way as subpatches, that you can > communicate with Pd patches, and I also have examples for that case so > people could 'deduce' if I hadn't mentioned. > > I guess I can be more clear that an abstraction is a Pd file, but that > seemed obvious to me. I also didn't want to give an explicit example with > an abstraction cause then I'd have to create yet another file. But this > might be a good thing to call them both in th help file of namecanvas and > this pd-message file. > > But I also made it clear how [namecanvas] is useful for abstractions in > its help file, that I emphatically tell people to check for reference. And > I don't think it makes sense to talk to an abstraction using its filename, > cause you can't just communicate with a single abstraction. I also don't > know of a use case that from a parent patch you need to send messages to > abstractions like that. Seems like the sane way to communicate with > abstractions is via inlets. > > I can only see a reason to change the main patch window of an abstraction > from within the abstraction, to edit, for instance, is graph size. But in > this case it makes sense to use [namecanvas] with a local name using "$0". > > For now I guess I can make a more modest mentioning about this issue and > how you probably want to use [namecanvas] in as abstraction's main window > instead of sending messages to its filename. I dunno, maybe first we need > to agree if it makes sense at all for me to document "messages to > files/canvases", which ones, etc... > > cheers > > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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é de Abreu wrote: 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 canvas to front, and then emulate the mouse... no idea, but yeah, this is bad, and iemguts makes deleting very easy) Em sáb., 27 de nov. de 2021 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 [iemguts/canvasposition] resp. [iemguts/canvasobjectposition] Are there any other use cases for "mouse" and "mouseup"? On 27.11.2021 16:47, Alexandre Torres Porres wrote: 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 examples, I'm curious ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 used in patches and the syntax won't likely change (so won't 'disconnect'). So this leaves us me touching a dark corner apparently only when talking about 'coords' and I guess I can have a warning about it. And we change and document your PR when it gets in. I can also refer to iemguts for more stable and further wizardry. Em sáb., 27 de nov. de 2021 às 13:27, José de Abreu escreveu: > 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 canvas > to front, and then emulate the mouse... no idea, but yeah, this is bad, and > iemguts makes deleting very easy) > > Em sáb., 27 de nov. de 2021 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 [iemguts/canvasposition] >> resp. [iemguts/canvasobjectposition] >> >> Are there any other use cases for "mouse" and "mouseup"? >> On 27.11.2021 16:47, Alexandre Torres Porres wrote: >> >> >> >> Em sáb., 27 de nov. de 2021 às 11:59, Christof Ressi < >> i...@christofressi.com> 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 examples, I'm curious >> >> ___ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 canvas to front, and then emulate the mouse... no idea, but yeah, this is bad, and iemguts makes deleting very easy) Em sáb., 27 de nov. de 2021 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 [iemguts/canvasposition] > resp. [iemguts/canvasobjectposition] > > Are there any other use cases for "mouse" and "mouseup"? > On 27.11.2021 16:47, Alexandre Torres Porres wrote: > > > > Em sáb., 27 de nov. de 2021 às 11:59, Christof Ressi < > i...@christofressi.com> 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 examples, I'm curious > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 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 other use cases for "mouse" and "mouseup"? >> On 27.11.2021 16:47, Alexandre Torres Porres wrote: >> >> >> >> Em sáb., 27 de nov. de 2021 às 11:59, Christof Ressi < >> i...@christofressi.com> 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 examples, I'm curious >> >> ___ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 [iemguts/canvasposition] > resp. [iemguts/canvasobjectposition] > > Are there any other use cases for "mouse" and "mouseup"? > On 27.11.2021 16:47, Alexandre Torres Porres wrote: > > > > Em sáb., 27 de nov. de 2021 às 11:59, Christof Ressi < > i...@christofressi.com> 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 examples, I'm curious > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 clearly mentioned? > > 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"? As you can see, I have two categories in this documentation file, both highlighted and separated. They are: *"Messages to Pd"* (even though I also document a couple of messages *"from"* Pd, namely: pd-dsp-started/stopped). The other section is "*Messages you can send to Pd files and canvases*", so yeah, this is where I document this, cause this is its category and it only makes sense. And I clearly document all that you say here right in the first paragraph. Quoting my text "*You can communicate with a Pd window by sending messages to the name of the file (which communicates to the main window). You can also commucate with a subpatch's window by sending messages to the subpatch's name. In both cases you need to preceed the send name with 'pd-'. Alternatively you can name a main window or a subpatch with [namecanvas].*" You can see then that I ask people to check the help file of [namecanvas], which has also been quite updated and also gives the same information and uses some examples and refers back to this document. But there are enough examples of [s pd-] in the patch anyway to deduce > it. > 'deduce' it? Well, if you read that text, there's nothing to deduce :) The second isn't mentioned at all, the search results for "abstraction" and > ".pd" return elements in other types of contexts. > You can see I also mentioned, in the same way as subpatches, that you can communicate with Pd patches, and I also have examples for that case so people could 'deduce' if I hadn't mentioned. I guess I can be more clear that an abstraction is a Pd file, but that seemed obvious to me. I also didn't want to give an explicit example with an abstraction cause then I'd have to create yet another file. But this might be a good thing to call them both in th help file of namecanvas and this pd-message file. But I also made it clear how [namecanvas] is useful for abstractions in its help file, that I emphatically tell people to check for reference. And I don't think it makes sense to talk to an abstraction using its filename, cause you can't just communicate with a single abstraction. I also don't know of a use case that from a parent patch you need to send messages to abstractions like that. Seems like the sane way to communicate with abstractions is via inlets. I can only see a reason to change the main patch window of an abstraction from within the abstraction, to edit, for instance, is graph size. But in this case it makes sense to use [namecanvas] with a local name using "$0". For now I guess I can make a more modest mentioning about this issue and how you probably want to use [namecanvas] in as abstraction's main window instead of sending messages to its filename. I dunno, maybe first we need to agree if it makes sense at all for me to document "messages to files/canvases", which ones, etc... cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 other use cases for "mouse" and "mouseup"? On 27.11.2021 16:47, Alexandre Torres Porres wrote: 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 examples, I'm curious___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 examples, I'm curious ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
(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 different processes, otherwise they could simply be C function calls. The nice thing about a private API is that you can change/extend it at will. Once the private API becomes public, this becomes hard or even impossible. Now, the problem with Pd is that it doesn't really have a mechanism to prevent users from calling those internal messages. (The only exception being the "dsp" method.) and when possible new methods should come out to replace them. I think that's where we should put our focus on. Things like emulating mouse interaction by sending "mouse" and "mouseup" messages are a huge red flag. The user is obviously trying to achieve something and we should ask ourselves what it is exactly and how this could be done in a more sane way. So maybe a good start would be to collect different dynamic patching use cases and then think about possible new APIs that could help achieve them. My "goprect" PR is just one step in this direction. [iemguts] is also a good example of this approach: it basically provides a stable public API over a unstable private APIs. The advantage is that whenever Pd changes the implementation, only [iemguts] needs to be updated, instead of every patch that directly uses the internal message. For example, 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... Christof On 27.11.2021 14:32, João Pais wrote: 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 messages found in Pd patch files, like [obj ...(, are pretty stable. We can't really change them without breaking literally all existing patches. However, anything else should really be considered private. Particularly mnssages like [mouse(, [mouseup(, [donecanvasdialog( are obviously internal messages sent between Pd core and the GUI process. People just discovered them in the source code (or by watching the GUI/Pd traffic) and started (ab)using them for dynamic patching. The Pd extended folks included them in their documentation, so usage became more wide-spread. However, it was never officially supported in Pd vanilla. yes, at some point it would be good to assume that they can stay and keep being abused (I forgot why they are "illegal"), and when possible new methods should come out to replace them. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 messages found in Pd patch files, like [obj ...(, are pretty stable. We can't really change them without breaking literally all existing patches. However, anything else should really be considered private. Particularly mnssages like [mouse(, [mouseup(, [donecanvasdialog( are obviously internal messages sent between Pd core and the GUI process. People just discovered them in the source code (or by watching the GUI/Pd traffic) and started (ab)using them for dynamic patching. The Pd extended folks included them in their documentation, so usage became more wide-spread. However, it was never officially supported in Pd vanilla. yes, at some point it would be good to assume that they can stay and keep being abused (I forgot why they are "illegal"), and when possible new methods should come out to replace them. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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'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 messages found in Pd patch files, like [obj ...(, are pretty stable. We can't really change them without breaking literally all existing patches. However, anything else should really be considered private. Particularly mnssages like [mouse(, [mouseup(, [donecanvasdialog( are obviously internal messages sent between Pd core and the GUI process. People just discovered them in the source code (or by watching the GUI/Pd traffic) and started (ab)using them for dynamic patching. The Pd extended folks included them in their documentation, so usage became more wide-spread. However, it was never officially supported in Pd vanilla. Christof On 27.11.2021 12:22, João Pais wrote: 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 Christof says I should really keep out of this dark corner, I wonder if I did right. I don't remember now exactly why these methods are "dangerous" and "unofficial" (it was discussed already a lot in the list anyway), but I've been using them for more than 15 years with no big issues. If any of these methods is cut, then my patches won't work anymore - hopefully someone else's as well. 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 clearly mentioned? 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. But there are enough examples of [s pd-] in the patch anyway to deduce it. The second isn't mentioned at all, the search results for "abstraction" and ".pd" return elements in other types of contexts. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 Christof says I should really keep out of this dark corner, I wonder if I did right. I don't remember now exactly why these methods are "dangerous" and "unofficial" (it was discussed already a lot in the list anyway), but I've been using them for more than 15 years with no big issues. If any of these methods is cut, then my patches won't work anymore - hopefully someone else's as well. 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 clearly mentioned? 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. But there are enough examples of [s pd-] in the patch anyway to deduce it. The second isn't mentioned at all, the search results for "abstraction" and ".pd" return elements in other types of contexts. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
+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, 2021 at 4:15 PM Alexandre Torres Porres wrote: > 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 Christof says I should really keep out of > this dark corner, I wonder if I did right. > > >> 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 clearly mentioned? > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 Christof says I should really keep out of this dark corner, I wonder if I did right. > 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 clearly mentioned? ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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) - unless there is a namecanvas used in those. 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/0ec5429629eb1045c901ab9c74befd124ccb6e69 already in an open PR Cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 to wait for this. Now, is the next '0.52-0 final'? :) i know it's not :( ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
> 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 use and abuse these for ages now... what if the documentation also gives us a "heads up", some "warning" that this is unstable and should be used assuming risks? This would be better than just having people check for this kind of documentation in Pd-extended or something and worse stuff. But I see this might needs lots of debates, and as soon as I have more input I can revise and move this to a github discussion and a parallel PR. thanks Em sex., 26 de nov. de 2021 às 17:18, Christof Ressi escreveu: > 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 they are not officially > supported. I think it would be better to exclude this from the main PR ( > https://github.com/pure-data/pure-data/pull/1455) and only offer this as > a secondary PR (that you can rebase regularly on top of the other one). > > In particular, please don't include any GUI dialog messages. Those are > really internal. Also, 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 :-) > > I think including dynamic patching would "taint" your otherwise great > documentation updates. > > Christof > On 26.11.2021 21:05, Alexandre Torres Porres wrote: > > 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 Torres Porres < > por...@gmail.com> escreveu: > >> I could just send the main Patch, but it just works best if you have all >> of the current state of the reference folder and also check other changes >> I'm proposing in this PR, so see attachment of the whole thing. >> >> I got a rather broken keyboard, so I must be generating more typos than >> usual. Will need to revise it! >> >> note that [Pd-messages] gets called in the help files of [send-receive], >> 'message boxes' and [namecanvas], all of them have been rewritten as well. >> >> cheers >> >> >> >> Em sex., 26 de nov. de 2021 às 16:55, Alexandre Torres Porres < >> por...@gmail.com> escreveu: >> >>> 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/0ec5429629eb1045c901ab9c74befd124ccb6e69 >>> >>> already in an open PR >>> >>> Cheers >>> >> > ___pd-l...@lists.iem.at mailing > list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 they are not officially
supported. I think it would be better to exclude this from the main PR
(https://github.com/pure-data/pure-data/pull/1455) and only offer this
as a secondary PR (that you can rebase regularly on top of the other one).
In particular, please don't include any GUI dialog messages. Those are
really internal. Also, 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 :-)
I think including dynamic patching would "taint" your otherwise great
documentation updates.
Christof
On 26.11.2021 21:05, Alexandre Torres Porres wrote:
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 Torres Porres
escreveu:
I could just send the main Patch, but it just works best if you
have all of the current state of the reference folder and also
check other changes I'm proposing in this PR, so see attachment of
the whole thing.
I got a rather broken keyboard, so I must be generating more typos
than usual. Will need to revise it!
note that [Pd-messages] gets called in the help files of
[send-receive], 'message boxes' and [namecanvas], all of them have
been rewritten as well.
cheers
Em sex., 26 de nov. de 2021 às 16:55, Alexandre Torres Porres
escreveu:
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/0ec5429629eb1045c901ab9c74befd124ccb6e69
already in an open PR
Cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management
->https://lists.puredata.info/listinfo/pd-list___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 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 Torres Porres < > por...@gmail.com> escreveu: > >> I could just send the main Patch, but it just works best if you have all >> of the current state of the reference folder and also check other changes >> I'm proposing in this PR, so see attachment of the whole thing. >> >> I got a rather broken keyboard, so I must be generating more typos than >> usual. Will need to revise it! >> >> note that [Pd-messages] gets called in the help files of [send-receive], >> 'message boxes' and [namecanvas], all of them have been rewritten as well. >> >> cheers >> >> >> >> Em sex., 26 de nov. de 2021 às 16:55, Alexandre Torres Porres < >> por...@gmail.com> escreveu: >> >>> 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/0ec5429629eb1045c901ab9c74befd124ccb6e69 >>> >>> already in an open PR >>> >>> Cheers >>> >> Pd-messages.pd Description: Binary data ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] documenting messages to/from Pd and dynamic patching
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 Torres Porres < por...@gmail.com> escreveu: > I could just send the main Patch, but it just works best if you have all > of the current state of the reference folder and also check other changes > I'm proposing in this PR, so see attachment of the whole thing. > > I got a rather broken keyboard, so I must be generating more typos than > usual. Will need to revise it! > > note that [Pd-messages] gets called in the help files of [send-receive], > 'message boxes' and [namecanvas], all of them have been rewritten as well. > > cheers > > > > Em sex., 26 de nov. de 2021 às 16:55, Alexandre Torres Porres < > por...@gmail.com> escreveu: > >> 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/0ec5429629eb1045c901ab9c74befd124ccb6e69 >> >> already in an open PR >> >> Cheers >> > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] documenting messages to/from Pd and dynamic patching
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/0ec5429629eb1045c901ab9c74befd124ccb6e69 already in an open PR Cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
