#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…

#32

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?

#33

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…

1 Like
#34

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!

3 Likes
#35

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!

2 Likes
#36

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.
Pipewire for linux
#37

I’m wondering: who’s still actively pursuing this concept?

I’ve just inherited an old mac mini and would like to turn it into a little studio-in-a-box - I’ve got a 16n and a Grid to connect. I could potentially have it all in a small box ready, portable, powered by a battery.

I’m not really sure what the status of linux-audio is. Is there a great forum or thread to discuss current setups? The best current linux-OS for audio, the best audio-layer software currently in use, etc?

1 Like
#38

by now, there’s actually quite a few companies/products pursuing this concept (norns, organelle, percussa ssp, etc).

i think that one of the largest misconceptions that newcomers to linux audio encounter is that there’s a best or better linux distribution for the practice–really it comes down to what hardware you’re using, your comfortability with linux, personal preferences, and the intended application.

most of the distributions are more or less equal, the only differentiators being pre-installed programs and what programs are conveniently available to you. you might even have heard of the linux rt audio patches–there are a couple of different sets and they might not even be desirable for you to install depending on your hardware platform and actual needs.

there are somethings i’d universally recommend though:

if you need help with the above please feel free to post here and we can continue this thread.
i might be open to having a discussion on what a music-centric linux distribution may look like–i’ve begun a meta-distribution earlier this year based on gentoo, but i haven’t decided if it’s the right way to go.

the only other forum i really know of that is specifically music and linux-focused:

2 Likes