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

[Christof Ressi]

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