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

Miller Puckette msp at ucsd.edu
Sun Nov 28 02:07:24 CET 2021


I think this is right.  "pd dsp 1" is definitely public, and "watchdog"
isn't.  Perhaps there should be two different destinations for the public
and non-public ones.  but it would be cruel to change that just to clean
the situation up, when people are probably using some things that I
would think are private.

cheers
M

On Sun, Nov 28, 2021 at 01:59:41AM +0100, Christof Ressi wrote:
> 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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_danomatika&d=DwICaQ&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=3S8AaMzeCf3L_b1ohfx7v5Vmbm9QKO8A6nogjGWv3Z3Enk15cmpKEduaMe33gBua&s=_ljqlgS1WWqMvkzRJQq_wfhezcRNCrDfMaHL5qQyNn8&e= >
> > danomatika.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__danomatika.com&d=DwICaQ&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=3S8AaMzeCf3L_b1ohfx7v5Vmbm9QKO8A6nogjGWv3Z3Enk15cmpKEduaMe33gBua&s=O_jUZxUYQOt4N2eABWvgfuv-QmWbsYuSTCMY96viFxM&e= >
> > robotcowboy.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__robotcowboy.com&d=DwICaQ&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=3S8AaMzeCf3L_b1ohfx7v5Vmbm9QKO8A6nogjGWv3Z3Enk15cmpKEduaMe33gBua&s=-d0Cqo9SrAlwUp1IsP7RxBi-oSJioVNKCbMgdQn4PSM&e= >
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Pd-list at lists.iem.at  mailing list
> > UNSUBSCRIBE and account-management ->https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist&d=DwICaQ&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=3S8AaMzeCf3L_b1ohfx7v5Vmbm9QKO8A6nogjGWv3Z3Enk15cmpKEduaMe33gBua&s=e0X71GmpUA1PSqQkpFzLO6rv9amyC92KmIWgPkgoChQ&e=

> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist&d=DwICAg&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=3S8AaMzeCf3L_b1ohfx7v5Vmbm9QKO8A6nogjGWv3Z3Enk15cmpKEduaMe33gBua&s=e0X71GmpUA1PSqQkpFzLO6rv9amyC92KmIWgPkgoChQ&e= 


-- 





More information about the Pd-list mailing list