#12

sticking with jack1 is no longer an option with the latest faust from git - found my way back to lines googling error messages! However the dbus fix above does not work for me now…

On a recent arch install (raspberry pi3) you may find (as I did) it’s necessary to recompile & install jack2 without dbus support in order to run headless. base-path defaults to /usr/local - so you can either configure jack2 with different options, or accept the default /usr/local, then modify your arch system to also search /usr/local:

echo ‘/usr/local/lib’ > /etc/ld.so.conf.d/usrlocal.conf
ldconfig

I prefer this one, so it’s obvious which things have been compiled/installed outside of arch’s build system…

#13

@ioflow @rick_monster and anyone interested: I’ve connected my main audio interface (a Presonus 1818VSL) to the Raspberry Pi 3 and was able to get unpatched Jack2 running. I attempted to run my monome application candor, but it segfaulted so I defaulted to a simple jack client (jacksandbox ) which compiled and ran fine. The following steps assume you’ve installed Jack2 on your Debian-Raspbian system, I’m fairly certain these steps will work on other distributions:

First, if you’re using an i2s soundcard, you’ll want to add the i2s-mmap overlay to your ‘/boot/config.txt’. Save it:

dtoverlay=i2s-mmap

Second, use aplay to list your soundcards:

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 1: VSL [AudioBox 1818 VSL], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

Then, based on which card you want to use, add an entry for that card in your dbus’ “/etc/dbus-1/system.conf”. Replace the ‘1’ at the end of the line with your intended ‘card’ number between the “<busconfig>” tags:

  <busconfig>
      ....
      <policy user="pi">
        <allow own="org.freedesktop.ReserveDevice1.Audio1"/>
      </policy>
      ....
  </busconfig>

And then append this to the end of your “~/.bashrc”:

export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket

Save and restart your Raspberry Pi. Here’s an example of a call to jackd, you can append the “-D” once you’ve settled on a configuration and observe a clean output:

/usr/bin/jackd -dalsa -r44100 -p1024 -n2 -Chw:VSL -Phw:VSL --midi raw

To interact with my ALSA/JACK system over SSH, I’ve installed Python and the JACK-Client module which I used to test my audio connections between clients. Good luck (I’ll update this thread as I experiment further and progress towards a more stable system)!

2 Likes
#14

are you using linux RT-preempt? I had a nightmare last week getting repeatedly mangled on a systemd bug, which was triggered by my linux-rt build…

Kind of thinking seriously at this stage about going back to slack but yea those steps all look familiar - we should really try to club together on here & produce a linux distro something like the old dynebolic but tailored to raspberry pi3, otherwise many others are just gonna be duplicating this same effort. I don’t know how to approach that!

1 Like
#15

Have you considered going with buildroot instead of a distro? It would be more like having a firmware for the Pi rather than an editable OS. AFAIK you can have a readonly rootfs and then mount the SD card for any RW you need.

2 Likes
#16

I am not using linux RT-preempt, I generally keep my kernels stock until I have a reason to patch (which I may have run into). I would love to put together a Raspbian or even ‘embedded linux music performance’ image. I think the desktop is covered with distro’s for multimedia, but maybe something more stripped down and streamlined would be useful.

1 Like
#17

Yeah, I fooled around with buildroot while poking around the AD Blackfin. I think that’s a great idea once a set configuration or selection of applications has been chosen.

#18

I’m currently starting jackd on my pisound box using JACK_NO_AUDIO_RESERVATION` environment variable, which is a bit shorter than fiddling with dbus. Jack just doesn’t try to reserve the sound board and doesn’t seem to mind the missing dbus session daemon.

2 Likes
#19

Nice, I’m going to give this a try tomorrow!

EDIT:
For those interested, here’s the relevant pull request that describes what this does

1 Like
#20

Has anyone tried/started making candor work on a 128? Thinking about UI for stripped-down version?

#21

There are arm7 jack2 debian packages now without dbus. I have a systemd init script…somewhere.

#22

You’re the second interested in a 128 version, I have some ideas in my head to condense the interface and make it embedded-friendly, “uCandor”–it would be a great opportunity to improve performance.
If anyone’s interested in developing a UI, I could provide better state tracking through the OSC interface.

#23

are you talking about adding a grid UI for load/save of the entire state of candor? I gather the way this is done for the eurorack modules is:

  • to save, you draw a glyph
  • to load, you can browse through the saved glyph-scenes & select one

I want to add something like this to the pd grid externals I’m working on - maybe the same system can be easily ported into candor… what do you think?

#24

Ah I see, you mean not computer-screen-visual UI, but the actual grid UI.
There’s no preset management, but as the system runs there’s quite a lot of LED-page drawing and redrawing as the user moves through the interface. I assumed your intention was a visual UI at first which is why I mentioned the OSC interface needing to reflect better state.

I’d love to hook into a grid UI for saving state–not sure where it would live off the top of my head but there’s room.

#25

Yup after a quick peruse of the manual I concluded that the grid UI for “uCandor” might be a tricky design problem. I guess one way to attack this would be to quickly jerry-rig another button (maybe return on stdin) to switch the 128 between acting as top/bottom half of the 256. This way someone with a 128 could get to know the features enough

#26

Would 8x8 with four mode switches work? I have a controller that could do this.

1 Like
#27

iirc you rolled your own serialosc clone… so you could potentially add 128/256 emulation at that layer. Come to think of it maybe ‘256 emulation for 128 owners’ would be a worthwhile addition to serialosc (though the feature makes more sense on a controller with the four extra buttons)

#28

I think what I’ll do is combine the bottom two quadrants into a hold-and-press system in the top-left. I’m pretty sure there’s an unused button on the right-most of the sequencer page-select row which might make a good candidate for a glyph-drawing page.

1 Like
#29

maybe getting ahead of myself a bit here… but an aspect of what I’m doing on the puredata side (again very much aimed at headless) is ‘focus-swapping’ between apps. An idea I’m toying with is for each app in the pd ‘ecosystem’ to have a key combo which triggers ‘unfocus’, accessing an overall navigation page where all the running apps are ‘registered’. This is totally achievable when all ‘apps’ are pd objects - maybe this kind of idea could extend to different programs too…

Could be worth keeping the possibility in mind while thinking about how to use those precious spare keys!

#30

I like this–how do the pd objects communicate whether they are focused? Inlets/outlets?

#31

currently the design is copied directly from aleph BEES. each grid app object responds to the message ‘focus’ by ‘grabbing’ focus from a central controller. This is an excellent design on the aleph because you have patchable buttons on the front panel which can handle the focus-swapping. In my pd external, apps respond to ‘unfocus’ by telling the central controller to focus, which currently just displays a pattern.

Haven’t yet implemented a navigation page in the central controller, partly because at the back of my mind I was thinking it’d be cool if such a thing was not constrained to my pd ops…