Linux-audio-dev December 2017

linux-audio-dev@lists.linuxaudio.org

33 participants
21 discussions

io GNU/Linux 2017.03 out :)

by io GNU/Linux

Hi all, New images are ready for testing (amd64, i386) ;) io GNU/Linux is a Live DVD/USB based on Debian Sid and focused on multimedia. -> Kernel 4.14 and 4.14-rt1, Jack2+PulseAudio as default sound server (can be easily changed to Jack2+AlsaLoop, Jack2+ZitaBridge, PulseAudio or Alsa) -> Enlightenment (e22) as desktop environment and a big collection of installed software... Full persistence for USB install (with encryption) and more stuff... For more infos: manual, packages list, screenshots, video etc... Visit: -> http://io.gnu.linux.free.fr -> https://sourceforge.net/projects/io-gnu-linux/ Feedbacks welcome, enjoy :) MK

7 years

io GNU/Linux 2017.03 out :)

by io GNU/Linux

7 years

Plugin Toolkits (was ~ Forgive me, toss your Macintosh)

by Harry van Haaren

On Sun, Dec 10, 2017 at 7:43 PM, Gordonjcp <gordonjcp(a)gjcp.net> wrote: <snip> Previous discussion about plugins using GUI library frameworks like Gtk/QT, which are not designed for plugin usage. As a result, they export symbols that may collide when loaded in a DAW and plugin, when DAW and plugin are compiled against different version, ending up in a segfault that is no single softwares fault, but one of usage of a library for a purpose it is not appropriate for. > So what would you write it in instead? There are a range of toolkits / libraries available especially designed for plugin usage. In no particular order, the following come to mind. (Note, as OpenAV I'm the author of Avtk(a), </disclaimer>) Toolkits / frameworks: https://github.com/x42/robtk/ (meters.lv2, scopes.lv2 and other x42 software) http://distrho.sourceforge.net/ (particularly the "DGL" component IIRC) https://github.com/mruby-zest (new Zyn Fusion UI toolkit) https://github.com/wrl/rutabaga https://juce.com/ http://openavproductions.com/avtk/ (and its WIP 2.0 version https://github.com/openAVproductions/openAV-avtka) <apologies; I expect there to be others toolkits, the above are all I can think of right now.. > Many of the above are based on a fantastic abstraction library from the LV2 author, specifically abstracting away platform and implementation details, without any static data. That means it was designed for a purpose - like embedding and plugin GUIs: https://github.com/drobilla/pugl I have previously used Gtk, FLTK/NTK, and other toolkits. None of them are guaranteed to work correctly in DAW X that links to the same libraries. They're just not designed for that use case - and that's fine. But we (as developers) need to be careful to not consume a library in a way not intended for it to be used.. As such, Avtk is developed on PUGL to ensure there is no static data, and to fix lots of other potential issues that many toolkits have (forking new threads, waiting for a response in a thread while displaying a modal dialog, using static caches for data, etc...) For details on AVTK, there was a presentation at LAC '15 video, slides + paper available[1]. OpenAV dog-fooded[2] writing the ArtyFX[3] plugins using the AVTK library for the UIs. Based on the experience, I'm developing AVTKA (Avtk v2) in plain C, with emphasis on ease of use and simplicity in getting lightweight plugin interfaces built. This makes it easier to use the toolkit for LV2 plugin UIs, as well as a range of other uses. An example of other uses is creating "virtual hardware" devices for the Ctlra library, inside existing audio software without needing to care which UI toolkit: eg: Mixxx + Ctlra virtual interface, built using PUGL + AVTKA. A demo video of exactly that from the Sonoj event available here[4]. As you may notice, I'm a little passionate about doing the right engineering in terms of solving the UI toolkit + plugin problem. As hardware controllers are getting more fully-featured, they also have screens available. In order to capitalize on thier potential, we need to handle this use case too - so we can have user-interfaces on Desktop, DAW, and Hardware controller that have similar look and feel. Looking forward to what the next steps are in Linux Audio Community start doing, with these root problems addressed, and various solutions available... Regards -Harry [1] http://lac.linuxaudio.org/2015/video.php?id=14 [2] https://en.wikipedia.org/wiki/Eating_your_own_dog_food [3] https://github.com/openAVproductions/openAV-artyfx [4] https://youtu.be/qHt-AQHcBXg?t=1237 -- http://www.openavproductions.com

7 years

https for linuxaudio.org

by David Runge

Hey all, I'm currently taking over a bunch of packages for Arch Linux (mainly pro-audio stuff). Would it be possible to implement letsencrypt for linuxaudio.org and all of its subdomains? This would greatly improve the security of the packages hosted there (or rather their transfer from the server to the build machine) and help for said packages not to be dropped, as more and more distros try to switch to more reliable and authenticatable (is that a word?) upstreams. Additionally, there is the benefit of raising privacy for users of all things hosted on linuxaudio.org. An example are all sources hosted here (all of which are packages in Arch's main repos): http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html Best, David -- https://sleepmap.de

7 years

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

by Kjetil Matheussen

> > From: nils <info(a)sonoj.org> > > Yes, that is possible and I wholeheartly lobby for that because library > bugs and mismatches are common and could be avoided. > > Ardour does it and I do it in my own programs as well, or at least will > if properly released. If you can copy a library into your source tree > (Python in my case) why would depend to the external ecosystem? > > Some Linux distributions? (mostly very small and unknown though) do it > already but the "way of forefathers", the shared library, is still stuck > in peoples head. > > Bottom line: It turned out the Windows way of shipping all or most > libs with the program is a really good way to compatibility. > > Definitely. Including as many 3rd party dependencies as possible makes life easier both for software providers and users. The biggest advantage is that you avoid all the bugs caused by incompatible (or too old) versions of libraries people might have on their system.

7 years

Carla (was... whatever)

by Len Ovens

I agree that Carla has a long list of deps. However, it is worth building on one's own system and excluding some features. This is very easy to do, if Carla doesn't find a depend, it just leaves features requiring those depends out. This does mean the user does have to: - build their own - know what they need - know why they are using Carla in the first place - understand that Carla _tries_ to make up for the mistakes of plugin developers or distro packagers. It is a tool to make the best of a broken situation. In general, a better solution is to use the OS the plugin is made for or use plugins made for your OS of choice. -- Len Ovens www.ovenwerks.net

7 years

What's with Nedko Arnaudov?

by David Runge

Hey all, is anyone maybe in close contact with Nedko Arnaudov? I've had trouble piecing together the upstream for a2jmidid [1], when rebuilding the package for Arch Linux and tried contacting him. There doesn't seem to be any activity in any of his repositories on github [2] in recent years (not a good sign). Especially in the case of a2jmidid, everything I hear from people when asking them is "this was meant as a quick fix and not to stay around long"... well, it's 2017 and it has stayed around long. Additionally, it is dependency to some things currently in use, such as cadence, etc. Nedko also worked on ladish [3], afaics, which is still dependant on the - long outdated/dead - flowcanvas [4]. I don't see any activity there either (at least not in the past four years). Writing "the site is down" [5] doesn't make me believe that that project is not dead, either. This actively keeps programs such as cadence to be integrated into the [community] repository in Arch, as I will not add flowcanvas back and if upstream for a2jmidid deteroriates even more, it will be removed from the main repositories eventually! It would be great, if someone could shed some light on this. Best, David [1] https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/a2… [2] https://github.com/nedko [3] https://github.com/LADI/ladish [4] https://drobilla.net/software/flowcanvas [5] http://ladish.org/ -- https://sleepmap.de

7 years

Re: [LAD] What's with Nedko Arnaudov?

by Simon van der Veldt

> The source tarball download link, that I replaced in the PKGBUILD (see first mail) went missing, as there was no web server running on gna.org anymore. > Now I switched to the git repo mentioned in the same link, but the tarball naming is not based on tags. > a2jmidid still works, but a flaky upstream is just not so nice to deal with as a packager at the dawn of reproducible builds in Arch. Ah, so that was the issue. Yeah, we ran into this issue as well. Using git probably makes the most sense, or make use of your distro's mirror functionality (I believe arch offers this as well, not sure though). The tags do actually match with the releases and the tarball names, they are just single integers. I.e. the link we had was "http://download.gna.org/ a2jmidid/a2jmidid-8.tar.bz2", which matches git tag 8. For a list, see http://repo.or.cz/a2jmidid.git/refs, but you probably already checked that. On Wed, Dec 6, 2017 at 8:57 PM, David Runge <dave(a)sleepmap.de> wrote: > On December 6, 2017 8:37:53 PM GMT+01:00, Simon van der Veldt < > simon.vanderveldt(a)gmail.com> wrote: > >I sent Nedko a mail about 6 months ago asking similar questions, to > >which > >he kindly replied. The short version of the answer was no real plans > >for > >ladish, but he did want to bring the ladish site back up. > Hmm, that's too bad. > > >I didn't ask anything regarding a2jmidid because it's been working > >perfectly for me. > The source tarball download link, that I replaced in the PKGBUILD (see > first mail) went missing, as there was no web server running on gna.org > anymore. > Now I switched to the git repo mentioned in the same link, but the tarball > naming is not based on tags. > a2jmidid still works, but a flaky upstream is just not so nice to deal > with as a packager at the dawn of reproducible builds in Arch. > > >If you want to know more I'd suggest to try sending him an e-mail :) > I did three weeks ago. > > > -- > https://sleepmap.de >

7 years

Fwd: Linux Audio Berlin meeting @ c-base 2017-12-06

by Simon van der Veldt

> Would have some topics to talk about though (pro-audio software inclusion and keeping in the Arch Linux main repositories, amongst others). I'd be interested in this topic as well. Been doing some packaging for audio production applications for gentoo and I'm starting to consider proposing splitting off these specific pieces of software from the main tree because I feel that that could work towards more ownership and by extension a higher quality of the packages compared to the state we're at currently with the "monolithic" package tree. Since for both Arch and Gentoo it's pretty easy for user to add custom packages I'd be interested in the reasons why you would prefer to have the packages in the main Arch repo (assuming that you actually prefer this of course :)). Thanks, Simon On Tue, Dec 5, 2017 at 12:03 PM, David Runge <dave(a)sleepmap.de> wrote: > > > On 2017-12-05 11:17:36 (+0100), Daniel Swärd wrote: > > On Tue, 2017-12-05 at 11:04 +0100, Filipe Coelho wrote: > > > Who else is coming? > I can't most likely. Have an electronic orchestra rehearsal on > Wednesdays atm. which let's me be home around 9 most of the time. > Tomorrow additionally there's a concert I might attend to (this > Wednesday seems more crowded than most Saturdays!). > > Would have some topics to talk about though (pro-audio software > inclusion and keeping in the Arch Linux main repositories, amongst > others). > > Some other time then, hopefully... > > Best, > David > > -- > https://sleepmap.de > > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > https://lists.linuxaudio.org/listinfo/linux-audio-dev > >

7 years

Linux Audio Berlin meeting @ c-base 2017-12-06

by Daniel Swärd

Hi all. Just a friendly reminder for the monthly meeting at c-base (Rungestraße 20). I'll be in the mainhall from 20:00. Hope to see you there! Cheers /Daniel

7 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev December 2017