On Fri, Apr 29, 2016 at 09:08:40AM +0200, Jano Svitok wrote:
> I tried to compile ffado trunk now (ubuntu 14.04 trusty) and the
> compilation failed with undefined errno.
> The attached patch fixed that.
Thanks. Patch applied as r2607.
> I didn't look why the others work and these two files not.
The others either don't reference errno directly or include other headers
which apparently pull it in.
Regards
jonathan
Folks!
it has been our pleasure having some of you at c-base the past weekend!
It trully was an awesome event. Thank you!
Some notes about the event:
* all videos here: https://media.ccc.de/c/minilac16
* github association here: https://github.com/linuxaudio
* update your information and files for content freeze prior to wiki
move before 20160430! http://minilac.linuxaudio.org/
Please watch https://media.ccc.de/v/minilac16-lacisdeadlongliveminilac
to get an update on a possible location for next year.
The video also serves as explanatory for our proposal of a collective
redesign, managed through github.
For this to happen, please let me know about your github name, so I can
add you!
All the best from c-base,
David
--
David Runge
Schreinerstraße 11
10247 Berlin
http://sleepmap.de
Hi everybody,
On the wrap of the late miniLAC2016(a)c-base.org Berlin (April 8-10)
[7][8], where this Yet Same Old Qstuff* (continued) workshop [9]
babbling of yours truly (slides, videos[10]) was taken place.
There's really one (big) thing to keep in mind, as always: Qtractor [1]
is not, never was, meant to be a 'do-it-all' monolith DAW. Quite frankly
it isn't a 'pure' modular model either. Maybe we can agree on calling it
a 'hybrid' perhaps? And still, all this time, it has been just truthful
to its original mission statement--modulo some Qt [2] major version
numbers--nb. it started on Qt3 (2005-2007), then Qt4 (2008-2014), it is
now Qt5 full throttle.
It must have been like start saying uh. this is probably the best dot or
rather beta release of them all!
Now,
Qtractor 0.7.7 (haziest photon) is out!
Everybody is here compelled to update.
Leave no excuses behind.
As for the 'mission statement' coined above, you know it's the same as
ever was (and it now goes to eleven years in the making [11]):
Qtractor [1] is an audio/MIDI multi-track sequencer application
written in C++ with the Qt framework [2]. Target platform is Linux,
where the Jack Audio Connection Kit (JACK [3]) for audio and the
Advanced Linux Sound Architecture (ALSA [4]) for MIDI are the main
infrastructures to evolve as a fairly-featured Linux desktop audio
workstation GUI, specially dedicated to the personal home-studio.
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
http://sourceforge.net/projects/qtractor/files
- source tarball:
http://download.sf.net/qtractor/qtractor-0.7.7.tar.gz
- source package:
http://download.sf.net/qtractor/qtractor-0.7.7-25.rncbc.suse.src.rpm
- binary packages:
http://download.sf.net/qtractor/qtractor-0.7.7-25.rncbc.suse.i586.rpmhttp://download.sf.net/qtractor/qtractor-0.7.7-25.rncbc.suse.x86_84.rpm
Git repos:
http://git.code.sf.net/p/qtractor/codehttps://github.com/rncbc/qtractor.githttps://gitlab.com/rncbc/qtractor.githttps://bitbucket.org/rncbc/qtractor.git
Change-log:
- LV2 UI Touch feature/interface support added.
- MIDI aware plug-ins are now void from multiple or parallel instantiation.
- MIDI tracks and buses plug-in chains now honor the number of effective
audio channels from the assigned audio output bus; dedicated audio
output ports will keep default to the stereo two channels.
- Plug-in rescan option has been added to plug-ins selection dialog (yet
another suggestion by Frank Neumann, thanks).
- Dropped the --enable-qt5 from configure as found redundant given
that's the build default anyway (suggestion by Guido Scholz, thanks).
- Immediate visual sync has been added to main and MIDI clip editor
thumb-views (a request by Frank Neumann, thanks).
- Fixed an old MIDI clip editor contents disappearing bug, which
manifested when drawing free-hand (ie. Edit/Select Mode/Edit Draw is on)
over and behind its start/beginning position (while in the lower view pane).
License:
Qtractor [1] is free, open-source Linux Audio [5] software,
distributed under the terms of the GNU General Public License (GPL [6])
version 2 or later.
References:
[1] Qtractor - An audio/MIDI multi-track sequencer
http://qtractor.sourceforge.net
[2] Qt framework, C++ class library and tools for
cross-platform application and UI development
http://qt.io/
[3] JACK Audio Connection Kit
http://jackaudio.org
[4] ALSA, Advanced Linux Sound Architecture
http://www.alsa-project.org/
[5] Linux Audio consortium of libre software for audio-related work
http://linuxaudio.org
[6] GPL - GNU General Public License
http://www.gnu.org/copyleft/gpl.html
[7] miniLAC, a more compact, community-driven version of the yearly
Linux Audio Conference
http://minilac.linuxaudio.org
[8] c-base.org, Berlin
http://c-base.org
[9] Yet Same Old Qstuff* (continued) workshop
http://minilac.linuxaudio.org/index.php/Workshop#Yet_Same_Old_Qstuff.2A_.28…
[10] slides:
http://minilac.linuxaudio.org/index.php/File:Lac2016_qstuff_slides.pdf
videos: http://media.ccc.de/v/minilac16-yetsameoldqstuff
[11] Siskel & Ebert - "This Is Spinal Tap"
http://www.youtube.com/watch?v=4xgx4k83zzc
See also:
http://www.rncbc.org/drupal/node/1033
Enjoy && Have fun.
--
rncbc aka Rui Nuno Capela
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
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=46912http://linuxmusicians.com/viewtopic.php?f=19&t=2290&p=51449http://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.
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
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
Hello! I've released the new version of the sound editor EKO:
http://semiletov.org/ekohttps://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
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