Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7535 discussions

[LAD] Adding apps to wiki.linuxaudio.org

by Joel Roth

Hi all, After creating an account for the wiki, it appears that apps are in a separate database from the wiki page itself. I'd like to add an entry for Nama, to the list of DAW software. Can someone put me in touch with the database maintainer? Joel -- Joel Roth

9 years, 9 months

[LAD] ableton link and live tempo changing

by Perry Nguyen

Hi, I'm Perry, also I'm tatch on linuxmusicians if you've ever been there. I posted this message on LM a while ago but was encouraged by falktx to post this to LAD. so that is what I am doing now (here <https://linuxmusicians.com/viewtopic.php?t=14913> is the original topic). not sure if you’ve read about ableton live 9.5 but one of their planned updates is this thing called ableton link <http://createdigitalmusic.com/2015/11/link-could-change-how-you-play-music-…> that seems to be a convincing inter-device tempo sync. paul davis was present during the unveiling of ableton sync and has an interesting perspective: …The JACK community developed technology back in 2005 or earlier that could > do what Link does (and a whole lot more besides). But the developers failed > to package it, failed to make it usable for anyone other than a small group > of tech-oriented tinkerers, failed to give it an inviting face. In > addition, the developers failed to understand how significant platform is > when trying to create products for people. Designing the most awesome thing > in the world is no help if it doesn’t run on the platforms that people want > to use (for whatever reason). Ableton not only chose OS platforms with huge > numbers of users, but has proceeded to develop its own product-centric > platform that provides compelling reasons for users to want to remain > within its walls. The open source community shouldn’t be trying to follow > or copy what a company like Ableton does, but there is a strong lesson > here: our technology is not as important as we like to think. In any case, one thing that we’ve talked about to various degrees in the past is tempo ramping in JACK, and with the announcement of ableton link I’d like to revisit the topic. http://linuxmusicians.com/viewtopic.php?f=44&t=11681&p=46912 http://linuxmusicians.com/viewtopic.php?f=19&t=2290&p=51449 http://linuxmusicians.com/viewtopic.php?f=1&t=9835&p=30447 JACK does indeed largely do what Link does (and more) but I’ve been having difficulty successfully tempo ramping. Incidentally, danboid recently posted <https://linuxmusicians.com/viewtopic.php?f=1&t=14912> about how he can successfully ramp in MuSE; but I don’t use MuSE nor do I plan to in the near future, and unfortunately my attempts to change tempo dynamically within the greater JACK/modular LAU paradigm have been rather unsuccessful. To clarify my own use-case, I’d like to map an encoder/knob to a tempo control and be able to speed up/slow down the tempo live, e.g. during a performance. *changing tempo as timebase master* For the most part it seems that changing tempo dynamically is possible but it is not well-defined. - seq24 forces itself to be transport master (I know there’s supposed to be a patch but it has still never worked for me ever) and disallows tempo changes while playing - hydrogen sort of allows tempo changes but it will sometimes politely refuse to change (which is bad) - klick can be configured to send out predefined tempo ramps but I haven’t been able to set it as timebase master and actually interact with it (I was trying klick -Ti and klick -To 8080 but it seems -i and -o somehow disregard the -T option) *changing tempo as a slave* - hydrogen is happy to oblige tempo changes but is equally happy to cut off the beginning/end of a bar - qmidiarp follows tempo changes but doesn’t stay in time and forgets to send note-offs I’d appreciate if someone more familiar with the transport spec could chime in on this, I’d like to understand what is missing from a technical perspective (I’m actually not entirely clear on the timebase master/slave relationship either). Going a step further, it seems that ableton link may become the go-to replacement for midi clock in software-based production; it could be beneficial to discuss possible timebase master clock clients that can also communicate using the ableton link protocol. Of course this is contingent on the SDK being compatible with linux, which may be unlikely but they *are* encouraging interested developers to get in touch <https://www.ableton.com/en/link/>. By the same token it would be great to have this for midi clock as well — I know of jack_midi_clock <https://github.com/x42/jack_midi_clock> already but I don’t believe the reverse case exists, though falktx and I briefly discussed something related <https://linuxmusicians.com/viewtopic.php?f=48&t=12755> a while ago. To reiterate, 1. lau apps have to implement tempo ramping in JACK properly 2. a JACK timebase master clock client must be made that can - change tempo dynamically - communicate with ableton link to send/receive tempo information (pending a working SDK for linux (this could also be optional in the app for those who don’t want anything proprietary)) - set tempo given a midi clock input Thoughts? I think tempo syncing is one way we can get JACK to interact more proactively with other software/equipment, and that seems like it could be a great way to reconnect with the rest of the audio community.

9 years, 9 months

[LAD] Favorite Python3 equivalent of PyJack?

by Jonathan Brickman

I am finding myself motivated to convert from Python 2.7 to Python 3, and I just realized that PyJack, the Python JACK library I have been using, has not been set up for Python 3. Anyone have a favorite JACK library for Python3? -- *Jonathan E. Brickman jeb(a)ponderworthy.com <http://login.jsp/?at=02e47df3-a9af-4cd9-b951-1a06d255b48f&mailto=jeb@ponder…> (785)233-9977* *Hear us at http://ponderworthy.com <http://ponderworthy.com> -- CDs and MP3s now available! <http://ponderworthy.com/ad-astra/ad-astra.html>* *Music of compassion; fire, and life!!!*

9 years, 9 months

Re: [LAD] [PATCH ffado] tests: fix build error due to wrong errno initialization

by Jonathan Woithe

On Fri, Apr 15, 2016 at 09:24:15AM +0200, Stefan Richter wrote: > gcc 5.2.0 reports this as an error: > function ???int* __errno_location()??? is initialized like a variable > int errno = 0; > ^ Thanks. Applied (r2605). jonathan

9 years, 10 months

Re: [LAD] [FFADO-devel] can't build libffado 2.2.1 under gentoo

by Jonathan Woithe

Hi Stefan On Thu, Apr 14, 2016 at 11:04:15PM +0200, Stefan Richter wrote: > On Apr 14 Stefan Richter wrote: > > I tried multiple things, among them > > $ export CXXFLAGS=-std=c++11 > > $ export CUSTOM_ENV=True > > $ scons -c > > $ scons > > but so far I did not manage to inspire scons to add -std=c++11 to the gcc > > command line. > > The syntax is > $ CXXFLAGS="-std=c++11" scons CUSTOM_ENV=True > or alternatively > $ CXXFLAGS="--std=c++11" scons CUSTOM_ENV=True > and it is highly effective. The build now goes through with lots of > warnings but without error... until the build descends into the support/ > directory. Right. So what do we take away from this? Do we need to modify the ffado scons script to add "-std=c++11" whenever a certain version of gcc is in use? Is the problem specific to gentoo? Is it something FFADO does, or is it a problem between certain gcc versions and the versions of libraries such as libxml++ which are used by FFADO? > This is how a re-run of scons looks like (after src/ was built successfully > in a previous run, and now support/ is to be built): > > [...] > scons: Building targets ... > scons: `src' is up to date. > g++ -o support/dbus/test-dbus.o -c -std=c++11 -m64 -Wall -g -fPIC -Wno-unused-but-set-variable -DDEBUG -DDEBUG_MESSAGES -DDBUS_HAS_THREADS_INIT_DEFAULT -DDBUS_API_SUBJECT_TO_CHANGE -I. -Isrc -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/dbus-c++-1 -I/usr/local/include -I/usr/include/libxml++-2.6 -I/usr/lib64/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include support/dbus/test-dbus.cpp > In file included from /usr/include/dbus-c++-1/dbus-c++/dbus.h:28:0, > from support/dbus/controlclient.h:29, > from support/dbus/test-dbus.cpp:30: > /usr/include/dbus-c++-1/dbus-c++/types.h:194:20: error: redefinition of âstruct DBus::type<int>â > template <> struct type<int32_t> > ^ > /usr/include/dbus-c++-1/dbus-c++/types.h:180:20: error: previous definition of âstruct DBus::type<int>â > template <> struct type<int16_t> > ^ To my naive eye this appears to be a problem with the dbus-c++ headers in combination with the gcc version in use. Which version of dbus-c++ is installed? I'm away from my development machine at present so I can't take a look at this file right now: either your compilation environment is setting defines which result in the redefinition, or the redefinition has always been present but is now triggering an error instead of a warning under the newer gcc version. Comments? > As soon as I remove -std=c++11, the build fails again already in src/. Right. There appear to be two problems then. 1) It looks like we need this "-std=c++11" flag under some circumstances which are yet to be fully determined. 2) Newer compilers may require the treatment of some errors as warnings in order to work with dbus-c++, unless there's a fixed dbus-c++ which addresses the problems. Added to this is the success of the Debian build as pointed out by Adrian. Do we have any obvious patterns emerging yet? Comments are welcome: since I'm not able to recreate the compilation problem on my systems I can't contribute all that much to the ongoing experiments and tests. Regards jonathan

9 years, 10 months

[LAD] EKO sound editor

by Петр Семилетов

Hello! I've released the new version of the sound editor EKO: http://semiletov.org/eko https://github.com/psemiletov/eko This release features FX presets engine, and the new effect Vynil Taste that simulates vynil plate noises. EKO is based on Qt5, libsndfile, portaudio and libsamplerate. -- Петр Семилетов, сайт: semiletov.org текстовый редактор TEA: semiletov.org/tea Киевоград (неформальное краеведение Киева): www.kievograd.org

9 years, 10 months

Re: [LAD] [FFADO-devel] can't build libffado 2.2.1 under gentoo

by Jonathan Woithe

On Thu, Apr 14, 2016 at 03:25:37PM +0200, Stefan Richter wrote: > On Apr 14 Jonathan Woithe wrote: > > On Thu, Apr 14, 2016 at 09:30:21AM +0200, Stefan Richter wrote: > > > gcc (Gentoo 4.9.3 p1.2, pie-0.6.3) 4.9.3" > > > [...] > > > Build log: http://pastebin.com/fRHScVVH > > > > > > Not sure what changed since the last successful build. gcc was possibly > > > the same. > > > > In Nikita's report the errors are reported in src/libutil/cmd_serialize.h. > > This file hasn't been changed for ages and certainly not any time this year. > > There may be something rather obscure going on, but it's hard to see that > > any changes have been made to FFADO to cause Nikita's errors. I wonder > > there is something strange going on with the compiler or the compilation > > environment. > > > > In Stefan's report the error is different: > > Unlike Nikita, I haven't added -std=c++11 yet. Yes, so it seems - my bad. Somehow I managed to convince myself that I'd seen it in the pastebin log you posted, but I've just rechecked it and it clearly isn't in there. Evidently I need more sleep. > > /usr/include/glibmm-2.4/glibmm/ustring.h:267:12: error: expected â?????;â?????? at > > end of member declaration > > ~ustring() noexcept; > > ^ > > > > This file is included via libxml++'s exception.h header file. I know there > > have been some issues with libxml++ and newer gcc versions so I wonder > > whether any of those are behind this. I remember that libxml++ did throw me > > some curveballs when I moved my development system from gcc 4.5.x to 4.8.x > > but I can't remember the details - I'll look them up tonight. It wasn't > > anything that affected FFADO though. > > On the mainline Gentoo package repo (the only one which I use), there are > now only the packages > dev-cpp/libxmlpp-2.38.1 > dev-cpp/libxmlpp-2.40.1 > available. I have 2.40.1 installed right now; downgrading to 2.38.1 is > currently impossible since its build fails as described in > https://bugs.gentoo.org/show_bug.cgi?id=567526. A downgrade of libxmlpp is probably not needed since it seems you have the same version that resulted in a successful build in the Debian build log that Adrian linked to. > Note that my build log also contains errors in > /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/exception for > example. Yes, further down the log. They are of the same form as the ustring.h errors though, so whatever's tripping ustring.h up is probably responsible for the g++-v4/exception woes as well. > The Debian build log with successful build, which Adrian linked to, lists > the following Debian package versions: > gcc-5_5.2.1-26 > libxml++2.6-dev_2.40.1-1 > libglibmm-2.4-dev_2.46.2-1 > etc. > > I guess I attempt an upgrade to gcc-5 next. It's strange, since I think you mentioned that the same thing happened for you with a gcc 4.8.x on that system. I guess 4.9.x could break something which worked in 4.8.x but such behaviour would be more likely with gcc 5. Still, stranger things have happened, and there's still the issue that the Debian build worked fine. > On Apr 14 Jano Svitok wrote: > > can you add -std=c++11 to CXX_FLAGS or how is it called to enable C++11 > > extensions? Most of the errors come from these - noexcept, override,... > > I tried multiple things, among them > $ export CXXFLAGS=-std=c++11 > $ export CUSTOM_ENV=True > $ scons -c > $ scons > but so far I did not manage to inspire scons to add -std=c++11 to the gcc > command line. So where did it come from? It must be something the ebuild is adding. Regards jonathan

9 years, 10 months

Re: [LAD] [FFADO-devel] can't build libffado 2.2.1 under gentoo

by Jonathan Woithe

On Thu, Apr 14, 2016 at 10:24:05AM +0200, Stefan Richter wrote: > On Apr 14 Stefan Richter wrote: > > gcc (Gentoo 4.9.3 p1.2, pie-0.6.3) 4.9.3" > > [...] > > Build log: http://pastebin.com/fRHScVVH > > > > Not sure what changed since the last successful build. gcc was possibly > > the same. > > Build fails in the same way with gcc (Gentoo 4.8.5 p1.3, pie-0.6.2) 4.8.5. Current svn builds fine for me in Slackware 14.1: gcc 4.8.2, libxml++ 2.37.2, dbus-c++ git from Nov 2014, glibmm 2.36.2. My compilation lines do *not* include "-std=c++11", so I wonder whether the presence of that is the root cause for the trouble. My typical g++ call is g++ -o src/dice/dice_avdevice.os -c -m64 -Wall -g -Werror -fPIC -fPIC ... This is in a multilib x86_64 environment, so "-m64" is expected. I don't think the "-std=c++11" should be specified; it would be interesting to query the ebuild commit log to see what reason was given when it was added (assuming that this is where it's coming from). Is there a way for you to hack the build script to get rid of it so this theory can be tested? Also, following up on my earlier comment about libxml++, I checked my logs and the problem I was thinking about wasn't a compilation error, but was related to the chasing the cause of warnings in a couple of libraries. It's therefore not relevant here. Regards jonathan

9 years, 10 months

Re: [LAD] [FFADO-devel] can't build libffado 2.2.1 under gentoo

by Jonathan Woithe

On Thu, Apr 14, 2016 at 09:30:21AM +0200, Stefan Richter wrote: > > On 04/13/16 20:27, Nikita Zlobin wrote: > > > Hello, i'm trying to build libffado from proaudio overlay. > [...] > > > Somewhat long time ago (about year) i could install it, but now i have > > > following problems on compilation: > > > - First, it seems, that it now uses more modern language features: the > > > specified option --std=c99, added by one of ebuild's patch, as well > > > as without any options (tried to build tarball with) gives long error > > > list. > > > - With compiler flag --std=c++11 compilation continued for relatively > > > long time, but then failed with following > > > errors: http://pastebin.com/hkttBN9X > > Building from a recent ffado.org SVN checkout worked for me on Gentoo > sometime earlier this year. > > But right now it fails to build for me too. > $ gcc --version > gcc (Gentoo 4.9.3 p1.2, pie-0.6.3) 4.9.3" > [...] > Build log: http://pastebin.com/fRHScVVH > > Not sure what changed since the last successful build. gcc was possibly > the same. In Nikita's report the errors are reported in src/libutil/cmd_serialize.h. This file hasn't been changed for ages and certainly not any time this year. There may be something rather obscure going on, but it's hard to see that any changes have been made to FFADO to cause Nikita's errors. I wonder there is something strange going on with the compiler or the compilation environment. In Stefan's report the error is different: /usr/include/glibmm-2.4/glibmm/ustring.h:267:12: error: expected â;â at end of member declaration ~ustring() noexcept; ^ This file is included via libxml++'s exception.h header file. I know there have been some issues with libxml++ and newer gcc versions so I wonder whether any of those are behind this. I remember that libxml++ did throw me some curveballs when I moved my development system from gcc 4.5.x to 4.8.x but I can't remember the details - I'll look them up tonight. It wasn't anything that affected FFADO though. Regards jonathan

9 years, 10 months

[LAD] can't build libffado 2.2.1 under gentoo

by Nikita Zlobin

Hello, i'm trying to build libffado from proaudio overlay. The problem seems to be in ffado itself. Somewhat long time ago (about year) i could install it, but now i have following problems on compilation: - First, it seems, that it now uses more modern language features: the specified option --std=c99, added by one of ebuild's patch, as well as without any options (tried to build tarball with) gives long error list. - With compiler flag --std=c++11 compilation continued for relatively long time, but then failed with following errors: http://pastebin.com/hkttBN9X there seems to be one common feature: definition with "quadlet_t" argument fails to overload same def with "byte_t" arg. I looked to src/libutil/cmd_serialize.h, and there are four (with original) variants for each functions... i don't understand, why only quadlet_t - typed variant fails, while others proceed. What i found yet is that this type is defined in raw1394 headers: $ grep -r 'quadlet_t;' /usr/include /usr/include/libraw1394/raw1394.h:typedef u_int32_t quadlet_t; And what is interesting, when i tried to build from tarball manually: $ scons -DCOMPILE_FLAGS='--std=c++11' ... that flag was not even passed to g++, so thanks for gentoo S). ------------- $ gcc --version gcc (Gentoo 4.9.3 p1.5, pie-0.6.4) 4.9.3

9 years, 10 months

Jump to page:

2026

2025

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