[PD] documenting messages to/from Pd and dynamic patching
Christof Ressi
info at christofressi.com
Wed Dec 1 22:13:16 CET 2021
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 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.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
> _______________________________________________
> 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/16fd6bfb/attachment-0001.htm>
More information about the Pd-list
mailing list