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

#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