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/
