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

[Alexandre Torres Porres]

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