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 info@christofressi.com Subject: [PD-dev] Re: gtk front end for Pd? To: Dan Wilcox danomatika@gmail.com, Miller Puckette mpuckette@cloud.ucsd.edu, Antoine Rousseau antoine@metalu.net Cc: pd-dev pd-dev@lists.iem.at Message-ID: 731f731d-f127-4ba3-9d17-4d81ab5368f0@christofressi.com Content-Type: multipart/alternative; boundary="------------wD0i6FUdzZrSWYCHnQzdmL6B"
- (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!
- 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!
- 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...)
- 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.
- 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." ;)
- IOhannes + Giulio etc did a bunch of work with the refactor but can
we admit that has stalled? Perhaps a different approach is warranted?
- 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.
- 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*).
- 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-request@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
***************************************
On 01.10.2024 00:29, Sebastian Shader via Pd-dev wrote:
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..)
See https://github.com/pure-data/pure-data/pull/1357. (You gave a "hooray", so you're probably already/still aware of this PR.)
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 info@christofressi.com Subject: [PD-dev] Re: gtk front end for Pd? To: Dan Wilcox danomatika@gmail.com, Miller Puckette mpuckette@cloud.ucsd.edu, Antoine Rousseau antoine@metalu.net Cc: pd-dev pd-dev@lists.iem.at Message-ID: 731f731d-f127-4ba3-9d17-4d81ab5368f0@christofressi.com Content-Type: multipart/alternative; boundary="------------wD0i6FUdzZrSWYCHnQzdmL6B"
- (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!
- 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!
- 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...)
- 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.
- 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." ;)
- IOhannes + Giulio etc did a bunch of work with the refactor but can
we admit that has stalled? Perhaps a different approach is warranted?
- 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.
- 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*).
- 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-request@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/QKSHVB5D7E5...
-
Christof Ressi -
Sebastian Shader