[PD] documenting messages to/from Pd and dynamic patching

Wed Dec 1 22:04:55 CET 2021

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 at 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 at 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 at 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 at lists.iem.at wrote:
>>>
>>> Message: 1
>>> Date: Sat, 27 Nov 2021 20:20:49 +0100
>>> From: Jean-Yves Gratius <jyg at gumo.fr>
>>> To: pd-list at lists.iem.at
>>> Subject: Re: [PD] documenting messages to/from Pd and dynamic patching
>>> Message-ID: <f41bab20-e831-3f04-52fb-ba273b1e0daf at gumo.fr>
>>> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>>>
>>> On 27/11/2021 17:19, pd-list-request at lists.iem.at wrote:
>>>
>>> ForwardedMessage.eml
>>>
>>> Subject:
>>> Re: [PD] documenting messages to/from Pd and dynamic patching
>>> From:
>>> Christof Ressi <info at christofressi.com>
>>> Date:
>>> 27/11/2021 ? 17:01
>>>
>>> To:
>>> Pd-List <pd-list at 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
>>> robotcowboy.com
>>>
>>>
>>>
>>>
>>> _______________________________________________Pd-list at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>>>
>>> _______________________________________________
>>> Pd-list at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> https://lists.puredata.info/listinfo/pd-list
>>>
>>
> _______________________________________________Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20211201/3b5a7285/attachment-0001.htm>