Beginning a GNU/Linux/JACK headless performance system

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!

dailybells · 2017-12-09T01:08:36.279Z

Has anyone tried out pipewire yet? The fedora folks are working on new system and just shipped the audio part of it in 27. I actually have a fedora 27 desktop at work right now, but I haven’t done anything except play audio from firefox with it yet. (That works great though!)

Here’s the pipewire site: https://pipewire.org/

(I just use ALSA w/o jack personally, but only because I don’t do any inter-application routing any more…)

And some context from the docs – these are all exciting goals:

PipeWire is a new multimedia framework designed from scratch that aims to provide

graph based processing with support for feedback loops and atomic graph updates

flexible and extensible media format negotiation and buffer allocation

support for out-of-process processing graphs with minimal overhead

Hard real-time capable plugins

achieve very low-latency for both audio and video processing

The framework is used to build a modular daemon that can be configured to:

be a low-latency audio server with features like pulseaudio and/or jack

a video capture server that can manage hardware video capture devices and provide access to them

a central hub where video can be made available for other applications such as the gnome-shell screencast API.