>As I have long > seen, there can be lots of noise on pd-list but little outcome. I'd > rather not see it again here on pd-dev. Though it is useful to have discussions on the architecture.
As an off-topic aside, for the memory-allocation perspective/management I wonder how difficult it would be to allocate on non-realtime threads with some 'finished' queue/callback to send back to the realtime one? (or just non-realtime operations in general..) Object creation being more realtime-friendly would be better for live patching. Also to me the 'backends as plugins' idea seems nice, whether for GUI or audio. I guess if libpd were used the realtime system would be a library itself, pd container process could manage and orchestrate messages/pointers between the different components whether audio backends or gui or PD (libpd) itself. -seb Date: Mon, 30 Sep 2024 21:56:51 +0200 From: Christof Ressi <i...@christofressi.com> Subject: [PD-dev] Re: gtk front end for Pd? To: Dan Wilcox <danomat...@gmail.com>, Miller Puckette <mpucke...@cloud.ucsd.edu>, Antoine Rousseau <anto...@metalu.net> Cc: pd-dev <pd-dev@lists.iem.at> Message-ID: <731f731d-f127-4ba3-9d17-4d81ab536...@christofressi.com> Content-Type: multipart/alternative; boundary="------------wD0i6FUdzZrSWYCHnQzdmL6B" > 2. (Please don't take this personally.) I am a little disappointed > that many initial responses to Millers mail were more "you should have > done it this way" as opposed to "wow, we are super happy you are > interested in this and also spend time making a preliminary tech > demonstration". Sorry if I came across as too criticial. I've realized this myself and tried to make it clear in my last mail that I'm actually very excited about Millers initiative! > 3. Comparisons are useful but Pd is not SuperCollider. That being > said, there are definitely technical solutions to consider form SC but > I wouldn't want that to overshadow the discussion and turn into "lets > redo Pd core into SC core." ;) I certainly don't want to turn Pd into SC. The reason why I keep mentioning SC is because a) it's the other big open source computer music language and b) I'm very familiar with the source code. I'm also a little bit active in SC development and I often ask them to look at how certain things are handled in Pd. There is so much to learn from each other! > 5. IHMO I'd also like people to consider libpd. In a dream going way > back to PdCon 2026 in NYC, I imagined a future where Pd vanilla and > various forks all shared the same Pd core through libpd with GUI > handling, customization, etc implemented in some modular way. I think we share the same vision after all. > This is actually how Pd Party and Pd Droid Party work... we intercept > the messages sent to the widget via send/receive names and simple > respond to accordingly. In this case, there is a separate GUI tree of > a sort, but it works fine without sending any actual input messages to > the core. Visuals are implemented via CoreGraphics calls: Yeah, I can remember that you've shown me this and I absolutely think it goes into the right direction. > In fact, pretty much *all* modern UI frameworks do this and using it > builds down to implementing a callback for mouse enter/exit, move, > clicked, etc. Exactly :) > Same for touch events (which would be a *very* good idea to add > handling of to Pd. +1000 On 30.09.2024 19:12, Dan Wilcox wrote: > How'd y'all, > > (I will try to keep this short, since I find I really don't read > beyond a couple of paragraphs when people start writing long treatises...) > > 1. Miller I am happy you spent some time looking into this. It is IMO > an important direction we have to all consider for the project's future. > > > > 3. Comparisons are useful but Pd is not SuperCollider. That being > said, there are definitely technical solutions to consider form SC but > I wouldn't want that to overshadow the discussion and turn into "lets > redo Pd core into SC core." ;) > > 3. IOhannes + Giulio etc did a bunch of work with the refactor but can > we admit that has stalled? Perhaps a different approach is warranted? > > 4. I think Miller's demo code is pretty compact... and probably easy > to modify to prove an alternate technical approach. ;) As I have long > seen, there can be lots of noise on pd-list but little outcome. I'd > rather not see it again here on pd-dev. > > 5. IHMO I'd also like people to consider libpd. In a dream going way > back to PdCon 2026 in NYC, I imagined a future where Pd vanilla and > various forks all shared the same Pd core through libpd with GUI > handling, customization, etc implemented in some modular way. The > dream was that we could *all* leverage the work across various places > to benefit everyone and make all of this more sustainable. (ie. I'd > rather make work *with* Pd than have Pd my *work*). > > 6. I think we need a video call on this soon! > > --- > > And now to confuse the thread even more, I will to chime in here: > >> On Sep 30, 2024, at 3:16 PM, pd-dev-requ...@lists.iem.at wrote: >> >> Suppose we replace "draw X, Y,Z" with "draw button". I think this then >> spins out in either of two possible ways: >> >> (1) the "button" widget on the GUI side now takes care of mouse-hit >> detection and making itself flash (and eventually widgets with text can >> grab focus, handle copy/paste, etc). In this case the GUI widget has to >> maintain a connection with its corresponding object in Pd. This gets >> very complicated when, for instance, changing text causes inlets or >> outlets to appear, which perhaps on the Pd side the text is getting >> hammered by messages from elsewhere at the same time. Distributed >> database management, anyone? > > This is actually how Pd Party and Pd Droid Party work... we intercept > the messages sent to the widget via send/receive names and simple > respond to accordingly. In this case, there is a separate GUI tree of > a sort, but it works fine without sending any actual input messages to > the core. Visuals are implemented via CoreGraphics calls: > > https://github.com/danomatika/PdParty/tree/master/src/gui > > Honestly, the situation on iOS is *very* easy since the UIKit layout > engine handles views within views and hit testing for you. Same for > AppKit on macOS. In fact, pretty much *all* modern UI frameworks do > this and using it builds down to implementing a callback for mouse > enter/exit, move, clicked, etc. Same for touch events (which would be > a *very* good idea to add handling of to Pd. > > > -------- > Dan Wilcox > danomatika.com <http://danomatika.com> > robotcowboy.com <http://robotcowboy.com> *************************************** --- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/QKSHVB5D7E5QCZIV2P7XFFGR7O3QTJA4/
