TEST - please ignore

Thank you :)

--
Marc-Olivier Barre
XMPP ID : marco@...
www.MarcOChapeau.org

Re: updated ebuild

updated ebuild

# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

EAPI="3"

inherit distutils git-2

DESCRIPTION="LADITools is a set of tools to improve desktop integration and user workflow of Linux audio systems"
HOMEPAGE="http://www.marcochapeau.org/software/laditools"

EGIT_REPO_URI="git://git.marcochapeau.org/laditools.git"

LICENSE="GPL-3"
SLOT="0"
KEYWORDS=""
IUSE=""

PYTHON_DEPEND="2:2.6"

RDEPEND="dev-lang/python
	dev-python/pyyaml
	>=dev-python/enum-0.4.4
	>=media-sound/jack-audio-connection-kit-0.109.2-r2[dbus]
	>=x11-libs/vte-0.30.1[introspection]"

DOCS="README"

github

github provides useful features for colaboration so I created set of
LADI related repos there:

https://github.com/LADI

repo.or.cz is not deprecated, and stays as alternative to github.

--

-- 
Nedko Arnaudov <GnuPG KeyID: 5D1B58ED>

lash-compat

Hi, a question about lash-compat.

My understanding is that it enables old programs that need
/usr/include/lash to compile, and perhaps even work better (L2 instead
of L1/0) under ladish.

It now seems that Debian is dropping lash-compat from their packaging
of ladish [1], because it is "not needed any more". True, many old
LASH programs have compile-time flags to disable LASH.

Is this a good thing? Are old LASH programs better of as L0 (by
compiling them with --disable-lash or whatever) or as L2 (using
lash-compat)?

[1] http://anonscm.debian.org/gitweb/?p=pkg-multimedia/ladish.git;a=summary

-- Dan

Adding Jack transport support?

Hi,

I was thinking about adding in Gladish a simple "Tools/Transport"
sub-menu (Start, Stop, Rewind). It's annoying to start a separate
qjackctl or gjacktransport client just for these simple tasks.

However, looking at the jack2 source, I see that
dbus/controller_iface_transport.c seems to be an empty stub. Nedko, am
I misreading that? Can jackdbus affect the transport?

-- Dan

ladish_control documentation?

ladish roadmap update, mobilis in mobili

ladish initial roadmap was set more than two years ago and like it or
not, some things have changed since then. The most important thing is
JACK session that was released earlier this year. It gained some
popularity and seems to be looked for, despite its drawbacks. So the the
next ladish release will have JACK session and LASH support.

These were originally planned for preview 5 (ladish-0.5) but are here
already. The export/import feature was planned for preview 4
(ladish-0.4) but there seems to be little demand for it. The other
feature that was planned for 0.5, libladish, is not forgotten and its
goal is still valid - to provide the perfect session management
API. Unfortunately JACK session introduction caused big disturbance in
The Force that lowered expectations, promotes ignorance and attempts to
reject the path of perfection. So libladish is moving forward to future
perfect, maybe even post-1.0.

From now on the roadmap will not try to cover long term goals anymore,
except for the 2.0 feature set (multihost sessions). The 0.5 milestone
is removed and 0.4 is redefined. The next release will be ladish-0.4
(preview 4). Given that even in its current state ladish serves its main
goals, the release after 0.4 may be 1.0.

After the 1.0 release I'll switch to integer version numbering. To me
this approach makes much sense for projects driven by a single man. 2.0
milestone will be renamed to "Distributed studio" to better reflect the
availability expectations - when it’s ready. New releases will be rolled
out when the codebase has enough important changes.

--

-- 
Nedko Arnaudov <GnuPG KeyID: 5D1B58ED>

BUG 161

Dear Nedko,

I'm running into BUG 161 (compiling from GIT)
Is there any possibility to get araound that or can I provide any help or
information to fix this?

Thanks, Holger

room apps with ALSA MIDI

When an ALSA-Midi-only app is started in a room, a2j creates the
Jack-bridged MIDI port in the studio, not in the room. How should this
be handled?

Even worse, some apps auto-connect to system:capture_*. If they are
started in a room, it is then impossible to disconnect them using
(g)ladish. There should be some work-around for such apps (even if one
could argue they are "broken").

I can't help but notice that there are some circumstances when the
"room abstraction" breaks down.

-- Dan

Gentoo ebuild deprecated warning ...