April 2019 - Arch-proaudio - lists.archlinux.org

[arch-proaudio] New additions since some time this year
by David Runge 24 Jun '19

24 Jun '19

Hey all, I'd like to give information on the work being done so far: Since my last mail regarding the "new packages in [community] topic", I've added a few more: * dpf-plugins * fabla * luppp * non-daw (non-{mixer,session-manager,timeline}) * sorcer * sonic-pi (but that's seriously on its way out again...) * infamousplugins * zam-plugins * rt-tests * giada * artyfx * freewheeling * avldrums.lv2 * blop.lv2 * eteroj.lv2 * fomp.lv2 * mda.lv2 * midi_matrix.lv2 * moony.lv2 * sherlock.lv2 * vm.lv2 * cmt * convolv2 * din * patchmatrix * spectmorph * lmms (updated to latest RC) * sweep * qmidictl * qxgedit * alsa-tools * python-jack-client * python-pyalsa * python-zita-audiotools * python-zita-jacktools * zita-jclient * zita-jclient * aliki * jaaa * jconvolver * jnoisemeter * njconnect * paulstretch * realtime-privileges * japa * lv2file * noise-repellent * setbfree * ams-lv2 * beatslash-lv2 * gmsynth.lv2 * lsp-plugins * libmusicxml * dragonfly-reverb * wolf-shaper * ssr @Albert: pd-lua is still on the list, let's get in touch! @Chris: dexed can also go to [community], I'll look into it! Most of them are in (at least) one of the audio related groups: "pro-audio", "lv2-plugins", "dssi-plugins", "vst-plugins", "ladspa-plugins" or "realtime" You can have a look with: pacman -Sg <group_name> And install the whole group with: pacman -S <group_name> I have done some (minor) revamps of the relevant Arch wiki pages ([1], [2], [3]), but would love to see many more changes (to remove irrelevant data and add actual good and concise examples). Enjoy! David P.S.: If you have suggestions for more additions, let me know! [1] https://wiki.archlinux.org/index.php/Professional_audio [2] https://wiki.archlinux.org/index.php/Realtime_kernel_patchset [3] https://wiki.archlinux.org/index.php/JACK_Audio_Connection_Kit -- https://sleepmap.de

5 18

[arch-proaudio] Deprecation of jack2-dbus
by David Runge 23 Apr '19

23 Apr '19

Hi all, I've just completed the further decoupling of libffado from jack/jack2 (libffado had a dependency on jack, but was required for jack2) by turning it into an optional dependency. Besides that, looking at our current setup of the jack2 package, I would like to deprecate the jack2-dbus package. Its sole purpose is to *only* be able to use dbus for starting jack. However, we're the only distribution doing this (IMHO weird) separation (AFAIK) and the standard daemon way of starting it will not go away any time soon. This schizm creates further confusion about what to use (the jack/ jack2 schizm is already confusing enough). jack2 features: * supports classic mode (start with jackd) * supports dbus mode (e.g. start with jack_control or cadence) * defaults to jackd (classic mode) jack2-dbus features: * supports dbus mode (e.g. start with jack_control or cadence) * defaults to dbus Caveats: With the jack2 package defaulting to jackd (classic mode), it means, that as soon as jack is not yet started, any program requesting it, will start jack via the jackd executable. However, jackd will remain started with the settings that application has chosen, once the client quits. If the user wants to use the dbus way of starting jack, then it has to be used explicitely (e.g. with jack_control or a client like cadence), *before* any other client wants to start it. With jack2-dbus an application requesting the start of jack will use the dbus interface (AFAIK). The jack instance will remain running, but due to the more flexible nature of the dbus mode, its parameters can be changed on the fly (e.g. changing the periods). With helper tools, such as cadence it should be possible to start jack with one's session. However, users are not able to use jackd when they have jack2-dbus installed (it's not build). Upsides: In the upcoming jack2 1.9.13 there will a templated systemd user unit, which is able to start jackd (in a more or less static way) based on profiles, defining the parameters. This enables the user to achieve something similar to the dbus-start-with-the-graphical-session way, by enabling starting jackd with the user session (even before login of the graphical session). This is quite a benefit to systemd managed (minimal and especially headless) systems, but is of course more generally applicable. Closing, I would like to add, that it can usually be considered the *easiest and best way* (TM) to start jack *before* any client wants to use it. However, setups vary and what works for one, might not work for the other. I would like to hear your concerns regarding this matter (if any). Best, David P.S.: I'm not using DEs such as Gnome or KDE, so my assumptions about integration might be contrary to what your setup is and I might be missing valuable workflows someone is having. -- https://sleepmap.de

3 5

[arch-proaudio] Live video/presentation software
by Farid A 04 Apr '19

04 Apr '19

Hi, I'm in a student group where we organize monthly conferences with public personnalities, and during the conference we use a powerpoint (c) presentation to show images, video, text related to the presentation. Only last time we had issues with the powerpoint (and the macbooks they ran on) so I decided to step in and move us to something more reliable. I'm therefore looking for software (preferably FOSS) that runs on arch, which can broadcast video, audio and text on a screen connected through HDMI whilst being controlled from the computer's screen. Ideally the software would leave little room for error, be reliable/stable, and be rather easy to manipulate live. Thanks in advance for your help

3 2