Not working anymore: single click to launch Pd patch from USB

-nogui sounds like a better fix - logging in as ‘Pi’ would not be required if you’d like to use Pd in headless mode.

Would you see any possible issues arising from added -nogui?

We’d like to keep the PureData GUI opening up on the single click, so it’d be best to avoid the -nogui option.

Any ideas how to restore the original functionality that meets the requirements of starting PD with GUI if the user is logged in, as well as being able to start PD even without the ‘pi’ user being logged in?

I don’t see the issue of running Pd with -nogui except when still setting things up and troubleshooting possible hiccups. For now it could be a feasible fix (so thanks for it @thetechnobear!) , but I agree with @Giedrius, there should be a more permanent fix that does not involve -nogui or logging in as ‘pi’

and regarding this:

Hi, what output does PD give about MIDI?

It does not give any output at all. that’s the weird thing. Both the terminal output and the log stops at “Connecting all MIDI ports to and from Pure Data.”

Ah, it’s expected to give no output then :slight_smile: It’s just the last thing logged by the single_click.sh script: https://github.com/BlokasLabs/pisound/blob/master/pisound-btn/single_click.sh#L113

It would not require logging on as PI, it would just run the process as PI.
Which would mean IF you were running an session with PI it would have access to the desktop.

I think there is also a way to let root have acces to the desktop too, by granting rights in Xauthority.
I’ll take a look.

The main issue I see with nogui is if (like me) you have a touchscreen attached , you might still want the one click… though I can see that’s probably not that likely, as you could start PD easily thru X or X startup

ok, you can get pure data to pop up on the PI x display if you add the following to the top of /usr/local/etc/pisound/single_click.sh

export XAUTHORITY=/home/pi/.Xauthority
export DISPLAY=:0

not quite decided which way I’m going to go… depends how I decide to do the UI interaction with the PD patches… but at least I know I can use either way…

3 Likes

Hey, cool! I think popping up the GUI is useful for making sure things work.

One issue I foresee though is that ‘pi’ user may have a different name on a different distribution or the user may rename / create another account for himself. Any ideas how should such situation be handled?

Thanks a lot! This is probably better than -nogui indeed.

I’d like single-click.sh to run pd with -nogui if there is no logged in X user, and without -nogui if there is.

That way I can run my pi & pisound headless, and set to boot into Console mode (via raspi-config). Pressing the button once now will launch my performance patch, without gui resources.

I have VNC set up, and so there is an X server running on boot, but no logged in session. That consumes a few resources, but not much. When I connect into the pi via VNC, and then log into X, then there is a session. I would be great if I could just make the pd GUI pop-up at this point (can you start the GUI separately after pd start?) However, it would be good enough for me to press the button again, re-starting my patch. In this state, single-click.sh would start without -nogui, and I’d see the GUI on my VNC session.

1 Like

Do you know any commands that can be used to know whether there is a logged in user with an X session? If so, making -nogui to be added conditionally should be doable.

The command is xhost. It exits with 0 if there is a session, 1 otherwise
So perhaps something like:

export XAUTHORITY=/home/pi/.Xauthority
export DISPLAY=:0
PURE_DATA_GUI='-nogui'
if xhost > /dev/null 2> /dev/null; then
    PURE_DATA_GUI=''
else
    unset XAUTHORITY
    unset DISPLAY
fi

# then later in the script...
nohup puredata $PURE_DATA_GUI #...

Edit: Needed to export the X env. vars before calling xhost, and so unset them if no session (not needed, but tidy.)
Edit 2: This is the working script out of my version of single_click.sh

3 Likes

I’ve updated my response above with the working script fragment that I now use.

One other thing I’ll bring up: It is somewhat awkward that this script runs pd and aconnect etc. as root, whereas when you’re fiddling you tend to run these as pi. pd reads settings from ~/.pdsettings, which is modified when doing things like installing externals, and those settings aren’t used when run as root.

I see both sides of this: You want single_click.sh to be predictable (not subject to what the user fiddles with when logged in…) - but one also wants it to just launch what the user could have launched.

1 Like

That is pretty much our line of thought. If anyone knows of a way to start a background process in a compatible way with the ‘main’ user on a Linux system (and without requiring for the user to login first, so it works in headless mode too), let us know. :slight_smile:

So if I understand this correctly I must make all patches that I want to run headlessly assuming a vanilla Pd without externals? This would pretty much defy the purpose of the Pisound for me…

Looks like there’s a misunderstanding - you may set up a /root/.pdesttings as you like and use that, or you may change the pisound-btn systemd daemon to run as pi or some other user instead. The latter way, I’m not sure it would work in headless mode without first logging in with the user, in addition, I’m not sure if there’s a way to know which user is the ‘main’ one on a Linux system, the only constant seems to be root. If anyone knows more or better ways to do this, we are open to suggestions. :slight_smile:

just to understand this better.
Everything I do when I run the normal desktop version of Raspbian through a monitor is using the pi user account, is that correct? So all settings I make in Pd will refer to that user.
If I run Pd headlessly using the button, I do it as pi or as root? So far it sounds like I’m running it as root.
So I assume I have to set up a /root/.pdesttings to mirror the equivalent for the pi user to my externals and settings are the same?

Yes, I think /root/.pdsettings could be a symbolic link referring to /home/pi/.pdsettings, as long as the root user has access to that file.

ok thanks a lot! I guess I can make it accessible via CHMOD can’t I?

A little bit of chown goes a long way: If you set up the place where externals get installed to be owned by pi, then you can install them while you are logged, using pd graphically, and later run the same patches from the button (which runs them as root). Here’s my externals directory:

pi@mupi   ~
[742] : ls -ld /usr/local/lib/pd-externals/
drwxr-sr-x 5 pi pi 4096 Sep  9 15:06 /usr/local/lib/pd-externals//

pi@mupi   ~
[743] : ls -l /usr/local/lib/pd-externals/
total 524
drwxr-sr-x 2 pi pi   4096 Nov 15  2016 abl_link~/
-rw-r--r-- 1 pi pi   2967 Aug 31 22:19 abl_link~-help.pd
-rwxr-xr-x 1 pi pi 512652 Aug 31 22:21 abl_link~.pd_linux*
drwxr-sr-x 2 pi pi   4096 Jul 29  2016 freeverb~/
drwxr-sr-x 2 pi pi   4096 Nov 18  2015 ggee/
-rw-r--r-- 1 pi pi   2140 Jul 29  2016 output~.pd

Fear not, @kurodama, as you can see I’ve got several externals installed there, and I can use them all from patches launched by the button.

The command for setting this up would be:

sudo chown -R pi:pi /usr/loca/lib/pd-externals

If sym-link or hard link /root/.pdsettings to /home/pi/.pdsettings, as @Giedrius suggests, then when you File > Preferences > Save All Settings from pd graphically, you’ll be saving the same settings that will be used when patches are launched from the button. This works well for getting the search paths right. Note that the button script explicitly sets some parameters on the command line - and those will override your preferences, so if you need to changed, change the script or remove them from the script and change in your preferences.

The command for setting this up would be:

sudo ln -s  /home/pi/.pdsettings /root/.pdsettings

Alternatively, you could edit single-click.sh script to launch pd as the pi user:

nohup sudo -u pi puredata ...
1 Like

Huge thanks! Of course I meant chown not chmod.

Yes the search paths were my concern! Everything else I’m totally fine with setting in the launch parameters inside the script.