Prebuilt Pure Data image

Pisound Feature Requests
1

Hey, as discussed in Complete Minimal Setup Instructions, we’d like to know what features you would like to see in a Pure Data flavored pre-built OS image for use with Pisound.

So far, the plan would be to make another fork of pi-gen repository used to build the original Raspbian Lite / Desktop images and MODEP, and apply the appropriate customizations to generate the PD image. It’d also be convenient for you to provide additional customizations via the pull requests.

The base so far would be Raspbian Lite, with GUI packages, Pure Data and Pisound software installed, ssh enabled by default.

What other things would you like to see in the image? Any PD externals to be included by default?

Let us know what you think! :slight_smile:

2

preemptive kernel, tuned with the usually audio settings.
would be good to have supercollider 3.9 on it too.

and by default X not too come up,
perhaps could be like the Organelle, where you just type startx to start x if needed.

main thing is it to be light and headless i think…

2 Likes
3

If we approach the whole thing from an activity-based perspective I’d say (some things already work, but for completeness’ sake I’ll list everything that comes to mind):
The aim is to offer a system that will provide all the necessary tools to be able to develop Pd (and perhaps Sc) patches and perform with these, without the need to attach a display and keyboard/mouse. If we break down this activity I’d say we need to be able to:

  • run the system headless and dynamically load/unload stuff with either the button or the app
  • have a simple way to move files from one’s main computer to the rpi and back
  • have low-latency audio performance
  • just attach a MIDI controller and have it work (as long as it’s class compliant)
  • access wifi hostspot mode, shutdown and reboot via button
  • in general not having extra stuff installed.

to be more specific these things seem to be needed:

  • access via SSH / VNC (and
  • bluetooth enabled and working
  • of course have the Pisound stuff already in place (button, driver, etc.)
  • maybe find a way to avoid the messy user discrepancy between running Pd normally from the desktop and via button/app (pi user vs. root)
  • have X installed, but not running by default (as thetechnobear said above)
  • Samba would be neat. I’ve looked into SCP, which totally works for me (I mean, I need to try, but seems very straightforward), but using the native OS file manager to manage files would certainly be easier for some people.
  • possibly already have some commonly used repositories set up, so installing further software would be easy.

This is of course from my perspective as somebody who does not get deep into development (i.e. by developing I mean just making patches, not writing additional code like for eg. externals).
But then, people who do that, will probably a) know how to make their own tailored linux install and b) have more specific needs anyway)

4 Likes
4

Basicly, you’ve listed all, i was hoping this setup would be, but since i don’t have a screen and don’t want to bother with VNC, it’s still collecting dust

5

I caution against too much optimization and specialization without us all doing the objective testing to know it is worth it.

In particular:

  • A preemptive kernel may not actually be better: RPi is four core, and even running SC, one isn’t running more than one intensive process per core. Fully preemptive setting makes the kernel more expensive as I understand it.
  • Governor choice doesn’t need to be compiled into the kernel - it can be changed dynamically in the standard kernel. The cost of ondemand (the default) isn’t all that high, and once running audio, the CPU frequency won’t drop. But if you were worried, you could switch it to performance with a shell script at boot, or on Pd / SC boot.
  • Changing the TICK interval (from 100Hz to 1000Hz) may have zero effect on modern audio software if they are using the hi-precision timers anyway. In fact, it can eat available CPU due to the increased overhead.
  • Modern X, with the minimal install I built, costs pretty much nothing in CPU or memory to have it running so long as you don’t have it automatically log in. And the convenience of just being able to VNC in (vs. SSH in, then startx, then VNC) seems worth it to me.

I want to stress that I have done NONE of these custom tunings - and I’m getting consistent -p 64 -n2 performance out of jackd, SC, and Pd with zero xruns.

6

I’m very happy with the amount of testing I did, and determining if it was necessary for my needs.
i assume likewise, you came to your own conclusions, based on your needs.

the question is not about if pre-empt kernel is ‘required’ or not, buffer settings etc, that depends on the dsp load you have, and how you are planning to use the image.

so, the question rather is,
what is the purpose of this image?

is it:
a) a general purpose PD image, allowing development of the patch on the box.
if so, then you want a ‘balanced’ setup, with some conveniences as you describe.

b) a performance ‘headless’ setup, avoiding latency and possibilities of audio glitches at all cost.

personally, I tend to develop on a desktop,
then transfer setups to a rPI for playing music… so the rPI is headless and setup for performance(*).
but, that’s just my workflow… others no doubt are different.

anyway, just suggestions, I already use my own images anyway, so its a moot point for me.

(*) i also have a another sdcard, with a rPI image which is used for development, e.g. compiling my C++ apps, though increasingly I want to move this over to the desktop and use cross-compilation)

7

I’m sure @Giedrius could do a little poll/research to see what the current user base needs most.

2 Likes
8

and btw. @thetechnobear I think there’s also a third category. I.e. an install that lets you do both, developing patches and performing with them. There’s many reasons why you’d want to develop patches directly on the rpi, one being that you need to keep an eye on what the thing can actually run, and second there’s externals (eg. your Mutable ports) that only run on linux/rpi, if you don’t want to have to compile them.

9

how does that differ from option (a)? except saying you want both :wink:
my points was a general purpose image, will compromise on performance a bit… its does this so that you get a decent ‘user experience’ and so that it can maximise throughput.

now its quite possible you do not need that last bit of power,
if your find running a stock Raspbian build for your patches, and they are working fine.
that’s cool - there is no right/wrong here, It totally depends on what your doing. (that’s why Linux gives us options to tailor our systems)

10

yeah, fair point. It is likely the same indeed. :slight_smile: