Howdy all,
My feeling on this is:
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.)
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).
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...
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-request@lists.iem.at wrote:
Message: 1 Date: Sat, 27 Nov 2021 20:20:49 +0100 From: Jean-Yves Gratius <jyg@gumo.fr mailto:jyg@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: <f41bab20-e831-3f04-52fb-ba273b1e0daf@gumo.fr mailto:f41bab20-e831-3f04-52fb-ba273b1e0daf@gumo.fr> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 27/11/2021 17:19, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
ForwardedMessage.eml
Subject: Re: [PD] documenting messages to/from Pd and dynamic patching From: Christof Ressi <info@christofressi.com mailto:info@christofressi.com> Date: 27/11/2021 ? 17:01
To: Pd-List <pd-list@lists.iem.at mailto:pd-list@lists.iem.at>
Two examples that come to my mind:
- [iemguts/canvasselect] allows to (de)select objects simply by
index. No need to emulate mouse selection with "mouse" and "mouseup".
- 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/
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:
- 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.)
- 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).
- 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...
- 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-request@lists.iem.at wrote:
Message: 1 Date: Sat, 27 Nov 2021 20:20:49 +0100 From: Jean-Yves Gratius jyg@gumo.fr To:pd-list@lists.iem.at Subject: Re: [PD] documenting messages to/from Pd and dynamic patching Message-ID: f41bab20-e831-3f04-52fb-ba273b1e0daf@gumo.fr Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 27/11/2021 17:19,pd-list-request@lists.iem.atwrote:
ForwardedMessage.eml
Subject: Re: [PD] documenting messages to/from Pd and dynamic patching From: Christof Ressi info@christofressi.com Date: 27/11/2021 ? 17:01
To: Pd-List pd-list@lists.iem.at
Two examples that come to my mind:
- [iemguts/canvasselect] allows to (de)select objects simply by
index. No need to emulate mouse selection with "mouse" and "mouseup".
- 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
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:
- 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.)
- 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).
- 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...
- 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-request@lists.iem.at wrote:
Message: 1 Date: Sat, 27 Nov 2021 20:20:49 +0100 From: Jean-Yves Gratius jyg@gumo.fr To:pd-list@lists.iem.at Subject: Re: [PD] documenting messages to/from Pd and dynamic patching Message-ID: f41bab20-e831-3f04-52fb-ba273b1e0daf@gumo.fr Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 27/11/2021 17:19,pd-list-request@lists.iem.atwrote:
ForwardedMessage.eml
Subject: Re: [PD] documenting messages to/from Pd and dynamic patching From: Christof Ressi info@christofressi.com Date: 27/11/2021 ? 17:01
To: Pd-List pd-list@lists.iem.at
Two examples that come to my mind:
- [iemguts/canvasselect] allows to (de)select objects simply by
index. No need to emulate mouse selection with "mouse" and "mouseup".
- 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&a... > danomatika.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__danomatika.com&d=DwI... > robotcowboy.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__robotcowboy.com&d=Dw... >
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
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 info@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:
- 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.)
- 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).
- 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...
- 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-request@lists.iem.at wrote:
Message: 1 Date: Sat, 27 Nov 2021 20:20:49 +0100 From: Jean-Yves Gratius jyg@gumo.fr To: pd-list@lists.iem.at Subject: Re: [PD] documenting messages to/from Pd and dynamic patching Message-ID: f41bab20-e831-3f04-52fb-ba273b1e0daf@gumo.fr Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 27/11/2021 17:19, pd-list-request@lists.iem.at wrote:
ForwardedMessage.eml
Subject: Re: [PD] documenting messages to/from Pd and dynamic patching From: Christof Ressi info@christofressi.com Date: 27/11/2021 ? 17:01
To: Pd-List pd-list@lists.iem.at
Two examples that come to my mind:
- [iemguts/canvasselect] allows to (de)select objects simply by
index. No need to emulate mouse selection with "mouse" and "mouseup".
- 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-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
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 < porres@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 < info@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:
- 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.)
- 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).
- 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...
- 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-request@lists.iem.at wrote:
Message: 1 Date: Sat, 27 Nov 2021 20:20:49 +0100 From: Jean-Yves Gratius jyg@gumo.fr To: pd-list@lists.iem.at Subject: Re: [PD] documenting messages to/from Pd and dynamic patching Message-ID: f41bab20-e831-3f04-52fb-ba273b1e0daf@gumo.fr Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 27/11/2021 17:19, pd-list-request@lists.iem.at wrote:
ForwardedMessage.eml
Subject: Re: [PD] documenting messages to/from Pd and dynamic patching From: Christof Ressi info@christofressi.com Date: 27/11/2021 ? 17:01
To: Pd-List pd-list@lists.iem.at
Two examples that come to my mind:
- [iemguts/canvasselect] allows to (de)select objects simply by
index. No need to emulate mouse selection with "mouse" and "mouseup".
- 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-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
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 porres@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 <info@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-request@lists.iem.at wrote: Message: 1 Date: Sat, 27 Nov 2021 20:20:49 +0100 From: Jean-Yves Gratius <jyg@gumo.fr> To:pd-list@lists.iem.at Subject: Re: [PD] documenting messages to/from Pd and dynamic patching Message-ID: <f41bab20-e831-3f04-52fb-ba273b1e0daf@gumo.fr> Content-Type: text/plain; charset="windows-1252"; Format="flowed" On 27/11/2021 17:19,pd-list-request@lists.iem.atwrote:ForwardedMessage.eml Subject: Re: [PD] documenting messages to/from Pd and dynamic patching From: Christof Ressi <info@christofressi.com> Date: 27/11/2021 ? 17:01 To: Pd-List <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_______________________________________________ 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
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 info@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 < porres@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 < info@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:
- 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.)
- 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).
- 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...
- 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-request@lists.iem.at wrote:
Message: 1 Date: Sat, 27 Nov 2021 20:20:49 +0100 From: Jean-Yves Gratius jyg@gumo.fr To: pd-list@lists.iem.at Subject: Re: [PD] documenting messages to/from Pd and dynamic patching Message-ID: f41bab20-e831-3f04-52fb-ba273b1e0daf@gumo.fr Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 27/11/2021 17:19, pd-list-request@lists.iem.at wrote:
ForwardedMessage.eml
Subject: Re: [PD] documenting messages to/from Pd and dynamic patching From: Christof Ressi info@christofressi.com Date: 27/11/2021 ? 17:01
To: Pd-List pd-list@lists.iem.at
Two examples that come to my mind:
- [iemguts/canvasselect] allows to (de)select objects simply by
index. No need to emulate mouse selection with "mouse" and "mouseup".
- 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-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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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 info@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 <porres@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 <info@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-request@lists.iem.at wrote: Message: 1 Date: Sat, 27 Nov 2021 20:20:49 +0100 From: Jean-Yves Gratius <jyg@gumo.fr> To:pd-list@lists.iem.at Subject: Re: [PD] documenting messages to/from Pd and dynamic patching Message-ID: <f41bab20-e831-3f04-52fb-ba273b1e0daf@gumo.fr> Content-Type: text/plain; charset="windows-1252"; Format="flowed" On 27/11/2021 17:19,pd-list-request@lists.iem.atwrote:ForwardedMessage.eml Subject: Re: [PD] documenting messages to/from Pd and dynamic patching From: Christof Ressi <info@christofressi.com> Date: 27/11/2021 ? 17:01 To: Pd-List <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_______________________________________________ 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
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 info@christofressi.com 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 < info@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 < porres@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 < info@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:
- 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.)
- 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).
- 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...
- 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-request@lists.iem.at wrote:
Message: 1 Date: Sat, 27 Nov 2021 20:20:49 +0100 From: Jean-Yves Gratius jyg@gumo.fr To: pd-list@lists.iem.at Subject: Re: [PD] documenting messages to/from Pd and dynamic patching Message-ID: f41bab20-e831-3f04-52fb-ba273b1e0daf@gumo.fr Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 27/11/2021 17:19, pd-list-request@lists.iem.at wrote:
ForwardedMessage.eml
Subject: Re: [PD] documenting messages to/from Pd and dynamic patching From: Christof Ressi info@christofressi.com Date: 27/11/2021 ? 17:01
To: Pd-List pd-list@lists.iem.at
Two examples that come to my mind:
- [iemguts/canvasselect] allows to (de)select objects simply by
index. No need to emulate mouse selection with "mouse" and "mouseup".
- 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-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
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
-
Alexandre Torres Porres -
Christof Ressi -
Dan Wilcox -
Miller Puckette