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, [email protected] wrote: > > > > > > Message: 1 > > > Date: Sat, 27 Nov 2021 20:20:49 +0100 > > > From: Jean-Yves Gratius <[email protected]> > > > To:[email protected] > > > Subject: Re: [PD] documenting messages to/from Pd and dynamic patching > > > Message-ID: <[email protected]> > > > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > > > > > On 27/11/2021 17:19,[email protected]: > > > > ForwardedMessage.eml > > > > > > > > Subject: > > > > Re: [PD] documenting messages to/from Pd and dynamic patching > > > > From: > > > > Christof Ressi <[email protected]> > > > > Date: > > > > 27/11/2021 ? 17:01 > > > > > > > > To: > > > > Pd-List <[email protected]> > > > > > > > > > > > > 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= > > > > > > > > > > > > > _______________________________________________ > > [email protected] 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= > _______________________________________________ > [email protected] 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= > -- _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
