Is Pof outdated? (was: [PD-dev] Re: Pd in wayland - maybe use gtk branch?)

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 PoF
>
>
> In 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 <[email protected]> 
> 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
>     >>>
>     >>>
>     >>> ---
>     >>> [email protected] - the Pd developers' mailinglist
>     >>>
>     https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/[email protected]/message/JZXNOQBOCFZK2T6XXTSUKRERY3QB7IIR/__;!!Mih3wA!C-5NW8j9D3v0EtXyZhF9C7vMdHi0yDlva-dOqv9yDb2bGgUnYV48gNqQwE7rsos0yt3xBdIXt4rf6g$
>
>     >>
>     >>
>     >>
>     >> ---
>     >> [email protected] - the Pd developers' mailinglist
>     >>
>     https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/[email protected]/message/E3WGNEWBS7DVYC76RI5OI4TS4MJWJPWL/__;!!Mih3wA!C-5NW8j9D3v0EtXyZhF9C7vMdHi0yDlva-dOqv9yDb2bGgUnYV48gNqQwE7rsos0yt3xBdK8kyOvQw$
>
>     >
>     >
>     >
>
>      ---
>     [email protected] - the Pd developers' mailinglist
>     https://lists.iem.at/hyperkitty/list/[email protected]/message/SADTCXMYXB3KFEOLDJ5PUTJIFPCKVYZA/
>
>
>   ---
> [email protected] - the Pd developers' mailinglist
> https://lists.iem.at/hyperkitty/list/[email protected]/message/UVOHCVX435PASY7RWO2QRZGW3CP7T622/

---
[email protected] - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/[email protected]/message/SUOUWUVP2VOERE2VQME45CFWFSWXJ5V2/

To unsubscribe send an email to [email protected] mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/