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

Re: Adding Jack transport support?

Hi Dan,

> 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?

You are reading it right. jackdbus transport interface is not
implemented yet.

--

-- 
Nedko Arnaudov <GnuPG KeyID: 5D1B58ED>

Hi Dan,

> 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?

You are reading it right. jackdbus transport interface is not
implemented yet.

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

Re: lash-compat

Dan Muresan <danmbox@...> writes:

> 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.

I don't know what exactly lash_compat package is for. In gentoo I'm
handling liblash through a virtual package that is satisfied either by
LASH or ladish implementation of liblash.

> 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.

Well, Alessio reported problem with ABI changes and asked for bumping
soname. I refuse because IMO soname must match the one of the emulated
liblash version, i.e. the one from the latest lash release. This may
have something to do with drop of lash-compat.

> 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)?

IMO its good to keep lash until there is a ubiquitous winner. Or at
least ubiquitous replacement for lash. This is why I implemented liblash
between 0.3 and 1.

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

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>

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>

Re: lash-compat

Well, what is your current recommendations for app writers who want
their apps to "play nice" in ladish? Use jack-session, liblash, stick
to L1, or what?

> Well, Alessio reported problem with ABI changes and asked for bumping
> soname. I refuse because IMO soname must match the one of the emulated
> liblash version, i.e. the one from the latest lash release. This may
> have something to do with drop of lash-compat.

Maybe... The changelog just says

+  * Drop lash compatibility library, it's not needed anymore since we
+    don't want applications use something deprecated.

To make things worse Debian has been dropping liblash support  from
apps for a while now, on the theory that Lash is abandoned. At the
same time some of those apps are unmaintained (jack_mixer?). So in the
end they may never run properly (>= L1) under Ladish (in Debian
distros that is). Which is a pity!

> IMO its good to keep lash until there is a ubiquitous winner. Or at
> least ubiquitous replacement for lash. This is why I implemented liblash
> between 0.3 and 1.

A winner between... Jack-session vs liblash? With the 800-pound Debian
dropping liblash support completely, I think it's clear which way
things are heading.

-- Dan

Re: lash-compat

Dan Muresan <danmbox@...> writes:

> Well, what is your current recommendations for app writers who want
> their apps to "play nice" in ladish? Use jack-session, liblash, stick
> to L1, or what?

To use at least one of jack-session, L1 or liblash. They can implement
all three and thus be more flexible to user`s needs.

>> Well, Alessio reported problem with ABI changes and asked for bumping
>> soname. I refuse because IMO soname must match the one of the emulated
>> liblash version, i.e. the one from the latest lash release. This may
>> have something to do with drop of lash-compat.
>
> Maybe... The changelog just says
>
> +  * Drop lash compatibility library, it's not needed anymore since we
> +    don't want applications use something deprecated.
>
> To make things worse Debian has been dropping liblash support  from
> apps for a while now, on the theory that Lash is abandoned. At the
> same time some of those apps are unmaintained (jack_mixer?). So in the
> end they may never run properly (>= L1) under Ladish (in Debian
> distros that is). Which is a pity!

jack_mixer should me considered maintained I think. I want to add L1 to
it at some point. IIRC it can manually save internal state as well. In
any case if you or someone else contributes improvements in this area,
I'll commit them. Frederic is the current maintainer. His position
wrt session handling is:

Re: lash-compat

Nedko Arnaudov <nedko@...> writes:

> AFAIK Alessio is going to re-add lash support in Debian but its better
> to ask him directly for an official position. I think he is not
> subscribed to this list.

Alessio just confirmed on IRC:

"I'll have a look and re-introduce lash compatibility layer (with a proper Debian's custom SONAME) ASAP"

-- 
Nedko Arnaudov <GnuPG KeyID: 5D1B58ED>

Nedko Arnaudov <nedko@...> writes:

> AFAIK Alessio is going to re-add lash support in Debian but its better
> to ask him directly for an official position. I think he is not
> subscribed to this list.

Alessio just confirmed on IRC:

"I'll have a look and re-introduce lash compatibility layer (with a proper Debian's custom SONAME) ASAP"

--

-- 
Nedko Arnaudov <GnuPG KeyID: 5D1B58ED>

Re: lash-compat

> Alessio just confirmed on IRC:
>
> "I'll have a look and re-introduce lash compatibility layer (with a proper Debian's custom SONAME) ASAP"

That's good news -- it means "old" lash apps can become L1 apps
straight away (well, upon recompilation).

I saw a ladish commit disabling studio-level lash apps -- will this be
"fixed" eventually?

-- Dan

Re: lash-compat

Dan Muresan <danmbox@...> writes:

>> Alessio just confirmed on IRC:
>>
>> "I'll have a look and re-introduce lash compatibility layer (with a proper Debian's custom SONAME) ASAP"
>
> That's good news -- it means "old" lash apps can become L1 apps
> straight away (well, upon recompilation).

No... lash apps will stay lash apps (L2)...

> I saw a ladish commit disabling studio-level lash apps -- will this be
> "fixed" eventually?

Eventually but unlikely. lash requires app dirs and studios dont have
dedicated dirs. the studio level lash app support used per app dirs in
studios directory. this made lash apps somewhat shared between studios.
In theory because app uuids are used one app should belong to only one
studio. In practice studio "save as" does not regenerate app uuids so
they will be shared and user will be clueless.

--

-- 
Nedko Arnaudov <GnuPG KeyID: 5D1B58ED>

Dan Muresan <danmbox@...> writes:

>> Alessio just confirmed on IRC:
>>
>> "I'll have a look and re-introduce lash compatibility layer (with a proper Debian's custom SONAME) ASAP"