Since Pof came up in the thread below, I tried to use it and I'm getting the following error:
/home/alex/Documents/Pd/externals/pof/pof.pd_linux:libFLAC.so.8: cannot
open shared object file: No such file or directory
I do have libflac14 on my system (Debian 13) and there's no libflac8 in my system's repositories (apt-cache search libflac8 returned no results). How can this be resolved? Or is Pof abandoned?
On 12/16/25 01:31, Antoine Rousseau wrote:
Gem does not *require* the GUI to run in a separate process. It's really the other way round: because the GUI runs in a separate process, Gem has to spin up its own event loop. If Pd itself had an UI event loop, Gem could simply forward all the window management (window creation, destruction, moving, resizing, etc.) and input events to the UI thread. The actual OpenGL rendering can stay on the scheduler thread. In fact, this is exactly what Antoine is doing with PoFIn Gem, the rendering is done directly by the Pd thread (aka audio thread). In Pof however, the rendering is executed by a separate dedicated thread. OpenGL operations can take time, that's why most of the time using Gem we have to run two different Pd instances, one for Gem and one for audio. That is what Pof tries to avoid. BTW I think we should say: because the Pd GUI runs in a separate process, Gem (or Pof) has to open its own window and graphic context. If Pd itself offered such things, Gem could have been designed to draw directly into the patch windows (hopefully it will happen with an integrated Gtk GUI!).
Antoine
Le lun. 15 déc. 2025 à 17:29, Christof Ressi info@christofressi.com a écrit :
Hi Miller, I think you accidentally replied only to me, so I'm bringing this back to the list. First about the dev meeting: > I'm up for a dev meeting... I have a deadline coming up Dec 21 but > anytime after that is fine. Cool! I'll be on holidays till end of December, but after that I'm pretty flexible. For example, the first or second week of January would be fine for me. What about the others? --- Now the technical stuff: On 14.12.2025 13:04, Miller Puckette wrote: > I thought about combining the GUI and Pd into a single process but > ended up thinking that it's simpler to keep the situation as it is > currently. The biggest disadvantage I see is that the Gui and/or the > real-time part can get hung up without the other one knowing how to > deal with it. Since the two components run on different threads, they can totally detect if the other part is hanging. What you cannot do is kill one of the components and then restart it. (Technically you can kill a thread, but it's pretty hairy.) The question is: what would you even do if the one of the components hangs or crashes? If the core hangs/crashes, you've lost all the state, so you have to restart the application. In that case you might as well crash. If the GUI hangs/crashes, you could automatically restart it. This sounds attractive indeed. However, I can't remember the last time "wish.exe" crashed or locked up. 99% of the time it's the core that crashes :) > But (IIRC) Iohannes mentioned that Gem (I think) really requires a > separate Pd process from the GUI - and it would be miserable to have > to resort to using some special startup flag to force the old (that > is, the current) behavior in order to run Gem. Gem does not *require* the GUI to run in a separate process. It's really the other way round: because the GUI runs in a separate process, Gem has to spin up its own event loop. If Pd itself had an UI event loop, Gem could simply forward all the window management (window creation, destruction, moving, resizing, etc.) and input events to the UI thread. The actual OpenGL rendering can stay on the scheduler thread. In fact, this is exactly what Antoine is doing with PoF: https://github.com/Ant1r/ofxPof > Since it's important (both in the IOT versions of Pd but also for > running remotely and/or with GEM) to keep the GUI process separate, > the simplest thing is to make that the only option as at present. I understand. For now it's totally ok, but in the future I would really like to have an option to run everthing in the same process. IMO the main advantages would be: 1. much easier to debug 2. custom native windows (Gem, vstplugin~, etc.) would integrate with the remaining GUI. Currently, they appear as two separate applications, which I find really awkward. 3. It would automatically solve the event loop problem on macOS (see https://github.com/pure-data/pure-data/pull/1117) The only downside I see is that if the GUI crashes, it takes the core with it. But that has always been the case, even with the separate processes, so it doesn't seem to be a big issue in practice. As I said above, the GUI very rarely crashes in the first place. (Let's hope this doesn't change with the move to GTK :) > > I'm not sure, but I think any technique for avoiding blocking on GUI > writes could be implemented in Pd. I've tried to do that already in > s_inter.c - perhaps there are situations where it doesn't work > properly, but if so that could be fixed by replacing the queue I > already have (the circular buffer for graphics updates) with any other > sort of queue or fifo. Actually, all of the realtime-safety concerns would already be solved with threaded network I/O. See https://github.com/pure-data/pure-data/pull/1261 > > cheers > Miller > > On 12/8/25 3:09 PM, Christof Ressi wrote: >> Hi Miller, >> >> I'm happy about any initiatives that help us move away from Tcl/Tk! >> >> One general question: why is the GUI still a separate executable? IMO >> this doesn't buy as anything and only adds overhead. Yes, there >> should be an *option* to run the GUI as a separate application (e.g. >> for running the GUI on a separate machine), but for the common case >> where both the core and the GUI live on the same machine, they should >> run in the same process. >> >> All of the actual GUI code can be shared, the only difference is in >> the initialization/teardown and the implementation of the GUI queue. >> (The in-process GUI would simply use two thread-safe queues instead >> of a TCP socket.) >> >> Generally, an in-process GUI would be more efficient and real-time >> safe. First, it would remove two or three layers of buffering. >> Second, sending messages to the GUI can be made non-blocking. >> (pdgui_vmess() could push messages directly to a lockfree FIFO. Then >> we could either post a single message to the UI thread at the end of >> the scheduler tick to tell the GUI that there are pending messages, >> or the GUI could poll the queue in regular intervals.) >> >> Another big advantage is that it can integrate windows created by >> externals. For example, the VST editor windows created by >> [vstplugin~] would appear as part of the main GUI, and not as a >> separate application. >> >> Also, this would finally force Pd to get off the main thread :) >> >> Christof >> >> PS: Should we maybe have another dev meeting? >> >> On 08.12.2025 18:37, Miller Puckette via Pd-dev wrote: >>> To Pd dev - >>> >>> I just pushed a 'gtk' branch to github for everyone's joy and >>> delectation :) I think this idea was >>> very much annoying to Christof and perhaps others. My strategy is >>> to simplify the tcl commands >>> coming out of Pd to the point that they're easy to parse and carry >>> out in other environments. To >>> start with I'm just using the tcl interpreter but calling gtk >>> drawing commands. >>> >>> In the future this could be replaced by a more formal API on the Pd >>> side that would conditionally >>> generate either tcl or any other kind of stream to a GUI. >>> >>> Note that this is only possible because the GUI itself is extremely >>> 'thin', not knowing how to do >>> mouse-hit detection for example. I think this could be viewed as >>> positive (it's fairly easy to just replace >>> it as this branch shows) or as negative ("why can't the GUI take >>> some of the non-real-time work off >>> Pd?) >>> >>> I'm doing this now because it looks like X windows is being phased >>> out of linux distros and apparently >>> TCL/TK has lots of problems under wayland. It's possible that the >>> TCL/TK folks will somehow patch TCL/TK >>> up to work with Wayland's X emulation in which case this all might >>> be unnecessary - but OTOH I don't mind >>> having an escape route in case not. >>> >>> AND... the dependence on GTK itself is pretty lightweight so far so >>> this would probably also be adaptable to QT >>> or whatnot if the world so desires. Most of the work is in >>> interpreting the TCL commands (net.c and tclparser.c) >>> which could move right over to some other GUI setup. >>> >>> cheers >>> Miller >>> >>> >>> --- >>> pd-dev@lists.iem.at - the Pd developers' mailinglist >>> https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/JZXNOQBOCFZK2T6XXTSUKRERY3QB7IIR/__;!!Mih3wA!C-5NW8j9D3v0EtXyZhF9C7vMdHi0yDlva-dOqv9yDb2bGgUnYV48gNqQwE7rsos0yt3xBdIXt4rf6g$ >> >> >> >> --- >> pd-dev@lists.iem.at - the Pd developers' mailinglist >> https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/E3WGNEWBS7DVYC76RI5OI4TS4MJWJPWL/__;!!Mih3wA!C-5NW8j9D3v0EtXyZhF9C7vMdHi0yDlva-dOqv9yDb2bGgUnYV48gNqQwE7rsos0yt3xBdK8kyOvQw$ > > > --- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/SADTCXMYXB3KFEOLDJ5PUTJIFPCKVYZA/
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/UVOHCVX435P...