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

Christof Ressi info at christofressi.com
Wed Dec 1 22:00:07 CET 2021


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.atwrote:
>>>>         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 <http://danomatika.com>
>>         robotcowboy.com <http://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20211201/d9942c6e/attachment-0001.htm>


More information about the Pd-list mailing list