> On Oct 8, 2024, at 11:28 PM, pd-dev-request(a)lists.iem.at wrote:
>
> Message: 2
> Date: Tue, 8 Oct 2024 09:49:09 -0500
> From: Miller Puckette <mpuckette(a)cloud.ucsd.edu <mailto:mpuckette@cloud.ucsd.edu>>
> Subject: [PD-dev] Re: puredata jack audio crashes using pipewire-jack
> with more than 15 channels under Linux/Debian
> To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>
> Message-ID: <e30022b2-ccff-4b23-b03d-8fdcc7775f6f(a)cloud.…
[View More]ucsd.edu <mailto:e30022b2-ccff-4b23-b03d-8fdcc7775f6f@cloud.ucsd.edu>>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> This might be serious enough to warrant putting out 0.55-2.
I would like a new bug fix this for the libpd fixes as well...
--------
Dan Wilcox
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
[View Less]
I don't agree that Lua version are that much different. The API is pretty stable.
Funny, I've regularly updated Lua for my openFrameworks bindings, from 5.1 all the way to 5.4 over the years and have not had major issues. I think I am simply not using any real end case features to where it matters. So far SWIG is handling the bindings generation well enough and I do add whatever small shims are needed via macros, but so far that has only been on the C side. The Lua side has been stable for me.
…
[View More]
> On Oct 3, 2024, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote:
>
> On Wednesday, October 2, 2024 at 11:39:30 AM CDT, Christof Ressi <info(a)christofressi.com <mailto:info@christofressi.com>> wrote:
> On 02.10.2024 18:30, Timothy Schoen wrote:
>> Currently, pdlua is not compatible with luaJIT, since it was updated
>> to Lua 5.4 (and uses some of the new features internally). It's
>> possible to port it back to luaJIT by taking out all the new Lua bits.
>>
>> Both have some advantages and disadvantages. But for me, regular Lua
>> would win (but only by a small amount). The reason is: it's
>> architecturally simpler, more mainstream, more widely used/tested, and
>> (in my estimation) more likely to be maintained for a very long time.
>> luaJIT is very fast, so I'm not opposed to it either. Having any kind
>> of scripting for objects available at all is the most important thing
>> here 🙂
>
> If LuaJIT stopped working for whatever reason, we could still use
> vanilla Lua 5.1 - which will continue to work as long as we have C
> compilers :) Lua is a bit peculiar in that every minor version is really
> a different language. Once you pick a Lua version, you typically don't
> upgrade, unless there is some very compelling reason.
>
> Personally, I'm using Lua 5.3 and I would also tend towards Lua 5.3 or
> 5.4. We just have to be aware that once we pick a version, we basically
> have to stick with it because of backwards compatibility.
>
> Christof
--------
Dan Wilcox
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
[View Less]
Well, hopefully someday the allocations/processing/interpretation/compilation isn't happening on the audio thread :)
I think JIT compilation shouldn't necessarily be shied away from given class/object creation isn't realtime-safe anyways, and how much slower is it actually?
Imo JIT compilation to lower-level should be considered more, like for [expr~] or maybe some heavy-like patch compiler thing that can do some of what gen~ does.
somewhat off-topic: there are also some cool compiled lua-…
[View More]inspired languages like terra and nelua (which I was thinking of switching to for the project I was using luajit/pdlua for anyways)
-seb
On Wednesday, October 2, 2024 at 11:39:30 AM CDT, Christof Ressi <info(a)christofressi.com> wrote:
On 02.10.2024 18:30, Timothy Schoen wrote:
> Currently, pdlua is not compatible with luaJIT, since it was updated
> to Lua 5.4 (and uses some of the new features internally). It's
> possible to port it back to luaJIT by taking out all the new Lua bits.
>
> Both have some advantages and disadvantages. But for me, regular Lua
> would win (but only by a small amount). The reason is: it's
> architecturally simpler, more mainstream, more widely used/tested, and
> (in my estimation) more likely to be maintained for a very long time.
> luaJIT is very fast, so I'm not opposed to it either. Having any kind
> of scripting for objects available at all is the most important thing
> here 🙂
If LuaJIT stopped working for whatever reason, we could still use
vanilla Lua 5.1 - which will continue to work as long as we have C
compilers :) Lua is a bit peculiar in that every minor version is really
a different language. Once you pick a Lua version, you typically don't
upgrade, unless there is some very compelling reason.
Personally, I'm using Lua 5.3 and I would also tend towards Lua 5.3 or
5.4. We just have to be aware that once we pick a version, we basically
have to stick with it because of backwards compatibility.
Christof
>
>
> Tim
>
>
> On 02/10/2024 16:09, Sebastian Shader via Pd-list wrote:
>> I know it's old but I think for lua in pd luaJit should be considered
>> if adding a lua.
>> Imo they took out a very powerful feature in setfenv after 5.1 anyways.
>>
>> Luajit was still working with pdlua last I checked.
>> Plus pd messages only use floats.
>>
>> -Seb
>>
>>
>> On Wednesday, October 2, 2024 at 05:27:03 AM CDT, Timothy Schoen
>> <timschoen123(a)gmail.com> wrote:
>>
>> Yeah, +1 for pdlua for me!
>>
>> Here's a few more reasons I'd love to see this:
>>
>> * pdlua objects require vastly less boiler-plate code than
>> C externals. Especially for signals and graphics, it takes care of
>> all the hard parts and common pitfalls for you.
>>
>> * As a result, creating pdlua objects is much more
>> beginner friendly, and experienced programmers are less likely to
>> make mistakes. Not requiring compilation makes writing coded
>> externals as accessible as abstractions are currently.
>>
>> * The biggest weakness for a project like pdlua is needing
>> to be installed manually. This discourages people from directly
>> uploading their Lua objects on Deken. Like porres said, ELSE now
>> ships with pdlua just so that we can ship lua objects. It would be
>> amazing if we could assume them to just work.
>>
>> * As you might know, Lua is very compact, it can be
>> compiled by adding "onelua.c" to your sources, and it has no external
>> dependencies. For ease of maintenance, it's as good at it gets. Lua
>> is also fast for a scripting language. Seems like the perfect fit for
>> pure-data.
>>
>>
>> If you want a sample of the API, here's the documentation for pdlua
>> graphics:
>> https://agraef.github.io/pd-lua/tutorial/pd-lua-intro.html#graphics
>>
>> Tim
>>
>>
>>
>>
>> On 02/10/2024 06:12, Alexandre wrote:
>>
>>
>>>
>>>
>>>
>>> Let me share Tim's thoughts he sent me via a chat about coding
>>> externals in lua, which I think are a perfect sell. Compared to C
>>> externals, lua externals:
>>> * Encourages open-source, since the source code is the
>>> object
>>> * Works on every OS, architecture, pd floatsize,
>>> multi-instance, all without needing recompilation
>>> * You can easily modify objects if you want to
>>> * GUIs are now much easier to write with Lua than with C
>>> * Are guaranteed to keep working even if Pd's C API
>>> changes, or Pd changes GUI framework
>>> * Are guaranteed to work across Pd forks, as long as they
>>> correctly implement the lua API
>>>
>>>
>>>
>>>
>>>
>>>
>>> Em ter., 1 de out. de 2024 às 15:36, Alexandre <porres(a)gmail.com>
>>> escreveu:
>>>
>>>
>>>> Em seg., 30 de set. de 2024 às 16:59, Christof Ressi
>>>> <info(a)christofressi.com> escreveu:
>>>>
>>>>
>>>>>>>>> Thanks to Antoine for mentioning pdlua! I will need to
>>>>>>>>> check it out. I have already seen people doing some very cool
>>>>>>>>> stuff with it. Maybe they already have the perfect solution :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I'm also looking at pdlua, which might want to become the
>>>>>>>> official way to make graphical externs AND to add scripting in
>>>>>>>> a fundamental way to Pd :)
>>>>>>>>
>>>>>> +1 for an official scripting language! :) (I love Lua, BTW.) And
>>>>>> yes, it would make lots of sense to leverage the scripting
>>>>>> language to implement custom UIs!
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> +1k
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Yay, great to hear that! BTW, I remembered about this ticket we
>>>> opened years ago inquiring about adding lua to Pd
>>>> natively! https://github.com/pure-data/pure-data/issues/687
>>>>
>>>>
>>>>
>>>>
>>>> Now that Tim is doing great work for graphics, this would be even
>>>> more awesome! And I wouldn't have to worry in shipping it in ELSE
>>>> for some externals that already use it :)
>>>>
>>>>
>>>>
>>>>
>>>> cheers
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ---
>>> pd-dev(a)lists.iem.at - the Pd developers' mailinglist
>>> https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/WOQJIW3FBB…
>>>
>>
>> ---
>> pd-list(a)lists.iem.at - the Pure Data mailinglist
>> https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/GG7IF7MWR…
>>
>>
>> To unsubscribe send an email to pd-list-leave(a)lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.iem.at/
>>
>> ---
>> pd-list(a)lists.iem.at - the Pure Data mailinglist
>> https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/TJOTDRAY3…
>>
>>
>> To unsubscribe send an email to pd-list-leave(a)lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.iem.at/
>
> ---
> pd-list(a)lists.iem.at - the Pure Data mailinglist
> https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/F6CWKKSQH…
>
>
> To unsubscribe send an email to pd-list-leave(a)lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.iem.at/
---
pd-list(a)lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/GY5ULQJGM…
To unsubscribe send an email to pd-list-leave(a)lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/
[View Less]
(forwarding to pd-dev :)
> in Pd it's everything the drag-rectangle touches. This might not be
> an issue for other people.
That's what QGraphicsScene does by default! I just double checked with
my level editor. Don't underestimate modern UI frameworks ;-)
-------- Forwarded Message --------
Subject: Re: [PD-dev] Re: Fwd: Re: gtk front end for Pd?
Date: Mon, 30 Sep 2024 21:55:54 +0200
From: Miller Puckette <mpuckette(a)cloud.ucsd.edu>
To: Christof Ressi <info(a)…
[View More]christofressi.com>
The specific thing I hate is that only things entirely inside the
drag-rectangle get selected - in Pd it's everything the drag-rectangle
touches. This might not be an issue for other people.
cheers
M
On 9/30/24 9:45 PM, Christof Ressi wrote:
>
>>> I also hate the way every canvas I've seen does
>>> rectangle-selection. Maybe you know of one I won't hate :)
>>>
>>> And... every widget set I've seen thinks widgets live in
>>> rectangles. The second most important graphical item in Pd is the
>>> patch line. Giving it a widget-style selection method? Disaster. I
>>> don't think patch lines can be TK or GTK r QT or anyone's widgets -
>>> imagine how those bounding rectangles would fill th screen :)
>
> Qt only uses bounding rectangles for the broad phase hit detection.
> The actual hit detection can then be further customized for each
> widget. The collision shape can be anything from a circle to an
> arbitrary polygon or even a bitmap. For example, a line item only
> receives a mouse event if you click on the actual line.
>
> In case you're talkinga about the actual graphical representation of
> the selection: that's totally up to you. By default, QGraphicsScene
> only notifies the selected items; you can then decide to how to
> present the selection to the user. In the case of Pd, you would only
> change the appearance of the selected objects (i.e. make them blue),
> but not draw a bounding rectangle.
>
> Another nice feature about Qt's selection mechanism is that you can
> use arbitrary selection shapes. For example, you can select items by
> drawing an arbitary path, similar to "free selection" mode in painting
> programs. That's actually a feature I've always wanted in Pd :)
>
>>>>
>>>> Thanks to Antoine for mentioning pdlua! I will need to check it
>>>> out. I have already seen people doing some very cool stuff with it.
>>>> Maybe they already have the perfect solution :)
>>>>
>>> I'm also looking at pdlua, which might want to become the official
>>> way to make graphical externs AND to add scripting in a fundamental
>>> way to Pd :)
>
> +1 for an official scripting language! :) (I love Lua, BTW.) And yes,
> it would make lots of sense to leverage the scripting language to
> implement custom UIs!
>
> Christof
>
>
> ---
> pd-dev(a)lists.iem.at - the Pd developers' mailinglist
> https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@lis…
[View Less]
>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-…
[View More]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(a)christofressi.com>
Subject: [PD-dev] Re: gtk front end for Pd?
To: Dan Wilcox <danomatika(a)gmail.com>, Miller Puckette
<mpuckette(a)cloud.ucsd.edu>, Antoine Rousseau <antoine(a)metalu.net>
Cc: pd-dev <pd-dev(a)lists.iem.at>
Message-ID: <731f731d-f127-4ba3-9d17-4d81ab5368f0(a)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-request(a)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>
***************************************
[View Less]
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.
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 …
[View More]are interested in this and also spend time making a preliminary tech demonstration".
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(a)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/>
[View Less]
The pdgtk demo compiled ok on macOS 14.5 with the following Homebrew packages installed: tcl-tk gtk4
I am not able to run it though, pdgtk is complaining about a missing port on invocation:
danomatika@danomatika pdgtk % pd -guicmd `pwd`/pdgtk -nrt -stderr z.pd
usage: /Users/danomatika/Downloads/pdgtk/pdgtk <port>
^CPd: signal 2
gui socket 0 -
closing audio...
closing MIDI...
... done.
> On Sep 29, 2024, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote:
>
> Well, I made a stab …
[View More]at doing the same thing with GTK4 - you can grab it
> here: http://msp.ucsd.edu/tmp/2024.09.28-pdgtk.tgz . It's about 1200
> lines of code and does only a coupe of very basic things, but it allows
> us to guess what it would entail to do the whole job. Of the 325 calls
> to pdgui_v[a]mess in the PD source, it takes care of about 10 I think.
--------
Dan Wilcox
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
[View Less]
oops, re-sending....
On 30.09.2024 19:19, Miller Puckette wrote:
> On 9/30/24 6:23 PM, Christof Ressi 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 …
[View More]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?
>>>
>>> (2) it's just a drawing with a tag, not an active widget; perhaps
>>> mouse hit detection is done in the GUI but everything else in Pd. In
>>> this case it's not a big enough change to make much difference,
>>> except for this noisome one: "GUI externals" such as the knob now
>>> have to load dynamic libraries into two programs, instead of just one.
>>>
>>> Depending on which scenario we want to consider (or perhaps this is
>>> somehow a false choice) we can go into more detail about this...
>>
>> These are important points! I think there are two separate concerns:
>>
>> 1. who is doing the mouse-hit-detection?
>>
>> 2. who initiates the state changes (e.g. flashing, selection)
>>
>> For example, it would be possible to do the hit detection on the GUI,
>> but still do the state changes on the core. For example, in IOhannes
>> draft PR, the "bang" object has an "activate" message that is sent
>> whenever the flash state changes:
>> https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/176…
>>
>> We could move such internal state changes to the GUI, but we don't
>> have to if it only complicates things.
>>
>> However, I would love to move the hit detection to the GUI! Note that
>> some GUI frameworks already do hit detection for canvas items. (In
>> Qt, graphic items in a QGraphicsScene can receive mouse events!) In
>> this case, doing the hit detection on the core is just duplicate
>> work. It is also rather expensive since the core only stores the
>> objects in a linked list, without spatial indexing, so every mouse
>> movement has to potentially iterate over hundreds or even thousands
>> gobjects and do rectangle intersection tests until it finds a hit.
>> This is not something that you would want to do on the audio thread :)
>>
>> The same thing applies to selections. The GUI typically already knows
>> which objects are selected, so we only need to send this information
>> to the core.
>>
>> If we do the hit detection on the GUI, you are right that we need to
>> keep an association between GUI widget and gobject. I think we just
>> need to have a hashtable of tag -> gobject on the core; when the core
>> receives a mouse event, it looks up the tag in the hashtable and then
>> dispatches the event to the corresponding object. If the tag is not
>> found, it means that the object has been destroyed in flight and we
>> can just ignore the event.
>>
>> There's one slight problem: some objects need to know *where* the
>> user clicked. E.g. a slider with steady-on-click needs to know the
>> position to set the new value. This means that the core side has to
>> maintain some knowledge about the graphical representation. This does
>> not seem to much of a problem to me, but it's something to be aware of.
>>
> One idea would be to do the hit detection in the GUI and simply pass
> Pd the (x,y) coords along with a list of all the GUI objects that got
> hit (each with a "fuzziness" quotient so that we can be smart about
> disambiguating multiple hits). The only reason I didn't do that
> already is because I didn't want to get too deeply involved with
> TclTk's canvases. And yes, anything we kick up to the GUI has to be
> done both in TCL/TK and in whatever 5 new GUIs are tried out -- that's
> one reason I've kept as much of the intelligence as possible down in
> Pd land.
>
> I also hate the way every canvas I've seen does rectangle-selection.
> Maybe you know of one I won't hate :)
>
> And... every widget set I've seen thinks widgets live in rectangles.
> The second most important graphical item in Pd is the patch line.
> Giving it a widget-style selection method? Disaster. I don't think
> patch lines can be TK or GTK r QT or anyone's widgets - imagine how
> those bounding rectangles would fill th screen :)
>
>> ---
>>
>> Now here's the big catch: what should we do with GUI externals?
>>
>> Ad 1: externals could define a region that acts as the bounding
>> rectangle and which can be filled with drawing commands. This way
>> they can partipicate in hit detection on the GUI.
>>
>> Ad 2: I think state changes for externals have to be handled on the
>> core because the external has no access to the GUI features. It does
>> not even know which GUI it runs in.
>>
>> One idea I had was to provide the GUI features as API functions. E.g.
>> pdgui_drawrect() to draw a rectangle or pdgui_delay() to start a
>> timer, etc. These API functions have to be implemented by the GUI,
>> the core would just delegate the calls to the GUI. The external would
>> register a callback function that is called whenever the object needs
>> to be redrawn. Also, the GUI external could register callbacks for
>> mouse events and paintings
>>
>> One problem I see is that not every GUI can export C functions. For
>> example, this probably wouldn't work with a web browser GUI...
>>
>> The easiest solution is to just keep state changes for external GUI
>> objects on the core, i.e. the external needs to send raw drawing
>> commands. As an upside, this would make it easier to update existing
>> externals as they would just have to update the drawing commands. Of
>> course, as I said, sending all these individual commands not only
>> increases traffic, it also means that the GUI has to maintain
>> individual graphical primitives instead of just a single widget.
>>
>> Either way, we should provide a stable GUI/drawing API for externals.
>> Currently, it's all unofficial.
>>
>> Thanks to Antoine for mentioning pdlua! I will need to check it out.
>> I have already seen people doing some very cool stuff with it. Maybe
>> they already have the perfect solution :)
>>
> I'm also looking at pdlua, which might want to become the official way
> to make graphical externs AND to add scripting in a fundamental way to
> Pd :)
>> ---
>>
>> I think all of this needs quite a bit of planning and design. We
>> already had an online meeting two or three years ago before we
>> started the GUI refactoring process. I would suggest to have another
>> meeting where we can talk through all the potential issues and get a
>> feel for the overall design.
>>
>> Anyway, I'm very excited that the GUI refactoring is moving forward!
>>
>> Christof
>>
>>>
>>> cheers
>>>
>>> M
>>>
>>>
>>>
>>> ---
>>> pd-dev(a)lists.iem.at - the Pd developers' mailinglist
>>> https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@lis…
>>
>>
>>
>>
>> ---
>> pd-dev(a)lists.iem.at - the Pd developers' mailinglist
>> https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@lis…
>
>
>
[View Less]
To Pd dev -
I don't know if any of you remember this, but at the first Pd convention
in 2004, someone (I forget who) had the idea of replacing the Pd front
end by using the tcl parser but making gtk bindings in place of the tk
ones. This is not the most streamlined or elegant way to replace Pd's
front end, but it has the advantage of easily coexisting with the
existing setup.
Well, I made a stab at doing the same thing with GTK4 - you can grab it
here: http://msp.ucsd.edu/tmp/2024.…
[View More]09.28-pdgtk.tgz . It's about 1200
lines of code and does only a coupe of very basic things, but it allows
us to guess what it would entail to do the whole job. Of the 325 calls
to pdgui_v[a]mess in the PD source, it takes care of about 10 I think.
To proceed further it would be best to replace calls like <canvas-tag>
itemconfigure <item-tag> -width 4 with calls to specific purpose-build
tcl procedures like pdtk_canvas_configure_line_width, of which there
would probably be 100 or so. I haven't done any of this since I'd like
to see if the rest of you have thoughts about doing that. Proceeding
that way, and perhaps taking care of 10 cases a day, I think this can be
done in a month of work (and then years of followup as usual :)
I've heard it suggested that ther could be a C API in Pd that would
break out all these calls, but I personally think the pdgui_vmess
protocol is good enough and is much easier to manage. We could even
replace the ASCII strings with a binary format without changing anything
outside of s_inter_gui.c on the PD side, a binary-to-ascii converter for
the tcl/tk layer, and then do away entirely with the TCL interpreter for
the GTK front end, replaing it with a simple function dispatcher.
[View Less]
Dear all,
I am experiencing a strange bug in Pd 0.55.1.
When I launch Pd, it crashes.
Running it with Valgrind, I got the following message:
==83263== Thread 4:
==83263== Invalid free() / delete / delete[] / realloc()
==83263== at 0x48461EF: free (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==83263== by 0x1D9539: jack_polling_callback (s_audio_jack.c:164)
==83263== by 0x4A7AECC: ??? (in
/usr/lib/x86_64-linux-gnu/libjack.so.0.1.0)
==83263== by 0x4A7AB87: ??? (in
/usr/…
[View More]lib/x86_64-linux-gnu/libjack.so.0.1.0)
==83263== by 0x4A97F2F: ??? (in
/usr/lib/x86_64-linux-gnu/libjack.so.0.1.0)
==83263== by 0x4B46731: start_thread (pthread_create.c:447)
==83263== by 0x4BC10FF: clone (clone.S:100)
==83263== Address 0x535b180 is 0 bytes inside a block of size 65,536 free'd
==83263== at 0x48461EF: free (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==83263== by 0x1D9522: jack_polling_callback (s_audio_jack.c:160)
==83263== by 0x4A7AECC: ??? (in
/usr/lib/x86_64-linux-gnu/libjack.so.0.1.0)
==83263== by 0x4A7AB87: ??? (in
/usr/lib/x86_64-linux-gnu/libjack.so.0.1.0)
==83263== by 0x4A97F2F: ??? (in
/usr/lib/x86_64-linux-gnu/libjack.so.0.1.0)
==83263== by 0x4B46731: start_thread (pthread_create.c:447)
==83263== by 0x4BC10FF: clone (clone.S:100)
==83263== Block was alloc'd at
==83263== at 0x48489F3: calloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==83263== by 0x188F16: getbytes (m_memory.c:21)
==83263== by 0x1D94F8: jack_polling_callback (s_audio_jack.c:115)
==83263== by 0x4A7AECC: ??? (in
/usr/lib/x86_64-linux-gnu/libjack.so.0.1.0)
==83263== by 0x4A7AB87: ??? (in
/usr/lib/x86_64-linux-gnu/libjack.so.0.1.0)
==83263== by 0x4A97F2F: ??? (in
/usr/lib/x86_64-linux-gnu/libjack.so.0.1.0)
==83263== by 0x4B46731: start_thread (pthread_create.c:447)
==83263== by 0x4BC10FF: clone (clone.S:100)
==83263==
Running it via gdb, I am getting the following message:
Thread 4 "pd" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff74926c0 (LWP 109587)]
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6,
no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
warning: 44 ./nptl/pthread_kill.c: No such file or directory
Then, I build Pd tag 0.54.1 commit 0259d003 and everything works fine,
while I am getting the same error directly from Pd tag 0.55-0test1 commit
46e3ec2d.
I manage to open Pd in callback mode while avoiding polling.
Here some details about my setup:
Debian 12, Linux kernel 6.10
Jackd2 installed via apt, v 1.9.22
Pd installed via apt, 0.55.1, and then built locally using --enable-debug
--enable-jack as flags for the configuration. Source code cloned from git.
I also tried to search (randomly) in my local machine where pthread_kill.c
is located, without success. libpthread is in: /usr/lib/x86_64-linux-gnu/ .
I took a look at recent emails and issues on Github but I do not see
anything relevant with this issue.
My next step is to compare and study the relevant code (starting from
s_audio_jack.c) that differs between 0.54.1 and 0.55.0test1.
If someone has some ideas, they are appreciated.
Additionally, if useful, I can report an issue on Github. Honestly, I am
stuck while understanding if it is an issue on my local machine, such that
an issue may be noise on the main repo.
Best regards,
Marco
[View Less]