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
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-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:
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.