My experience with Pisound so far

Pisound
1

Preamble

I got the Pisound through the Indiegogo campaign, so that was some time ago. Since first getting it I have been using it intermittently, with long periods of time in between. I’m quite busy with work, so making music is mostly something I do at night (late) and on weekends. This is just to say that my memories of the experience might not be 100% accurate and that I’m certainly forgetting many details. But still… it might be useful as a feedback to the devs, so here we go.

Also it might be good to know that – while not being a developer, nor a computer expert – I did always mess a bit with linux and coding. This probably makes me a medium-type user.

Getting Started

Getting started was easy. Connecting the Pisound to the Rpi was quick and straightforward, and the case was really simple to assemble as well.

Downloading Raspbian, burning it on an SD with Etcher and booting the thing was spent 90% downloading and then 10% for the rest. So, again, pretty quick and easy.

I first got the version before Stretch (can’t remember the name) and I remember struggling to install Pd 0.47 (at the time the official repository only had 0.45 or something like that). But once Stetch came out that (and some other issues I can’t remember) were sorted out.

When I got the Pisound I did have a couple of ideas of what I wanted to do with it (having a headless Pd system being my main goal), but these weren’t overly specific. So I spent quite a bit of time just trying out random stuff. Installing some software and seeing what I could do with it.

Getting deeper into it

This is where things started to get a bit rough. Nothing major, just many little frustrations. Linux does have the tendency to be a bit like that, especially for people like me, who are not really experts, and just wrestle their way through somehow. Some of it was definitely just part of the learning process (to learn something new, you have to fail, and then fail again, until you start getting it right). I should note that most of this is not related to the Pisound board itself , but to Linux/Raspbian/Pd in general.
I can’t remember all of it, but the major aspects probably were:

Running Pd

The whole “Push a button” to run a patch is nice, albeit a bit limiting. You quickly hit a wall with that, so I’m really glad I have the app now. Having to carry around 10 USB sticks just to be able to have different patches ready is not really an option.

The actual issues were mostly these:

  • It took me a bit to realize that most externals compiled for rpi/Arm are not available in Deken, but can be easily installed via apt-get (though I also found that some of them are buggy and/or lack some bits and pieces, for eg. the version of Zexy in the repo does lack multiplex~)
  • when you run Pd from the desktop you run it as “pi”, when you run it through the button or app you run it as “root”. This has been discussed previously (several times, I know) so I won’t get into the details, but this keeps being annoying to me mainly because I can’t get Pd to read my settings file (despite trying the recommended fix, which for some reason just won’t work for me). The consequence of it being that Pd won’t look into the search paths I have specified for the externals, forcing me to add them directly to the patch.
  • I do have some weird performance issues which I wan’t able to troubleshoot yet. It seems to happen with certain patches (some of Patrick Pagano’s recent ones also do this). The symptoms are that the audio quality degrades, Pd spits out some error messages (snd_pcm_delay failed). I Need to properly troubleshoot this. It’s a bit annoying because once this happens I have to reboot the rpi, or Pd will just crash badly all the time or refuse to load patches.
  • when running Pd from the desktop, using ALSA for MIDI is a major pain. Unlike OSS MIDI where you can just select which MIDI devices to use, ALSA relies on aconnect, which – at least as far as I could find out – needs to be set up from scratch every time. Fortunately OSS MIDI does work fine though.
  • In the beginning I had Raspbian set to automatically boot into X. Later I found out that this would crash Pd when run over SSH -X. Solved it by setting the boot option to CLI and manually starting X when I need it.

File Sharing

Setting up Samba didn’t work. Don’t ask me why, but I just couldn’t get it to work. The shared folders just wouldn’t show up on any computer.

I did try SCP, which in theory seems nice, but there’s a couple of caveats:

  • You can only access files or folders that belong to the “pi” user, anything that belongs to root (like for eg. the “puredata-patches” folder) won’t work. There goes that “root” issue again. this means hat copying anything needs two steps: copy to some accessible folder on the rpi using SCP (usually one in the user’s home directory), then doing a sudo cp via SSH to copy that to the actual destination folder.
  • Using the CLI to copy files around is a major pain. Need to look into some other solution. Maybe Filezilla will work.

Bluetooth

Setting up bluetooth with the Pisound app was really quick and easy when I did it the second time (after re-burning and tweaking the image according to mzero’s guide). The first time it drove me mad. I had disabled bluetooth from the desktop since I wasn’t using it, then when I did want to enable it again it didn’t seem to work properly. Took me several attempts until it then worked (but don’t ask me what I did, it’s a mystery to me).

Swapping SD cards

As a minor note… I wish the SD compartment was a bit easier to access with the official plexy case. Having to unscrew it every time is not 100% ideal.

Other things worth mentioning

Ardour seems to be a bit buggy on rpi. There’s a couple of showstopper bugs like for eg. when you create a new stereo track it will crash.
while it makes the board very small (which is a great thing) having stereo 1/4" jacks instead of two mono ones means you need special cables and/or adapters.

2 Likes
2

Hey, first of all, thank you for sharing your comprehensive feedback with us, it’s definitely useful for us to take into account.

If this is what I’m thinking, starting puredata with ‘-nogui’ argument could have been an alternative solution.

This is a permissions problem, the easiest way to get around it, would be to grant everyone access to the puredata-patches folder, like this:

sudo chmod -R 777 /usr/local/puredata-patches

Then you can access the files in it via scp directly.

3

I started noticing this error too, however didn’t get system freezes because of that. It seems to have appeared with more recent builds of Raspbian, didn’t have such problems before. I suspect it could be a process priority problem where pure data does not get enough processing time to run without glitches. This is something we’ll look into in the near future.

4

Yeah, but I want to see the GUI when running X, because usually I do that to troubleshoot/test patches.

Yeah, not sure why I hadn’t thought about that that, thanks a lot!
Now let’s hope Filezilla works!

To be more specific the bad freezes happened with one of my own patches. There I was using 8 tables (read via tabread) and loading rather long samples into them. Probably that was pushing the system to its limits. Patrick’s Odyssey patch does get glitchy after some time, but restarting Pd does fix that. I also noticed some snd_pcm_delay errors with granular delays and effects.
As I said, I’ll try to collect more data and report back when I have something.

5

chmod -R 777 did the trick indeed and I can confirm that Filezilla works fine to transfer files around. So that can be considered SOLVED!

1 Like
6

Continuing the discussion from My experience with Pisound so far:

Im in a similar situation to Kurodama although it sounds like they have a little more experience in linux than i have. Busy at work and a young child has left me with little time to learn more about Linux and PD in general, i had great ambitions about building midi controllers etc to put to use on these patches but all these ideas are now on the back burner.
I will say that i have learnt a lot so far and hope to in time be able to contribute in some way in time. However at the moment all i really have time for is, the primary reason i got this device, playing around with the patches kindly provide by others.
I very much appreciate the simple “how to” instructions by members like mzero these are very helpful to people with limited experience like me.
i also have to echo Kurodama issues with externals and root user permissions that was really wrecking my head for a while. having different paths for different users was annoying…also issues with adding patches to the root folder meant that i ended up just using the app for this process for the last while . i will attempt the fix stated above.

2 Likes
7

I think at times we have all been there… more projects than time :slight_smile:

my recommendation for this is very simple:
setup your pisound (or whatever) to do one thing… with really modest ‘ambitions’,
even if that is to just run say the modep image with a nice patch, and perhaps assigned to a midi controller you have - something you can realistic do in a few hours.

I like to do this now, early on when I get something like pisound - so that it immediately ‘has a use’, and doesn’t stare at me as a ‘potential project’, and then what I find, is because I use it, I start slowly tinkering with it, and slowly start fulfilling more ambitious aims.
might not work for everyone, but works for me, makes me feel less frustrated…

sorry, i don’t use the button, but im not quite sure i understand the problem…
is the button handling not run as a service?
if it is services, then services can be run as a user, they don’t have to be run as root… so just have the service as PI, then you always have the same environment.
(you can also specific environment vars/working directories etc)

for me switching patches via the buttons is not really useful.
i go for a ‘startup’ patch, and then if i wanted to switch, i think that’s better done by a midi controller via program change.
it is was to use the button, it would probably be for wifi on/off… and perhaps shutdown.

anyway, hopefully if a standard image is created, then this could be refined to work on these little ‘niggles’

as for experience, im pretty happy with the pisound, I love the midi din, and the proper TRS jacks, and i think the gain/volume knobs are useful.

the only things i think could be improved for a v2 are:

  • midi din makes it really difficult to access the sdcard, if you have a touchscreen attached.
  • headphone/monitor jack
  • use less gpio, so more available for adding your own buttons/encoders/pots

… oh and id like a proper case,
ive not got a second Pi3, which currently i have a hifi berry dac+ on,
id switch that for a pisound, but when i bought it came with a beautiful steel case , mines in brushed steel and looks great - so im loathe to change it… but i do miss the audio in from pisound

1 Like
8

Yeah that reminds me of somebody :slight_smile:

For what it is worth, now that I have it all figured out things really run well. The only thing I have to do to make sure things work is to put any external I use into the same folder as the main Pd file is. But this is good in general since this way it’s one thing less to do in case I want to share the patch to others.

That’s a great suggestion. I can only second that. Took me a lot of “banging my head against the wall” to figure that out. Now I only use the Pisound as a headless Pd box and do not look at anything else. it’s much better this way.

Not sure why it works as it works, but when you run a patch trough the button scripts (or the app, same thing) Pd will be launched as “root” not as the normal “pi” user.

9

It gets launched as root, because both pisound-btn and pisound-ctl daemons are running as root themselves. I’d prefer them to run as regular users too, however, I couldn’t find a safe way to know who is the ‘main user’ of the system. People may rename ‘pi’ to something else or use a different distribution like arch linux one which has a different user name by default. Another question is whether if there’s no one logged in into the system, would services running only as the given user get started up automatically on system boot, if autologin is not enabled.

The only dependable user in linux world seems to be ‘root’. :slight_smile:

If someone knows how to solve the above issues properly, do let us know!

10

Maybe it’s just a matter of adding some info in the documentation. Now that I know how do deal with it, it’s not a problem anymore. It’s just a bit of a hassle for people who are new to linux, or not expert enough to know how to sort things out.

11

yeah, thats true, unfortunately i don’t think you can be totally distribution independent.
(its one of the pains with linux)

one way around this, would be for you to create a user , say pisound, as part of the ‘install process/image’, that way you can dictate things like environments.

services started independently of to the user being logged in (or not)
so yes, if enabled they start automatically.

generally i think all you (blokas) can do, is target a specific distribution (that you provide) , but make the scripts etc open source, so if someone want to convert to a different image/distribution then thats up to them.

or put another way…

this way inexperienced owners, just have want a working system with little effort.
but more experienced owners can dig in and adapt what you have provided to their needs.

one real advantage of you standardising the image, is then open source developers/community , can provide you with PRs to improve it, in say a similar way to what I have done with Organelle.
with the current, ‘all things to all men’, thats kind of impossible… theres nothing really to build on - all you can do is help people when they are trying to set things up.

i do however, recognise this is almost a different ‘product’
rather than supporting some hardware your providing , your more developing a hardware/software platform for end-users … which can be hacked as required.

3 Likes
12

FWIW, I have a mostly painless workflow. My pi is a similar simple headless pd box which I load with patches via a personal git repo. I edit patches on a windows machine, and when I am happy with the patches, I log into the pi and run git pull to update. Button presses select one of eight patches. Works quite well!

Looking forward to trying out the monome norns system at some point.

13

@thetechnobear, it would be great to hear your experience with the DAC+ steel case in terms of on-board Wi-Fi & Bluetooth performance. What’s the impact on distance? Any other issues?

1 Like
14

I dont use bluetooth, so no idea :slight_smile:
Wifi Ive not had an issue with , but in the interests of comparison I did a test …

Raspberry PI3B+ w/ PiSound , no case
iwconfig wlan0 : Link Quality=70/70 Signal level=-40 dBm
Router : Signal -41 Noise -92 SNR 51 Quality 65%

Raspberry PI3B w/ hifiberry DAC+, steel case
iwconfig wlan0 : Link Quality=53/70 Signal level=-57 dBm
Router: Signal -58 Noise -92 SNR 34 Quality 44%

both in exactly same position.
its not that far from the router, but has a wall in-between, and quite a lot of gear (so interference)

for comparison, my iPhone 6, is showing around same signal strength as rPI3b+, so thats pretty good.

ok, this is not identical, as the 3B+ has an improved wifi chip, and I don’t know if this is resulting in an improved signal, but if it is Id say its not going to the 15dbM (but honestly, I can be bother to take it out of the case to test without :wink: )

so Id says its going to hit you on distance… but in practice for my needs, Ive never really noticed an issue, but YMMV, and having it in a nice, and solid case is worth it.

again, my usage may not be typical…
when doing ‘development’ on the PI (mainly compiling/cross-platform testing), I often plug in an spare ethernet cable which I have on my desk.
when Im ‘using’ the PI, Ive tended to often use it without any kind of network…
though this is changing a bit now, so Im thinking of having an access point started.

1 Like
15

Thanks! Bluetooth & Wi-Fi performance is a major concern when it comes to steel enclosures, and there are many different experiences reported around the web. We will be doing some tests on our own to see what could be the most optimal solution for the more rugged case. Some custom cut-outs or maybe mix’n’matching both steel and acrylic parts could be an option too. :slight_smile:

1 Like
16

I used a regular Hammond alu case with large cut outs either side for access. No problem with WiFi.

2 Likes
17

I’ve used the Pisound+Rpi+App combo for a bit now, so maybe it’s worth updating my feedback from above a bit.
But first big thank you to people here and over at llllllll.co for helping me with my struggles! A thing like Pisound can only be as great as the community that surrounds it, and I mean it in the most positive sense.

As a general note I must say that the inclusion of the new app features and MEC have made Pisound and its app much more useful to me. The experience of using it has been smooth and so far bugless (as far as I can see).
I have to say though, that my overall experience with Rpi linux / Pd has been a very frustrating and painful one since the beginning and it still is a bit like that, despite the efforts put into making it better. But it’s improved since the beginning, so I’m still positive, even if I’m less enthusiastic about Pd now…

Anyway, there’s a couple of areas where I think the Pisound app could be improved and it mostly has to do with how you script the MEC integration (and please excuse me if I misidentify what is the actual app and what is MEC, I don’t have the full understanding of what happens under the hood).
First of all, there seems to be a lot of redundancy to me. The same info (eg. patch name) has to be typed in multiple times in 3 different files. This gets more pronounced when you get to the parameters. Also a little question: do I have to fill in the “rack” JSON file, or will that be filled out automatically by the app? I see that the content of the file gets updated by the app sometimes, but it does not seem to happen all the time.
Right now it’s very easy to make a mistake when typing down the info in the JSON files, but the app does not really give you much to work with if things don’t work (eg. if the controls don’t appear on screen).

I think the main issue with the Pisound ecosystem right now is that it’s made up of a lot of very heterogeneous bits and pieces that you need to make it work: SSH -X or VNC for direct access, SCP for file transfer, Shell scrips for the launching of things, YAML for the main app infos, MEC / two JSON files for the control part and then of course Pd… it’s a very fragmented experience and it hides a huge lot of potential error causes, which are often hard to troubleshoot.
Having less elements involved would probably help somehow.

1 Like
18

With mec you should only need to edit the parameter json file (aka module.json) , not the rack file.
I’d recommend watching the videos I’ve made for Orac over the module creation process, it’s largely the same as is being used, and might provide some context.

It’s probably best to have these discussions in a separate thread - preferably with specific questions, as I’m not 100% clear how mec has been used by blokas so i’ll need some context.

19

The rack.json file gets filled / updated after midi-mapping a control in the app, that’s when the app asks MEC to save a preset called ‘default’, saving and loading custom-named presets will come in a later version.

You probably mean the blokas.yml, …-module.json and patch.pd. There are perspectives for making an editor for the first 2 files, even if command line one, but it will take a while for them to appear.

This is kind of a curse of Linux ecosystem as a whole, evident by the sheer number of Linux distributions and the many competing ways of achieving the same goal. But it also enables small teams to achieve a greater whole by reusing bits and pieces from here and there.

20

@thetechnobear: yeah you’re right, I’ll do that

@giedrius: I guess I’m currently a bit frustrated with linux as a whole. I think you’re doing a great job at making Rpi linux more usable for music projects, and I’m sure it will just get better and better.
So the goal here was just to share some of my frustration points, in case that is something useful for future development of the platform.

No actually I erroneously thought I had to fill in the “rack” file myself the first time, but my fault.

1 Like