My 2 (EUR) cents... :)

Message: 2 Date: Thu, 21 Feb 2019 22:46:32 +0100 From: Antoine Rousseau antoine@metalu.net To: Pd-list pd-list@lists.iem.at Subject: Re: [PD] Audio clicks with postgresql external Message-ID: CAOCG5Hx9uP7emPN3SoeGPPVAAiS07Wj4yH5eCn2sX09GT1Xfdw@mail.gmail.com Content-Type: text/plain; charset="utf-8"

You could try:

• to launch a second instance of Pd from your init script, and communicate

via [netsend] / [netreceive]

• or to run this second Pd instance via [pd~]; this could be simpler to

implement (because you'll just use inlet/outlet to communicate), but I don't know, even with -noaudio and -nogui flags, if it will avoid the master instance to block.

On limited resource machines, if you have plenty of RAM, I would suggest running the postgres part of the project in a separate process using something like a python script. Then use OSC for the communication. This way, Pd will never block the audio while the postgres process blocks accessing the db. You can wrap up the project into a script which starts both pd and the python script in the right order. Even better would be to write it in C, but try something like Python first and stick with it if it works well enough.

This approach worked quite well for me on my old wearable running a 500 Mhz Pentium 3 with 256 Mb RAM. One thing to do is to balance the process priority toward Pd by using "nice" to make Pd "no nice" and make the python script / postures access program "more nice."

I'm a bit conservative and have never approached running *everything* in Pd partially because of this reason. I usually write separate IO programs which then communicate to Pd which does the audio and most of the creative "sauce" / mapping. The added benefit of this approach is that you can easy distribute things if/when you need to, such as expanding an existing installation to have say 10 clients and 1 server.

Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/