Dear Linux Audio developer, user, composer, musician, philosopher
and anyone else interested, you are invited to the...
Linux Audio Conference 2010
The conference about Open Source Software for music and audio
May 1-4 2010
Hogeschool voor de Kunsten Utrecht (HKU)
Utrecht, The Netherlands
Registration is open, and so is the call for abstracts and papers.
More information can be found on the website:
http://lac.linuxaudio.org/2010
For previous editions, look here:
http://lac.linuxaudio.org
For concerts, music and workshops a submission system and protocol will
be available soon. In the meantime, ideas and announcements can be sent by
e-mail ("lac -at- linuxaudio -dot- org ")
or written on the wiki:
http://wiki.linuxaudio.org/lac2010
We hope to see you all in Utrecht !
Kind regards on behalf of the LAC team,
Marc Groenewegen, lecturer music software design @ HKU
After recent discussion on IRC I'm loosing faith in whether it is worth
to contribute to linux audio session handling/management. Two reasons
were given why it does not get testing from users. One is that what I
did so far is not mature, has annoying bugs and I'm not wanting to fix
them. The other one is that ladish is not giving more than users already
have with qjackctl. Also it was mentioned that D-Bus is not what users
find acceptable for controlling jack server.
Given the almost missing feedback about LADI development from community
members that could benefit from it, I'm not sure whether I should
continue to contribute. Maybe I should give up on trying to make linux
audio usable for my needs. I could also stop using computers and make
music only by using my guitar. Because alternatives to Linux Audio
(windows/mac) don't suit my needs. Moreover they don't have the
potential to suit. This is why I'm contributing to Linux Audio and not
making VST plugins or something. This anti-dbus movement is getting too
far. If there is no user that accepts my point of view, there is no point
of me contributing.
Because it may be possible that someone has missed the whole point of my
jackdbus and session handling effort, I'll try to explain what I find
wrong/unacceptable in JACK (dbus-less) system as we have it now.
* JACK server tries to kill clients that are suspected to misbehave and
cause xruns or expose other kind of bad behaviour. This can result in
qjackctl (or patchage for example) being killed. IMO, killing control
apps is wrong. Apps that that don't process audio/midi should be
treated differently.
* When jackd is autolaunched, log messages are going to stdout/stderr of
the app that launched them. This is wrong, unix daemons are supposed
to have a log file, even if they are per-user. One of the reasons why
log file is a good thing to have is that it allows to analyze problem
post factum. This helps a lot if some misbehaviour is rarely
reproducable.
* Control apps that start the jack server through jackd know only about
the parameters that were known at compile time. Somewhat recent
example, IIRC, jack2 specific parameters (-S) and firewire options
missing after upgrade of jack because qjackctl does not know about
them. IMO, control apps should be able to query parameters for jack
and display the available options to user.
* Control apps that manage jack connections, are subject to realtime
constraints. IMO, this complicates control apps development for no
good reason. This is valid only for jack1. jack2 already uses
non-realtime threads for port notifications.
* Implementing control app requires C level program or use of specially
crafted bindings. It will be good if control apps could be
implemented with few lines of code in a scripting language as Python,
Ruby, Perl, etc.
* JACK graph (clients, ports and connections) API is badly designed and
is prone to race conditions. Fons talked about this problem recently
too.
* Session handling capabilities are suboptimal. Various programs lurk
here. I'll mention the two most popular ones: qjackctl cant
save/restore internal state of the programs. It also cant save and
then relaunch them automatically. lash cannot manage jack
settings and cannot restore connections for applications that are not
linked against liblash. There are other problems but those are the most
frustrating ones.
* Hardware port virtualization is suboptimal. it is provided through
the JACK "system" client. The only reliable ports are first ones, they
are expected to be the main input/output. If applications wants to
connect to phones for example it does not know on what ports they
are. projects/session should be movable to other system, one with
different hardware setup and [extensive] reconnecting should not be
required.
* Hardware port names are not human readble. Aliases exist but are not
widely used for various reasons. Users should be able to name and
group their ports to match their hardware cable setup.
* JACK "system" client is used for non-hardware ports (-X seq).
* There is no global list of JACK enabled applications.
* JACK MIDI is not widely accepted. JACK AUDIO + ALSA seq appears to be
acceptable solution. IMO, sample accurate audio+midi is very
important.
* There is no session handling for netjack LAN setups.
* Session handling apps cannot restore apps to more than one X11 screen (do
not mix with X11 display).
* Patchage-like (flowcanvas based) patchbay interface is best what I've
seen. Unfortunately Patchage does not integrate well with other parts
of JACK infrastructure.
As you can see, I have collected enough problems to fight. Almost all of
these fixes need new software modules to be written or existing ones to
be rewritten. In past years I've tried to collaborate
with people behind JACK, LASH, Patchage and Qjackctl. At the end, I
think that this attempt was probably wrong, with the only excepton of
jack2 (Stephane Letz) who accepted my jackdbus development into jack2
and we worked toghether on improving it and on the more general
"control API" initiative. The jackdbus code, my first contribution, that
is supposed to improve this mess was rejected by Paul Davis whom
maintains jack1. I've got some patches accepted by Patchage`s
author and maintainer, Dave Robillard, but they were rather cosmetic
ones. This forced me to maintain a software branch (Dave calls it a
fork) called lpatchage. It was supposed to be dashboard for the JACK
system. I also actively participated in lash-0.6.x development. The only
other developper, Juuso Alasuutari, shared some of my ideas, but at the
end we ended with fundamental differences about how session handling
should behave and what lash should become.
As part of my LADI efforts, two people where very helpful. Marc-Olivier
Barre and I managed to create pyjackctl, later renamed to laditools. It
is set of minimalistic but very useful control apps for JACK, a2jmidid
and LASH/ladish. Krzysztof Foltman helped a lot with probably the most
complex app in the laditools suite, ladiconf.
I'd like to mention people with whom collaboration, even if attempted by
me was non-existing: Rui Nuno Capela and Bob Ham. They clearly declared
From start that wont help for various reasons and I appreciate
this. Because this saved my precious time of part-time contributor to
Linux Audio.
In May/June this year, Fons Andriaensen got hit by a forcibly packaged
jackdbus (i'd call it mispackaging of jack) and started a flame war
against D-Bus evilness. I tried to be constructive until I got message
From the packager that dbus was forced, even given that he earlier
stated that he explicitly enabled dbus support in that package for one
reason or another.
In June this year, it become evident that I'm not able to contribute to
LASH anymore and that I want something else. I left the LASH project and
started a new session manager, ladish (project page is at ladish.org).
The first preview was released not long after. It was not yet a real
session manager but it was able to save and restore multiple jack
configs, a foundation for what I call "studio" in ladish. Since then
I've implemented some more stuff and I was hoping that next preview that
will be able to relaunch applications and restore connections between
their jack ports will be ready by the end of this year.
In recent few months, I had less time to contribute to ladish and
development slowed. The anti-dbus statements from various people
continued almost always without real argumentation behind them. For
these that were complains about dbus problems in real setups, I've given
suggestions. Almost always I got ignorace and more anti-dbus statements
in return. Maybe what I did is really unusable by others, despite
it being obviously usable by me. Maybe I suck at trying to help & support
people who seem to think that ladi is not that bad. Or maybe D-Bus
is indeed evil and eats babies and I fail to understand why, even after
I've listen to so many "arguments". Or maybe there are happy people
using jackdbus and laditools (or even lash-0.6.x) and looking toward
ladish. But I dont see them. If community does not share my frustration
with problems of the JACK system I mentioned above and does not accept
my vision that D-Bus is just the most suitable (but not perfect)
technology for what I'm trying to achieve, then it would be better for
everybody if I don't contribute anymore. I can detach from the community
and I can even detach from linux and even computers.
So now is the time to give your positive feedback and constructive
critics. Don't troll and don't start another flame war unless your goal
is to alienate me to stage of me detaching from this community. I will
not respond to trolish and flamish mails, feel free to contact me
with private mails if you prefer so. As I'm cross posting this mail, if
you are subscribed to more than one of the mailing lists, please reply
only to one of them. In order of preference, lad, lau, jack-devel. This
should avoid discussions half-shared between lists. If they happen at
all.
This mail is not supposed to be offensive to anyone. If someone feels
so, I declare that offense is not intentional. I don't deny the right of
different opinion on any subject and thus I have no reason to burn
witches.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Announcing phasex-0.12.0-pre1:
The pre-release is here. It's stable. It builds cleanly. No build
errors or warnings. No runtime errors or crashes. No glitches.
If no bugs are found in the next week, then this code (with the
addition of some brand-new patches) will become the stable release.
Changes since phasex-0.12.0-beta4:
- Build system overhaul. GCC version detection for better arch-
specific optimization (compiles clean with gcc-3.4.x or higher).
Atom builds fall back to next-best optimizations for GCC < 4.5.x.
New --enable-32bit and --cpu-power-level= flags and better user
variable handling for ./configure. Missing -lpthread in link phase
is fixed.
- Velocity control for the amplifier. Better aftertouch handling.
- Scheduling policy defaults to SCHED_RR, and can be changed in the
settings at runtime.
- Broken ringbuffer code has been fixed. No more glitches (unless you
have actually run out of CPU).
- Theme loading has been fixed. Now properly detects if the nodoka
theme engine is installed, and quietly falls back to an engineless
theme.
- Fullscreen and Maximize interaction have been fixed.
- New command line options: -m (--midi-channel=), -f (--fullscreen),
and -M (--maximize). Loading a patch by name or by program number
on the command line now finds the appropriate patch in the patchbank.
- The lurking patch name corruption bug has been fixed!
- And more. See the ChangeLog for details...
Download phasex and hear for yourself...
http://sysex.net/phasex/
Alternatively, you can utilize the git repositoty:
git clone http://sysex.net/git/phasex.git
Cheers,
--ww
On 11/29/2009 03:36 PM, Ken Restivo wrote:
> On Tue, Nov 24, 2009 at 10:33:45AM +0100, Karl Hammar wrote:
>
>> Nick Copeland:
>>
>>> Adrian Knoth:
>>>
>>>> I'm also somewhat interested in the network part, I feel IPv6 could help
>>>> a lot. It supports autoconfiguration and it has decent multicast
>>>> support, so it would be possible to broadcast/multicast the streams on
>>>> the net (LAN). This could be useful if you want to access the stream at
>>>> a mixing console for a life setup and simultaneously record it on a
>>>> computer.
>>>>
>>> Put another way, it would be far more compatible if this were done over
>>> an IP stream rather than any native ethernet stream, not least it could use
>>> any ethernet driver that linux supports rather than a small subset of them.
>>>
>> Ack, a standard ip-stream is a sensible first choise.
>>
>>
>>> Perhaps the project needs to be specified with regards to its goals?
>>>
>> ...
>>
>> My goals is "just" to extend another project (industrial i/o).
>> What would your goals be ?
>>
>> Shall we decide on a single mailing list ?
>>
>>
> IIRC the motivation for this was:
>
> 1) Firewire is going away on laptops
> 2) USB 2.0 is proprietary and non-standard
> 3) Because of (1) and (2), Linux Audio users will soon be left without any way to do multichannel recording on laptops.
>
> The original thread converged on a goal pretty quickly: an inexpensive, multi-channel audio interface which is open hardware and software, and uses Gig Ethernet as its physical connection method.
>
> So, if I were going to put the goal simply: I'd like a Focusrite Saffire (or equivalent) that runs over Ethernet, please :-) Price-wise, it'd be nice if it cost the same or less than equivalent USB 2.0 product. Latency-wise, comparable with USB 2.0.
>
> In terms of how many I/O, I think that was still being calculated and experimentation was going to be required. Obviously options for 4, 8, or 16 I/O would be nice.
>
>
Did anyone have a good reason for not including support for a
usb-1.0/2.0/3.0 interface seeing as we can write the driver ourselves
and adhere to the standard?
Most chipsets these days have support for both port types. It would be
very useful if the schematic provided tracks for both ootb.
BTW, I will be able to contribute development funds towards this project
if required once we have a BoM.
Cheers.
Patrick Shirkey
Boost Hardware Ltd
I'm happy to announce a new guitarix release
guitarix is a simple Linux Rock Guitar amplifier and is designed
to achieve nice thrash/metal/rock/blues guitar sounds.
Guitarix uses the Jack Audio Connection Kit as its audio backend
and brings in one input and two output ports to the jack graph.
Release 0.05.2-1 comes with some changes:
* remove dependency of the boost library
(Many thanks to "thrasher13b" for the patch)
* fix missing "./" in ./debian/rules reported
by GMag (AV Linux)
* add 2 Channel gain and delay chooser to the
Jconv settings widget.
* add scroll/zoom mode to the wave view
* reworked Jconv settings widget UI
* various GUI and feature clean-up's
have fun
Comments and suggestions are welcome.
________________________________________________________________________
The standalone version of guitarix is based on GTK2+.
But guitarix is also released as a suite of LADSPA plugins
and can be used in e.g. ardour.
guitarix is licensed under the GPL.
Project page with screenshots:
http://guitarix.sourceforge.net/
download:
http://sourceforge.net/projects/guitarix/
For capture, guitarix uses the external application
'jack_capture' (version >= 0.9.30) written by Kjetil
S. Matheussen. If you don't have it installed,
you can look here:
http://old.notam02.no/arkiv/src/?M=D
For extra Impulse Responses, guitarix uses the
convolution application 'jconv' created by Fons Adriaensen.
If you don't have it installed, you can look here:
http://www.kokkinizita.net/linuxaudio/index.html
I(hermann) use faust to build the prototype and will say
thanks to
: Julius Smith
http://ccrma.stanford.edu/realsimple/faust/
: Albert Graef
http://q-lang.sourceforge.net/examples.html#Faust
: Yann Orlary
http://faust.grame.fr/
regards
Hermann Meyer & James Warden
------------------------------------------
guitarix-dev team
hello everyone,
I am trying to write a c++/qt4 jack client which mix 2 inputs and has a jack
output. The problem is that currently jack gets zombified too often and I would
like some info on how can I debug the exact reason this happens. I suspect
it's the way the app is written and I am planning to rewrite it but I need
some advices first.
The way it's currently written makes use of mutexes and locks to pass the
data beetween a custom global buffer. Is this the reason for not synchronizing
good enough and zombifies jack or it's something else that screw things? Should
I use a ringbuffer (which, to my understanding is lock-free and doesn't need
mutexes) to get the work done, and if so, are there any jack2 example of this
or some hints for what I should be aware of? Or have I misunderstand something
completely?
Please, any recommendation of how I can eliminate this "jack zombified" thing
and understand the whole realtime issue is welcome.
Thank you in advance.
Dear fellow Linux enthusiasts and consortium members,
Please allow me to bring to your attention the upcoming L2Ork debut:
On December 4th Virginia Tech DISIS (<http://disis.music.vt.edu>) Linux
Laptop Orchestra (L2Ork, <http://l2ork.music.vt.edu>) will hold its first
sneak preview debut performance on Virginia Tech (VT) campus, Squires Studio
Theatre, starting at 7pm. Admission is free.
At noon on the same day, L2Orkists will also host a demo booth outside the
Commonwealth Ballroom in Squires Student Center (VT campus) demoing how
L2Ork works.
For additional info on L2Ork and a video preview of L2Ork in rehearsal:
<http://l2ork.music.vt.edu>
Facebook Event Page:
<http://www.facebook.com/home.php#/event.php?eid=180832548428&ref=mf>
Sincerely,
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
ico(a)vt.edu
http://www.music.vt.edu/faculty/bukvic/
Hi,
I'm trying to do a simple effect in the frequency domain, nothing extraordinary.
I need to apply various gains to specific frequencies.
For this purpose, I want to process a 16bit audio input stream, block by block,
apply a hanning window, do a fft, now apply my effect, and then an inverse fft,
followed by overlap and add buffering.
For now, I'm simply trying to do all of this without applying any effect, just
to see if my time to frequency and back conversion is correct.
I managed to do this in Octave. Now, I'm trying to do it in C with fftw and the
sound I obtain is like "shivering". It's recognizable but severely altered. I've
spent hours on this, it just won't work.
Attached :
- freqfilter.m: my working octave version
- transform.h and transform.c: time -> frequency -> time routines
- transformtest.c: test program
Could anyone tell me what's wrong with this C code?
Thanks in advance
--
Olivier
Hi Nedko :)
today I tried to compile LADI, but it failed for openSuse 11.2 x86_64
and 64 Studio 3.0-beta3 x86_64. Please take a look at the attachments.
Cheers,
Ralf
suse11-2:/usr/src/ladish-0.1/flowcanvas # ./waf configure
Checking for program gcc : ok /usr/bin/gcc
Checking for program cpp : ok /usr/bin/cpp
Checking for program ar : ok /usr/bin/ar
Checking for program ranlib : ok /usr/bin/ranlib
Checking for gcc : ok
Checking for program g++ : ok /usr/bin/g++
Checking for g++ : ok
Checking for libgvc >= 2.8 : ok
Checking for gtkmm-2.4 >= 2.10.0 : ok
Checking for libgnomecanvasmm-2.6 >= 2.6.0 : ok
Checking for header boost/shared_ptr.hpp : ok
Checking for header boost/weak_ptr.hpp : ok
Global configuration
Install prefix : /usr/local
Debuggable build : False
Strict compiler flags : False
Build documentation : False
FlowCanvas Configuration
Auto-arrange : True
Anti-Aliasing : True
'configure' finished successfully (0.730s)
suse11-2:/usr/src/ladish-0.1/flowcanvas # ./waf
[snip]
'build' finished successfully (15.788s)
suse11-2:/usr/src/ladish-0.1/flowcanvas # ./waf install
[snip]
'install' finished successfully (0.074s)
suse11-2:/usr/src/ladish-0.1/flowcanvas # cd ..
suse11-2:/usr/src/ladish-0.1 # ./waf configure
[snip]
Install prefix : /usr/local
Build liblash : no
WARNING: D-Bus session services directory as reported by pkg-config is
WARNING: /usr/share/dbus-1/services
WARNING: but service file will be installed in
WARNING: /usr/local/share/dbus-1/services
WARNING: You may need to adjust your D-Bus configuration after installing jackdbus
WARNING: You can override dbus service install directory
WARNING: with --enable-pkg-config-dbus-service-dir option to this script
'configure' finished successfully (1.034s)
suse11-2:/usr/src/ladish-0.1 # ./waf configure --prefix=/usr
Checking for program gcc : ok /usr/bin/gcc
Checking for program cpp : ok /usr/bin/cpp
Checking for program ar : ok /usr/bin/ar
Checking for program ranlib : ok /usr/bin/ranlib
Checking for gcc : ok
Checking for program g++ : ok /usr/bin/g++
Checking for g++ : ok
Checking for dbus-1 >= 1.0.0 : ok
Retrieving D-Bus services dir : ok
Checking for uuid : ok
Checking for header expat.h : ok
Checking for glib-2.0 : ok
Checking for dbus-glib-1 : ok
Checking for gtk+-2.0 : ok
Checking for libglade-2.0 : ok
Checking for flowcanvas >= 0.4.0 : ok
boost headers : Version 1_39 (/usr/include)
==================
ladish-0.1 exported from 0d1ac13dd396785602ea157b5acb12f81da17b63
Install prefix : /usr
Build liblash : no
'configure' finished successfully (0.745s)
suse11-2:/usr/src/ladish-0.1 # ./waf
Waf: Entering directory `/usr/src/ladish-0.1/build'
[ 1/41] cxx: gui/canvas.cpp -> build/default/gui/canvas_3.o
[ 2/41] copy: daemon/dbus.service.in -> build/default/org.ladish.service
[ 3/41] git_ver: -> build/default/version.h
tarball from git revision 0d1ac13dd396785602ea157b5acb12f81da17b63
[ 4/41] cc: jack_proxy.c -> build/default/jack_proxy_1.o
[ 5/41] cc: catdup.c -> build/default/catdup_1.o
cc1: warnings being treated as errors
../jack_proxy.c: In function ‘jack_proxy_set_parameter_value’:
../jack_proxy.c:588: error: ‘type’ may be used uninitialized in this function
Waf: Leaving directory `/usr/src/ladish-0.1/build'
Build failed
-> task failed (err #1):
{task: cc jack_proxy.c -> jack_proxy_1.o}
suse11-2:/usr/src/ladish-0.1 #
root@64studio:/usr/src/ladish-0.1/flowcanvas# ./waf configure
Checking for program gcc : ok /usr/bin/gcc
Checking for program cpp : ok /usr/bin/cpp
Checking for program ar : ok /usr/bin/ar
Checking for program ranlib : ok /usr/bin/ranlib
Checking for gcc : ok
Checking for program g++ : ok /usr/bin/g++
Checking for g++ : ok
Checking for libgvc >= 2.8 : ok
Checking for gtkmm-2.4 >= 2.10.0 : ok
Checking for libgnomecanvasmm-2.6 >= 2.6.0 : ok
Checking for header boost/shared_ptr.hpp : ok
Checking for header boost/weak_ptr.hpp : ok
Global configuration
Install prefix : /usr/local
Debuggable build : False
Strict compiler flags : False
Build documentation : False
FlowCanvas Configuration
Auto-arrange : True
Anti-Aliasing : True
'configure' finished successfully (1.610s)
root@64studio:/usr/src/ladish-0.1/flowcanvas# ./waf
Waf: Entering directory `/usr/src/ladish-0.1/flowcanvas/build'
[1/9] cxx: src/Canvas.cpp -> build/default/src/Canvas_2.o
[2/9] cxx: src/Connectable.cpp -> build/default/src/Connectable_2.o
In file included from /usr/include/graphviz/gvc.h:20,
from ../src/Canvas.cpp:32:
/usr/include/graphviz/types.h:26:1: warning: "FALSE" redefined
In file included from /usr/lib/glib-2.0/include/glibconfig.h:9,
from /usr/include/glib-2.0/glib/gtypes.h:30,
from /usr/include/glib-2.0/glib/galloca.h:30,
from /usr/include/glib-2.0/glib.h:30,
from /usr/include/glib-2.0/gobject/gtype.h:26,
from /usr/include/glib-2.0/gobject/gboxed.h:26,
from /usr/include/glib-2.0/glib-object.h:25,
from /usr/include/glibmm-2.4/glibmm/containerhandle_shared.h:31,
from /usr/include/glibmm-2.4/glibmm/arrayhandle.h:24,
from /usr/include/glibmm-2.4/glibmm.h:27,
from /usr/include/gtkmm-2.4/gtkmm.h:29,
from /usr/include/libgnomecanvasmm-2.6/libgnomecanvasmm.h:29,
from ../flowcanvas/Canvas.hpp:24,
from ../src/Canvas.cpp:27:
/usr/include/glib-2.0/glib/gmacros.h:167:1: warning: this is the location of the previous definition
In file included from /usr/include/graphviz/gvc.h:20,
from ../src/Canvas.cpp:32:
/usr/include/graphviz/types.h:27:1: warning: "TRUE" redefined
In file included from /usr/lib/glib-2.0/include/glibconfig.h:9,
from /usr/include/glib-2.0/glib/gtypes.h:30,
from /usr/include/glib-2.0/glib/galloca.h:30,
from /usr/include/glib-2.0/glib.h:30,
from /usr/include/glib-2.0/gobject/gtype.h:26,
from /usr/include/glib-2.0/gobject/gboxed.h:26,
from /usr/include/glib-2.0/glib-object.h:25,
from /usr/include/glibmm-2.4/glibmm/containerhandle_shared.h:31,
from /usr/include/glibmm-2.4/glibmm/arrayhandle.h:24,
from /usr/include/glibmm-2.4/glibmm.h:27,
from /usr/include/gtkmm-2.4/gtkmm.h:29,
from /usr/include/libgnomecanvasmm-2.6/libgnomecanvasmm.h:29,
from ../flowcanvas/Canvas.hpp:24,
from ../src/Canvas.cpp:27:
/usr/include/glib-2.0/glib/gmacros.h:171:1: warning: this is the location of the previous definition
[3/9] cxx: src/Connection.cpp -> build/default/src/Connection_2.o
[4/9] cxx: src/Ellipse.cpp -> build/default/src/Ellipse_2.o
[5/9] cxx: src/Item.cpp -> build/default/src/Item_2.o
[6/9] cxx: src/Module.cpp -> build/default/src/Module_2.o
[7/9] cxx: src/Port.cpp -> build/default/src/Port_2.o
[8/9] copy: flowcanvas.pc.in -> build/default/flowcanvas.pc
[9/9] vnum_cxx_link: build/default/src/Canvas_2.o build/default/src/Connectable_2.o build/default/src/Connection_2.o build/default/src/Ellipse_2.o build/default/src/Item_2.o build/default/src/Module_2.o build/default/src/Port_2.o -> build/default/libflowcanvas.so build/default/libflowcanvas.so.2
Waf: Leaving directory `/usr/src/ladish-0.1/flowcanvas/build'
'build' finished successfully (14.397s)
root@64studio:/usr/src/ladish-0.1/flowcanvas#
