Beginning a GNU/Linux/JACK headless performance system

murray · 2016-10-10T19:20:12.092Z

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.

murray · 2016-10-10T19:21:10.590Z

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.

artfwo · 2017-11-24T06:59:04.516Z

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.

murray · 2017-11-24T09:37:38.094Z

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

github.com/jackaudio/jack2

Enhance promiscuous mode

by sdrik on 01:33PM - 02 Nov 14 UTC

1 commits changed 8 files with 195 additions and 12 deletions.

rick_monster · 2017-11-24T18:12:39.694Z

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

lazzarello · 2017-11-24T22:09:20.181Z

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

murray · 2017-11-25T20:36:36.052Z

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.

rick_monster · 2017-11-25T20:48:23.061Z

murray:

If anyone’s interested in developing a UI, I could provide better state tracking through the OSC interface.

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?

murray · 2017-11-25T20:59:41.438Z

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.

rick_monster · 2017-11-25T21:14:56.575Z

murray:

Ah I see, you mean not computer-screen-visual UI, but the actual grid UI.

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

lazzarello · 2017-11-25T22:57:22.797Z

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

rick_monster · 2017-11-25T23:13:00.650Z

lazzarello:

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

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)

murray · 2017-11-26T01:04:31.056Z

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.

rick_monster · 2017-11-26T01:35:16.292Z

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!

murray · 2017-11-26T01:41:52.558Z

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

rick_monster · 2017-11-26T01:48:02.554Z

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…

murray · 2017-11-27T22:11:41.276Z

Would building out the pd externals to include liblo or a light library wrapping your focus functionality be enough to expose the functionality to external applications?

rick_monster · 2017-11-27T22:49:35.109Z

murray:

Would building out the pd externals to include liblo or a light library wrapping your focus functionality be enough to expose the functionality to external applications?

Already using liblo in pd-grid - need to think harder about the focus-swapping functionality though. My thoughts on this are too noisy right now - can’t figure it out…

I have another partially finished monome midi sequencer app - that would be a good testbench for ideas about how inter-process focus-swapping can be realised…

Galapagoose · 2017-11-29T03:43:21.190Z

This is basically what I was going for with Smallbatch (later used in Sum). Obviously the implementation is specific, and probably over-engineered – each app has it’s own OSC port that is registered with smallbatch — but I think the concept is generally a good one, especially for headless. Not sure there’s much reusable logic in there, but I think it’s at least an example that shows the utility of such a setup!

rick_monster · 2017-12-01T06:25:04.447Z

heh, I managed to resurrect this Sguenz (embeddable linux-hosted lisp sequencer) - it succumbed to the ‘lisp curse’ in a big way… couldn’t figure out how to use common lisp’s ‘portable’ socket library because the documentation & examples are dreadful. So of course instead of figuring it out, I decided not to use OSC & successfully rolled my own raw serial driver but only got 1/2 way towards a useful toplevel application before running out of steam. Could’ve been worse, I could’ve decided serialosc itself needed to be rewritten in common lisp along with every other piece of software ever…

anyway, finally figured out the tricks to use OSC portably from sbcl/ccl, documented my work, sent a pull to maintainer of the OSC lib & finally added bare minimum serialosc support to cl-monome (lisp-native libmonome-alike). glad I resurrected the app itself - there are some pretty neat aspects to it…

Onward toward a system for inter-process focus-swapping! (maybe even finish & publish my app…)

EDIT:
the desired focus-stealing behaviour is simple to implement (now done in both pd_grid & sguenz), because serialosc actually notifies the last focussed client when someone else steals focus. thanks serialosc!