20 Nov
2009
20 Nov
'09
4:16 p.m.
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>
20 Nov
20 Nov
8 p.m.
On Fri, Nov 20, 2009 at 10:15:20PM +0200, Nedko Arnaudov wrote:
<a lot, use your mail agent's facilities to read it>
Nedko,
Since you refer to me twice in your post I feel free to
respond. And even if you may regard me as one of your
'adversaries', please don't take anything I write as
a comment on you personally.
Let me say first that I'm sorry to see you in such a
state of despair. On one hand I'm sure you're not the
one to blame for it. On the other, you can't blame the
world. Some things are just what they are.
I do share many of your technical concerns about Jack,
about session management, and the state of LA in general.
My views on how they can be solved are probably quite
different to yours. This won't make me many friends, but
I don't believe there are easy solutions, in the sense
that there could be a gradual evolution, consisting of a
series of simple steps, each of them 'backwards compatible',
that would resolve the problems that do exist. Unless maybe
for someone who is prepared to wait much longer than I am.
This may be a personal attitude, but I believe that in a
situation like this one, at some point you have to bite
the bullet and clean up the mess that stands in the way,
no matter how much pain it causes. In IT language, some
of the solution (IMHO) will be incompatible with current
practices, APIs, and standards.
If I'd respond to all technical issues you raise the
result would be a 30-page paper. Maybe I should present
it a the next LAC, to be hung on the nearest high tree
shortly afterwards. So I'll limit my response to the
dbus related issues, also since you accuse me of having
waged a flame war against it.
Let me make it clear: I do not like dbus, for a variety
of reasons.
The first is its ugly API. That's opinion, but it's my
opinion and not likely to change any time soon.
The second, and more important, is that it mixes up a
lot of different things. Maybe, to arrive a Linux Audio
apps that are as user friendly as some of the ones that
exist on competing systems there are two solutions. One
is the 'integrated application' where everything can be
done within just one program, and the whole issue of
session management and connections is internal to that
application. The other is a degree of session management
that would provide almost the same user experience, and
for such a thing maybe a system like dbus is part of the
solution (but see comments below). But in that case the
only concern of such an inter-application communication
framework should be communication. Not security, access
control, or any form of policy. And certainly not any
dependency on irrelevant context, such as a desktop or
a local login.
** If you had proposed a separate 'audio dbus', completely
independent of the desktop session one, my reaction would
probably have been much more relaxed. **
The third, already hinted at above, is the close relation
of dbus to some other systems designed to provide a 'rich'
Windows-like desktop experience. The Kit family is not
really a set of independent and maybe on their own useful
components. It's rapidly becoming a 'all or nothing', take
it or leave it' sort of thing just like Windows, with all
the consequences that brings. And and least for me, those
consequences are not acceptable, the whole thing is much
too invasive and desktop-centered. And AFAICS, dbus is
very much married into that family.
Finally, some comments on session management.
If session management is supposed to work then apps have
to agree to being managed rather than doing everything
on their own. This includes for example external Jack
connections: to whom does a connection A->B belong, to
A or B ? At least Linux Audio's most famous app, Ardour,
is not moving that way - it's going the 'integrated app'
way, and even more so since its developers are looking
more and more towards OSX. Wait a bit more and it will
integrate everything you need to make (some types of)
music. And at that point the whole session management
issue will become irrelevant. Except for people like
me who are very much into minority interests that
never will be covered by integrated applications.
Secondly, being managed means that apps are talking to
their session manager. Not to each other. In other words,
this is a 'star' type of topology, not a bus. There are
many existing standard solutions for that, and they don't
need dbus. Nor do they need autolaunching of servers etc.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
8:51 p.m.
If I'd respond to all technical issues you raise the
result would be a 30-page paper. Maybe I should present
it a the next LAC, to be hung on the nearest high tree
shortly afterwards.
I think you should (present at at the LAC, not be hung on the nearest
tree). That's a very good forum for these discussions. Perhaps a Panel
discussion on 'desktop' versus 'pro-audio' could be set up.
Victor
21 Nov
21 Nov
8:12 a.m.
On Sat, Nov 21, 2009 at 12:51:35AM +0000, Victor Lazzarini wrote:
The conflict is not desktop vs. pro-audio. Even pro-audio users
want to use their desktops.
The real problem is all the auto-configuration and security
policy that gets added by the e.g. the Kit familiy and friends
in order to please the typical user who is happy to trade in
his autonomy and security for convenience. And it's being done
in a way that makes it near impossible to manually configure
a system.
Just one example. In the original CdS setup the three
rendering machines had a KVM switch and a shared screen,
mouse and keyboard. The idea was that maybe it could be
practical to login locally every now and then. Result:
a local login made the system unusable, as the audio
devices would be re-assigned to the local user. This
is done 'somehow' by gdm. I have wasted days trying to
find out where exactly this happened and how it could
be disabled. I did not find the solution, it's all done
behind the screens, probably by some members of the Kit
familiy or their friends. So in the end I just removed
the KVM switch and everything related, and made the
machines boot into runlevel 3, no local desktop logins
allowed at all.
I'm moving to ArchLinux because at least there you
remain more or less in control. For now that is.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
If I'd
respond to all technical issues you raise the
result would be a 30-page paper. Maybe I should present
it a the next LAC, to be hung on the nearest high tree
shortly afterwards.
I think you should (present at at the LAC, not be hung on the
nearest tree). That's a very good forum for these discussions.
Perhaps a Panel discussion on 'desktop' versus 'pro-audio' could be
set up. 
20 Nov
20 Nov
10 p.m.
On 11/20/2009 08:15 PM, Nedko Arnaudov wrote A LOT :)
Nedko, are you on some kind of a meltdown or something?
now that i was making my day (erm, night?:) with your lv2fil plugin, are
you throwing in the towel (*) ?
certainly you aren't _that_ desperate, i hope.
am i too naive to assume you're just stirring the heavy waters of the
reactor? ;)
uber-procrastinator dixit
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
(*) spam warning: lv2 plugin support shaping up in qtractor ;)
11:07 p.m.
On 11/21/2009 01:00 PM, Rui Nuno Capela wrote:
On 11/20/2009 08:15 PM, Nedko Arnaudov wrote A LOT :)
Nedko, are you on some kind of a meltdown or something?
now that i was making my day (erm, night?:) with your lv2fil plugin, are
you throwing in the towel (*) ?
certainly you aren't _that_ desperate, i hope.
am i too naive to assume you're just stirring the heavy waters of the
reactor? ;)
I know exactly where Nedko is coming from.
He has invested a lot of effort into making huge strides in developing
his vision for session management.
I didn't realise that Ladi was being left in the cold by the wider
community.
It's not easy to find motivation for continuing development when a large
subset of your ideas are received as fundamentally flawed because of the
core design choice that enables their existence. In addition being
continually dragged into a heated debate or having flames directed your
way by the people who you are trying to get constructive feedback from
can be extremely tiring, stressful and depressing. Not to mention the
trolls or people feeling trollish at a given moment like to direct their
attacks at the people who are taking the most heat which can be an
additional source of annoyance.
The same issues that Nedko sees with the anti reaction for his work is
the same thing that the PA developers receive and verges on the same
thing the OSS developers have received in the past. Hence there is
usually a conflict and heated argument when these parties contribute to
discussions in the wider community.
The one thing that cannot be denied is that each of the above has
technical merits that the core developers have decided are worth
"compromising" on or developing around to achieve their goals.
I personally see Nedkos work as extremely valuable so I will be making
some time for testing and feedback.
Patrick Shirkey
Boost Hardware Ltd
21 Nov
21 Nov
12:21 a.m.
On Fri, Nov 20, 2009 at 10:06 PM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
It's not easy to find motivation for continuing
development when a large
subset of your ideas are received as fundamentally flawed because of the
core design choice that enables their existence.
I think that I should be clear on why nedko's work on using dbus with
jack has not been integrated into the jack1 codebase. Its really very
simple, and has absolutely to do with the "dbus" issue in the way that
it has played out on this mailing list. there are basically a few core
reasons:
1) the coding guidelines specify that the core jack1 codebase should
contain only ANSI C and POSIX. we allow utility clients to exist that
have other dependencies, but they are always conditionally compiled
and are not considered core elements of JACK. dbus does not meet this
test.
2) the only API to talk to the JACK server has been provided by one or
more libraries provided by JACK. this means, for example, that we have
not "published" the protocol used between the server and libjack. It
is therefore incongruous with the existing design of JACK to add any
IPC mechanism (OSC, dbus, CORBA, DCOP, Sun-RPC or whatever else you
might care to suggest) directly into the JACK server or libraries that
make up the core of JACK.
3) reliance on 3rd party technology is only acceptable if it is
clearly platform independent. dbus does not meet this test (although
it is not terribly far from meeting it, it still does not meet it).
there are actually very few IPC technologies that do.
4) reliance on technologies that appear to be tied into
desktop-centric computing architectures should probably be avoided in
the core of JACK. Having other JACK tools that integrate well with
various desktop platforms seems VERY desirable, but it seems
reasonably clear that there is no inherent reason to build such
functionality into anything that is distributed as "part of JACK". if
a particular distribution wanted to "fix JACK" by integrating into
their desktop, that also seems entirely reasonable, and might be
something that other distributions would pick up. the success of such
work would have little to no impact on the core of JACK. Hopefully,
this can remain focused on providing, as well as it can, a
cross-platform pro-audio/music audio server for use on a variety of
platforms and a variety of use cases, including but not limited to
systems where "integration" is not an issue. Nedko's jackdbus actually
shows a way to do this: he provides (almost simultaneous) releases of
jackbus that feature a level of integration between JACK and
dbus-based IPC for control that seems inappropriate for a general
release of JACK. I am glad that those who which to control JACK in
this way have the chance to do so with current versions - its a good
thing.
What would always have been acceptable, and without any argument or
even much discussion was (a) implementation of the "control API" as a
JACK library combined with (b) a client that understand dbus (or OSC,
or Sun-RPC or DCOP or whatever) and translated between the JACK
control API and whatever protocol it used to communicate with the
outside world. Nedko did not want to do things in this way, and has
even stated to me on IRC that he believes that we/I should have been
willing to simply adopt the work that he did do until something better
came along. This is not how Linus has successfully managed the kernel,
and although I believe that Linus has done a better job of that then
we have managed with JACK, his example is still something that I
believe is correct to follow here.
Precisely the same points would have had to be made had Nedko or
someone else taken a similar approach using OSC, Sun-RPC, DCOP or any
other IPC protocol/technology.
None of this is intended to negate the entirely valid points that
Nedko makes about some aspects of JACK's implemenation(s). However,
his sensitivity to people's commentary on dbus, along with some of the
really undeserved and ignorant criticism of dbus that has appeared on
this mailing list, makes it necessary to try to be as clear as
possible on the actual issues that block adoption of some or all of
the work he has done. The problems that he has mentioned separately DO
need working on (and preferably fixing), and any ideas, designs and
contributions of code that meet the coding guidelines long
established, along with some of the points I have raised above will be
very welcome.
Moving on a bit ....
I am personally appalled by the debacle that LASH turned into.
Stemming from a proposal made years ago (by Bob Ham, I believe), LASH
has gone more or less nowhere. It has never arrived at a stable,
congruent and consistent specification, even via a header file. The
people working on the project have appeared to a casual observer like
myself to be in constant turnover and/or constantly redesigning the
entire system with a claim that this time it will be done right. The
project is, quite frankly, a joke when compared to what has been
managed with ALSA, LADSPA, JACK and even something like DSSI.
Certainly session management is an important issue when using a weakly
connected set of cooperating applications, and it remains almost
entirely unsolved. I personally have no faith that any of the work on
LASH has moved us notably closer to an actual solution to this issue,
although I will grant that it has helped some developers to get a
better grasp on what some of the issues actually are, and for that I
suppose we must be grateful.
1:19 a.m.
On 11/21/2009 03:21 PM, Paul Davis wrote:
I am personally appalled by the debacle that LASH turned into.
Stemming from a proposal made years ago (by Bob Ham, I believe), LASH
has gone more or less nowhere. It has never arrived at a stable,
congruent and consistent specification, even via a header file. The
people working on the project have appeared to a casual observer like
myself to be in constant turnover and/or constantly redesigning the
entire system with a claim that this time it will be done right. The
project is, quite frankly, a joke when compared to what has been
managed with ALSA, LADSPA, JACK and even something like DSSI.
Certainly session management is an important issue when using a weakly
connected set of cooperating applications, and it remains almost
entirely unsolved. I personally have no faith that any of the work on
LASH has moved us notably closer to an actual solution to this issue,
although I will grant that it has helped some developers to get a
better grasp on what some of the issues actually are, and for that I
suppose we must be grateful.
We have seen many good things come from the session management
development process. LADI is the most advanced implementation for
session management that has been achieved so far.
There have been a consistent set of procedures applied in all the above
projects and in many cases the issues that the session management people
have encountered have been consistent the main exception being the lack
of consensus by the community on which approach makes the most sense.
As has been stated before many times, the standard model established
over the years in LAD has required one or two highly motivated people to
push forward with their vision and also take on the wider community with
a forceful and intense defense of their direction.
Nedko has chosen to work with dbus and has provided a very flexible
system built on that decision. However his approach is not acceptable
for all use cases. Afaict there is very little interest from parties
that disagree with the dbus approach to enhance the LADI toolset in a
way that makes it more flexible for their use and vision.
One major item of note is that qjackctl now has preliminary dbus support
even though Rui has stated that it would not happen. This step in itself
should be clear a major roadblock to LADI integration and deployment.
Patrick Shirkey
Boost Hardware Ltd
7:13 a.m.
On 11/21/2009 05:18 AM, Patrick Shirkey wrote:
One major item of note is that qjackctl now has preliminary dbus support
even though Rui has stated that it would not happen. This step in itself
should be clear a major roadblock to LADI integration and deployment.
wait, i don't seem to remember having said it would *not* happen. i
think i had said it would be *hard* to happen, mainly due to my
everlasting lack of time. you all know the stance ;)
and moving on a bit (but staying in the same place):
i think a also made my position long ago that qjackctl is a jack control
application and thus, it should harness the jack control api and nothing
else on the side. imo, it's this jack control api or protocol that
should be implemented through whatever ipc mechanism you think of (dbus,
osc, yada yada).
ok, in that sense, you can say that qackctl would not go the jack dbus
route, at least directly face to face. again imo, it must do it on top a
an established jack control interface. no more no less ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
10:48 a.m.
On 11/21/2009 10:13 PM, Rui Nuno Capela wrote:
On 11/21/2009 05:18 AM, Patrick Shirkey wrote:
LADI represents a very powerful and flexible session management system
that has been built on 7 years of intense debate/thinking/development
and several competing and complimentary implementations.
Qjackctl *is* the default desktop management interface for jack.
It would be a very powerful combination if qjackctl supported the
functionality provided by the LADI tools. Currently we have a
chicken/egg situation as you are not prepared to spend your valuable
time on session support until it is officially established but if the
default management tool doesn't support the most flexible option we have
available then how can it be considered established?
If LADI which now represents a significant effort by several very clever
and committed developers is not officially supported then we as a
community are encouraging the fragmentation to continue rather than
forging better integration.
Supporting LADI doesn't mean that a non dbus solution can't be supported
or that everyone has to be forced to use the dbus solution.
Patrick Shirkey
Boost Hardware Ltd
One major item of note is that qjackctl now has
preliminary dbus support
even though Rui has stated that it would not happen. This step in itself
should be clear a major roadblock to LADI integration and deployment.
wait, i don't seem to remember having said it would *not* happen. i
think i had said it would be *hard* to happen, mainly due to my
everlasting lack of time. you all know the stance ;)
and moving on a bit (but staying in the same place):
i think a also made my position long ago that qjackctl is a jack control
application and thus, it should harness the jack control api and nothing
else on the side. imo, it's this jack control api or protocol that
should be implemented through whatever ipc mechanism you think of (dbus,
osc, yada yada).
ok, in that sense, you can say that qackctl would not go the jack dbus
route, at least directly face to face. again imo, it must do it on top a
an established jack control interface. no more no less ;)
11:36 a.m.
On 11/21/2009 02:47 PM, Patrick Shirkey wrote:
On 11/21/2009 10:13 PM, Rui Nuno Capela wrote:
first time i've heard of the ladi effort was in the lac2007@koln
cafeteria. is there an old conspiracy or has dan brown already picked up
the lads as subjects? nevermind, i've been m.i.a. too many times :)
On 11/21/2009 05:18 AM, Patrick Shirkey wrote:
LADI represents a very powerful and flexible session management system
that has been built on 7 years of intense debate/thinking/development
and several competing and complimentary implementations.
One major item of note is that qjackctl now has
preliminary dbus support
even though Rui has stated that it would not happen. This step in itself
should be clear a major roadblock to LADI integration and deployment.
wait, i don't seem to remember having said it would *not* happen. i
think i had said it would be *hard* to happen, mainly due to my
everlasting lack of time. you all know the stance ;)
and moving on a bit (but staying in the same place):
i think a also made my position long ago that qjackctl is a jack control
application and thus, it should harness the jack control api and nothing
else on the side. imo, it's this jack control api or protocol that
should be implemented through whatever ipc mechanism you think of (dbus,
osc, yada yada).
ok, in that sense, you can say that qackctl would not go the jack dbus
route, at least directly face to face. again imo, it must do it on top a
an established jack control interface. no more no less ;)
Qjackctl *is* the default desktop management interface
for jack.
It would be a very powerful combination if qjackctl supported the
functionality provided by the LADI tools. Currently we have a
chicken/egg situation as you are not prepared to spend your valuable
time on session support until it is officially established but if the
default management tool doesn't support the most flexible option we have
available then how can it be considered established?
please note, i've meant the establishment of the so called *jack control
api* iow, libjackcontrol.so.
i really don't care whether that jack-control-api is actually
implemented through dbus, osc or whatever-ipc, but it must be
established enough as the official way to control jack. qjackctl, as i
know it, is only going through that jack-control-api and *not* dbus,
osc, whatever.
If LADI which now represents a significant effort by
several very clever
and committed developers is not officially supported then we as a
community are encouraging the fragmentation to continue rather than
forging better integration.
Supporting LADI doesn't mean that a non dbus solution can't be supported
or that everyone has to be forced to use the dbus solution.
of course.
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
2:12 p.m.
On 11/22/2009 02:36 AM, Rui Nuno Capela wrote:
On 11/21/2009 02:47 PM, Patrick Shirkey wrote:
I was referring to the entire development process of session managment
tools. Nedko has studied the previous examples and tried to build on the
ideas that were offered.
Patrick Shirkey
Boost Hardware Ltd
On 11/21/2009 10:13 PM, Rui Nuno Capela wrote:
first time i've heard of the ladi effort was in the lac2007@koln
cafeteria. is there an old conspiracy or has dan brown already picked up
the lads as subjects? nevermind, i've been m.i.a. too many times :)
On 11/21/2009 05:18 AM, Patrick Shirkey wrote:
LADI represents a very powerful and flexible session management system
that has been built on 7 years of intense debate/thinking/development
and several competing and complimentary implementations.
One major item of note is that qjackctl now has
preliminary dbus support
even though Rui has stated that it would not happen. This step in itself
should be clear a major roadblock to LADI integration and deployment.
wait, i don't seem to remember having said it would *not* happen. i
think i had said it would be *hard* to happen, mainly due to my
everlasting lack of time. you all know the stance ;)
and moving on a bit (but staying in the same place):
i think a also made my position long ago that qjackctl is a jack control
application and thus, it should harness the jack control api and nothing
else on the side. imo, it's this jack control api or protocol that
should be implemented through whatever ipc mechanism you think of (dbus,
osc, yada yada).
ok, in that sense, you can say that qackctl would not go the jack dbus
route, at least directly face to face. again imo, it must do it on top a
an established jack control interface. no more no less ;)
Qjackctl *is*
the default desktop management interface for jack.
It would be a very powerful combination if qjackctl supported the
functionality provided by the LADI tools. Currently we have a
chicken/egg situation as you are not prepared to spend your valuable
time on session support until it is officially established but if the
default management tool doesn't support the most flexible option we have
available then how can it be considered established?
please note, i've meant the establishment of the so called *jack
control
api* iow, libjackcontrol.so.
i really don't care whether that jack-control-api is actually
implemented through dbus, osc or whatever-ipc, but it must be
established enough as the official way to control jack. qjackctl, as i
know it, is only going through that jack-control-api and *not* dbus,
osc, whatever.
If LADI which now represents a significant effort
by several very clever
and committed developers is not officially supported then we as a
community are encouraging the fragmentation to continue rather than
forging better integration.
Supporting LADI doesn't mean that a non dbus solution can't be supported
or that everyone has to be forced to use the dbus solution.
of course.
byee
2:21 p.m.
On 11/21/2009 06:11 PM, Patrick Shirkey wrote:
On 11/22/2009 02:36 AM, Rui Nuno Capela wrote:
>>
>> LADI represents a very powerful and flexible session management system
>> that has been built on 7 years of intense debate/thinking/development
>> and several competing and complimentary implementations.
>>
>>
> first time i've heard of the ladi effort was in the lac2007@koln
> cafeteria. is there an old conspiracy or has dan brown already picked up
> the lads as subjects? nevermind, i've been m.i.a. too many times :)
>
i was wrong by one year: it was in lac2008@khm-koln (lac2007 was in
tu-berlin)
I was referring to the entire development process of session managment
tools. Nedko has studied the previous examples and tried to build on the
ideas that were offered.
you mean ever since ladcca, then lash and now ladi(sh), right?
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
2:24 p.m.
On 11/22/2009 05:21 AM, Rui Nuno Capela wrote:
On 11/21/2009 06:11 PM, Patrick Shirkey wrote:
Yes.
Patrick Shirkey
Boost Hardware Ltd
On 11/22/2009 02:36 AM, Rui Nuno Capela wrote:
>> LADI represents a very powerful and flexible session management system
>> that has been built on 7 years of intense debate/thinking/development
>> and several competing and complimentary implementations.
>>
>>
>>
> first time i've heard of the ladi effort was in the lac2007@koln
> cafeteria. is there an old conspiracy or has dan brown already picked up
> the lads as subjects? nevermind, i've been m.i.a. too many times :)
>
>
i was wrong by one year: it was in lac2008@khm-koln (lac2007 was in
tu-berlin)
I was referring to the entire development process
of session managment
tools. Nedko has studied the previous examples and tried to build on the
ideas that were offered.
you mean ever since ladcca, then lash and now ladi(sh), right?
10:45 a.m.
On Sat, Nov 21, 2009 at 12:18 AM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
Nedko has chosen to work with dbus and has provided a
very flexible
system built on that decision. However his approach is not acceptable
for all use cases. Afaict there is very little interest from parties
that disagree with the dbus approach to enhance the LADI toolset in a
way that makes it more flexible for their use and vision.
I don't really care at all about the technology inside a Linux session
handling "toolkit", although clearly it would be nicer if it worked on
all Linux systems. What I care about is the complete lack of any
stable API that a developer of an application that would participate
in this could use and have some confidence in. Do I believe that using
dbus as an IPC mechanism makes sense in this case, and that therefore
"the API" is really just a set of dbus names and semantics? Well, i'm
agnostic about that (my doubt comes from the fact that the
participants are all already connected via an existing IPC mechanism
that is guaranteed to be running; its called JACK), but in the end it
does not matter much to me - what matters more is that the work to
integrate an application into the system can be done, and stay done.
My impression of LASH and its cousins is that this simply hasn't
happened yet.
11:01 a.m.
On 11/22/2009 01:45 AM, Paul Davis wrote:
On Sat, Nov 21, 2009 at 12:18 AM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
I think this is why Nedko has decided to draw a line here. He has
attempted to provide a very flexible and powerful implementation built
on top of several other implementations. The big problem is that
developer community is not getting on board.
If we gave more support to the LADI tools as a session management option
then we could get feedback on the capabilities of the toolset from the
wider community of users and get a better impression of how far from the
target we really are.
If jack1/2, qjackctl, patchage, gnome, kde, etc... don't get behind it
as a viable session management option then we will never fulfil the
potential.
Patrick Shirkey
Boost Hardware Ltd
Nedko has chosen to work with dbus and has
provided a very flexible
system built on that decision. However his approach is not acceptable
for all use cases. Afaict there is very little interest from parties
that disagree with the dbus approach to enhance the LADI toolset in a
way that makes it more flexible for their use and vision.
I don't really care at all about the technology inside a Linux session
handling "toolkit", although clearly it would be nicer if it worked on
all Linux systems. What I care about is the complete lack of any
stable API that a developer of an application that would participate
in this could use and have some confidence in. Do I believe that using
dbus as an IPC mechanism makes sense in this case, and that therefore
"the API" is really just a set of dbus names and semantics? Well, i'm
agnostic about that (my doubt comes from the fact that the
participants are all already connected via an existing IPC mechanism
that is guaranteed to be running; its called JACK), but in the end it
does not matter much to me - what matters more is that the work to
integrate an application into the system can be done, and stay done.
My impression of LASH and its cousins is that this simply hasn't
happened yet.
5:54 p.m.
On Sun, 2009-11-22 at 02:00 +1100, Patrick Shirkey wrote:
On 11/22/2009 01:45 AM, Paul Davis wrote:
[...]
> I don't really care at all about the
technology inside a Linux session
> handling "toolkit", although clearly it would be nicer if it worked on
> all Linux systems. What I care about is the complete lack of any
> stable API that a developer of an application that would participate
> in this could use and have some confidence in.
Bingo.
The big problem is that
developer community is not getting on board.
Bingo. Not a coincidence.
-dr
23 Nov
23 Nov
8:26 a.m.
On Sat, 2009-11-21 at 09:45 -0500, Paul Davis wrote:
I don't really care at all about the technology
inside a Linux session
handling "toolkit", although clearly it would be nicer if it worked on
all Linux systems. What I care about is the complete lack of any
stable API that a developer of an application that would participate
in this could use and have some confidence in. Do I believe that using
dbus as an IPC mechanism makes sense in this case, and that therefore
"the API" is really just a set of dbus names and semantics? Well, i'm
agnostic about that
I'd like to comment on this issue in order to clarify and also to
explain why, as Nedko stated in his original email, I gave no support to
D-Busification efforts.
One of the goals of LADCCA, LASH and even LADISH is to enable
network-wide session management. A D-Bus connection enables
communication between remote objects on a single bus. However, that bus
is limited to a single host. Buses cannot span hosts. In order to
implement a network-aware session management system using D-Bus, there
must necessarily be one of only two approaches.
The first approach is to have one bus on one host which all clients and
servers on all hosts connect to. This is a star topology which has
inherent weaknesses in terms of resilience. I believe the robustness
needed for a usable networked audio session cannot be provided using an
IPC mechanism with a single point of failure.
The second option is to have multiple buses; for each session client and
server to open multiple D-Bus connections. However, this introduces
another layer of addressing. In order for messages to be passed to a
remote object, not only must you know the address of the object but the
address of the bus to which it is connected. This completely undermines
the use of D-Bus. D-Bus is an IPC mechanism for communication with
remote objects that doesn't allow communication with remote objects on
remote hosts.
I have never understood why D-Bus was even considered for a network-wide
audio session system. It seems to me to be a case of all problems
looking like a nail when you have a hammer.
--
Bob Ham <rah(a)bash.sh>
9:17 a.m.
On Mon, Nov 23, 2009 at 12:26:06PM +0000, Bob Ham wrote:
I have never understood why D-Bus was even considered
for a network-wide
audio session system.
Just curious: I wonder who's using network audio. Much of Linux Audio
is related to this "network" stuff, but I've never seen it anywhere
else.
I've been in several studios with tons of expensive equipment, however,
all this stuff was packed in a single room, usually around a decent
mixing console or a computer with multichannel audio I/O (ProTools,
Tascam, RME, whatever).
On the digital side, all these sites had total recall, that is, they've
opened the mixing session in ProTools and all the plugins had their
settings right. That's the reason why you usually don't want analog
outboard equipment, but if need be, even that sometimes provided total
recall (SSL consoles, some newer FX gear, preamps and some on).
Nobody ever used a plugin on a remote system. Nobody ever used a remote
I/O.
I agree that in some larger broadcasting studio, routing between several
rooms might be an issue, but this is a rather large investment, probably
millions of Euros.
I've been in the studio where they'd recorded Sarah Connor. I've been in
the studio of Germany's children TV (Kika). Though they had serveral
rooms, they just exchanged sessions via file servers. So what's the
point of all this network audio?
Cheerio
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
9:36 a.m.
Adrian,
This is not limited to transferring audio over a network. This is also
about managing several workstation/distributed systems and external
gear. Audio streams are just one part of the picture.
I have never
understood why D-Bus was even considered for a network-wide
audio session system.
Just curious: I wonder who's using network audio. Much
of Linux Audio
is related to this "network" stuff, but I've never seen it anywhere
else. I've been in several studios with tons of
expensive equipment, however,
all this stuff was packed in a single room, usually around a decent
mixing console or a computer with multichannel audio I/O (ProTools,
Tascam, RME, whatever).
Big consoles already use GBit Ethernet to connect their bits and pieces,
and manufacturers are seeking solutions that allow interoperability.
Nobody ever used a plugin on a remote system. Nobody
ever used a remote
I/O.
You probably just haven't seen it yet :)
I am very much looking forward to connect my first PoE powered
microphone to the network and have it pop up in ardour.
Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net
6:17 p.m.
On Tue, Nov 24, 2009 at 12:17 AM, Adrian Knoth
<adi(a)drcomp.erfurt.thur.de> wrote:
On Mon, Nov 23, 2009 at 12:26:06PM +0000, Bob Ham
wrote:
Fantastic summary. I think it's a very tiny % of users who are
probably happy writing shell scripts or using weird stuff to get it to
work. I haven't quite worked out why getting actual normal, everyday
task to work well isn't more of a focus, but i suspect for most
developers it's less exciting. Which is totally fair. I'd be rather
impressed if external reverb programs (jconv) got started and setup
when I load my ardour session. I really don't care if it works between
machines.
Loki
I have never understood why D-Bus was even
considered for a network-wide
audio session system.
Just curious: I wonder who's using network audio. Much of Linux Audio
is related to this "network" stuff, but I've never seen it anywhere
else.
24 Nov
24 Nov
4:53 a.m.
On Tue, 2009-11-24 at 09:17 +1100, Loki Davison wrote:
On Tue, Nov 24, 2009 at 12:17 AM, Adrian Knoth
<adi(a)drcomp.erfurt.thur.de> wrote:
> On Mon, Nov 23, 2009 at 12:26:06PM +0000, Bob Ham wrote:
>
>> I have never understood why D-Bus was even considered for a network-wide
>> audio session system.
>
> Just curious: I wonder who's using network audio. Much of Linux Audio
> is related to this "network" stuff, but I've never seen it anywhere
> else.
I haven't quite worked out why getting actual
normal, everyday
task to work well isn't more of a focus
I would say local sessions are actually the primary focus. However,
local sessions are a subset of the functionality provided by network
sessions so while it may seem as though local sessions are being
ignored, that's not the case. In focussing on the wider problem with a
lower priority, we also solve the narrower problem with a higher
priority. This is a more efficient than solving the narrower problem
first and then solving the wider problem with another solution (which
would also then mean two solutions to the narrower problem.)
(As a side note, LASH was specifically written as a network session
system but the network-session part of it has never been implemented.
The change from a socket protocol to D-Bus undermined that
implementation.)
--
Bob Ham <rah(a)bash.sh>
11:53 a.m.
On Tue, Nov 24, 2009 at 08:53:02AM +0000, Bob Ham wrote:
local sessions are a subset of the functionality
provided by network
sessions
If you want to have network transparency inside the audio framework,
this perspective might be true.
But you could also ignore network on the audio level and just treat
remote components as special plugins in local sessions, plugins that use
socket() to connect to another host.
With this perspective, getting local things done becomes more important.
You immediately want total recall in your plugin API. LV2 anyone? ;)
The LV2-remote-controller-plugin could then (re-)connect to the remote
host and launch stuff there. This stuff doesn't even need to know
anything about jack. If it's data-triggered, you don't need a clock.
Just send data, let remote end process it, receive it back in your local
LV2 plugin and feed it into local jackd. As long as the whole process is
fast enough, everything is fine.
As already said, this is all a question of perspective. To me, having
jamin (mastering-EQ/comp/limiter) as a stand alone application is a
mistake. The mastering tool gets inserted in the project's master bus,
and every project has its own required jamin settings.
So when I open project A in Ardour, I want my mastering settings back.
LV2 could do the trick. When I open project B, a different setting might
be loaded.
From today's point of view, I would completely
ignore jamin (or any
other standalone jack application) and just use the LV2 version
of the
calf plugins. Total recall, easy to handle.
The average music producer isn't interested in a bunch of single
applications which he can wire up to something special. We need to get
work done, and we need to save/recall work. On OSX and Win32, this is
achieved by a decent editor (Cubase, ProTools, Logic) and tons of
plugins. We have ardour as the decent editor, and we have LV2 plugins,
perhaps not enough, yet.
I wonder why Linux Audio always reinvents the wheel. Just look at the
Win32 side: VST-Instruments, then put your favourite EQ on the outputs
and your mastering compressor somewhere else. Still modular, but
provides total recall.
All we need is a decent plugin API, and LV2 seems to be the choice.
Total recall then comes for free from this API. LASH? Don't know why I
would want to use it, all my plugins get controlled via LV2 from the
Ardour project.
Looks like there are different stakeholders involved. The music
producer's focus is the editor which gets extended by plugins. I'm such
a representative. Whatever I do, I want to do it from ardour, inside
ardour, saved in ardour. Ardour is the most important tool to me, and
plugins are the salt to spice things up.
Call me ignorant, but I don't have a single use case for netjack. I load
a bunch of wav files, make some overdub recordings with mostly one
(vocal) to twelve (drums) tracks simultaneously, trim regions, move
snippets around, apply some FX, apply some parameter automation and mix
it all together.
Even a full-blown rock production won't exceed 150 channels. I can also
afford to freeze channels if processing power gets low - I'm not
constantly changing the drum EQs. Once setup correctly, I don't touch
them anymore. So scalability isn't really an issue, here. I did 150
channels back in 2005 on a Quad-Xeon, it would surprise me if a modern
machine couldn't handle it.
And then, there seems to be people who'd constantly record the Vienna
symphony orchestra with its hundreds of tracks, with endless demand of
DSP processing power. Those who laugh at SSL, because their tiny 96
channel consoles cannot compete. I agree those people could benefit from
network scalability.
A third group is the signal processing coder/scientist who doesn't care
about anything already mentioned. He's happy to hack his DSP code into
some standalone app, manually/statically wire it via jack and that's it.
So when talking about Pro Audio, I mean the music producer and his
desire to have everything in his single editing software. Cubase,
Ardour, ProTools. You name it. Moderate IO capabilities (usually
somewhere between 16 and 64 channels), all available in a single box.
(ProTools-HD, RME MADI, RME Fireface).
So when Florian is talking about Pro Audio, he means large broadcasting
studios and linux-under-the-hood, where a 128 channel desk is magically
expanded by another 128 channel outboard I/O rack. Granted.
To draw the conclusion: in my world, things are already pretty good as
long as it's available as LV2. I haven't checked LV2 automation, yet,
and I'd like to see a ping-pong delay be able to query/obey the host
tempo. I'd like to see LV2 virtual instruments, that is, Linuxsampler
and Hydrogen.
Given that, I shouldn't really be participating in a thread called
"LADI" ;) But perhaps I gave some insights on the everyday work of a
music producer.
And never forget: Hans Zimmer was able to win a Grammy with Logic on a
single Apple laptop. ;)
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
12:05 p.m.
On Tue, Nov 24, 2009 at 10:53 AM, Adrian Knoth
<adi(a)drcomp.erfurt.thur.de> wrote:
I wonder why Linux Audio always reinvents the wheel.
Just look at the
Win32 side: VST-Instruments, then put your favourite EQ on the outputs
and your mastering compressor somewhere else. Still modular, but
provides total recall.
In this particular case, there are some very simple reasons. In fact,
I'm not even sure that I would call it "reinventing the wheel" as much
as "trying a different way of doing things than has been done before".
It happened this for one primary reason: there was (and to a limited
still is) no plugin API for linux that provides all that is desired by
users, hosts, and developers. It has also allowed the independent
development of useful tools in ways that even with a good plugin API
just doesn't really seem to happen on windows or OS X. Whether this is
a long term win for users is not so clear, but it has certainly made
developers' lives easier and more enjoyable, and linux tends to be
nothing if not developer driven ...
All we need is a decent plugin API, and LV2 seems to
be the choice.
It is looking increasingly like that, but there are still issues that
are not solved. You still will not be able to take any existing LV2
plugin and use its provided GUI in a host written in Qt. Solvable?
Almost certainly. Solution exists? Not at this time. Is it the right
idea for the future? I'd say probably, yes.
Call me ignorant, but I don't have a single use
case for netjack. I load
a bunch of wav files, make some overdub recordings with mostly one
(vocal) to twelve (drums) tracks simultaneously, trim regions, move
snippets around, apply some FX, apply some parameter automation and mix
it all together.
You mentioned Hans Zimmer. No single computer is powerful enough for a
lot of his soundtrack work, so he has a rack of systems running <some
sample playback engine>. He currently connects them all via audio
outputs, but there's no inherent reason why you couldn't just feed the
output of all those samplers back via a network connection.
And never forget: Hans Zimmer was able to win a Grammy
with Logic on a
single Apple laptop. ;)
Sure, but thats not how he works all the time :)
12:13 p.m.
On Tue, Nov 24, 2009 at 11:04 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Tue, Nov 24, 2009 at 10:53 AM, Adrian Knoth
<adi(a)drcomp.erfurt.thur.de> wrote:
and just to go a little deeper ... this in turn is caused in largest
part by the absence of a single "event loop" abstraction/API on
"bare"
unix systems. windows and OS X defined this relatively early in their
lifetimes (OS X from before birth, windows many, many versions back).
This means that there just isn't a clear path to adding "plugins" that
have to interact with event processing on a "bare" unix system. its
not that it can't be done, its just messy. what has happened instead
is that we continue to have different classes of applications dealing
with event-driven programming in very different ways:
* command line apps that don't interact with a mouse+graphical
display at all, just kbd stuff
* applications that use Xlib or some very old widget library that
is very close to the Xlib API in this regard
* applications that use Qt's event loop
* applications that use glib's event loop
* applications that use Qt using glib's event loop (!)
* applications using some other GUI toolkit's event loop
By contrast, on OS X, there is one event loop abstraction, and no
matter what program you use, if it uses event-driven programming (as
almost any user-driven app will do), it uses that single abstraction
at some layer. Thus, dynamically loading a "plugin" that has a GUI
that has to be a part of the overall app is easy - its obvious what
the "touching points" between the host and the plugin are.
This just isn't true on "bare" unix systems, where the insistence on
choice and flexibility and "developer driven" approaches to almost
everything have ruled out such a common core.
I wonder why Linux Audio always reinvents the
wheel. Just look at the
Win32 side: VST-Instruments, then put your favourite EQ on the outputs
and your mastering compressor somewhere else. Still modular, but
provides total recall.
In this particular case, there are some very simple reasons. In fact,
I'm not even sure that I would call it "reinventing the wheel" as much
as "trying a different way of doing things than has been done before".
It happened this for one primary reason: there was (and to a limited
still is) no plugin API for linux that provides all that is desired by
1:05 p.m.
On Tue, Nov 24, 2009 at 11:12:59AM -0500, Paul Davis wrote:
This just isn't true on "bare" unix
systems, where the insistence on
choice and flexibility and "developer driven" approaches to almost
everything have ruled out such a common core.
There are at least to separate aspects to this problem.
1. Almost all GUI toolkits mix up a few things that should
remain well separated:
- Getting X11 events,
- Handling X11 events,
- Creating a framework for messaging (events + data)
between threads, and if you are lucky a RT-safe API
for this or at least part of it,
- Creating the main loop (which if you separate out
the three above, becomes a trivial thing).
A well designed GUI toolkit should do only the first
two and be able to use whatever messaging system and
event loop.
2. Almost all toolkits try to be cross-platform. Which
means they will translate X11 events and other data
structures from/into their 'portable' format. That's
OK as if they would also provide these translations
as separate functions which then could be used at the
interface between a host and a plugin using different
toolkits.
The only reason I can see why most GUI toolkits do not
provide the required modularity is that it would complicate
their 5-line 'hello world in a window' demo programs, and
that is considered bad marketing. The fact that such trivial
demos are not representative of real-life applications, let
alone those that do include real-time audio processing, is
not a point, the user will discover that only much later when
he's already firmly hooked into a particular toolkit.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
1:55 p.m.
On Tue, Nov 24, 2009 at 12:02 PM, <fons(a)kokkinizita.net> wrote:
1. Almost all GUI toolkits mix up a few things that
should
remain well separated:
- Getting X11 events,
- Handling X11 events,
- Creating a framework for messaging (events + data)
between threads, and if you are lucky a RT-safe API
for this or at least part of it,
- Creating the main loop (which if you separate out
the three above, becomes a trivial thing).
Neither Qt nor GTK combine these. They are both built on an event loop
that has nothing to do with X11 events, or thread message dispatch.
A well designed GUI toolkit should do only the
first
two and be able to use whatever messaging system and
event loop.
I'm not quite sure what you mean, but my initial interpretation of
this suggests a goal that is a little absurd to me. The design of the
event loop is where the design of a GUI toolkit starts, because the
event loop needs to be able to handle things other than X11 (or Aqua
or GDI or whatever) events. If you use an event loop that doesn't do
this well, then you rule out a class of moderately complex
applications from being implemented in the most obvious way.
So, you start with a given event loop (hopefully a good one) and then
start adding other functionality on top, either as part of the toolkit
or as part of the application itself (via direct interactions with the
event loop API). How do you propose that the toolkit just be able to
switch to "any" event loop? When Trolltech modified Qt to be able to
(optionally) use the glib event loop, it was quite a bit of tricky
work. Perhaps you just mean that the specific event loop that is
chosen is not that relevant, rather than that it should be possible to
switch them?
2. Almost all toolkits try to be cross-platform.
Which
means they will translate X11 events and other data
structures from/into their 'portable' format. That's
OK as if they would also provide these translations
as separate functions which then could be used at the
interface between a host and a plugin using different
toolkits.
I don't think that would really address the issue. Take a look at what
Qt did to allow use of the glib event loop, and thus, by extension,
GTK widgets from within a Qt application. It has nothing to do with
event translation - you simply deliver the raw events from whatever
source (or even, just "i/o") into the relevant event loop handlers and
the translation happens in the same place that it would normally do
so. There is no reason to expose this to any higher level - the plugin
is not interested in doing explicit translation in its GUI - it just
wants a normal event stream delivered to it. What matters here is
being able to *register* the event handler with the event loop, and
this precisely where the lack of any common event loop abstraction on
Unix breaks down. GTK has a very abtract event handler that picks up
stuff from a communication endpoint that (might) happen to be
connected to an X server. But the API it uses for this (provided by
the glib event loop) is different than the one it would have to use if
it wanted to integrate with the Qt "native" event loop. As a result,
you either have to have N versions of the low level integration
handlers (N == number of event loop APIs supported) or you need a
common event loop API. Unix has never had the latter, and most toolkit
developers are not planning to see their upper layers running on a
different event loop core. What Trolltech did with Qt + glib was quite
remarkable, really. However, it still only makes N=2. If you wanted to
use Qt widgets in an application that used on a self-made X11 event
loop, it wouldn't work.
The only reason I can see why most GUI toolkits do
not
provide the required modularity is that it would complicate
their 5-line 'hello world in a window' demo programs, and
that is considered bad marketing.
I think this is ridiculous. 99% or more of the people developing
applications with GUI toolkits are not interested in the kind of
modularity that you describe. It would bring them no benefits, and
complicates the lives of toolkit developers and possibly app
developers too. Why should toolkit developers add complexity to their
work to satisfy a tiny number of developers who want to be able to do
clever things?
OS X put the run loop abstraction (CFRunLoop) into the lowest layer of
their "application stack" (i.e. the part of OS X that isn't Unix). To
me, *that's* the right kind of "modularity by commonality" - you could
build a huge variety of different toolkits and GUIs around this single
abstraction (and indeed, their X11 server does just that, alongside
the Aqua display server). But on Unix, everybody's been pushing for
"modularity by decomposition" for so long that the idea that you'd
have a common core for any application that is event-driven rather
than data driven just seems ... well, its disparaged as
"unnecessary".
The fact that such trivial
demos are not representative of real-life applications, let
alone those that do include real-time audio processing, is
not a point, the user will discover that only much later when
he's already firmly hooked into a particular toolkit.
The only that an app with an RT part and a GUI part really needs is a
way of delivering messages from the RT part to the GUI part in an RT
safe way. This doesn't require the cooperation of the toolkit at all,
so what would the toolkit matter?
There are lots of different reasons to prefer one toolkit over
another, but the presence of RT code in its own thread within the app
has never seemed to be one of them, for me.
3:28 p.m.
On Tue, Nov 24, 2009 at 12:55:39PM -0500, Paul Davis wrote:
What do you mean by 'raw events', or a 'normal event stream' ?
Both toolkits would normally represent X11 events in different
ways (GTK seems to remain close to the 'raw' X11 form, don't
know about Qt). They would also represent basic objects (such as
'a window') in different ways. If an event is dispatched in its
GTK form but in the end has to be handled by a Qt object then
some translation will be required somewhere. And indeed the plugin
will not want to do this itself.
What you write seems to suggest that both the GTK and Qt
dispatching mechanism exist at the same time, that they don't
really interface to each other, but that raw X events get
handled either by the one or the other. This will work if
they can somehow work out who should handle what without
tripping on things from the other one. All raw X events have
a destination window ID, and for most cases testing on that
would be all that's required. But again this has nothing do
to with how the event loop (in my sense) is organised.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
I'm not quite sure what you mean, but my initial
interpretation of
this suggests a goal that is a little absurd to me. The design of the
event loop is where the design of a GUI toolkit starts, because the
event loop needs to be able to handle things other than X11 (or Aqua
or GDI or whatever) events. If you use an event loop that doesn't do
this well, then you rule out a class of moderately complex
applications from being implemented in the most obvious way.
Seems we are saying the same thing in different terminology, and
using different meanings of the same term such as 'even loop'.
An event loop (as I use the term) is just something of the
form
while (running)
{
E = wait_for_events();
process_event(E);
}
which in a typical multi-threaded and event-driven program
you would find in some form in each thread.
Unless you like using lots of mutexes, it is convenient to
handle most events that have an impact on the global state
of a app in a single thread. This could be mix of X11 events,
notifications from you RT-audio thread, messages from network
threads, or those doing non-RT calculations, etc.
This means that wait_for_events() has to wait for a number
of different things at the same time. One traditional way
to do this is using poll() or select(() on a set of fds.
Or if most of the event sources are threads it could be
done using a inter-thread message service not based on fds
but directly on low-level threading primitives such as
semaphores or condition variables (this is what clxthreads
does).
In process_event() the first selection would be on event
origin. Messages from you other threads for example would
get handled by whatever code you provide for that, while
X11 events would be handled by code provided by the GUI
toolset, delivering them somehow to the objects that need
them.
From what you write I understand that you call this
handling
of X11 events 'the event loop' of a the toolset, which is of
course something quite different than what I understand by
this term and try to explain here. What you call 'the event
loop' (in the discussion about linking GTK and Qt) is not
the loop - it is the dispatching and handling of X11 events.
I agree fully that a developer normally does not wants to
meddle with this - he's using a GUI toolset to take that
work away from him.
The problem I pointed out exists when the 'real' loop (in
the C, C++ sense), in other words the while() thing above,
is completely absorbed into a GUI toolkit. A toolkit should
probably provide this as a convenience, but the user should
also have the option to open up this code and mix in his own
events in any way he prefers. He should e.g. not be forced to
translate all his event/messages sources into e.g. a poll()
based framework just because the toolkit uses a fd to wait
on X11.
The loop as written above is a multiplexer (the wait_for_events()),
and a demultiplexer (the process_event()). The GUI toolkit is on
an input to the first and on an output of the second. The only
thing that should matter is that the link between these two
points exists, not how it is implemented.
2. Almost all
toolkits try to be cross-platform. Which
means they will translate X11 events and other data
structures from/into their 'portable' format. That's
OK as if they would also provide these translations
as separate functions which then could be used at the
interface between a host and a plugin using different
toolkits.
I don't think that would really address the issue. Take a look at what
Qt did to allow use of the glib event loop, and thus, by extension,
GTK widgets from within a Qt application. It has nothing to do with
event translation - you simply deliver the raw events from whatever
source (or even, just "i/o") into the relevant event loop handlers and
the translation happens in the same place that it would normally do
so. There is no reason to expose this to any higher level - the plugin
is not interested in doing explicit translation in its GUI - it just
wants a normal event stream delivered to it.
3:46 p.m.
On Tue, Nov 24, 2009 at 2:24 PM, <fons(a)kokkinizita.net> wrote:
An event loop (as I use the term) is just something of
the
form
while (running)
{
E = wait_for_events();
process_event(E);
}
Sure.
In process_event() the first selection would be on
event
origin. Messages from you other threads for example would
get handled by whatever code you provide for that, while
X11 events would be handled by code provided by the GUI
toolset, delivering them somehow to the objects that need
them.
From what you write I understand that you call this handling
of X11 events 'the event loop' of a the toolset, which is of
course something quite different than what I understand by
this term and try to explain here.
not at all. what i mean by the event loop is exactly the same as you.
but any general purpose event loop needs way to add and remove event
sources, which can include additional file descriptors, timeouts, the
concept of "idle" and other more esoteric things. so at the core of
any GTK application, for example, is the extremely general purpose
glib event loop. the connection to the X11 display server is just one
source of events that it handles (though clearly, for a GTK app, an
important one).
The problem I pointed out exists when the
'real' loop (in
the C, C++ sense), in other words the while() thing above,
is completely absorbed into a GUI toolkit.
you can view it that way around if you wish. but i think that its
equally accurate to say that things start with a particular event loop
(in the C, C++ sense) and then the toolkit is built around it.
He should e.g. not be forced to
translate all his event/messages sources into e.g. a poll()
based framework just because the toolkit uses a fd to wait
on X11.
the glib event loop has completely abstract notions of what an event
source is. an event source simply has a few simply functions like
"prepare", "ready" and "dispatch".
The loop as written above is a multiplexer (the
wait_for_events()),
and a demultiplexer (the process_event()). The GUI toolkit is on
an input to the first and on an output of the second. The only
thing that should matter is that the link between these two
points exists, not how it is implemented.
the GTK (and now Qt) toolkits simply add handlers for events that come
from the "X11 event source" that they added early in the program's
life. the event loop can be handling other entirely different event
sources using entirely different code - but it is all now centralized
by the single glib event loop. the event loop itself doesn't really
care about what the event types are, or what handles them.
What do you mean by 'raw events', or a
'normal event stream' ?
raw events: whatever actually happened somewhere in the computer to
make an event source believe that a new event was ready. could be an
X11 event, could be a byte arriving on an arbitrary byte-oriented
communication endpoint, the creation or modification of a file, etc.
etc. etc.
"normal event stream" : whatever the GUI toolkit passes around to widgets.
What you write seems to suggest that both the GTK and
Qt
dispatching mechanism exist at the same time, that they don't
really interface to each other, but that raw X events get
handled either by the one or the other.
Thats more or less correct, yes.
This will work if
they can somehow work out who should handle what without
tripping on things from the other one.
And they can, by using a variety of mechanisms, none of which are
particularly clean.
All raw X events have
a destination window ID, and for most cases testing on that
would be all that's required.
for X events, yes. But the event loop handles things other than X events.
But again this has nothing do
to with how the event loop (in my sense) is organised.
Agreed. What I consider central is the idea of set of event sources,
and event loop and handlers for events that are injected into the
loop. There is no common framework for this on Unix, there never has
been and as long design policy is made by developers who value choice
and flexibility over single frameworks that enforce consistency, there
almost certainly never will be. Hell, on Unix you can't even wait for
file I/O and/or a signal in the same thread.
Again, contrast this to the situation on OS X where time and again,
when I am wondering just how you are supposed to integrate a
particular kind of event-driven programming into some code, it all
ultimately comes back to a CFRunLoop (which conceptually is not far
from being a thread, although its not).
The unix programming model is awesome for data driven programming. It
just hasn't ever stepped up to provide these kinds of abstractions for
event driven programming.
--p
4:19 p.m.
On Tue, Nov 24, 2009 at 7:46 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Tue, Nov 24, 2009 at 2:24 PM,
<fons(a)kokkinizita.net> wrote:
At the event loop level, neither GTK nor Qt is a GUI toolkit. That
is, GTK's event loop is found in glib rather than GTK itself; Qt's
event loop (whether native or using glib) is also below the GUI
toolkit level, available for use by event-driven applications that
neither use X11 nor link against any of Qt's GUI code.
Chris
The problem I pointed out exists when the
'real' loop (in
the C, C++ sense), in other words the while() thing above,
is completely absorbed into a GUI toolkit.
you can view it that way around if you wish. but i think that its
equally accurate to say that things start with a particular event loop
(in the C, C++ sense) and then the toolkit is built around it.
5:41 p.m.
On Tue, Nov 24, 2009 at 02:46:44PM -0500, Paul Davis wrote:
Agreed. What I consider central is the idea of set of
event sources,
and event loop and handlers for events that are injected into the
loop. There is no common framework for this on Unix, there never has
been and as long design policy is made by developers who value choice
and flexibility over single frameworks that enforce consistency, there
almost certainly never will be. Hell, on Unix you can't even wait for
file I/O and/or a signal in the same thread.
Hehe... It has been for at least 15 years my privately held but
otherwise not so humble ipinion that the 'ideal' interface to
everything Unix would be asynchronous and event driven. For
example if you write to a file, you issue the command to do so
and some time later the system will inform you that it's done.
And of course you can build such things on top of the standard
read/write stuff, and we both are probably doing it. But it's a
bit sad having to do that if you suspect that on the other side
someone has done the inverse to provide the 'standard' synchronous
interface...
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
1:09 p.m.
On Tue, 24 Nov 2009 11:04:59 -0500, Paul Davis
<paul(a)linuxaudiosystems.com>
wrote:
On Tue, Nov 24, 2009 at 10:53 AM, Adrian Knoth
<lame-interrupt>maybe not thee solution, but erm... qtractor (svn trunk)
already does it for the lv2 external uis (only one existing attow, Nedko's
4band filter?
the problem here seems to be re.hosting lv2 gtk ui extension based
plugins.
i'm too lazy to tell whether it's feasible under qt, maybe not, maybe
outright wrong :) why not have it all as external ui? Nedko has proved
it's doable. why is there a gtk ui extension in the first place, for
crying out loud? why call it "extension" ? seems more like an
"occlusion"
:))
nevermind
plugin guis should be freely written using gtk or any other toolkit.
requiring the host to be of the very same flesh-and-blood is what i find
questionable, to say the least ;)
</lame-interrupt>
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
All we need is a decent plugin API, and LV2 seems
to be the choice.
It is looking increasingly like that, but there are still issues that
are not solved. You still will not be able to take any existing LV2
plugin and use its provided GUI in a host written in Qt. Solvable?
Almost certainly. Solution exists? Not at this time. Is it the right
idea for the future? I'd say probably, yes.
6:11 p.m.
On Tue, 2009-11-24 at 16:53 +0100, Adrian Knoth wrote:
On Tue, Nov 24, 2009 at 08:53:02AM +0000, Bob Ham
wrote:
I do want that.
--
Bob Ham <rah(a)bash.sh>
for (;;) { ++pancakes; }
local sessions are a subset of the functionality
provided by network
sessions
If you want to have network transparency inside the audio framework,
this perspective might be true. 
19 Dec
19 Dec
4:15 p.m.
Bob Ham wrote:
On Tue, 2009-11-24 at 16:53 +0100, Adrian Knoth
wrote:
I have read this thread with interest, all though I lack the
knowledge
to have an opinion about the technical choices.
To me it seems that there is some kind of agreement that dbus is not the
most ideal thing to use.
Also if I understand it well, Nedko has chosen dbus because it's the
best solution which is available now. Plus he really needs a session
handler... so he's taking some kind of practical approach here.
Roughly I think I can make three groups after reading this thread:
1) The 'one app with plugins' group. People who are focusing on one big
app, extended by plugins (Ardour, Qtractor, LV2/DSSI). This group
doesn't have much interest in a session handler.
2) The people who likes to work with different, small Jack applications
(ams, aeolus, epichord etc.). These people are interested in a session
handler. But they think dbus is the wrong approach, it is to limited for
them, or it is not the right thing for the Linux platform in their opinion.
3) Group 3 is the same as group 2, BUT they have chosen dbus as
solution. It's the LADI group.
I don't think we can expect the members of group 1 to build a session
handler for us. They are not interested enough in a session handler.
We can expect that group 3 will build a session handler for us. LADI is
in active development and they already made some progress.
Now I'm wondering, what can we expect from group 2?
\r
On Tue, Nov 24, 2009 at 08:53:02AM +0000, Bob Ham
wrote:
I do want that. local sessions are a subset of the functionality
provided by network
sessions
If you want to have network transparency inside the audio framework,
this perspective might be true.
6:23 p.m.
On Sat, Dec 19, 2009 at 09:15:22PM +0100, rosea grammostola wrote:
1) The 'one app with plugins' group. People
who are focusing on one big
app, extended by plugins (Ardour, Qtractor, LV2/DSSI). This group
doesn't have much interest in a session handler.
And quite probably the authors of these apps are not very
motivated to make them compatible with session handlers.
2) The people who likes to work with different, small
Jack applications
(ams, aeolus, epichord etc.). These people are interested in a session
handler. But they think dbus is the wrong approach, it is to limited for
them, or it is not the right thing for the Linux platform in their opinion.
'Like to work' may not be the correct interpretation. See (4)
3) Group 3 is the same as group 2, BUT they have
chosen dbus as
solution. It's the LADI group.
4. And there's group 4, or maybe that group is just me.
If there are others I'd like to know. For group 4:
* Sessions are multi-host since there is no other way.
In most cases all but one of the machines involved will
be headless, and whatever is supposed to happen there
is by definition remote controlled instead of being
launched from a local desktop.
* There are no usable 'single app with plugins' solutions
since none of these comes close to what would be required,
in particular w.r.t. the multi-host situation, and also
because all of these apps silently assume a human user
watching them and being able to take corrective action
if necessary. Anything that could pop up an error dialog
and refuse to proceed until someone reacts is completely
useless in such systems.
* Any interaction between components of such a system is
supposed to use networked communication from the start.
Dual-layer solutions based on some local IPC system plus
some additional layer that would connect them via a network
are just an unnecessary complication, and probably one that
would not provide the right semantics, since the design would
be based on the single host assumption in blissfull ignorance
of what it takes to make things work together via a network.
* Given the potential complexity of a networked system, loading
a 'session' would in general not mean a complete teardown and
buildup of all apps and their connections, but could just mean
loading a different configuration in a single app, without even
any others being aware of this.
People using such systems are *very* motivated to create
some form session handling, since controlling this sort of
thing manually is a real PITA, in particular if you have
to do it a hundred times a day, or if you have to provide
an interface usable by non-experts. Which is why I have
been working on this. And given the quite hostile reactions
shown in recent threads, and the probably minute potential
user base, the chances that the results will be made public
are rather small.
Ciao,
--
FA
8:48 p.m.
Hey guys!
I am not a developer, I am a musician who has decided to try to switch to
Linux.
I am not sure how many times this has been discussed and I have signed up to
this list
being interested in audio linux development, specifically lv2 plugins.
But I can say that in three months of very active work with audio, learning
new concepts,
trying out Ardour, Qtractor, Zyn synth, Patchage, Kluppe, Sooperlooper,
JackRack
and LMMS, I can say that although modular approach has its charm and even
use,
for most of the cases it is very awkward and very difficult to set up and
any potential solution
bumps into many problems since any session management system will have to
work with different
apps and it means more chances for errors - excuse me if I am not correct.
On the other hand, an integrated environment, while opposed by many linux
users and programmers,
gives much more control to the musician both in live performance and studio
work.
I must say that I have used Ardour, Kluppe and Jack Rack and Patchage in
live performance and it was great,
but I had to play only one tune. To set up the tune I had to open 4
instances of Kluppe, one Jack Rack,, open Ardour,
load session, load Patchage, disconnect unnecessary connections, connect
Ardour to Jack Rack (for some reason
it does not save connections to Jack Rack) and then connect all of that to a
midi keyboard. This usually takes around
a minute of time.
If I had to play another tune, it would be a disaster, since I would have to
close lots of stuff and reopen, not to mention that
with a complex setup it is difficult to forget.
As for studio work, setting up a whole big number of apps to work on a tune
is very difficult. It also seems to bring up a technical
problem - please sorry again if my technical conclusions are wrong - but
with an integrated environment it seems it is easier to do
memory management. With several apps Jack can just throw an app out without
warning and it is very frustrating and time consuming.
So, as a musician, I think linux audio developers have to focus on
1. integrated audio environment
2. sotware synthesizers/effects (LV2)
LMMS is an integrated environment and having Zyn inside it is great. LMMS is
very promising.
But what isn't there are plugins and synthesizers. As an ambient composer I
simply lack the tools
I need,
Hope any of this was useful.
Louigi Verona.
On Sun, Dec 20, 2009 at 1:19 AM, <fons(a)kokkinizita.net> wrote:
On Sat, Dec 19, 2009 at 09:15:22PM +0100, rosea
grammostola wrote:
1) The 'one app with plugins' group.
People who are focusing on one big
app, extended by plugins (Ardour, Qtractor, LV2/DSSI). This group
doesn't have much interest in a session handler.
And quite probably the authors of these apps are not very
motivated to make them compatible with session handlers.
2) The people who likes to work with different,
small Jack applications
(ams, aeolus, epichord etc.). These people are interested in a session
handler. But they think dbus is the wrong approach, it is to limited for
them, or it is not the right thing for the Linux platform in their
opinion.
'Like to work' may not be the correct interpretation. See (4)
3) Group 3 is the same as group 2, BUT they have
chosen dbus as
solution. It's the LADI group.
4. And there's group 4, or maybe that group is just me.
If there are others I'd like to know. For group 4:
* Sessions are multi-host since there is no other way.
In most cases all but one of the machines involved will
be headless, and whatever is supposed to happen there
is by definition remote controlled instead of being
launched from a local desktop.
* There are no usable 'single app with plugins' solutions
since none of these comes close to what would be required,
in particular w.r.t. the multi-host situation, and also
because all of these apps silently assume a human user
watching them and being able to take corrective action
if necessary. Anything that could pop up an error dialog
and refuse to proceed until someone reacts is completely
useless in such systems.
* Any interaction between components of such a system is
supposed to use networked communication from the start.
Dual-layer solutions based on some local IPC system plus
some additional layer that would connect them via a network
are just an unnecessary complication, and probably one that
would not provide the right semantics, since the design would
be based on the single host assumption in blissfull ignorance
of what it takes to make things work together via a network.
* Given the potential complexity of a networked system, loading
a 'session' would in general not mean a complete teardown and
buildup of all apps and their connections, but could just mean
loading a different configuration in a single app, without even
any others being aware of this.
People using such systems are *very* motivated to create
some form session handling, since controlling this sort of
thing manually is a real PITA, in particular if you have
to do it a hundred times a day, or if you have to provide
an interface usable by non-experts. Which is why I have
been working on this. And given the quite hostile reactions
shown in recent threads, and the probably minute potential
user base, the chances that the results will be made public
are rather small.
Ciao,
--
FA
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
9:19 p.m.
On 12/20/2009 11:48 AM, Louigi Verona wrote:
So, as a musician, I think linux audio developers have to focus on
1. integrated audio environment
2. sotware synthesizers/effects (LV2)
I prefer to work with a modular environment and want to see session
management working properly. I would be very disappointed if no further
work was done on session management.
I am looking forward to the progress that will be made over the next
couple of years on that front.
Patrick Shirkey
Boost Hardware Ltd
LMMS is an integrated environment and having Zyn
inside it is great.
LMMS is very promising.
But what isn't there are plugins and synthesizers. As an ambient
composer I simply lack the tools
I need,
Hope any of this was useful.
Louigi Verona.
On Sun, Dec 20, 2009 at 1:19 AM, <fons(a)kokkinizita.net
<mailto:fons@kokkinizita.net>> wrote:
On Sat, Dec 19, 2009 at 09:15:22PM +0100, rosea grammostola wrote:
1) The 'one app with plugins' group.
People who are focusing on
one big
app, extended by plugins (Ardour, Qtractor,
LV2/DSSI). This group
doesn't have much interest in a session handler.
And quite probably the authors of these apps are not very
motivated to make them compatible with session handlers.
2) The people who likes to work with different,
small Jack
applications
(ams, aeolus, epichord etc.). These people are
interested in a
session
handler. But they think dbus is the wrong
approach, it is to
limited for
them, or it is not the right thing for the Linux
platform in
their opinion.
'Like to work' may not be the correct interpretation. See (4)
3) Group 3 is the same as group 2, BUT they have
chosen dbus as
solution. It's the LADI group.
4. And there's group 4, or maybe that group is just me.
If there are others I'd like to know. For group 4:
* Sessions are multi-host since there is no other way.
In most cases all but one of the machines involved will
be headless, and whatever is supposed to happen there
is by definition remote controlled instead of being
launched from a local desktop.
* There are no usable 'single app with plugins' solutions
since none of these comes close to what would be required,
in particular w.r.t. the multi-host situation, and also
because all of these apps silently assume a human user
watching them and being able to take corrective action
if necessary. Anything that could pop up an error dialog
and refuse to proceed until someone reacts is completely
useless in such systems.
* Any interaction between components of such a system is
supposed to use networked communication from the start.
Dual-layer solutions based on some local IPC system plus
some additional layer that would connect them via a network
are just an unnecessary complication, and probably one that
would not provide the right semantics, since the design would
be based on the single host assumption in blissfull ignorance
of what it takes to make things work together via a network.
* Given the potential complexity of a networked system, loading
a 'session' would in general not mean a complete teardown and
buildup of all apps and their connections, but could just mean
loading a different configuration in a single app, without even
any others being aware of this.
People using such systems are *very* motivated to create
some form session handling, since controlling this sort of
thing manually is a real PITA, in particular if you have
to do it a hundred times a day, or if you have to provide
an interface usable by non-experts. Which is why I have
been working on this. And given the quite hostile reactions
shown in recent threads, and the probably minute potential
user base, the chances that the results will be made public
are rather small.
Ciao,
--
FA
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
<mailto:Linux-audio-dev@lists.linuxaudio.org>
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
9:32 p.m.
Patrick Shirkey wrote:
On 12/20/2009 11:48 AM, Louigi Verona wrote:
Is there any out of the box audio distro using JACK with dbus support
out of the box? This isn't a rhetorical question, but serious.
Is LADI included out of the box to any audio distro?
At the moment for me it's easier to use an integrated environment. Btw.
I'm also using a non-audio-distro. Setting up real-time audio was easy
to do, but now "normal" GNOME multimedia applications don't work any more.
So, as a musician, I think linux audio developers have to focus on
1. integrated audio environment
2. sotware synthesizers/effects (LV2)
I prefer to work with a modular environment and want to see session
management working properly. I would be very disappointed if no
further work was done on session management.
I am looking forward to the progress that will be made over the next
couple of years on that front.
20 Dec
20 Dec
5:33 a.m.
Modular environment is great, but integrated environment seems to be more
effective. I mean, imho it is not
a matter of preference and I am not saying no work should be done on session
management. I am just saying that so
far my observations show me that integrated environment has too many
benefits over modular environment.
I am relatively new to linux audio, so I would be grateful if you would
explain to me the benefits of modular environment.
So far I've not been able to see any special benefits of such an
environment. I mean, it's curious, but it also means lots of open
windows, it means the project being dependent on many-many apps. Somehow to
me it means working on the problem
from the outside. All the inter-application management seems to be a
difficult problematic and even in the long run is doomed
to have many problems due to many apps involved. A dev releases new version
of his app that has a bug and session
handler cannot connect it - and boom!
But I also have a suggestion.
Is it possible to create an integrated environment based on modules? That
is, an app which would have "plugins", but not plugins in a
sense like effects and synths only, but plugins as elements of the sequencer
itself, like piano roll, song editor, such stuff. A person opens this app
and starts adding elements he needs to it. For a particular project he might
not need a piano roll, he might need only audio track arranger,
for another projects he takes an audio track arranger and also adds a piano
roll.
Modules of such an app could be very different, like a loop player like
Kluppe, etc - all the apps linux audio has to this day but remade as modules
to an integrated sequencer.
What do you think?
Louigi Verona.
On Sun, Dec 20, 2009 at 4:18 AM, Patrick Shirkey <pshirkey(a)boosthardware.com
wrote:
>
> On 12/20/2009 11:48 AM, Louigi Verona wrote:
>
>
> So, as a musician, I think linux audio developers have to focus on
>
> 1. integrated audio environment
> 2. sotware synthesizers/effects (LV2)
>
>
>
>
> I prefer to work with a modular environment and want to see session
> management working properly. I would be very disappointed if no further work
> was done on session management.
>
> I am looking forward to the progress that will be made over the next couple
> of years on that front.
>
>
>
>
>
>
> Patrick Shirkey
> Boost Hardware Ltd
>
>
>
>
>
>
>
>
> LMMS is an integrated environment and having Zyn inside it is great. LMMS
> is very promising.
> But what isn't there are plugins and synthesizers. As an ambient composer I
> simply lack the tools
> I need,
>
> Hope any of this was useful.
>
> Louigi Verona.
>
>
>
>
>
>
> On Sun, Dec 20, 2009 at 1:19 AM, <fons(a)kokkinizita.net wrote:
>
>> On Sat, Dec 19, 2009 at 09:15:22PM +0100, rosea grammostola wrote:
>>
>> > 1) The 'one app with plugins' group. People who are focusing on one
big
>> > app, extended by plugins (Ardour, Qtractor, LV2/DSSI). This group
>> > doesn't have much interest in a session handler.
>>
>> And quite probably the authors of these apps are not very
>> motivated to make them compatible with session handlers.
>>
>> > 2) The people who likes to work with different, small Jack applications
>> > (ams, aeolus, epichord etc.). These people are interested in a session
>> > handler. But they think dbus is the wrong approach, it is to limited for
>> > them, or it is not the right thing for the Linux platform in their
>> opinion.
>>
>> 'Like to work' may not be the correct interpretation. See (4)
>>
>> > 3) Group 3 is the same as group 2, BUT they have chosen dbus as
>> > solution. It's the LADI group.
>>
>> 4. And there's group 4, or maybe that group is just me.
>> If there are others I'd like to know. For group 4:
>>
>> * Sessions are multi-host since there is no other way.
>> In most cases all but one of the machines involved will
>> be headless, and whatever is supposed to happen there
>> is by definition remote controlled instead of being
>> launched from a local desktop.
>>
>> * There are no usable 'single app with plugins' solutions
>> since none of these comes close to what would be required,
>> in particular w.r.t. the multi-host situation, and also
>> because all of these apps silently assume a human user
>> watching them and being able to take corrective action
>> if necessary. Anything that could pop up an error dialog
>> and refuse to proceed until someone reacts is completely
>> useless in such systems.
>>
>> * Any interaction between components of such a system is
>> supposed to use networked communication from the start.
>> Dual-layer solutions based on some local IPC system plus
>> some additional layer that would connect them via a network
>> are just an unnecessary complication, and probably one that
>> would not provide the right semantics, since the design would
>> be based on the single host assumption in blissfull ignorance
>> of what it takes to make things work together via a network.
>>
>> * Given the potential complexity of a networked system, loading
>> a 'session' would in general not mean a complete teardown and
>> buildup of all apps and their connections, but could just mean
>> loading a different configuration in a single app, without even
>> any others being aware of this.
>>
>> People using such systems are *very* motivated to create
>> some form session handling, since controlling this sort of
>> thing manually is a real PITA, in particular if you have
>> to do it a hundred times a day, or if you have to provide
>> an interface usable by non-experts. Which is why I have
>> been working on this. And given the quite hostile reactions
>> shown in recent threads, and the probably minute potential
>> user base, the chances that the results will be made public
>> are rather small.
>>
>> Ciao,
>>
>> --
>> FA
>>
>> _______________________________________________
>> Linux-audio-dev mailing list
>> Linux-audio-dev(a)lists.linuxaudio.org
>> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>>
>
>
> _______________________________________________
> Linux-audio-dev mailing
listLinux-audio-dev@lists.linuxaudio.orghttp://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
>
6:31 a.m.
Louigi Verona <louigi.verona(a)gmail.com> writes:
I am relatively new to linux audio, so I would be
grateful if you would
explain to me the benefits of modular environment.
Assuming that you mean modular environment in the sense of LADI as
opposed to the sense of plugins (LV2) in a single host, one of the
advantages is that with LV2 plugins, bad plugin will bring your whole
app down. With multiple JACK apps approach and a session handled, only
single JACK "plugin" crashes. You can still save the work, and even
restart (manually or automatically) the crashed JACK plugin.
This is not the case with some all-in-one applications for Windows. They
use SEH (Structured Exception Handling) to display warning to user and
recommend him to save his work and restsart the app. SEH patent expires
in 2016. Since Windows XP there seems to be something new, VEH (Vectored
Exception Handling) that is also patented, expires in 2023.
I'm not aware of exception handling alternative for Linux.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
6:32 a.m.
Ah! So part of it is a patent issue?
On Sun, Dec 20, 2009 at 1:29 PM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
Louigi Verona <louigi.verona(a)gmail.com> writes:
I am relatively new to linux audio, so I would be
grateful if you would
explain to me the benefits of modular environment.
Assuming that you mean modular environment in the sense of LADI as
opposed to the sense of plugins (LV2) in a single host, one of the
advantages is that with LV2 plugins, bad plugin will bring your whole
app down. With multiple JACK apps approach and a session handled, only
single JACK "plugin" crashes. You can still save the work, and even
restart (manually or automatically) the crashed JACK plugin.
This is not the case with some all-in-one applications for Windows. They
use SEH (Structured Exception Handling) to display warning to user and
recommend him to save his work and restsart the app. SEH patent expires
in 2016. Since Windows XP there seems to be something new, VEH (Vectored
Exception Handling) that is also patented, expires in 2023.
I'm not aware of exception handling alternative for Linux.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
7:27 a.m.
I'd have to disagree with this. A modular environment makes for better
use of resource.
Plugins occupy the same memory allocation as the app, and the same is
true in win and mac. For all the perceived benefits of a "one stop
shop" as far as workflow goes, there are drawbacks. It's noted that
some users are ok with freezing tracks to best manage limited
resources, but other's aren't. I spent a large chunk of my working
life bouncing tracks on a constant basis, and unlike the linux
environment, i didn't have a choice, no matter the strength of
hardware i was using. It wasn't that long ago that if you wanted to
run a full orchestral template, plus plugins, you needed a cluster of
boxes, or a CRAY. I had a cluster of 5 gig boxes PRECISELY because of
the limitations of allocated app memory space, and i was still
bouncing tracks, if i wanted to run plugins as well.
The modular environment offers a way out of this workflow killer
(imho), and with the massive advantage of using jack, with its
unlimited port structure, plugins no longer need to reside inside an
app, but can be effectively hosted and ported to and from, outside the
app, and in their own memory allocation.
So i would vote against a push to put everything in one app. Quite the
contrary, based on experience, and the many many frustrating hours i
put into bouncing tracks, and handling a pandora's box worth of
workarounds, just to get the client's material done.
Again, i perceive this drive to centralise everything into one "super"
app, as an intent to be "just like" win and mac, including the obvious
and frustrating workflow limitations, along with any
perceived.....advantages, when a little applied imagination on the
part of users would reveal a much greater use of resource, and
workflow satisfaction, in an unlimited workstation, where only the
strength of the hardware, and the corresponding depth of the user's
wallet, applies.
There's also the perception that having "lots" of plugins inside an
app is somehow.........cool, and "the best way to work". It isn't,
beyond the first hour of use. Managing lots of plugins is as much, and
possibly more of a time killer, than setting up a multiapp template in
a linux audio environment. Been there, done that, and it's no
sinecure.
So no to centralisation, and yes to developing dedicated external lv2
plugin hosting more effectively. (Multi hosts, for example.) The power
of JACK should not be underestimated in this regard, and the real work
lies (imho) in managing software resource, i.e. sessions, port
connections, save states across clusters, etc... This would focus any
technical lv2 expectations in one spot, and remove the need to hack
sequencers constantly, as the lv2 protocol develops further.
As for multiple app management, you might be missing the boat a bit
here as well. Unlike Win and Mac, with the commerically imposed
limitations, linux gives you more than one to lead an elephant across
a pond of custard.
Outside of the mainstream distros, who are generally more
commerical-like in their presentation, there's a wealth of choice for
users to really build a great system, unique to requirements. I run
Gentoo, and the fluxbox window manager, with no icons, and driven by
keybindings. Where an app can run without a GUI, then i do that from a
script, or a terminal, saving resources for something else. Linux is
extremely openended in that regard, and with a bit of effort of the
part of a user, he or she can see a direct relationship between effort
in/reward out. So the resources that are chewed up by endless GUI's,
now go where they belong, into running the DAW, for practical use. (I
have in a normal template 7 apps running, of which only 2 are GUI's
for constant use.)
Also worth noting here that apps like Jconvolver, for instance, can be
run as a standalone single instance, with multiple ins and outs, each
one of which can be configured in a file. 1 impulse for an entire
project, with each in/out configurable.
There's 65 plugins taken care of right there, in one small cli app............
So Louigi, i disagree with you, and think it IS a personal preference,
and should not be an imposed workflow.
Why walk with the rest of the turkeys, when you can soar like an eagle?
Alex.
On Sun, Dec 20, 2009 at 9:33 AM, Louigi Verona <louigi.verona(a)gmail.com> wrote:
Modular environment is great, but integrated
environment seems to be more
effective. I mean, imho it is not
a matter of preference and I am not saying no work should be done on session
management. I am just saying that so
far my observations show me that integrated environment has too many
benefits over modular environment.
I am relatively new to linux audio, so I would be grateful if you would
explain to me the benefits of modular environment.
So far I've not been able to see any special benefits of such an
environment. I mean, it's curious, but it also means lots of open
windows, it means the project being dependent on many-many apps. Somehow to
me it means working on the problem
from the outside. All the inter-application management seems to be a
difficult problematic and even in the long run is doomed
to have many problems due to many apps involved. A dev releases new version
of his app that has a bug and session
handler cannot connect it - and boom!
But I also have a suggestion.
Is it possible to create an integrated environment based on modules? That
is, an app which would have "plugins", but not plugins in a
sense like effects and synths only, but plugins as elements of the sequencer
itself, like piano roll, song editor, such stuff. A person opens this app
and starts adding elements he needs to it. For a particular project he might
not need a piano roll, he might need only audio track arranger,
for another projects he takes an audio track arranger and also adds a piano
roll.
Modules of such an app could be very different, like a loop player like
Kluppe, etc - all the apps linux audio has to this day but remade as modules
to an integrated sequencer.
What do you think?
Louigi Verona.
On Sun, Dec 20, 2009 at 4:18 AM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
On 12/20/2009 11:48 AM, Louigi Verona wrote:
So, as a musician, I think linux audio developers have to focus on
1. integrated audio environment
2. sotware synthesizers/effects (LV2)
I prefer to work with a modular environment and want to see session
management working properly. I would be very disappointed if no further work
was done on session management.
I am looking forward to the progress that will be made over the next
couple of years on that front.
Patrick Shirkey
Boost Hardware Ltd
LMMS is an integrated environment and having Zyn inside it is great. LMMS
is very promising.
But what isn't there are plugins and synthesizers. As an ambient composer
I simply lack the tools
I need,
Hope any of this was useful.
Louigi Verona.
On Sun, Dec 20, 2009 at 1:19 AM, <fons(a)kokkinizita.net> wrote:
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
On Sat, Dec 19, 2009 at 09:15:22PM +0100, rosea grammostola wrote:
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
1) The 'one app with plugins' group.
People who are focusing on one big
app, extended by plugins (Ardour, Qtractor, LV2/DSSI). This group
doesn't have much interest in a session handler.
And quite probably the authors of these apps are not very
motivated to make them compatible with session handlers.
2) The people who likes to work with different,
small Jack applications
(ams, aeolus, epichord etc.). These people are interested in a session
handler. But they think dbus is the wrong approach, it is to limited
for
them, or it is not the right thing for the Linux platform in their
opinion.
'Like to work' may not be the correct interpretation. See (4)
3) Group 3 is the same as group 2, BUT they have
chosen dbus as
solution. It's the LADI group.
4. And there's group 4, or maybe that group is just me.
If there are others I'd like to know. For group 4:
* Sessions are multi-host since there is no other way.
In most cases all but one of the machines involved will
be headless, and whatever is supposed to happen there
is by definition remote controlled instead of being
launched from a local desktop.
* There are no usable 'single app with plugins' solutions
since none of these comes close to what would be required,
in particular w.r.t. the multi-host situation, and also
because all of these apps silently assume a human user
watching them and being able to take corrective action
if necessary. Anything that could pop up an error dialog
and refuse to proceed until someone reacts is completely
useless in such systems.
* Any interaction between components of such a system is
supposed to use networked communication from the start.
Dual-layer solutions based on some local IPC system plus
some additional layer that would connect them via a network
are just an unnecessary complication, and probably one that
would not provide the right semantics, since the design would
be based on the single host assumption in blissfull ignorance
of what it takes to make things work together via a network.
* Given the potential complexity of a networked system, loading
a 'session' would in general not mean a complete teardown and
buildup of all apps and their connections, but could just mean
loading a different configuration in a single app, without even
any others being aware of this.
People using such systems are *very* motivated to create
some form session handling, since controlling this sort of
thing manually is a real PITA, in particular if you have
to do it a hundred times a day, or if you have to provide
an interface usable by non-experts. Which is why I have
been working on this. And given the quite hostile reactions
shown in recent threads, and the probably minute potential
user base, the chances that the results will be made public
are rather small.
Ciao,
--
FA
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
7:51 a.m.
Thanks, Alex, for this lengthy explanation. I must think about it. I can
certainly see
the massive advantages of modular approach for complex setups and specific
tasks.
How good is it for simple things like making an ordinary song?
Also, tell me guys, is session handling a matter of - what? Apps supporting
it or is
it programmatically a complex problem?
Louigi Verona.
On Sun, Dec 20, 2009 at 2:26 PM, alex stone <compose59(a)gmail.com> wrote:
I'd have to disagree with this. A modular
environment makes for better
use of resource.
Plugins occupy the same memory allocation as the app, and the same is
true in win and mac. For all the perceived benefits of a "one stop
shop" as far as workflow goes, there are drawbacks. It's noted that
some users are ok with freezing tracks to best manage limited
resources, but other's aren't. I spent a large chunk of my working
life bouncing tracks on a constant basis, and unlike the linux
environment, i didn't have a choice, no matter the strength of
hardware i was using. It wasn't that long ago that if you wanted to
run a full orchestral template, plus plugins, you needed a cluster of
boxes, or a CRAY. I had a cluster of 5 gig boxes PRECISELY because of
the limitations of allocated app memory space, and i was still
bouncing tracks, if i wanted to run plugins as well.
The modular environment offers a way out of this workflow killer
(imho), and with the massive advantage of using jack, with its
unlimited port structure, plugins no longer need to reside inside an
app, but can be effectively hosted and ported to and from, outside the
app, and in their own memory allocation.
So i would vote against a push to put everything in one app. Quite the
contrary, based on experience, and the many many frustrating hours i
put into bouncing tracks, and handling a pandora's box worth of
workarounds, just to get the client's material done.
Again, i perceive this drive to centralise everything into one "super"
app, as an intent to be "just like" win and mac, including the obvious
and frustrating workflow limitations, along with any
perceived.....advantages, when a little applied imagination on the
part of users would reveal a much greater use of resource, and
workflow satisfaction, in an unlimited workstation, where only the
strength of the hardware, and the corresponding depth of the user's
wallet, applies.
There's also the perception that having "lots" of plugins inside an
app is somehow.........cool, and "the best way to work". It isn't,
beyond the first hour of use. Managing lots of plugins is as much, and
possibly more of a time killer, than setting up a multiapp template in
a linux audio environment. Been there, done that, and it's no
sinecure.
So no to centralisation, and yes to developing dedicated external lv2
plugin hosting more effectively. (Multi hosts, for example.) The power
of JACK should not be underestimated in this regard, and the real work
lies (imho) in managing software resource, i.e. sessions, port
connections, save states across clusters, etc... This would focus any
technical lv2 expectations in one spot, and remove the need to hack
sequencers constantly, as the lv2 protocol develops further.
As for multiple app management, you might be missing the boat a bit
here as well. Unlike Win and Mac, with the commerically imposed
limitations, linux gives you more than one to lead an elephant across
a pond of custard.
Outside of the mainstream distros, who are generally more
commerical-like in their presentation, there's a wealth of choice for
users to really build a great system, unique to requirements. I run
Gentoo, and the fluxbox window manager, with no icons, and driven by
keybindings. Where an app can run without a GUI, then i do that from a
script, or a terminal, saving resources for something else. Linux is
extremely openended in that regard, and with a bit of effort of the
part of a user, he or she can see a direct relationship between effort
in/reward out. So the resources that are chewed up by endless GUI's,
now go where they belong, into running the DAW, for practical use. (I
have in a normal template 7 apps running, of which only 2 are GUI's
for constant use.)
Also worth noting here that apps like Jconvolver, for instance, can be
run as a standalone single instance, with multiple ins and outs, each
one of which can be configured in a file. 1 impulse for an entire
project, with each in/out configurable.
There's 65 plugins taken care of right there, in one small cli
app............
So Louigi, i disagree with you, and think it IS a personal preference,
and should not be an imposed workflow.
Why walk with the rest of the turkeys, when you can soar like an eagle?
Alex.
On Sun, Dec 20, 2009 at 9:33 AM, Louigi Verona <louigi.verona(a)gmail.com>
wrote:
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
Modular environment is great, but integrated
environment seems to be more
effective. I mean, imho it is not
a matter of preference and I am not saying no work should be done on
session
management. I am just saying that so
far my observations show me that integrated environment has too many
benefits over modular environment.
I am relatively new to linux audio, so I would be grateful if you would
explain to me the benefits of modular environment.
So far I've not been able to see any special benefits of such an
environment. I mean, it's curious, but it also means lots of open
windows, it means the project being dependent on many-many apps. Somehow
to
me it means working on the problem
from the outside. All the inter-application management seems to be a
difficult problematic and even in the long run is doomed
to have many problems due to many apps involved. A dev releases new
version
of his app that has a bug and session
handler cannot connect it - and boom!
But I also have a suggestion.
Is it possible to create an integrated environment based on modules? That
is, an app which would have "plugins", but not plugins in a
sense like effects and synths only, but plugins as elements of the
sequencer
itself, like piano roll, song editor, such stuff.
A person opens this app
and starts adding elements he needs to it. For a particular project he
might
not need a piano roll, he might need only audio
track arranger,
for another projects he takes an audio track arranger and also adds a
piano
roll.
Modules of such an app could be very different, like a loop player like
Kluppe, etc - all the apps linux audio has to this day but remade as
modules
to an integrated sequencer.
What do you think?
Louigi Verona.
On Sun, Dec 20, 2009 at 4:18 AM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
>
> On 12/20/2009 11:48 AM, Louigi Verona wrote:
>
> So, as a musician, I think linux audio developers have to focus on
>
> 1. integrated audio environment
> 2. sotware synthesizers/effects (LV2)
>
>
>
>
> I prefer to work with a modular environment and want to see session
> management working properly. I would be very disappointed if no further
work
> was done on session management.
>
> I am looking forward to the progress that will be made over the next
> couple of years on that front.
>
>
>
>
>
>
> Patrick Shirkey
> Boost Hardware Ltd
>
>
>
>
>
>
> LMMS is an integrated environment and having Zyn inside it is great.
LMMS
> is very promising.
> But what isn't there are plugins and synthesizers. As an ambient
composer
> I simply lack the tools
> I need,
>
> Hope any of this was useful.
>
> Louigi Verona.
>
>
>
>
>
>
> On Sun, Dec 20, 2009 at 1:19 AM, <fons(a)kokkinizita.net> wrote:
>>
>> On Sat, Dec 19, 2009 at 09:15:22PM +0100, rosea grammostola wrote:
>>
>> > 1) The 'one app with plugins' group. People who are focusing on one
big
>> > app, extended by plugins (Ardour,
Qtractor, LV2/DSSI). This group
>> > doesn't have much interest in a session handler.
>>
>> And quite probably the authors of these apps are not very
>> motivated to make them compatible with session handlers.
>>
>> > 2) The people who likes to work with different, small Jack
applications
>> > (ams, aeolus, epichord etc.). These
people are interested in a
session
> handler. But they think dbus is the wrong
approach, it is to limited
> for
> them, or it is not the right thing for the Linux platform in their
> opinion.
'Like to work' may not be the correct interpretation. See (4)
> 3) Group 3 is the same as group 2, BUT they have chosen dbus as
> solution. It's the LADI group.
4. And there's group 4, or maybe that group is just me.
If there are others I'd like to know. For group 4:
* Sessions are multi-host since there is no other way.
In most cases all but one of the machines involved will
be headless, and whatever is supposed to happen there
is by definition remote controlled instead of being
launched from a local desktop.
* There are no usable 'single app with plugins' solutions
since none of these comes close to what would be required,
in particular w.r.t. the multi-host situation, and also
because all of these apps silently assume a human user
watching them and being able to take corrective action
if necessary. Anything that could pop up an error dialog
and refuse to proceed until someone reacts is completely
useless in such systems.
* Any interaction between components of such a system is
supposed to use networked communication from the start.
Dual-layer solutions based on some local IPC system plus
some additional layer that would connect them via a network
are just an unnecessary complication, and probably one that
would not provide the right semantics, since the design would
be based on the single host assumption in blissfull ignorance
of what it takes to make things work together via a network.
* Given the potential complexity of a networked system, loading
a 'session' would in general not mean a complete teardown and
buildup of all apps and their connections, but could just mean
loading a different configuration in a single app, without even
any others being aware of this.
People using such systems are *very* motivated to create
some form session handling, since controlling this sort of
thing manually is a real PITA, in particular if you have
to do it a hundred times a day, or if you have to provide
an interface usable by non-experts. Which is why I have
been working on this. And given the quite hostile reactions
shown in recent threads, and the probably minute potential
user base, the chances that the results will be made public
are rather small.
Ciao,
--
FA
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
8:21 a.m.
Well, as a generally accepted view of simply writing songs from a
musical perspective, it's considered good practise to write the tune
from beginning to end first, then start work on polishing it. If
you're recording live, that is straight audio recording, then we're
well served in that regard with Ardour, Qtractor, and few others. Once
your recording is done, then it would be a fairly simple matter to
open one of your previously built templates, and assign your ports.
A possible use case:
You've got the guitar out and laid down a track or 2, managed to to
wake up the drummer, and after 78 takes, got something near a well
timed set of drum tracks. The bass player has got back from the
vegetarian food shop, and added his line. So you have say 12 tracks
all recorded, and ready to be polished. There are some good hosts in
Linux for lv2, and ladspa plugins, like ingen, for instance. It can
open templates you've built yourself, so you open the one named
"simple song". Now you have a dedicated plugin host, to which you port
your dozen tracks. (use sends for instance, in each track). Ardour,
for example, is terrific for "quick" recording. Simply "port up" (the
real man's terminology for setting up), and hit the red button. Ardour
remembers what you are ported to, so if you build a little 12 track
"instant" template, for example, with a basic "instant" plugin
template set in Ingen, you simply open Ingen, load the template, then
open Ardour, and load the template, and voila, you're ready to roll.
Like any working environment, setting up is important. Taking the time
to build templates for use pays dividends, as you can open your "core"
plugin set in an app like ingen, then add or subtract per project
according to need. You only need to build templates once, and then you
have an "instant" set to work with. And of course, you can build a lot
of them. In linux we have another massive advantage in multiple
workspaces, and i consider this feature essential when handling lots
of plugins, etc.. I have 8 workspaces, and i fly between them with a
pair of keybindings. So in this use case, i would have Ardour editor
in workspace 1, Ardour mixer in workspace 2, and the plugins in
workspace 3, and possibly 4.
I can say that spreading a working environment out like this is a vast
improvement over trying to handle a sequencer, and what seems like
constantly breeding plugins all in one window, or at a max 2. In my
win days when i wrote for ads, it was a nightmare trying to shift the
focus all the time between so many windows open, even over 2 monitors.
Add to that the image you were trying to write to, and the frustration
builds fairly easily, particularly when you're operating to a tight
time limit. I seemed to spend more time changing GUI focus than i did
work. :)
No such limitation in Linux, and it works so well, i'd never ever go back.
You'll need to devote some time to setup your DAW like this, and
probably ask a few questions along the way, but for reward in terms of
daily workflow satisfaction, i can say i'm in front by a long way, and
get a LOT more work done for less effort.
Thinking out of the commercially driven box is the key here, but as a
user in a linux audio environment, imho, you're more likely to enjoy
writing and working with music, for a far longer period of time.
Alex.
On Sun, Dec 20, 2009 at 11:51 AM, Louigi Verona <louigi.verona(a)gmail.com> wrote:
Thanks, Alex, for this lengthy explanation. I must
think about it. I can
certainly see
the massive advantages of modular approach for complex setups and specific
tasks.
How good is it for simple things like making an ordinary song?
Also, tell me guys, is session handling a matter of - what? Apps supporting
it or is
it programmatically a complex problem?
Louigi Verona.
On Sun, Dec 20, 2009 at 2:26 PM, alex stone <compose59(a)gmail.com> wrote:
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
I'd have to disagree with this. A modular environment makes for better
use of resource.
Plugins occupy the same memory allocation as the app, and the same is
true in win and mac. For all the perceived benefits of a "one stop
shop" as far as workflow goes, there are drawbacks. It's noted that
some users are ok with freezing tracks to best manage limited
resources, but other's aren't. I spent a large chunk of my working
life bouncing tracks on a constant basis, and unlike the linux
environment, i didn't have a choice, no matter the strength of
hardware i was using. It wasn't that long ago that if you wanted to
run a full orchestral template, plus plugins, you needed a cluster of
boxes, or a CRAY. I had a cluster of 5 gig boxes PRECISELY because of
the limitations of allocated app memory space, and i was still
bouncing tracks, if i wanted to run plugins as well.
The modular environment offers a way out of this workflow killer
(imho), and with the massive advantage of using jack, with its
unlimited port structure, plugins no longer need to reside inside an
app, but can be effectively hosted and ported to and from, outside the
app, and in their own memory allocation.
So i would vote against a push to put everything in one app. Quite the
contrary, based on experience, and the many many frustrating hours i
put into bouncing tracks, and handling a pandora's box worth of
workarounds, just to get the client's material done.
Again, i perceive this drive to centralise everything into one "super"
app, as an intent to be "just like" win and mac, including the obvious
and frustrating workflow limitations, along with any
perceived.....advantages, when a little applied imagination on the
part of users would reveal a much greater use of resource, and
workflow satisfaction, in an unlimited workstation, where only the
strength of the hardware, and the corresponding depth of the user's
wallet, applies.
There's also the perception that having "lots" of plugins inside an
app is somehow.........cool, and "the best way to work". It isn't,
beyond the first hour of use. Managing lots of plugins is as much, and
possibly more of a time killer, than setting up a multiapp template in
a linux audio environment. Been there, done that, and it's no
sinecure.
So no to centralisation, and yes to developing dedicated external lv2
plugin hosting more effectively. (Multi hosts, for example.) The power
of JACK should not be underestimated in this regard, and the real work
lies (imho) in managing software resource, i.e. sessions, port
connections, save states across clusters, etc... This would focus any
technical lv2 expectations in one spot, and remove the need to hack
sequencers constantly, as the lv2 protocol develops further.
As for multiple app management, you might be missing the boat a bit
here as well. Unlike Win and Mac, with the commerically imposed
limitations, linux gives you more than one to lead an elephant across
a pond of custard.
Outside of the mainstream distros, who are generally more
commerical-like in their presentation, there's a wealth of choice for
users to really build a great system, unique to requirements. I run
Gentoo, and the fluxbox window manager, with no icons, and driven by
keybindings. Where an app can run without a GUI, then i do that from a
script, or a terminal, saving resources for something else. Linux is
extremely openended in that regard, and with a bit of effort of the
part of a user, he or she can see a direct relationship between effort
in/reward out. So the resources that are chewed up by endless GUI's,
now go where they belong, into running the DAW, for practical use. (I
have in a normal template 7 apps running, of which only 2 are GUI's
for constant use.)
Also worth noting here that apps like Jconvolver, for instance, can be
run as a standalone single instance, with multiple ins and outs, each
one of which can be configured in a file. 1 impulse for an entire
project, with each in/out configurable.
There's 65 plugins taken care of right there, in one small cli
app............
So Louigi, i disagree with you, and think it IS a personal preference,
and should not be an imposed workflow.
Why walk with the rest of the turkeys, when you can soar like an eagle?
Alex.
On Sun, Dec 20, 2009 at 9:33 AM, Louigi Verona <louigi.verona(a)gmail.com>
wrote:
Modular environment is great, but integrated
environment seems to be
more
effective. I mean, imho it is not
a matter of preference and I am not saying no work should be done on
session
management. I am just saying that so
far my observations show me that integrated environment has too many
benefits over modular environment.
I am relatively new to linux audio, so I would be grateful if you would
explain to me the benefits of modular environment.
So far I've not been able to see any special benefits of such an
environment. I mean, it's curious, but it also means lots of open
windows, it means the project being dependent on many-many apps. Somehow
to
me it means working on the problem
from the outside. All the inter-application management seems to be a
difficult problematic and even in the long run is doomed
to have many problems due to many apps involved. A dev releases new
version
of his app that has a bug and session
handler cannot connect it - and boom!
But I also have a suggestion.
Is it possible to create an integrated environment based on modules?
That
is, an app which would have "plugins", but not plugins in a
sense like effects and synths only, but plugins as elements of the
sequencer
itself, like piano roll, song editor, such stuff. A person opens this
app
and starts adding elements he needs to it. For a particular project he
might
not need a piano roll, he might need only audio track arranger,
for another projects he takes an audio track arranger and also adds a
piano
roll.
Modules of such an app could be very different, like a loop player like
Kluppe, etc - all the apps linux audio has to this day but remade as
modules
to an integrated sequencer.
What do you think?
Louigi Verona.
On Sun, Dec 20, 2009 at 4:18 AM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
On 12/20/2009 11:48 AM, Louigi Verona wrote:
So, as a musician, I think linux audio developers have to focus on
1. integrated audio environment
2. sotware synthesizers/effects (LV2)
I prefer to work with a modular environment and want to see session
management working properly. I would be very disappointed if no further
work
was done on session management.
I am looking forward to the progress that will be made over the next
couple of years on that front.
Patrick Shirkey
Boost Hardware Ltd
LMMS is an integrated environment and having Zyn inside it is great.
LMMS
is very promising.
But what isn't there are plugins and synthesizers. As an ambient
composer
I simply lack the tools
I need,
Hope any of this was useful.
Louigi Verona.
On Sun, Dec 20, 2009 at 1:19 AM, <fons(a)kokkinizita.net> wrote:
>
> On Sat, Dec 19, 2009 at 09:15:22PM +0100, rosea grammostola wrote:
>
> > 1) The 'one app with plugins' group. People who are focusing on one
> > big
> > app, extended by plugins (Ardour, Qtractor, LV2/DSSI). This group
> > doesn't have much interest in a session handler.
>
> And quite probably the authors of these apps are not very
> motivated to make them compatible with session handlers.
>
> > 2) The people who likes to work with different, small Jack
> > applications
> > (ams, aeolus, epichord etc.). These people are interested in a
> > session
> > handler. But they think dbus is the wrong approach, it is to limited
> > for
> > them, or it is not the right thing for the Linux platform in their
> > opinion.
>
> 'Like to work' may not be the correct interpretation. See (4)
>
> > 3) Group 3 is the same as group 2, BUT they have chosen dbus as
> > solution. It's the LADI group.
>
> 4. And there's group 4, or maybe that group is just me.
> If there are others I'd like to know. For group 4:
>
> * Sessions are multi-host since there is no other way.
> In most cases all but one of the machines involved will
> be headless, and whatever is supposed to happen there
> is by definition remote controlled instead of being
> launched from a local desktop.
>
> * There are no usable 'single app with plugins' solutions
> since none of these comes close to what would be required,
> in particular w.r.t. the multi-host situation, and also
> because all of these apps silently assume a human user
> watching them and being able to take corrective action
> if necessary. Anything that could pop up an error dialog
> and refuse to proceed until someone reacts is completely
> useless in such systems.
>
> * Any interaction between components of such a system is
> supposed to use networked communication from the start.
> Dual-layer solutions based on some local IPC system plus
> some additional layer that would connect them via a network
> are just an unnecessary complication, and probably one that
> would not provide the right semantics, since the design would
> be based on the single host assumption in blissfull ignorance
> of what it takes to make things work together via a network.
>
> * Given the potential complexity of a networked system, loading
> a 'session' would in general not mean a complete teardown and
> buildup of all apps and their connections, but could just mean
> loading a different configuration in a single app, without even
> any others being aware of this.
>
> People using such systems are *very* motivated to create
> some form session handling, since controlling this sort of
> thing manually is a real PITA, in particular if you have
> to do it a hundred times a day, or if you have to provide
> an interface usable by non-experts. Which is why I have
> been working on this. And given the quite hostile reactions
> shown in recent threads, and the probably minute potential
> user base, the chances that the results will be made public
> are rather small.
>
> Ciao,
>
> --
> FA
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
8:54 a.m.
Louigi Verona wrote:
Thanks, Alex, for this lengthy explanation. I must
think about it. I
can certainly see
the massive advantages of modular approach for complex setups and
specific tasks.
How good is it for simple things like making an ordinary song?
@Alex, thanks for
your view.
I don't think it has to be 'one or the other' here. As I see it now I
think it will be good to have the ability on Linux to use roughly two
different approaches.
1) The 'all-in-one-app' + plugins inside approach (Ardour with LV2
plugins for example).
And
2) The modular approach, (e.g. Jack apps, pluginhosts like lv2rack
(naspro), synths etc.).
Approach 1 is an improvement for many people and many people like to
work that way.
But if you only focusing on approach 1, you throw away a lot of the
potential of Linux audio and what it has accomplished so far. As Alex
pointed out nicely, the modular approach can be a big advantage of Linux.
And yes, there is also one (big) disadvantage, that is, manually
launching all the applications and settings every session again and
again. This can be really bad.
Just recently the openoctave project is trying to achieve a nice
workflow with the modular approach. This is quite a new and unique
project. And it could take away the disadvantages of the modular
approach. At least if you want to work the way openoctave project is
working, focusing on orchestral and film music.
For 'light music' (Pop, Rock, Electro etc) the situation is a bit
different. They work with many apps and many different synths in many
different situations and combinations. The question is whether the
openoctave way is an solution for this group. Because you don't work
with a static set of tools as the openoctave project does (Ardour,
oomidi, linuxsampler, jconvolver).
(I'm thinking about the way artist as Atte Jensen are working and the
discussion he recently started about the lack of tools for quick
composition on Linux and also about the discussion about some kind of
Ableton Live for Linux tool.)
Especially for the 'light music' group, a session handler could be very
useful. Making scripts for every combination of apps those people use,
is not very realistic and at least not very 'workflow friendly'.
Especially not if you realize that those artists work a lot by
improvisation and small creative ideas which should be put into an
computer easy and fast.
So unless there is a movement towards approach 1 (which is not bad at
all), the modular approach will always have it's advantages for a group
of artists. And for many of these artists, a session handler will not
only be useful but also necessary.
Now I feel we have quality wood, precise hammers, good sounding strings,
decent pedals and nice feeling keys. But every-time before we can play
this great piano we have to put those components together first. And a
majority of us are not even piano builders!
A session handler could provide a piano for us, which is ready to play.
And that is where many artists are looking for...
\r
9:40 a.m.
On Sun, Dec 20, 2009 at 4:33 AM, Louigi Verona <louigi.verona(a)gmail.com> wrote:
Modular environment is great, but integrated
environment seems to be more
effective.
statements like this are meaningless without clear qualifiers. feel
free to say "for the kind of audio/music composition that I do, and
the workflow that i use, i find an integrated environment more
effective". please don't try to make blanket statements about the way
that people use tools.
But I also have a suggestion.
Is it possible to create an integrated environment based on modules? That
is, an app which would have "plugins", but not plugins in a
sense like effects and synths only, but plugins as elements of the sequencer
itself, like piano roll, song editor, such stuff. A person opens this app
and starts adding elements he needs to it. For a particular project he might
not need a piano roll, he might need only audio track arranger,
for another projects he takes an audio track arranger and also adds a piano
roll.
Modules of such an app could be very different, like a loop player like
Kluppe, etc - all the apps linux audio has to this day but remade as modules
to an integrated sequencer.
What do you think?
i think you are new to linux audio. i also think that like most users
of software, you don't actually know what you want or need - this is
not a slam or a negative criticism, just a fact of life. it wouldn't
be a problem if developers like me knew what you wanted or needed too,
but alas, neither do we.
--p
10:19 a.m.
söndag december 20 2009 14.40.24 skrev Paul Davis:
...i also think that like most users
of software, you don't actually know what you want or need - this is
not a slam or a negative criticism, just a fact of life. it wouldn't
be a problem if developers like me knew what you wanted or needed too,
but alas, neither do we.
Very well said. I extract your words out of this thread's sentence and keep
this words in my mind. Helping my self to understand and respect other
projects better and also defending my own. :-)
Thanks!
Jostein
22 Dec
22 Dec
1:45 p.m.
On Sun, 2009-12-20 at 12:33 +0300, Louigi Verona wrote:
I am relatively new to linux audio, so I would be
grateful if you
would explain to me the benefits of modular environment.
I would recommend the following chapter from ESR's book, The Art of Unix
Programming. In particular, rules 1, 3, 5 and most importantly, 6:
http://catb.org/~esr/writings/taoup/html/ch01s06.html
--
Bob Ham <rah(a)bash.sh>
1:55 p.m.
On Tue, Dec 22, 2009 at 12:45 PM, Bob Ham <rah(a)bash.sh> wrote:
On Sun, 2009-12-20 at 12:33 +0300, Louigi Verona
wrote:
another marvellous demonstration of my credo:
"never let what you are really attempting to accomplish stand in the
way of deepening your knowledge of computer science"
the problem is that this a tautological reference: the question of
whether rule 6 applies is precisely the question.
I am relatively new to linux audio, so I would be
grateful if you
would explain to me the benefits of modular environment.
I would recommend the following chapter from ESR's book, The Art of Unix
Programming. In particular, rules 1, 3, 5 and most importantly, 6:
http://catb.org/~esr/writings/taoup/html/ch01s06.html
7:35 p.m.
On Tue, 2009-12-22 at 12:55 -0500, Paul Davis wrote:
On Tue, Dec 22, 2009 at 12:45 PM, Bob Ham
<rah(a)bash.sh> wrote:
Well the Unix philosophy is, I think aptly described as a philosophy.
It isn't generally something that is based on rational measurement. I
think ESR has done a very good job of writing it down. A lot of times
he doesn't try to justify aspects of it, precisely because they aren't
based on rationality but on the intuition that arises from experience
programming and using Unix systems.
The issue of whether rule 6 "applies" (I'm taking that to mean 'is a
valid rule') is based on an appeal to intuition. Hence, it is entirely
subjective. It depends on whether your experience programming and using
Unix systems gives rise to the intuitive feeling that writing large
programs should be a last resort. I certainly have that intuitive
feeling. I guess YMMV.
In general, The Art of Unix Programming appeals very much to my
intuition and I am happy to submit to the rules laid down by those more
wizardly than myself.
--
Bob Ham <rah(a)bash.sh>
On Sun, 2009-12-20 at 12:33 +0300, Louigi Verona
wrote:
another marvellous demonstration of my credo:
"never let what you are really attempting to accomplish stand in the
way of deepening your knowledge of computer science"
the problem is that this a tautological reference: the question of
whether rule 6 applies is precisely the question. I am relatively new to linux audio, so I would be
grateful if you
would explain to me the benefits of modular environment.
I would recommend the following chapter from ESR's book, The Art of Unix
Programming. In particular, rules 1, 3, 5 and most importantly, 6:
http://catb.org/~esr/writings/taoup/html/ch01s06.html
19 Dec
19 Dec
9:21 p.m.
Louigi Verona wrote:
Hey guys!
I am not a developer, I am a musician who has decided to try to switch
to Linux.
I am not sure how many times this has been discussed and I have signed
up to this list
being interested in audio linux development, specifically lv2 plugins.
But I can say that in three months of very active work with audio,
learning new concepts,
trying out Ardour, Qtractor, Zyn synth, Patchage, Kluppe,
Sooperlooper, JackRack
and LMMS, I can say that although modular approach has its charm and
even use,
for most of the cases it is very awkward and very difficult to set up
and any potential solution
bumps into many problems since any session management system will have
to work with different
apps and it means more chances for errors - excuse me if I am not correct.
On the other hand, an integrated environment, while opposed by many
linux users and programmers,
gives much more control to the musician both in live performance and
studio work.
I must say that I have used Ardour, Kluppe and Jack Rack and Patchage
in live performance and it was great,
but I had to play only one tune. To set up the tune I had to open 4
instances of Kluppe, one Jack Rack,, open Ardour,
load session, load Patchage, disconnect unnecessary connections,
connect Ardour to Jack Rack (for some reason
it does not save connections to Jack Rack) and then connect all of
that to a midi keyboard. This usually takes around
a minute of time.
If I had to play another tune, it would be a disaster, since I would
have to close lots of stuff and reopen, not to mention that
with a complex setup it is difficult to forget.
As for studio work, setting up a whole big number of apps to work on a
tune is very difficult. It also seems to bring up a technical
problem - please sorry again if my technical conclusions are wrong -
but with an integrated environment it seems it is easier to do
memory management. With several apps Jack can just throw an app out
without warning and it is very frustrating and time consuming.
So, as a musician, I think linux audio developers have to focus on
1. integrated audio environment
2. sotware synthesizers/effects (LV2)
LMMS is an integrated environment and having Zyn inside it is great.
LMMS is very promising.
But what isn't there are plugins and synthesizers. As an ambient
composer I simply lack the tools
I need,
Hope any of this was useful.
Louigi Verona.
Full acknowledge.
If you do live stuff you should write simple shell scripts, that will
set up most of the things automatically. To do this, there's no need to
have much knowledge about writing shell scripts.
There are helping applications e.g.
http://tapas.affenbande.org/wordpress/?page_id=14.
Did you try Qtractor from SVN?
http://qtractor.sourceforge.net/qtractor-downloads.html#SVN
Cheers,
Ralf
--
How to keep us all safe
Hi,
I just joined over 11 million people in the world's largest-ever campaign to keep us
all safe.
There has never been a more important time to add your name - our message is being
delivered to leaders at the Copenhagen climate summit later this week.
Please add your voice now at
http://www.avaaz.org/en/save_copenhagen/98.php?CLICK_TF_TRACK
Thanks!
9:22 p.m.
On 12/20/2009 09:19 AM, fons(a)kokkinizita.net wrote:
People using such systems are *very* motivated to create
some form session handling, since controlling this sort of
thing manually is a real PITA, in particular if you have
to do it a hundred times a day, or if you have to provide
an interface usable by non-experts. Which is why I have
been working on this. And given the quite hostile reactions
shown in recent threads, and the probably minute potential
user base, the chances that the results will be made public
are rather small.
I would be very surprised if the intensity of discussion stopped you
from releasing your work on session management to the public domain.
In fact I might even eat my hat if that happened... :-)
Patrick Shirkey
Boost Hardware Ltd
20 Dec
20 Dec
1:25 a.m.
On Sat, 19 Dec 2009, fons(a)kokkinizita.net wrote:
Over the past few months I've decided that I'm in group #1.
Session management is good... but it requires /some/ level
of consensus. I think LAD (at present) is too hostile to
achieve this without some sort of "politician" showing up to
unify the devs (and it ain't me, babe).
That said, I'm open to adding session management to my
applications and would love it if session management could
succeed.
1) The
'one app with plugins' group. People who are focusing on one big
app, extended by plugins (Ardour, Qtractor, LV2/DSSI). This group
doesn't have much interest in a session handler.
And quite probably the authors of these apps are not very
motivated to make them compatible with session handlers. 4. And there's group 4, or maybe that group is
just me.
If there are others I'd like to know. For group 4:
When I'm not in group 1, I'm hanging out in group 4.
Inter-host and headless session management is important to
me, too.
I really do hope that Fons releases his code. :-)
-gabriel
6:24 a.m.
Gabriel M. Beddingfield wrote:
When I'm not in group 1, I'm hanging out in
group 4.
Inter-host and headless session management is important to
me, too.
I really do hope that Fons releases his code. :-)
@Fons, thanks for your reply. It seems that you're not planned to make a
session handler for the mass... That's not bad at all in many cases.
Good luck with it and I hope you decide to release your code.
Ok, roughly we have 4 groups now (assuming that we can call >1
individuals a group ;) )
Group 1 has spoken, group 3 and group 4.
What can we expect from group 2? Maybe some of the lash developers
belongs in this group?
Dave, Juuso, Bob Ham, ... ? What are your plans now?
Regards,
\r
8:13 a.m.
On Sun, Dec 20, 2009 at 11:23:54AM +0100, rosea grammostola wrote:
Gabriel M. Beddingfield wrote:
dunno... jack session is frozen now.
it took a huge flame war to find out some implications of the
requirements.
so basically i dont think we can reach consensus.
and sessionhandling is _only_ about consensus. its not a problem at all
to implement.
lad is dead.
When I'm not in group 1, I'm hanging out
in group 4.
Inter-host and headless session management is important to
me, too.
I really do hope that Fons releases his code. :-)
@Fons, thanks for your reply. It seems that you're not planned to make a
session handler for the mass... That's not bad at all in many cases.
Good luck with it and I hope you decide to release your code.
Ok, roughly we have 4 groups now (assuming that we can call >1
individuals a group ;) )
Group 1 has spoken, group 3 and group 4.
What can we expect from group 2? Maybe some of the lash developers
belongs in this group?
Dave, Juuso, Bob Ham, ... ? What are your plans now?
Regards,
\r
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
torben Hohn
4:11 p.m.
torbenh wrote:
On Sun, Dec 20, 2009 at 11:23:54AM +0100, rosea
grammostola wrote:
Torben, thanks for your reply.
Can you, for the people who didn't follow the development of jack
session, shortly point out what jack session does.
1) What do you want to achieve with jack session.
2) How do you think you are able to achieve it?
3) Why do you think this is the best way to do it?
Please keep it short and to the point if you want.
\r
What can we expect from group 2? Maybe some of
the lash developers
belongs in this group?
Dave, Juuso, Bob Ham, ... ? What are your plans now?
dunno... jack session is frozen now.
4:30 p.m.
Alex Stone:
I do electronic music. Which means I cannot just "record" a song. If I
record some TB-303
kinda line and I have all the cutoff filter tweaks I made in real time and
recorded that to audio in Qtractor,
and later I want to, say, omit a note or change the cutoff automation, I
cannot do this with audio. I
have to rerecord everything and since Qtractor does not have automation, I
actually have to re-perform
the whole thing.
Ardour has automation but no midi.
So making an electronic kinda track is very tough.
Paul Davis:
Very well said. This is why I am asking questions. At the same time I am
throwing in my thoughts, so that
you, the devs, could see what musicians might or might not need. Perhaps I
do not know a 100% what I want,
but some things I do know.
Of course, my blank statement was an incorrect generalization, I agree and
will try not to generalize in the future.
It is also evident to me as well that I am very new to linux audio, this is
why I generally do not post to this list ;)
Basically, the kind of music I do is based on manipulating sound through
effects, sweeping filters, vocoders.
So to me it is important to have automation and at the same time to go back
to any moment in the song and change
something. In other words, I need to have the song in "development" mode.
Atm, I do not know how to work in, say,
Qtractor and not render things to audio in order to work with them, same
with Ardour. If Ardour gets midi maybe this is
going to change.
Anyway, all of the above is just my workflow. Might no be interesting to
anyone else, of course.
Louigi.
6:19 p.m.
You might want to look at jack transport. Then you can use something
like rosegarden with ardour and not have the limitations you are
speaking of.
-------- Original Message --------
Subject: Re: [LAD] LADI
From: Louigi Verona <louigi.verona(a)gmail.com>
To: rosea grammostola <rosea.grammostola(a)gmail.com>
Cc: linux-audio-dev(a)lists.linuxaudio.org
Date: 12/20/09 13:30
Alex Stone:
I do electronic music. Which means I cannot just "record" a song. If I
record some TB-303
kinda line and I have all the cutoff filter tweaks I made in real time
and recorded that to audio in Qtractor,
and later I want to, say, omit a note or change the cutoff automation,
I cannot do this with audio. I
have to rerecord everything and since Qtractor does not have
automation, I actually have to re-perform
the whole thing.
Ardour has automation but no midi.
So making an electronic kinda track is very tough.
Paul Davis:
Very well said. This is why I am asking questions. At the same time I
am throwing in my thoughts, so that
you, the devs, could see what musicians might or might not need.
Perhaps I do not know a 100% what I want,
but some things I do know.
Of course, my blank statement was an incorrect generalization, I agree
and will try not to generalize in the future.
It is also evident to me as well that I am very new to linux audio,
this is why I generally do not post to this list ;)
Basically, the kind of music I do is based on manipulating sound
through effects, sweeping filters, vocoders.
So to me it is important to have automation and at the same time to go
back to any moment in the song and change
something. In other words, I need to have the song in "development"
mode. Atm, I do not know how to work in, say,
Qtractor and not render things to audio in order to work with them,
same with Ardour. If Ardour gets midi maybe this is
going to change.
Anyway, all of the above is just my workflow. Might no be interesting
to anyone else, of course.
Louigi.
------------------------------------------------------------------------
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
Christopher Cherrett
ccherrett(a)openoctave.org
http://www.openoctave.org
7:18 p.m.
On Sun, Dec 20, 2009 at 09:11:04PM +0100, rosea grammostola wrote:
torbenh wrote:
session management ?
load/save of whole jack graph .
On Sun, Dec 20, 2009 at 11:23:54AM +0100, rosea
grammostola wrote:
Torben, thanks for your reply.
Can you, for the people who didn't follow the development of jack
session, shortly point out what jack session does.
1) What do you want to achieve with jack session. What can we expect from group 2? Maybe some of
the lash developers
belongs in this group?
Dave, Juuso, Bob Ham, ... ? What are your plans now?
dunno... jack session is frozen now.
2) How do you think you are able to achieve it?
with very few exceptions every app thats a target for session
management, is a jack client.
so why not add some callbacks, and let the sessionmanager
communicate with apps via jack ?
this basically reduces the size of the app patches.
allowing me to patch at least one app per hour.
3) Why do you think this is the best way to do it?
every app is already using jack IPC to communicate with jackd.
-> minimally invasive on the app.
no reinvention of the wheel or yet another IPC mechanism to add.
anyways... effort is frozen.
we are dumping a working implementation.
--
torben Hohn
21 Dec
21 Dec
4:56 a.m.
On 12/21/2009 10:18 AM, torbenh wrote:
On Sun, Dec 20, 2009 at 09:11:04PM +0100, rosea
grammostola wrote:
I don't understand why you have made this decision.
The basic framework that you have implemented will be very useful for a
large subset of the requirements of a session management system. In may
be more than enough for 95% of normal users to get things done.
If people need to take things further they have the option of using LADI
or waiting for Fon's to release his work.
There was only one person who categorically said they wouldn't be able
to work with your additions and he is already making his own system anyway.
I would like to see your work included as an option as that would also
give Nedko (and maybe even Fons) an opportunity to extend and integrate
their efforts to work with yours.
Wholesale writing off your efforts simple because the debate got heated
seems unnecessary to me.
Patrick Shirkey
Boost Hardware Ltd
torbenh wrote:
session management ?
load/save of whole jack graph .
On Sun, Dec 20, 2009 at 11:23:54AM +0100, rosea
grammostola wrote:
Torben, thanks for your reply.
Can you, for the people who didn't follow the development of jack
session, shortly point out what jack session does.
1) What do you want to achieve with jack session.
What can we expect from group 2? Maybe some of
the lash developers
belongs in this group?
Dave, Juuso, Bob Ham, ... ? What are your plans now?
dunno... jack session is frozen now.
2) How do you think you are able to achieve it?
with very few exceptions every app thats a target for session
management, is a jack client.
so why not add some callbacks, and let the sessionmanager
communicate with apps via jack ?
this basically reduces the size of the app patches.
allowing me to patch at least one app per hour.
3) Why do you think this is the best way to do
it?
every app is already using jack IPC to communicate with jackd.
-> minimally invasive on the app.
no reinvention of the wheel or yet another IPC mechanism to add.
anyways... effort is frozen.
we are dumping a working implementation.
5:22 a.m.
This is probably because the Jacksession version would need to
maintained in a seperate branch, and so we'd have 3 versions of jack
to deal with.
I tested jacksession, and it works well. (Using the experimental branch)
As Torben says, there's minimal intrusion in apps, and importantly
minimal change to the jack API.
I'm sorry to see it stop, but Torben's been driving this forward, as a
practical opportunity for users, and not just a lot of discussion, and
if he feels the politics (and i think that is what's at the heart of
this) of doing this outweighs the positive benefits, then i can hardly
blame him for freezing it indefinitely or otherwise. Why keep bashing
your head against the wall?
If he decides to pick this up again, and take it further, then i'm
willing to continue testing, as i see jacksession as the simplest,
most elegant, and least intrusive session management system i've seen
to date. That's i guess, the best we can do for now.
The users will have to wait, find another way, or just accept it's not
going to happen.
Alex.
On Mon, Dec 21, 2009 at 8:54 AM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
On 12/21/2009 10:18 AM, torbenh wrote:
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
On Sun, Dec 20, 2009 at 09:11:04PM +0100, rosea
grammostola wrote:
I don't understand why you have made this decision.
The basic framework that you have implemented will be very useful for a
large subset of the requirements of a session management system. In may
be more than enough for 95% of normal users to get things done.
If people need to take things further they have the option of using LADI
or waiting for Fon's to release his work.
There was only one person who categorically said they wouldn't be able
to work with your additions and he is already making his own system anyway.
I would like to see your work included as an option as that would also
give Nedko (and maybe even Fons) an opportunity to extend and integrate
their efforts to work with yours.
Wholesale writing off your efforts simple because the debate got heated
seems unnecessary to me.
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
torbenh wrote:
session management ?
load/save of whole jack graph .
On Sun, Dec 20, 2009 at 11:23:54AM +0100, rosea
grammostola wrote:
> What can we expect from group 2? Maybe some of the lash developers
> belongs in this group?
> Dave, Juuso, Bob Ham, ... ? What are your plans now?
>
>
dunno... jack session is frozen now.
Torben, thanks for your reply.
Can you, for the people who didn't follow the development of jack
session, shortly point out what jack session does.
1) What do you want to achieve with jack session.
2) How do you think you are able to achieve it?
with very few exceptions every app thats a target for session
management, is a jack client.
so why not add some callbacks, and let the sessionmanager
communicate with apps via jack ?
this basically reduces the size of the app patches.
allowing me to patch at least one app per hour.
3) Why do you think this is the best way to do
it?
every app is already using jack IPC to communicate with jackd.
-> minimally invasive on the app.
no reinvention of the wheel or yet another IPC mechanism to add.
anyways... effort is frozen.
we are dumping a working implementation.
5:35 a.m.
On 12/21/2009 08:22 PM, alex stone wrote:
This is probably because the Jacksession version would
need to
maintained in a seperate branch, and so we'd have 3 versions of jack
to deal with.
I tested jacksession, and it works well. (Using the experimental branch)
As Torben says, there's minimal intrusion in apps, and importantly
minimal change to the jack API.
I'm sorry to see it stop, but Torben's been driving this forward, as a
practical opportunity for users, and not just a lot of discussion, and
if he feels the politics (and i think that is what's at the heart of
this) of doing this outweighs the positive benefits, then i can hardly
blame him for freezing it indefinitely or otherwise. Why keep bashing
your head against the wall?
If he decides to pick this up again, and take it further, then i'm
willing to continue testing, as i see jacksession as the simplest,
most elegant, and least intrusive session management system i've seen
to date. That's i guess, the best we can do for now.
The users will have to wait, find another way, or just accept it's not
going to happen.
I haven't seen anything on the lists that implied or suggested that
jack_session would not be applied to Trunk once it was decided it was
ready for wider testing.
I have been expecting that to happen and am quite surprised that Torben
has decided to freeze development. Is there some debate on irc that I
have missed in the past two weeks?
Just cos one person has strongly objected to it doesn't mean it
shouldn't be made an optional feature for the rest of us to have access
to. It can always be disabled at compile time.
It doesn't add bloat, it can be integrated with LADI, it is just a few
additional callbacks, it's simple to integrate and it enables at least
80% of functionality for a normal users session management requirements.
I would like to find out if it the remaining 20% is even needed by the
majority of users.
IIUC the current implementation is only missing support for undo. There
are a couple of proposed options for the other issue of handling
application naming conflicts. Any one of those options if implmented
will be better than we have now.
Patrick Shirkey
Boost Hardware Ltd
5:45 a.m.
You have no disagreement from me in any of the points you've made.
Alex.
On Mon, Dec 21, 2009 at 9:34 AM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
On 12/21/2009 08:22 PM, alex stone wrote:
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
This is probably because the Jacksession version
would need to
maintained in a seperate branch, and so we'd have 3 versions of jack
to deal with.
I tested jacksession, and it works well. (Using the experimental branch)
As Torben says, there's minimal intrusion in apps, and importantly
minimal change to the jack API.
I'm sorry to see it stop, but Torben's been driving this forward, as a
practical opportunity for users, and not just a lot of discussion, and
if he feels the politics (and i think that is what's at the heart of
this) of doing this outweighs the positive benefits, then i can hardly
blame him for freezing it indefinitely or otherwise. Why keep bashing
your head against the wall?
If he decides to pick this up again, and take it further, then i'm
willing to continue testing, as i see jacksession as the simplest,
most elegant, and least intrusive session management system i've seen
to date. That's i guess, the best we can do for now.
The users will have to wait, find another way, or just accept it's not
going to happen.
I haven't seen anything on the lists that implied or suggested that
jack_session would not be applied to Trunk once it was decided it was
ready for wider testing.
I have been expecting that to happen and am quite surprised that Torben
has decided to freeze development. Is there some debate on irc that I
have missed in the past two weeks?
Just cos one person has strongly objected to it doesn't mean it
shouldn't be made an optional feature for the rest of us to have access
to. It can always be disabled at compile time.
It doesn't add bloat, it can be integrated with LADI, it is just a few
additional callbacks, it's simple to integrate and it enables at least
80% of functionality for a normal users session management requirements.
I would like to find out if it the remaining 20% is even needed by the
majority of users.
IIUC the current implementation is only missing support for undo. There
are a couple of proposed options for the other issue of handling
application naming conflicts. Any one of those options if implmented
will be better than we have now.
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
6:12 a.m.
On 12/21/2009 08:45 PM, alex stone wrote:
You have no disagreement from me in any of the points
you've made.
Thinking back there was an agreement from Stephane and Torben that they
would not expect either to either work on jack_session for jack2.
However I don't recall Stephane explicitly stating that he had an
objection to jack_session being integrated into jack2. Simply that he
would not be the person to do it and that Torben didn't want to work
with c++.
Given that the actual code proposed by Torben is incredibly simple
compared to the mental effort it took to come up with the implementation
I don't see how it will not be integrated into jack2 at some point in
the not too distant future.
I definitely don't recall Paul saying anything about it not being
accepted to jack1 trunk. I have assumed his lack of communication to be
tacit agreement that it is a viable addition to the codebase.
The only person I can recall who had an explicit objection to it was
Fons, who said he would stop using jack if it was accepted. Given that
Fons is doing some pretty custom stuff with the system that he runs and
is more than capable of contributing code that would disable
jack_session if it was not made a compile time option (which is is
anyway). I don't think he should be allowed to make the decision for
the rest of us about what is accepted to trunk and what is not. Also
considering that he is now suggesting that he will not even release his
version of session management I really have an objection to his
objection being given priority over the rest of us who support
jack_session as a viable option.
Unless there is something that I have missed over the passed two weeks,
I think it is time for a vote on the issue if there really is no
consensus between the major stakeholders.
As far as I can tell it boils down to this:
jack1. Torben has provided a test case and code for integration.
jack2. No one has offered to integrate Torbens work yet.
jack_session adds 4 or 5 additional callbacks to the code base. It
allows for simple session management to be handled within jack with
minimal code needed on the client side. It can be integrated with LADI
realtively easily and Nedko has offered his support for making that
happen. Additionally there is a potential for a new non realtime thread
to be added to the server for handling session requests to enable things
like undo and application renaming when loading sessions while an
existing session and/or app is running.
From a normal users perspective we would need to have an interface that
gave us the options:
- killing already running apps before loading a session
- attempting to rename the apps without restarting them
- load a new jack instance and connect it with netjack
I see this interface being similar to the firefox recover session
interface but others may think of better ways to handle/present the options.
Patrick Shirkey
Boost Hardware Ltd
Alex.
On Mon, Dec 21, 2009 at 9:34 AM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
On 12/21/2009 08:22 PM, alex stone wrote:
This is probably because the Jacksession version
would need to
maintained in a seperate branch, and so we'd have 3 versions of jack
to deal with.
I tested jacksession, and it works well. (Using the experimental branch)
As Torben says, there's minimal intrusion in apps, and importantly
minimal change to the jack API.
I'm sorry to see it stop, but Torben's been driving this forward, as a
practical opportunity for users, and not just a lot of discussion, and
if he feels the politics (and i think that is what's at the heart of
this) of doing this outweighs the positive benefits, then i can hardly
blame him for freezing it indefinitely or otherwise. Why keep bashing
your head against the wall?
If he decides to pick this up again, and take it further, then i'm
willing to continue testing, as i see jacksession as the simplest,
most elegant, and least intrusive session management system i've seen
to date. That's i guess, the best we can do for now.
The users will have to wait, find another way, or just accept it's not
going to happen.
I haven't seen anything on the lists that implied or suggested that
jack_session would not be applied to Trunk once it was decided it was
ready for wider testing.
I have been expecting that to happen and am quite surprised that Torben
has decided to freeze development. Is there some debate on irc that I
have missed in the past two weeks?
Just cos one person has strongly objected to it doesn't mean it
shouldn't be made an optional feature for the rest of us to have access
to. It can always be disabled at compile time.
It doesn't add bloat, it can be integrated with LADI, it is just a few
additional callbacks, it's simple to integrate and it enables at least
80% of functionality for a normal users session management requirements.
I would like to find out if it the remaining 20% is even needed by the
majority of users.
IIUC the current implementation is only missing support for undo. There
are a couple of proposed options for the other issue of handling
application naming conflicts. Any one of those options if implmented
will be better than we have now.
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
6:34 a.m.
Patrick Shirkey <pshirkey(a)boosthardware.com> writes:
From a normal users perspective we would need to have
an interface that
gave us the options:
- killing already running apps before loading a session
- attempting to rename the apps without restarting them
- load a new jack instance and connect it with netjack
I don't get why these features are supposed to need support from jack
itself. Session handler/manager starts the apps and it for sure knows
how to kill them (ladishd does this already). Renaming of the clients is
not needed for ladish to operate, because ladishd implements graph
virtualization and boxes you see on canvas (clients) can be renamed and
ports can be regrouped. For handling apps that use multiple JACK
clients, more useful will be to have a function that returns the
originally requested JACK client name. netjack has two main uses
(Internet and LAN) but I don't see how jack session callbacks relate to
it. ladish-2.0 (multihost capable) will be able to start additional jack
servers, local or remote and use netjack tehcnology to link them in
single multihost studio.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
7:07 a.m.
Why not both?
Use either/or compile options:
--enable-jacksession
--enable-dbus
The bit you forgot to mention is the lack of network session
capability using your dbus method. It's still not suitable for
clusters.
However Bob Ham, in an earlier post, explained this far better than i
could, so reading up will bear fruit. He also eloquently highlighted
the rapidly ensuing complexity of having to run multiple dbusses in
some fashion to counter the limitations dbus has in providing cluster
support.
Far too complex, imho, compared to the simplicity, and minimal impact,
jacksession has on the API. Torben has already proved this
emphatically, imho, and as a user tester i found it SIMPLE and easy to
use. Surely a criteria for any developer to consider.
Add to that the ease at which he sessionised apps, with a few lines of
code, compared with the wholesale reconstruction required by lash, for
instance, and he makes a powerful and compelling case for jacksession
as a modest additional component in the API. (imho)
Jacksession, as a component, was accused of being insufficient,
therefore dismissed out of hand, for being "80%". The situation is no
better with a dbus version, and likely other constructs too.
So lets compare apples with apples here, if only for fair assessment.
Alex.
On Mon, Dec 21, 2009 at 10:33 AM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
Patrick Shirkey <pshirkey(a)boosthardware.com>
writes:
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
From a normal users perspective we would need to
have an interface that
gave us the options:
- killing already running apps before loading a session
- attempting to rename the apps without restarting them
- load a new jack instance and connect it with netjack
I don't get why these features are supposed to need support from jack
itself. Session handler/manager starts the apps and it for sure knows
how to kill them (ladishd does this already). Renaming of the clients is
not needed for ladish to operate, because ladishd implements graph
virtualization and boxes you see on canvas (clients) can be renamed and
ports can be regrouped. For handling apps that use multiple JACK
clients, more useful will be to have a function that returns the
originally requested JACK client name. netjack has two main uses
(Internet and LAN) but I don't see how jack session callbacks relate to
it. ladish-2.0 (multihost capable) will be able to start additional jack
servers, local or remote and use netjack tehcnology to link them in
single multihost studio.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
7:25 a.m.
Hi all,
I have a question about jacksession :
will it be able to handle situations when the PC, for a reason or another, goes to S3
sleep, and resumes from S3 ?
Of course, one can on purpose close the jack session after saving it, put the PC to sleep,
and resume things when awake. However, for more automated environments, or simply if you
run your stuff on a laptop and the latter goes to sleep on its own (due to some power
management scheme in place), could the jack session handle this (intercept some particular
ACPI events maybe) ?
J.
--- On Mon, 12/21/09, alex stone <compose59(a)gmail.com> wrote:
From: alex stone <compose59(a)gmail.com>
Subject: Re: [LAD] LADI
To: "Nedko Arnaudov" <nedko(a)arnaudov.name>
Cc: linux-audio-dev(a)lists.linuxaudio.org
Date: Monday, December 21, 2009, 6:07 AM
Why not both?
Use either/or compile options:
--enable-jacksession
--enable-dbus
The bit you forgot to mention is the lack of network
session
capability using your dbus method. It's still not suitable
for
clusters.
However Bob Ham, in an earlier post, explained this far
better than i
could, so reading up will bear fruit. He also eloquently
highlighted
the rapidly ensuing complexity of having to run multiple
dbusses in
some fashion to counter the limitations dbus has in
providing cluster
support.
Far too complex, imho, compared to the simplicity, and
minimal impact,
jacksession has on the API. Torben has already proved this
emphatically, imho, and as a user tester i found it SIMPLE
and easy to
use. Surely a criteria for any developer to consider.
Add to that the ease at which he sessionised apps, with a
few lines of
code, compared with the wholesale reconstruction required
by lash, for
instance, and he makes a powerful and compelling case for
jacksession
as a modest additional component in the API. (imho)
Jacksession, as a component, was accused of being
insufficient,
therefore dismissed out of hand, for being "80%". The
situation is no
better with a dbus version, and likely other constructs
too.
So lets compare apples with apples here, if only for fair
assessment.
Alex.
On Mon, Dec 21, 2009 at 10:33 AM, Nedko Arnaudov <nedko(a)arnaudov.name>
wrote:
Patrick Shirkey
<pshirkey(a)boosthardware.com>
writes:
> From a normal users perspective we would need to
have an interface that
> gave us the options:
>
> - killing already running apps before loading a
session
> - attempting to rename the apps without
restarting
them
> - load a new jack instance and connect it
with
netjack
I don't get why these features are supposed to need
support from jack
itself. Session handler/manager starts the apps
and it
for sure knows
how to kill them (ladishd does this already).
Renaming
of the clients is
not needed for ladish to operate, because ladishd
implements graph
virtualization and boxes you see on canvas
(clients)
can be renamed and
ports can be regrouped. For handling apps that
use
multiple JACK
clients, more useful will be to have a function
that
returns the
originally requested JACK client name. netjack
has two
main uses
(Internet and LAN) but I don't see how jack
session
callbacks relate to
it. ladish-2.0 (multihost capable) will be able
to
start additional jack
servers, local or remote and use netjack
tehcnology to
link them in
single multihost studio.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
9:39 a.m.
On Mon, 21 Dec 2009, Patrick Shirkey wrote:
The only person I can recall who had an explicit
objection to it was
Fons, who said he would stop using jack if it was accepted. Given that
[snip]
anyway). I don't think he should be allowed to
make the decision for
the rest of us about what is accepted to trunk and what is not. Also
I recall a few people agreeing with Fons. Plus, Fons is so
frigging thorough that... what should we write? "Yeah!!
What he said!" Hardly an important contribution to the
discussion.
Also, with the reception that Fons got, I'm sure there were
a few like me who kept their mouths shut unless they had
something important to contribute.
Anyway, FWIW, I agreed 100% with Fons... and IIRC he was
open to having an in-JACK session management API provided
that it played nice with a larger, more comprehensive
session manager. (I.e. partial session loading/saving, no
client renaming, etc.)
-gabriel
6:55 p.m.
On 12/22/2009 12:39 AM, Gabriel M. Beddingfield wrote:
On Mon, 21 Dec 2009, Patrick Shirkey wrote:
So you agree with Fon's statement that if the jack_session code is
accepted you would not want to use jack1 any longer and would support a
fork or stop using it completely and create your own realtime audio daemon?
While Fons is thorough with his criticism which is to be respected as it
helps to refine the knowledge base and code, that should not mean that
the option of having jack_session available for the rest of us to use is
completely off the table. We just need to be aware of the limitations.
I must have missed the part of the debate where it was agreed or even
defined that jack_session would not be able to play nicely with more
advanced managers. In fact Nedko even offered his support/interest for
making LADI work with jack_session. Being that LADI is real and publicly
released that should hold more weight than Fon's views on the matter.
As far as I can tell the design process broke down mostly because one
person made a strong case for not having any other form of session
management except the one that he is working on (and is now saying he is
not interested in releasing publicly) and consequently wound the other
parties up to the point where they decided it was too frustrating or
stressful to discuss it any further at that point.
Patrick Shirkey
Boost Hardware Ltd
The only person I can recall who had an explicit
objection to it was
Fons, who said he would stop using jack if it was accepted. Given that
[snip]
anyway). I don't think he should be allowed
to make the decision for
the rest of us about what is accepted to trunk and what is not. Also
I recall a few people agreeing with Fons. Plus, Fons is so frigging
thorough that... what should we write? "Yeah!! What he said!" Hardly
an important contribution to the discussion.
Also, with the reception that Fons got, I'm sure there were a few like
me who kept their mouths shut unless they had something important to
contribute.
Anyway, FWIW, I agreed 100% with Fons... and IIRC he was open to
having an in-JACK session management API provided that it played nice
with a larger, more comprehensive session manager. (I.e. partial
session loading/saving, no client renaming, etc.)
8:35 p.m.
On Tue, 22 Dec 2009, Patrick Shirkey wrote:
So you agree with Fon's statement that if the
jack_session code is
accepted you would not want to use jack1 any longer and would support a
fork or stop using it completely and create your own realtime audio daemon?
Probably about as much as you agree with Stéphane's threat
to do the same over dbus (which, IIRC, is closely related to
the session management debates). :-)
I must have missed the part of the debate where it was
agreed or even
defined that jack_session would not be able to play nicely with more
Here's a few with the most recent proposal:
* save/restore requires application to shut down and
restart.
* session callback does not work asynchronously
* process call graph must be halted during the
session callback (a consequence of not being
asynchronous).
Also, I wasn't comfortable with how the serialization should
work... but it was too early in the process to pick nits on
that.
As far as I can tell the design process broke down
mostly because one
person made a strong case for not having any other form of session
management except the one that he is working on (and is now saying he is
not interested in releasing publicly) and consequently wound the other
parties up to the point where they decided it was too frustrating or
stressful to discuss it any further at that point.
Once it's in the JACK API, it won't be coming out.
Likewise, changing it will be very difficult after the
fact... so it needs to be right.
If it's not in the JACK API, there is no argument.
-gabriel
9:02 p.m.
On 12/22/2009 11:35 AM, Gabriel M. Beddingfield wrote:
We have at least 3 options on the table for dealing with this.
The argument continues either way afaict ;-)
On Tue, 22 Dec 2009, Patrick Shirkey wrote:
Don't you mean Fons here? Stephane has already provided support for dbus
in jack2.
So you agree with Fon's statement that if the
jack_session code is
accepted you would not want to use jack1 any longer and would support a
fork or stop using it completely and create your own realtime audio
daemon?
Probably about as much as you agree with Stéphane's threat to do the
same over dbus (which, IIRC, is closely related to the session
management debates). :-)
I must have
missed the part of the debate where it was agreed or even
defined that jack_session would not be able to play nicely with more
Here's a few with the most recent proposal:
* save/restore requires application to shut down and
restart.
* session callback does not work asynchronously
We can add a non realtime thread.
* process call graph must be halted during the
session callback (a consequence of not being
asynchronous).
Also handled by a non realtime thread.
Also, I wasn't comfortable with how the
serialization should work...
but it was too early in the process to pick nits on that.
I haven't seen any specifics on that aspect until now.
As far as I
can tell the design process broke down mostly because one
person made a strong case for not having any other form of session
management except the one that he is working on (and is now saying he is
not interested in releasing publicly) and consequently wound the other
parties up to the point where they decided it was too frustrating or
stressful to discuss it any further at that point.
Once it's in the JACK API, it won't be coming out. Likewise, changing
it will be very difficult after the fact... so it needs to be right.
If it's not in the JACK API, there is no argument.
11:31 p.m.
On Mon, Dec 21, 2009 at 06:35:47PM -0600, Gabriel M. Beddingfield wrote:
On Tue, 22 Dec 2009, Patrick Shirkey wrote:
so you want it async ?
well... lets make it async then ?
So you agree with Fon's statement that if the
jack_session code is
accepted you would not want to use jack1 any longer and would support a
fork or stop using it completely and create your own realtime audio daemon?
Probably about as much as you agree with Stéphane's threat to do the
same over dbus (which, IIRC, is closely related to the session
management debates). :-)
I must have missed the part of the debate where it
was agreed or even
defined that jack_session would not be able to play nicely with more
Here's a few with the most recent proposal:
* save/restore requires application to shut down and
restart.
* session callback does not work asynchronously
* process call graph must be halted during the
session callback (a consequence of not being
asynchronous).
wrong.
Also, I wasn't comfortable with how the serialization should work...
but it was too early in the process to pick nits on that.
please state your problems.
As far as I can tell the design process broke down
mostly because one
person made a strong case for not having any other form of session
management except the one that he is working on (and is now saying he is
not interested in releasing publicly) and consequently wound the other
parties up to the point where they decided it was too frustrating or
stressful to discuss it any further at that point.
Once it's in the JACK API, it won't be coming out. Likewise,
changing it will be very difficult after the fact... so it needs to
be right.
If it's not in the JACK API, there is no argument.
-gabriel _______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
torben Hohn
22 Dec
22 Dec
1:33 a.m.
On Tue, 22 Dec 2009, torbenh wrote:
:-)
Two links (requires jack-devel list authentication):
http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/2009-Novemb…
http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/2009-Novemb…
I really think there should be a quit-without-save.
Also, with respect to saving and restoring sessions,
suppose this work-flow:
1. Save a session (#1) with Ardour as a part of it.
Instead of transferring GB of data to the
session-data-dir, it stores a handle[1] to the
data (i.e. a URI tracing back to a save state).
2. When session #1 is reloaded, Ardour loads the
handle to the original project's save state.
3. User forces an export to the session-data-dir.
This means that Ardour must transfer all the
gigabytes of data necc. to recreate the session.
4. User opens session #1 from an exported archive.
Ardour finds heavy data in the session-data-dir,
and uses it (rather than, say, importing the
data to some other location).
5. User does a "save as" on the current session,
thus saving Session #2. Ardour saves a handle to
a save-state from Session #1 (and Session #1's
session-data-dir).
6. User deletes Session #1. They now
have also corrupted Session #2.
This just seems, to me, messy and error-prone. To the end
user, I don't think it would ever be obvious that Session #2
depended on Session #1. Meanwhile application developers
have to find a stable way to work with session data, whether
it's handles or heavy data. They also have to negotiate
what it means when the user says "Save," but the data is in
a session-data-dir, and the user /didn't/ say "Save
Session."
Ways that it might be cleaned up:
1. Always require that session data be "heavy"
in the session-data-dir.
- or -
2. Only store handles to session data... and
don't even have a session-data-dir. Export
is a special step. Exported sessions must be
"imported" before being used.
- or -
3. Session manager implements some manner of
"session data database" that manages the
dependencies between resources and sessions.[2]
Applications transfer data to session manager
as something like a zip stream... and the session
manager is responsible for storage and retrieval.
#1 is, I think, the most stable... but at the price of
wasting a lot of disk space. #2 is fast and efficient, but
at a much greater risk of corrupting session data. #3 is
like #1, but the session manager implementation is able to
conserve resources and even be on another host.
-gabriel
[1] In my e-mail in November, I used the word "stub"
instead of "handle."
[2] Yes, this idea is a little "out there." :-)
* session
callback does not work asynchronously
so you want it async ?
well... lets make it async then ? Also, I
wasn't comfortable with how the serialization should work...
but it was too early in the process to pick nits on that.
please state your problems.
3:29 a.m.
This is a bit disingenuous to use as an example.
1.) Ardour doesn't have a save as state, to begin with, so it's
unique in the way it has to be handled. Apps equipped with save as,
don't need special treatment, so the user can save them wherever they
like.
2.) you assume it's either/or based on your ardour example for "heavy"
or "light". Again, this is based on an app where the session, once
created, cannot be moved, and can, at best, only be linked to. Save as
for most normal apps wouldn't hit any of the challenges you allege,
because the user could recall, save as, do another recall, etc,
without having to create new links, etc, simply because the app
session was "stuck in place for all time."
Wrong example, imho, based on a unique app that doesn't behave as
others do. For most other use cases, where apps are coded in a more
"normal" fashion, jacksession would, and has, behaved........normally.
On Tue, Dec 22, 2009 at 5:33 AM, Gabriel M. Beddingfield
<gabriel(a)teuton.org> wrote:
On Tue, 22 Dec 2009, torbenh wrote:
:-)
Two links (requires jack-devel list authentication):
http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/2009-Novemb…
http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/2009-Novemb…
I really think there should be a quit-without-save.
Also, with respect to saving and restoring sessions,
suppose this work-flow:
1. Save a session (#1) with Ardour as a part of it.
Instead of transferring GB of data to the
session-data-dir, it stores a handle[1] to the
data (i.e. a URI tracing back to a save state).
2. When session #1 is reloaded, Ardour loads the
handle to the original project's save state.
3. User forces an export to the session-data-dir.
This means that Ardour must transfer all the
gigabytes of data necc. to recreate the session.
4. User opens session #1 from an exported archive.
Ardour finds heavy data in the session-data-dir,
and uses it (rather than, say, importing the
data to some other location).
5. User does a "save as" on the current session,
thus saving Session #2. Ardour saves a handle to
a save-state from Session #1 (and Session #1's
session-data-dir).
6. User deletes Session #1. They now
have also corrupted Session #2.
This just seems, to me, messy and error-prone. To the end
user, I don't think it would ever be obvious that Session #2
depended on Session #1. Meanwhile application developers
have to find a stable way to work with session data, whether
it's handles or heavy data. They also have to negotiate
what it means when the user says "Save," but the data is in
a session-data-dir, and the user /didn't/ say "Save
Session."
Ways that it might be cleaned up:
1. Always require that session data be "heavy"
in the session-data-dir.
- or -
2. Only store handles to session data... and
don't even have a session-data-dir. Export
is a special step. Exported sessions must be
"imported" before being used.
- or -
3. Session manager implements some manner of
"session data database" that manages the
dependencies between resources and sessions.[2]
Applications transfer data to session manager
as something like a zip stream... and the session
manager is responsible for storage and retrieval.
#1 is, I think, the most stable... but at the price of
wasting a lot of disk space. #2 is fast and efficient, but
at a much greater risk of corrupting session data. #3 is
like #1, but the session manager implementation is able to
conserve resources and even be on another host.
-gabriel
[1] In my e-mail in November, I used the word "stub"
instead of "handle."
[2] Yes, this idea is a little "out there." :-)
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
* session
callback does not work asynchronously
so you want it async ?
well... lets make it async then ? Also, I
wasn't comfortable with how the serialization should work...
but it was too early in the process to pick nits on that.
please state your problems.
8:13 a.m.
On Tue, 22 Dec 2009, alex stone wrote:
This is a bit disingenuous to use as an example.
Not quite:
1. I was actually thinking of the database used
by _Audacity_ to store data. For some reason
I thought it was Ardour doing that. So,
s/Ardour/Audacity/g if you like. But it still
stands for Ardour because of the size of the
data and the fact that it has save states
(snapshots) but no Save-As.
2. I was thinking of my own, future, application
where I'm seriously considering having all
audio resources (for all sessions and
compositions) in a single, managed database...
similar to Git (as was stated in the link).
3. In my day job, I work extensively with 3D CAD
models for mechanical engineering, where you
have hundreds of files with implied relationships
between them (parts, assemblies, drawings). It's
a fragile mess that requires a managed database
to keep straight.
And I'm not Not NOT using the example to say "session
management is junk" OR to be combative. I'm thinking
through the case where session data is large and what that
means with a session data directory.
2.) you assume it's either/or based on your ardour
example for "heavy"
or "light". Again, this is based on an app where the session, once
created, cannot be moved, and can, at best, only be linked to. Save as
I'm talking about what happens when the data set for
the session is very large. It's going to happen, and people
are going to try and speed it up and conserve disk space.
What about the case where someone wants to save their
session that uses that 1 GB piano patch (gigasampler)? If
it's part of the session... should the whole patch be copied
to the session directory or not? If that's your favorite
patch, that's a lot of copies.
-gabriel
8:29 a.m.
On Tue, Dec 22, 2009 at 12:13 PM, Gabriel M. Beddingfield
<gabriel(a)teuton.org> wrote:
On Tue, 22 Dec 2009, alex stone wrote:
But this doesn't happen. Jacksession saves the project state. So the
project entitled "my twiddles with my big piano" is saved, not a
repetitive copy of each patch. Patched are loaded in the sampler,
once. the sampler state is saved for that project, and when you reopen
that session, Gigasampler loads the "same" patch for the session as
you requested as saved previously. Sampled patches usually reside on a
static drive, and are "called" for when required. The same is not only
true for Gigasampler, but linuxsampler, kontakt, and most samplers.
They "request" the sample set, i.e. GIG. NKI. SFZ. Other, and it is
made available to the app. One sample library, accessible by request.
Same patch, same app, loaded as required, not saved everytime as a new
patch, i,e, big piano 1, big piano 2 ,etc...
the sampler data, i.e. "when this session is opened, load this patch"
is saved, only.
The same would be true for most apps in a jacksession, with the
exception of recorded audio sessions, and tell me a smart studio, or
serious audio engineer, that doesn't make multiple copies of recorded
sessions, with the view that a messed up session can be discarded, and
the engineer can go back to the previously saved set.
Even for domestic audio users, who don't want to back everything up,
and simply overwrite the previously saved session, most of their
session data is going to be saving "data states", and the overwrite
will imprint the new saved session over the old. Not the way i would
work, but it does work for others, who are quite happy to keep one
session.
Alex.
This is a bit disingenuous to use as an example.
Not quite:
1. I was actually thinking of the database used
by _Audacity_ to store data. For some reason
I thought it was Ardour doing that. So,
s/Ardour/Audacity/g if you like. But it still
stands for Ardour because of the size of the
data and the fact that it has save states
(snapshots) but no Save-As.
2. I was thinking of my own, future, application
where I'm seriously considering having all
audio resources (for all sessions and
compositions) in a single, managed database...
similar to Git (as was stated in the link).
3. In my day job, I work extensively with 3D CAD
models for mechanical engineering, where you
have hundreds of files with implied relationships
between them (parts, assemblies, drawings). It's
a fragile mess that requires a managed database
to keep straight.
And I'm not Not NOT using the example to say "session management is junk"
OR
to be combative. I'm thinking through the case where session data is large
and what that means with a session data directory.
2.) you assume it's either/or based on your
ardour example for "heavy"
or "light". Again, this is based on an app where the session, once
created, cannot be moved, and can, at best, only be linked to. Save as
I'm talking about what happens when the data set for the session is very
large. It's going to happen, and people are going to try and speed it up
and conserve disk space.
What about the case where someone wants to save their session that uses that
1 GB piano patch (gigasampler)? If it's part of the session... should the
whole patch be copied to the session directory or not? If that's your
favorite patch, that's a lot of copies.
-gabriel
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
9:04 a.m.
On Tue, 22 Dec 2009, alex stone wrote:
the sampler data, i.e. "when this session is
opened, load this patch"
is saved, only.
This is what I called a "handle," and this is fine (but not
great)... when the user tries to move the session to another
computer, the session will not be able to load properly
because it will be missing stuff.
And I can be OK with that... as long as it's in the specs
that it should work this way.
But at the moment, it's not well defined what is part of the
"state,"[1] nor what should (and should not) be saved in a
"jacksession" directory, nor what can be expected WRT
portability.
-gabriel
[1] For example, is window size part of the state? What
about window placement? Minimize/maximize? Do we get
this info from the window manager or from the
application? Which data is considered an
installed, persistent resource (like a
Hydrogen drum kit) and which is considered "session
data"?
10:09 a.m.
On Tue, Dec 22, 2009 at 1:04 PM, Gabriel M. Beddingfield
<gabriel(a)teuton.org> wrote:
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
On Tue, 22 Dec 2009, alex stone wrote:
This is the case with any OS, and was my experience with win and mac
over many years. If you have a session with 3 synths, and you transfer
the session to another computer with only 2 of those synths, you
usually got some sort of message that read:
"Warning, this project may not play back correctly, as the following
synths are missing, blah blah blah......"
The session still loads, but you're aware that it may not play back as
you expect.
the sampler data, i.e. "when this session is
opened, load this patch"
is saved, only.
This is what I called a "handle," and this is fine (but not great)... when
the user tries to move the session to another computer, the session will not
be able to load properly because it will be missing stuff.
And I can be OK with that... as long as it's in the specs that it should
work this way.
But at the moment, it's not well defined what is part of the "state,"[1]
nor
what should (and should not) be saved in a "jacksession" directory, nor what
can be expected WRT portability.
But it was defined. A file that showed the saved state of each app
present in the session, and a list of all connections that were
current at the time the session was saved. Couldn't be simpler.
-gabriel
[1] For example, is window size part of the state? What
about window placement? Minimize/maximize? Do we get
this info from the window manager or from the
application? Which data is considered an
installed, persistent resource (like a
Hydrogen drum kit) and which is considered "session
data"?
Again, this is self-evident. If Hydrogen is saved with a particular
kit loaded, then when the session is reopened, that kit is loaded.
And i'm not sure what you do for window size, etc, but in my workflow,
i have apps opening, and default sized, into designated workspaces, so
no matter where the app is opened from, i.e., "Sequencer" opens in the
"Sequencer" workspace. Linux Window Manager Feature no.1, on a list of
many....
It's been my experience that whatever size window is last designated
when an app is saved and closed, is the size it opens to next time. If
this isn't the case with some apps, then surely this is down to the
application developer to code as a default behaviour, and not the role
of a session manager.
I would think, given the feature set we have in Linux, including
multiple workspaces, and the ability to allocate an app to a defined
workspace, and/or size, that this would be a cause for user session
nirvana, and i only know of gnome, where allocating an app to a
workspace isn't possible. (Has this changed?)
Alex.
10:32 a.m.
On Tue, 22 Dec 2009, alex stone wrote:
So, if 'Foomatic DAW' saves state with a one-liner like
this:
<foomatic_session id='EBC429B5-373B-4840-8CCA-99FBE045EF82' />
That satisfies the requirements of your sentence.
Is it OK with you that the session doesn't load because you
moved or deleted the original project files? And is it OK
with you that the session can't load on another computer
without manually restoring Foomatic's files?
Just asking. For me, the answer to both is, "Not really,
but I might be willing to settle for it, though."
-gabriel
And I can be
OK with that... as long as it's in the specs that it should
work this way.
But at the moment, it's not well defined what is part of the "state,"[1]
nor
what should (and should not) be saved in a "jacksession" directory, nor what
can be expected WRT portability.
But it was defined. A file that showed the saved state of each app
present in the session, and a list of all connections that were
current at the time the session was saved. Couldn't be simpler. 
10:42 a.m.
Gabriel M. Beddingfield wrote:
On Tue, 22 Dec 2009, alex stone wrote:
So, if 'Foomatic DAW' saves state with a one-liner like
this:
<foomatic_session id='EBC429B5-373B-4840-8CCA-99FBE045EF82' />
That satisfies the requirements of your sentence.
Is it OK with you that the session doesn't load because you
moved or deleted the original project files? And is it OK
with you that the session can't load on another computer
without manually restoring Foomatic's files?
IIRC Reaper prompts the user if files are missing from a project and
asks if the user wants Reaper to search for them. Seems like an easy
mechanism, potentially time-consuming unless the search can be delimited.
Best,
dp
But at the moment, it's not well defined what is part of the "state,"[1]
nor
what should (and should not) be saved in a "jacksession" directory, nor what
can be expected WRT portability.
But it was defined. A file that showed the saved state of each app
present in the session, and a list of all connections that were
current at the time the session was saved. Couldn't be simpler.
3:29 p.m.
On 12/23/2009 01:32 AM, Gabriel M. Beddingfield wrote:
On Tue, 22 Dec 2009, alex stone wrote:
So, if 'Foomatic DAW' saves state with a one-liner like
this:
<foomatic_session id='EBC429B5-373B-4840-8CCA-99FBE045EF82' />
That satisfies the requirements of your sentence.
Jack_session has gone a bit further already.
char *
session_callback (jack_session_event_t code, const char *path, const char *uuid, void
*arg)
It's not exactly portable because it relies on the app to do all the
work with file storage. To make it portable would require an addition to
the yet to be written management interface. Functionality could be added
to create a portable archive file of the session with a single click. We
already have the path for each clients internal data folders so all that
would be needed is to add a small function to the interface to copy them
to a new location, and compress the complete set of files.
That seems like a quick and efficient method of enabling session transfer.
My list of requirements for the session management interface is growing
but I'm happy to see them becoming more defined.
1: Provide options to user for handling client renaming issues with
clients that are already running.
- killing already running apps before loading a session
- attempting to rename the apps without restarting them
- load a new jack instance and connect it with via netjack
- load a new jack instance and connect it directly to the already
running jack instance. Should be ok with a multicore and plenty of
memory but is it possible to define a jack instance as a parent for a
jack child instance?
2: Provide one click archive feature to allow session transfer. Copy
client data folders to a new location, and compress the complete set of
files.
3: Define default behaviour in a config file.
I would be very happy to have this in place and it would accomplish
everything that I currently need for desktop session management. With
the exception of having a jack menu on the window decorations title bar
for each client and handle the session and connections management
through that. With the above in place I can wait another 10 years for
integrated desktop window manager functionality to arrive :-)
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd
And I can
be OK with that... as long as it's in the specs that it should
work this way.
But at the moment, it's not well defined what is part of the "state,"[1]
nor
what should (and should not) be saved in a "jacksession" directory, nor what
can be expected WRT portability.
But it was defined. A file that showed the saved state of each app
present in the session, and a list of all connections that were
current at the time the session was saved. Couldn't be simpler.
3:41 p.m.
On 12/23/2009 06:27 AM, Patrick Shirkey wrote:
On 12/23/2009 01:32 AM, Gabriel M. Beddingfield
wrote:
integrated desktop window manager functionality
That should be on some packaging and promo material somewhere real soon now.
On Tue, 22 Dec 2009, alex stone wrote:
So, if 'Foomatic DAW' saves state with a one-liner like
this:
<foomatic_session id='EBC429B5-373B-4840-8CCA-99FBE045EF82' />
That satisfies the requirements of your sentence.
Jack_session has gone a bit further already.
char *
session_callback (jack_session_event_t code, const char *path, const char *uuid, void
*arg)
It's not exactly portable because it relies on the app to do all the
work with file storage. To make it portable would require an addition to
the yet to be written management interface. Functionality could be added
to create a portable archive file of the session with a single click. We
already have the path for each clients internal data folders so all that
would be needed is to add a small function to the interface to copy them
to a new location, and compress the complete set of files.
That seems like a quick and efficient method of enabling session transfer.
My list of requirements for the session management interface is growing
but I'm happy to see them becoming more defined.
1: Provide options to user for handling client renaming issues with
clients that are already running.
- killing already running apps before loading a session
- attempting to rename the apps without restarting them
- load a new jack instance and connect it with via netjack
- load a new jack instance and connect it directly to the already
running jack instance. Should be ok with a multicore and plenty of
memory but is it possible to define a jack instance as a parent for a
jack child instance?
2: Provide one click archive feature to allow session transfer. Copy
client data folders to a new location, and compress the complete set of
files.
3: Define default behaviour in a config file.
I would be very happy to have this in place and it would accomplish
everything that I currently need for desktop session management. With
the exception of having a jack menu on the window decorations title bar
for each client and handle the session and connections management
through that. With the above in place I can wait another 10 years for
integrated desktop window manager functionality to arrive :-)
And I can
be OK with that... as long as it's in the specs that it should
work this way.
But at the moment, it's not well defined what is part of the "state,"[1]
nor
what should (and should not) be saved in a "jacksession" directory, nor what
can be expected WRT portability.
But it was defined. A file that showed the saved state of each app
present in the session, and a list of all connections that were
current at the time the session was saved. Couldn't be simpler.
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd
5:36 a.m.
On Mon, 2009-12-21 at 23:33 -0600, Gabriel M. Beddingfield wrote:
Also, with respect to saving and restoring sessions,
suppose this work-flow:
1. Save a session (#1) with Ardour as a part of it.
Instead of transferring GB of data to the
session-data-dir, it stores a handle[1] to the
data (i.e. a URI tracing back to a save state).
2. When session #1 is reloaded, Ardour loads the
handle to the original project's save state.
3. User forces an export to the session-data-dir.
This means that Ardour must transfer all the
gigabytes of data necc. to recreate the session.
4. User opens session #1 from an exported archive.
Ardour finds heavy data in the session-data-dir,
and uses it (rather than, say, importing the
data to some other location).
5. User does a "save as" on the current session,
thus saving Session #2. Ardour saves a handle to
a save-state from Session #1 (and Session #1's
session-data-dir).
6. User deletes Session #1. They now
have also corrupted Session #2.
If you work with a session-managed Ardour, why not store audio files
within the session-data-dir? Otherwise I see no reason _not_ to use the
same exact Ardour session directories as now, keeping everything
external and just needing one link to it.
There is no "Save As" in Ardour. If there was, it would create a new
session directory, including an "audiofiles" dir with hardlinks to the
required audio files (symlinks if they are on another drive, though).
No problem with deleting the other hardlinks, the symlink case remains
ugly.
I've long been thinking that the "handling heavy audio files" problem
should be tackled together with the "using any media files within some
kind of document or session" problem, combined with the
linking-vs-embedding issue.
Locally, you would never embed files, but always use handles of a kind
that withstand renaming and moving of the files. Sending/transfering a
document/session elsewhere would trigger bundling of all required files.
Ideally, this would even include plugins. Think system-level dependency
tracking and resolution.
Well, seeing how difficult to impossible it is for people here to find
consensus, I guess I shouldn't hope for LADers to team up with projects
like Inkscape, Scribus and Lumiera :)
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
6:45 a.m.
torbenh wrote:
On Sun, Dec 20, 2009 at 09:11:04PM +0100, rosea
grammostola wrote:
@Torben, thanks for your answer. It seems one side effect of becoming a
session handler programmer, is getting a lot of debate. But this is
maybe not unexpected, cause it 'hits' the whole community. Also history
has shown that it will take at least some time to implement a session
handler. So maybe it's not realistic to expect consensus in a relative
short period.
Anyway, to get a more clear picture of the situation, I think it's good
to know what the opinions are from the (former) LASH maintainers. So
@Bob Ham, David Robillard and Juuso Alasuutari,
Can you describe in your own words:
1) What are the strong and weak points of LADI in your opinion and why?
2) What will be a good approach now for getting a Linux audio session
handler in your opinion
(taking also LASH/LADI/Jack Session and Fons ideas in account)?
3) Are you willing to contribute to an solution and how do you see this
(own project / collaboration with other projects etc.).
Please try to keep it short and to the point.
Thanks in advance,
\r
1) What do you want to achieve with jack
session.
session management ?
load/save of whole jack graph .
2) How do you think you are able to achieve it?
with very few exceptions every app thats a target for session
management, is a jack client.
so why not add some callbacks, and let the sessionmanager
communicate with apps via jack ?
this basically reduces the size of the app patches.
allowing me to patch at least one app per hour.
3) Why do you think this is the best way to do
it?
every app is already using jack IPC to communicate with jackd.
-> minimally invasive on the app.
no reinvention of the wheel or yet another IPC mechanism to add.
anyways... effort is frozen.
we are dumping a working implementation.
22 Dec
22 Dec
12:57 p.m.
On Mon, 2009-12-21 at 11:45 +0100, rosea grammostola wrote:
[...]
@Bob Ham, David Robillard and Juuso Alasuutari,
Can you describe in your own words:
1) What are the strong and weak points of LADI in your opinion and why?
2) What will be a good approach now for getting a Linux audio session
handler in your opinion
(taking also LASH/LADI/Jack Session and Fons ideas in account)?
3) Are you willing to contribute to an solution and how do you see this
(own project / collaboration with other projects etc.).
If contributing to a solution involves participating in this dead-end
"discussion", which will obviously never come to consensus, then no. I
am willing to implement a solution that does not suck.
Please try to keep it short and to the point.
Short and to the point, SIMPLE (to implement), low or no dependencies,
actually existent, portable. Interface is by a very wide margin the
most important thing.
Which of the present approaches best meets these goals should be
obvious; you tell me. I would prefer we go one further and just do a
"ladspa.h of session management" and throw away the implementation
detail crap that is the problem here entirely, but I don't really care
enough to deal with the torture of participating in threads like this.
The parties involved are obviously never going to let go of their
implementation (or imaginary hypothetical implementation, or whatever),
so there is no point in that.
I will probably end up creating something like the aforementioned header
for use in plugins anyway, though.
-dr
1:24 p.m.
David Robillard wrote:
On Mon, 2009-12-21 at 11:45 +0100, rosea grammostola
wrote:
[...]
@David, thanks for your reply.
"Portable to other platforms", can you explain why that is important for
you?
@Bob Ham, David Robillard and Juuso Alasuutari,
Can you describe in your own words:
1) What are the strong and weak points of LADI in your opinion and why?
2) What will be a good approach now for getting a Linux audio session
handler in your opinion
(taking also LASH/LADI/Jack Session and Fons ideas in account)?
3) Are you willing to contribute to an solution and how do you see this
(own project / collaboration with other projects etc.).
Short and to the point, SIMPLE (to implement), low or no dependencies,
actually existent, portable. Interface is by a very wide margin the
most important thing.
Which of the present approaches best meets these goals should be
obvious; you tell me.
It's sounds to me more like the 'jack session
approach' then the 'LADI
approach', right?
I will probably end up creating something like the
aforementioned header
for use in plugins anyway, though.
Which workflow do you prefer?
One 'all-in-one-app' like Ardour with (LV2) plugins or the modular
approach of connecting different jack applications to each other, or both?
Regards,
\r
4:35 p.m.
On Mon, 2009-12-21 at 11:45 +0100, rosea grammostola wrote:
Anyway, to get a more clear picture of the situation,
I think it's good
to know what the opinions are from the (former) LASH maintainers. So
@Bob Ham, David Robillard and Juuso Alasuutari,
Can you describe in your own words:
1) What are the strong and weak points of LADI in your opinion and why?
The strong points are very pragmatic; Nedko is actually making commits
and working on things. Which means he's likely to produce something
usable and fitting some requirements. "History is made by those who
turn up."
The huge, major weak point that would prevent me from investing myself
in LADI is the use of D-Bus which requires an extra, external layer in
order to perform routing between objects on different buses. See my
previous mail on the subject here:
http://lalists.stanford.edu/lad/2009/11/0350.html
From what Nedko has said on IRC, I believe LADISH has
such a layer.
2) What will be a good approach now for getting a
Linux audio session
handler in your opinion
(taking also LASH/LADI/Jack Session and Fons ideas in account)?
I believe a good session handler will require some very good network
protocol definitions. From what Fons has said, he may be into this so I
would say Fons should publish his protocol. Assuming people can focus
on constructive criticism rather than politics or flamage, this would no
doubt be productive.
3) Are you willing to contribute to an solution and
how do you see this
(own project / collaboration with other projects etc.).
Willing but not really able (unless someone is wants to pony up some
cash to replace the income from my job; I can't see that happening
though.) Considerations about the mode of contribution are therefore
moot.
--
Bob Ham <rah(a)bash.sh>
5:22 p.m.
Hi Bob,
thanks for commenting on LADI stuff
The huge, major weak point that would prevent me from
investing myself
in LADI is the use of D-Bus which requires an extra, external layer in
order to perform routing between objects on different buses. See my
previous mail on the subject here:
http://lalists.stanford.edu/lad/2009/11/0350.html
>From what Nedko has said on IRC, I believe LADISH has such a layer.
D-Bus *can* span over multiple hosts. I've sent mail to this mailing
list that explains how to do it and what needs to be improved:
http://lalists.stanford.edu/lau/2009/11/0043.html
see also:
http://www.freedesktop.org/wiki/Software/DBusRemote (probably somewhat
obsolete, check the timestamp and the missing link to gabriel site).
I've adopted the gabriel project because it is possible to improve it as
a mean to achieve multihost LADI studios in future:
http://gabriel.sourceforge.net/
That said, there is no guarantee that ladish will use D-Bus for
communication between daemon and apps. LASH got this mainly because of
Juuso Alasuutari and because it was subject of his Summercode
project. My aim with "D-Bus + LASH" was to use D-Bus for lashd <-> jack
comunication and for lashd <-> control app communication. I agreed on
using D-Bus for app <-> lashd communication because that simplified
(yes it did) the LASH codebase. The use of D-Bus for app <-> ladishd IPC
was risky and it took some time to fix bugs, but at the end we made it
to work acceptably well.
Also, there is no guarantee that ladish will use D-Bus for remote IPC.
I have rough plan how to use D-Bus for multihost studios, but there is
lot of work to do until 1.0 is reached. After 1.0 is reached, I will
reconsider available options for the multihost capable ladish (that
will be 2.0), I will decide and I'll provide finer milestones to
acomplish this goal, in the same way as I did for 1.0.
In summary, I plan to use D-Bus at least until ladish-1.0 is
relased. I've seen lot of arguments against D-Bus and so far I din't
find them valid for the goals I'm working for. If D-Bus gets proven as
wrong choice for single hosts studio before the release of 1.0, I'll
have to change it early. However I find such incident highly
non-probable. Chances for remote D-Bus being not suitable are slightly
higher and I'll reconsider D-Bus after ladish-1.0 release. Until then,
D-Bus is the IPC technology that allows me to implement LADI features in
fastest possible way and does not look as something that I'll abandon
soon.
This mail is not intended to be offensive to anyone. If someone dislikes
D-Bus for one reason or another it is his right.
I'm always open for constructive discussions, especially if they are in
the scope of the LADI project. I'm open and glad for the feedback of
early jackdbus and ladish adopters.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
8 p.m.
On Tue, 2009-12-22 at 23:21 +0200, Nedko Arnaudov wrote:
Hi Bob,
thanks for commenting on LADI stuff
The main issue isn't whether D-Bus clients can connect to buses on a
different host. The main issue is whether D-Bus clients connected to
one bus can send messages to objects on a different bus.
I was actually labouring under the impression that D-Bus as-is could
cope with connecting to remote hosts because it uses sockets. That this
isn't the case is, in fact *another* problem with D-Bus.
D-Bus clients can't send messages to objects on remote buses. As-is,
they can't even connect to buses on remote hosts. Shocking.
--
Bob Ham <rah(a)bash.sh>
The huge, major weak point that would prevent me
from investing myself
in LADI is the use of D-Bus which requires an extra, external layer in
order to perform routing between objects on different buses. See my
previous mail on the subject here:
http://lalists.stanford.edu/lad/2009/11/0350.html
>From what Nedko has said on IRC, I believe LADISH has such a layer.
D-Bus *can* span over multiple hosts.
23 Dec
23 Dec
7:29 a.m.
Bob Ham <rah(a)bash.sh> writes:
On Tue, 2009-12-22 at 23:21 +0200, Nedko Arnaudov
wrote:
Applications can connect to multiple buses. Even applications that don't
interract with remote machines do it. There are two standard local
buses, the session bus and the system bus. Here is a screenshot of a
dbus application called d-feet that shows two buses connected:
http://www.j5live.com/wp-content/uploads/2007/12/d-feet-016-execute.png
Hi Bob,
thanks for commenting on LADI stuff
The main issue isn't whether D-Bus clients can connect to buses on a
different host. The main issue is whether D-Bus clients connected to
one bus can send messages to objects on a different bus. The huge, major weak point that would prevent me
from investing myself
in LADI is the use of D-Bus which requires an extra, external layer in
order to perform routing between objects on different buses. See my
previous mail on the subject here:
http://lalists.stanford.edu/lad/2009/11/0350.html
>From what Nedko has said on IRC, I believe LADISH has such a layer.
D-Bus *can* span over multiple hosts. 
I was actually labouring under the impression that
D-Bus as-is could
cope with connecting to remote hosts because it uses sockets. That this
isn't the case is, in fact *another* problem with D-Bus.
D-Bus clients can't send messages to objects on remote buses. As-is,
they can't even connect to buses on remote hosts. Shocking.
I already replied to this:
http://lalists.stanford.edu/lad/2009/12/0296.html
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
8:05 a.m.
On Wed, 2009-12-23 at 13:28 +0200, Nedko Arnaudov wrote:
Applications can connect to multiple buses. Even applications that don't
interract with remote machines do it. There are two standard local
buses, the session bus and the system bus. Here is a screenshot of a
dbus application called d-feet that shows two buses connected:
That application will necessarily have two connection objects within it
(eg, DBusGConnection,) encapsulating connections to the two buses. If
you could have just one client object and use it to send messages to
objects on both buses, that would be great. Unfortunately, that isn't
what D-Bus does.
My comment was less a criticism of your approach to LADISH development
and more a general criticism of using D-Bus for a network-wide audio
session system.
--
Bob Ham <rah(a)bash.sh>
Bob Ham <rah(a)bash.sh> writes:
> On Tue, 2009-12-22 at 23:21 +0200, Nedko Arnaudov wrote:
D-Bus *can* span over multiple hosts.
The main issue isn't whether D-Bus clients can connect to buses on a
different host. The main issue is whether D-Bus clients connected to
one bus can send messages to objects on a different bus. I was actually
labouring under the impression that D-Bus as-is could
cope with connecting to remote hosts because it uses sockets. That this
isn't the case is, in fact *another* problem with D-Bus.
D-Bus clients can't send messages to objects on remote buses. As-is,
they can't even connect to buses on remote hosts. Shocking.
I already replied to this:
6:25 p.m.
Nedko Arnaudov wrote:
Hi Bob,
thanks for commenting on LADI stuff
Thanks for your explanation Nedko. It is clear to me that you see D-Bus
as the best practical solution at the moment. But that you do not
necessarily stick with it for always. You are open for discussion
which is good in my opinion. Others seems to think that D-Bus is not
the solution for an session handler for Linux audio. It doesn't have to
be bad to have different opinions or different ways to solve a problem.
Nedko, is LADI an project of your own, or are you willing to collaborate
with other developers who might have interest in the project? Do I
understand it right that characteristics of LADI are still open for
discussion?
Maybe it aint that bad to have two types of Session handlers for Linux.
The LADI approach and another approach without D-Bus. It's not bad to
have choice as user and maybe someone needs the features of LADI and
others features of more minimal session handlers.
Till now, LADI seems to be the only project that has reach an status so
that it actually works and is useful for musicians. Other projects seems
to be ideas on paper, nothing practical useful yet.
As a user I'm hoping that LADI will become an success, cause at the end
we really need an workable session handler. On the other hand I also
hope that people like Fons, Bob, Torben and David are able to release an
session handler without D-Bus. They have proven to have good ideas and
programming skills.
I think it will be good to have as much as consensus and especially
collaboration as possible. It would be good if others join the LADI
project I think. But I can't say which project goals are somewhat close
to the LADI project goals. Someone said that Torbens ideas could be
implemented or used in LADI in some way maybe. Then it would be good
maybe, to have a good (privat) discussion between the developers (at
least Nedko seems to say he stands open for that).
And what about the other ideas? Is there a chance that David, Fons, Bob
and others could find consensus between each other for a non D-Bus
solution? I think everyone would agree that collaboration should be
preferable here.
Today there is only one choice and that is LADI, so I'll test that first
and hope it works good enough for me so that at least I don't have to
launch all different applications again and again. It would be a big
breakthrough in Linux Audio imho. And then wait till an non-D-bus
solution appears, and see if that really works better...
Best wishes,
\r
The huge, major weak point that would prevent me
from investing myself
in LADI is the use of D-Bus which requires an extra, external layer in
order to perform routing between objects on different buses. See my
previous mail on the subject here:
http://lalists.stanford.edu/lad/2009/11/0350.html
D-Bus *can* span over multiple hosts. I've sent mail to this mailing
list that explains how to do it and what needs to be improved:
http://lalists.stanford.edu/lau/2009/11/0043.html
see also:
http://www.freedesktop.org/wiki/Software/DBusRemote (probably somewhat
obsolete, check the timestamp and the missing link to gabriel site).
I've adopted the gabriel project because it is possible to improve it as
a mean to achieve multihost LADI studios in future:
http://gabriel.sourceforge.net/
That said, there is no guarantee that ladish will use D-Bus for
communication between daemon and apps. LASH got this mainly because of
Juuso Alasuutari and because it was subject of his Summercode
project. My aim with "D-Bus + LASH" was to use D-Bus for lashd <-> jack
comunication and for lashd <-> control app communication. I agreed on
using D-Bus for app <-> lashd communication because that simplified
(yes it did) the LASH codebase. The use of D-Bus for app <-> ladishd IPC
was risky and it took some time to fix bugs, but at the end we made it
to work acceptably well.
Also, there is no guarantee that ladish will use D-Bus for remote IPC.
I have rough plan how to use D-Bus for multihost studios, but there is
lot of work to do until 1.0 is reached. After 1.0 is reached, I will
reconsider available options for the multihost capable ladish (that
will be 2.0), I will decide and I'll provide finer milestones to
acomplish this goal, in the same way as I did for 1.0.
In summary, I plan to use D-Bus at least until ladish-1.0 is
relased. I've seen lot of arguments against D-Bus and so far I din't
find them valid for the goals I'm working for. If D-Bus gets proven as
wrong choice for single hosts studio before the release of 1.0, I'll
have to change it early. However I find such incident highly
non-probable. Chances for remote D-Bus being not suitable are slightly
higher and I'll reconsider D-Bus after ladish-1.0 release. Until then,
D-Bus is the IPC technology that allows me to implement LADI features in
fastest possible way and does not look as something that I'll abandon
soon.
I'm always open for constructive discussions, especially if they are in
the scope of the LADI project. I'm open and glad for the feedback of
early jackdbus and ladish adopters.
From what Nedko has said on IRC, I believe LADISH
has such a layer.
24 Dec
24 Dec
2:34 p.m.
rosea grammostola <rosea.grammostola(a)gmail.com> writes:
Nedko, is LADI an project of your own, or are you
willing to collaborate
with other developers who might have interest in the project? Do I
understand it right that characteristics of LADI are still open for
discussion?
LADI is a project that I started about two years ago. While it is me
that is mainly driving it, it is not some kind of dictatorship. In past,
several devlopers have contributed code and even more users have
contributed ideas and provided feedback. Progress of the project brought
some well defined properties of the LADI system. While they can be
changed for sure, a large part of the involved people needs to
agree. As I, for good or bad, am playing the role of the leader of this
thing, I am responsible for decisions that affect the viability of the
LADI system. Hopefully this explains why my statements about some
subjects are so strong sometimes. It is good for the LADI project to
have more active developers. As a developer of this project, I've
collaborated with different people from the LAD community, and the
result was almost always good.
Maybe it aint that bad to have two types of Session
handlers for Linux.
The LADI approach and another approach without D-Bus. It's not bad to
have choice as user and maybe someone needs the features of LADI and
others features of more minimal session handlers.
It is always better to have more software to choose from. Unfortunately,
the reasons for so called competition in open source projects is often
working against users, because of the NIH (Not Invented Here) syndrome
and the SEP (Somebody Else's Problem) effect. I would really like to
beleive that I am wrong. And I would like LAD community to be less
stagnant and more open for new ideas and different perspectives.
Till now, LADI seems to be the only project that has
reach an status so
that it actually works and is useful for musicians. Other projects seems
to be ideas on paper, nothing practical useful yet.
As a user I'm hoping that LADI will become an success, cause at the end
we really need an workable session handler. On the other hand I also
hope that people like Fons, Bob, Torben and David are able to release an
session handler without D-Bus. They have proven to have good ideas and
programming skills.
I also hope that this will happen. More software we have, more value
this community has. Lets favour software creation instead of busting
flame wars.
I think it will be good to have as much as consensus
and especially
collaboration as possible. It would be good if others join the LADI
project I think. But I can't say which project goals are somewhat close
to the LADI project goals. Someone said that Torbens ideas could be
implemented or used in LADI in some way maybe. Then it would be good
maybe, to have a good (privat) discussion between the developers (at
least Nedko seems to say he stands open for that).
Yes I am open, as long as it is not at cost of killing the whole
project. One of the other projects I've started, zynjacku, is an example
of how project direction has shifted without sacrificing the original
goals. And this shift happened because of the community. Zynjacku got
more improvements for LV2 plugins with static set of ports and custom
GUIs (like calf and invada plugins) than it got for dynparam generic
GUIs (the lv2zynadd plugin).
Весела Коледа
Merry Christmas
Joyeux Noël
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
25 Dec
25 Dec
10:46 a.m.
Nedko Arnaudov wrote:
rosea grammostola <rosea.grammostola(a)gmail.com>
writes:
http://www.google.de/#hl=de&source=hp&q=starting+jack+with+dbus+sup…
did link to user wishes, e.g.
http://old.nabble.com/dbus-support-for-jack--td26467201.html
As a user never ask anything about multimedia at forums for
non-audio-distros like openSUSE. Within one question you'll become a
troll. Whatever. We can choose an audio-distro.
I do understand that audio-distros can't be state-of-the-art all the
time, but I don't understand that even if JACK without dbus support is
preferred by some (maybe all) audio-distros, there isn't a second
package for JACK supporting dbus.
We users ask for this, but nothing happens.
For today I planed to compile latest kernel-rt and Qtractor and then to
make music with latest Qtractor, Calf Monosynth and Jconv + GUI. 1. I
will write a shell script that is able to launch all applications, this
will be no big deal. 2. The script should connect JACK audio
connections, also no big deal, because I will use jack_snapshot to do
it, unfortunately Qtractor can't do this, the possibility to restore
connections is limited. 3. The needed ALSA MIDI connections can be
restored by Qtractor. 4. IIRC I once tried to build
http://home.gna.org/a2jmidid/ for 64 Studio, to restore the JACK MIDI to
ALSA MIDI bridge connections, but it failed. I'll try to build it today.
Maybe I'll use Calf DSSI or, because it's new LV2 with Qtractor instead
of running the Calf host.
Anyway, linux audio users need to prepare a lot. This is time-consuming.
*Many users want Nedko*'*s session handler*! Coders of other
applications should reconsider the dbus issue, keeping in mind, that the
user needs a session handler.
Some time ago I started a script that is able to take snapshots of a
session, not a real auto session handler, but anyway a help. It is able
to detect running audio applications, because it has got a list with all
audio applications, maybe I'll complete this script, but I don't think
so. I guess just writing a script that fit to a single session is easy
to do. This don't has the advantages we expect from a session handler,
but IMO it's the only way to restore audio sessions at the moment.
I still have got one major problem. I don't know any virtual mixing
console for Linux that is able to restore fader positions. I'm not
talking about mixers for applications like Qtractor, just for a mixer to
connect Calf Monosynths and Jconv. I only need something similar to jackEQ.
OT: I'll compile git clone http://nedko.arnaudov.name/git/lv2fil.git
for 64 Studio today too, for Suse it's already compiled :).
My 2 cents,
Ralf
[snip]
[snip]
11:39 a.m.
Ralf Mardorf wrote:
Nedko Arnaudov wrote:
The amount of users who wants LADI are
not that large atm. Mainly
because they do not know what to expect after the disappointing progress
of LASH. When LADI preview 0.2 will be released I expect that at least a
part of the community want to use it, so that the ask for LADI and
jackdbus support for distro's will grow. That's why I find it important
to think about how to handle the jackdbus situation now, before many
users start using jackdbus/Ladish.
I'm not surprised myself that distro's doesn't support it yet. It looks
like the LA community is searching for ways to handle the situation now.
Package maintainers will pick up the results of the discussion and
solutions after. Don't forget they also have to deal with Jack1 and Jack2.
So first, LADI is not that mature atm, all though progressing quickly
now. Qjackctl doesn't work well with jackdbus atm. It's the question (at
least for me) what jackdbus means for the use of Ardour. It's still a
question about the best approach by distro's. Only jackd, only jackdbus
or both mixed?
When qjackctl can handle jackdbus in a satisfying way, and when it's
clear what a good approach is, jackd, jackdbus or both... then it would
be more easy to decide what and how to implement. Maybe you see it in
the 2010 distro releases, who knows.
Till then, the best way imo, is to have different repo's with jackdbus
and ladish packages, which people who want to test or use Ladish, can
use. You might want to contact Nedko about how to package this stuff (I
think he made some packages for Ubuntu 8.04 a while ago).
\r
rosea grammostola
<rosea.grammostola(a)gmail.com> writes:
http://www.google.de/#hl=de&source=hp&q=starting+jack+with+dbus+sup…
did link to user wishes, e.g.
http://old.nabble.com/dbus-support-for-jack--td26467201.html
As a user never ask anything about multimedia at forums for
non-audio-distros like openSUSE. Within one question you'll become a
troll. Whatever. We can choose an audio-distro.
I do understand that audio-distros can't be state-of-the-art all the
time, but I don't understand that even if JACK without dbus support is
preferred by some (maybe all) audio-distros, there isn't a second
package for JACK supporting dbus.
We users ask for this, but nothing happens. [snip]
[snip]
12:16 p.m.
rosea grammostola wrote:
(I think he made some packages for Ubuntu 8.04 a while
ago).
Today I'll backup my 64 Studio, this might be a good time to compile
JACK2 featuring dbus after doing the backup, but I don't think I'll do
this, after all the other work I'll have to do.
Compiling LADISH isn't a problem (resp. maybe I'm wrong and it is a
problem for me), but for Suse and Debian based distros JACK2 can't be
simply compiled and installed while the package or all files of the
package aren't removed, because a self compiled JACK2 at least handles
libjack in a different way and removing the distro's package does cause
to much trouble.
Oops, right now I noticed that there's a package called "jackdbus" for
64 Studio's current version of jackd :). Embarrassing :S.
Hm, maybe I don't need to recompile LADI :).
spinymouse-sudo@64studio:~$ gladish
Loading glade from /usr/share/ladish/gui.glade
dbus_call_simple: calling method 'IsStarted' failed, error is 'The name
org.jackaudio.service was not provided by any .service files'
spinymouse-sudo@64studio:~$ sudo apt-get install jackdbus
[snip]
spinymouse-sudo@64studio:~$ gladish
Loading glade from /usr/share/ladish/gui.glade
dbus_call_simple: calling method 'IsStarted' failed, error is 'The name
org.jackaudio.service was not provided by any .service files'
Hm? Any hints are welcome! Did I need to compile LADI again or is
something inconsistent?
I guess I'll cross-post this.
Ralf
PS: OTOH I guess I use applications that don't support dbus, thus LADI
might not be a valid solution right now.
12:31 p.m.
spinymouse-sudo@64studio:~$ sudo apt-get install
jackdbus
[snip]
spinymouse-sudo@64studio:~$ gladish
Loading glade from /usr/share/ladish/gui.glade
dbus_call_simple: calling method 'IsStarted' failed, error is 'The
name org.jackaudio.service was not provided by any .service files'
Content of the package:
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/jackdbus
/usr/share/doc/jackdbus/copyright
/usr/share/doc/jackdbus/changelog.Debian.gz
/usr/share/doc/jackdbus/TODO
/usr/share/doc/jackdbus/README.gz
/usr/share/doc/jackdbus/changelog.gz
;)
It made me wonder that a package should be able to add jackdbus to jackd
that isn't compiled with jackdbus, it's just the well known advice how
to compile jackd with dbus support.
12:32 p.m.
Ralf Mardorf wrote:
rosea grammostola wrote:
All Jack apps work with Ladish at level 0 at least (autolaunch of apps
in a studio and auto activation of connections). which is already pretty
useful imo.
http://ladish.org/wiki/levels
But this is more a question for a user list imo.
\r
(I think he made some packages for Ubuntu 8.04 a
while ago).
Today I'll backup my 64 Studio, this might be a good time to compile
JACK2 featuring dbus after doing the backup, but I don't think I'll do
this, after all the other work I'll have to do.
Compiling LADISH isn't a problem (resp. maybe I'm wrong and it is a
problem for me), but for Suse and Debian based distros JACK2 can't be
simply compiled and installed while the package or all files of the
package aren't removed, because a self compiled JACK2 at least handles
libjack in a different way and removing the distro's package does
cause to much trouble.
Oops, right now I noticed that there's a package called "jackdbus" for
64 Studio's current version of jackd :). Embarrassing :S.
Hm, maybe I don't need to recompile LADI :).
spinymouse-sudo@64studio:~$ gladish
Loading glade from /usr/share/ladish/gui.glade
dbus_call_simple: calling method 'IsStarted' failed, error is 'The
name org.jackaudio.service was not provided by any .service files'
spinymouse-sudo@64studio:~$ sudo apt-get install jackdbus
[snip]
spinymouse-sudo@64studio:~$ gladish
Loading glade from /usr/share/ladish/gui.glade
dbus_call_simple: calling method 'IsStarted' failed, error is 'The
name org.jackaudio.service was not provided by any .service files'
Hm? Any hints are welcome! Did I need to compile LADI again or is
something inconsistent?
I guess I'll cross-post this.
Ralf
PS: OTOH I guess I use applications that don't support dbus, thus LADI
might not be a valid solution right now.
3:49 p.m.
On Fri, Dec 25, 2009 at 05:16:22PM +0100, Ralf Mardorf wrote:
but for Suse and Debian based distros JACK2 can't
be simply compiled
and installed while the package or all files of the package aren't
removed,
There's jack2 in Debian experimental, and you're free to download the
package source:
http://packages.debian.org/source/experimental/jack-audio-connection-kit
You then say dpkg-source -x *.dsc and run debuild in the directory. Feel
free to modify debian/rules, so you can add all the flags that you want.
I've disabled the jackdbus package at the moment, because I have yet to
try it myself and get the big picture. (to be honest, I'm not entirely
sure there's consensus about jackdbus, but I don't want to re-start this
lengthy discussion again)
Oops, right now I noticed that there's a package
called "jackdbus" for
Which is empty, as you've already shown. That was one of the reasons why
I've disabled it for now in the experimental package.
I must confess I know almost nothing about jackdbus. All I know is that
it can talk to pulseaudio to get the soundcard back, which, on the other
hand, is completely unimportant to usual studio setups where you have a
cheap (mainboard) system card and the real, unused recording card.
Given that it's unused, I don't have to ask anybody about releasing it,
so simply starting jackd does the trick.
Feel free to educate me. ;)
PS: For the occasional jackd-on-my-builtin-laptop-card-user, it would be
sufficient to run jackd *on top* of pulseaudio and no cards are handed
over back and forth. Latency on these chips is crap anyway, real work
beyond tweaking some volume curves isn't done, so it's all about running
jackd *somehow* to get the inter-app-routing. I suggest to add a PA
backend for jackd, that is, jackd -d pulse.
Steinberg does this on Win32, you can run your Cubase with poor latency
on top of the ordinary D3D- or MME API. Though nobody would ever use
this for recording or any other decent work, it gives you the chance of
running the app, make small changes and export a mixdown. That's roughly
the level one could expect from a builtin soundcard, for everything
else, additional audio gear would be used.
I think pleasing the desktop user who insists to run jackd on his el
cheapo card could be achieved with this jack-on-PA approach. This would
remove the need for passing access to sound hardware between PA and
jackd.
Just my €0.02
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
4:01 p.m.
Adrian Knoth wrote:
There's jack2 in Debian experimental, and
you're free to download the
package source:
http://packages.debian.org/source/experimental/jack-audio-connection-kit
You then say dpkg-source -x *.dsc and run debuild in the directory. Feel
free to modify debian/rules, so you can add all the flags that you want.
Thank you :)
6 Jan
6 Jan
9:24 a.m.
Adrian Knoth wrote:
On Fri, Dec 25, 2009 at 05:16:22PM +0100, Ralf Mardorf
wrote:
Hi,
The development version of Qjackctl seems to have (partial) jackdbus
support now. I have jackd (--classic) and jackdbus (--dbus) on my system
without big problems. The only problem you can get it when you stop an
certain 'studio' in Ladish, some apps seems to autolaunch jackd, and a
running jackd prevents jackdbus to be started. I suggested the Ladish
developers to implement some kind of mechanism which tracks if jackd is
running when jackdbus/ladish can't be started.
But I suggest you to enable both --classic and --dbus for Debian, along
with the latest qjackctl with jackdbus support, so people can use jackd
and jackdbus.
\r
but for Suse and Debian based distros JACK2
can't be simply compiled
and installed while the package or all files of the package aren't
removed,
There's jack2 in Debian experimental, and you're free to download the
package source:
http://packages.debian.org/source/experimental/jack-audio-connection-kit
You then say dpkg-source -x *.dsc and run debuild in the directory. Feel
free to modify debian/rules, so you can add all the flags that you want.
I've disabled the jackdbus package at the moment, because I have yet to
try it myself and get the big picture. (to be honest, I'm not entirely
sure there's consensus about jackdbus, but I don't want to re-start this
lengthy discussion again)
Oops, right now I noticed that there's a
package called "jackdbus" for
Which is empty, as you've already shown. That was one of the reasons why
I've disabled it for now in the experimental package.
I must confess I know almost nothing about jackdbus. All I know is that
it can talk to pulseaudio to get the soundcard back, which, on the other
hand, is completely unimportant to usual studio setups where you have a
cheap (mainboard) system card and the real, unused recording card.
Given that it's unused, I don't have to ask anybody about releasing it,
so simply starting jackd does the trick.
Feel free to educate me. ;)
PS: For the occasional jackd-on-my-builtin-laptop-card-user, it would be
sufficient to run jackd *on top* of pulseaudio and no cards are handed
over back and forth. Latency on these chips is crap anyway, real work
beyond tweaking some volume curves isn't done, so it's all about running
jackd *somehow* to get the inter-app-routing. I suggest to add a PA
backend for jackd, that is, jackd -d pulse.
Steinberg does this on Win32, you can run your Cubase with poor latency
on top of the ordinary D3D- or MME API. Though nobody would ever use
this for recording or any other decent work, it gives you the chance of
running the app, make small changes and export a mixdown. That's roughly
the level one could expect from a builtin soundcard, for everything
else, additional audio gear would be used.
I think pleasing the desktop user who insists to run jackd on his el
cheapo card could be achieved with this jack-on-PA approach. This would
remove the need for passing access to sound hardware between PA and
jackd.
Just my €0.02
25 Dec
25 Dec
7:12 p.m.
On 12/26/2009 01:46 AM, Ralf Mardorf wrote:
I still have got one major problem. I don't know any virtual mixing
console for Linux that is able to restore fader positions. I'm not
talking about mixers for applications like Qtractor, just for a mixer to
connect Calf Monosynths and Jconv. I only need something similar to jackEQ.
This is something I have planned for a while but never got round to
finishing.
The main problem was at the time I wrote jackEQ I didn't fully
understand how to use a config file. 6 years later I should have another
go at it...
Anyway have you checked out either of these tools?
http://home.gna.org/jackmixer/
http://www.arnoldarts.de/drupal/?q=JackMix
Patrick Shirkey
Boost Hardware Ltd
OT: I'll compile git clone
http://nedko.arnaudov.name/git/lv2fil.git
for 64 Studio today too, for Suse it's already compiled :).
My 2 cents,
Ralf
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
9:48 p.m.
Patrick Shirkey wrote:
On 12/26/2009 01:46 AM, Ralf Mardorf wrote:
Thank you.
Nedko referred to this one off-list and I'll compile it later.
Unclear GUI. I don't like it.
I still have got one major problem. I don't
know any virtual mixing
console for Linux that is able to restore fader positions. I'm not
talking about mixers for applications like Qtractor, just for a mixer to
connect Calf Monosynths and Jconv. I only need something similar to jackEQ.
This is something I have planned for a while but never got round to
finishing.
The main problem was at the time I wrote jackEQ I didn't fully
understand how to use a config file. 6 years later I should have another
go at it...
Anyway have you checked out either of these tools?
http://home.gna.org/jackmixer/
26 Dec
26 Dec
12:25 a.m.
Am Samstag, den 26.12.2009, 02:48 +0100 schrieb Ralf Mardorf:
This is something I have planned for a while but never got round to
finishing.
The main problem was at the time I wrote jackEQ I didn't fully
understand how to use a config file. 6 years later I should have another
go at it...
Anyway have you checked out either of these tools?
http://home.gna.org/jackmixer/
Thank you.
Nedko referred to this one off-list and I'll compile it later.
Unclear GUI. I don't like it.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Patrick Shirkey wrote:
> On 12/26/2009 01:46 AM, Ralf Mardorf wrote:
>
>> I still have got one major problem. I don't know any virtual mixing
>> console for Linux that is able to restore fader positions. I'm not
>> talking about mixers for applications like Qtractor, just for a mixer to
>> connect Calf Monosynths and Jconv. I only need something similar to jackEQ.
>>
>>
That's the special task, were jcgui is build for. All settings
will auto
store, you could save them additional as preset(session).
Only a small rework is needed to make a multi channel mixer out of the
source. :-)
hermann
7:18 a.m.
New subject: JackMix [was: LADI]
On 26/12/2009, "Ralf Mardorf" <ralf.mardorf(a)alice-dsl.net> wrote:
Any ideas as to how to get it to recognize JACK in /usr/local/lib64/ ?
8:13 a.m.
New subject: JackMix [was: LADI]
On 12/26/2009 10:18 PM, james morris wrote:
On 26/12/2009, "Ralf
Mardorf"<ralf.mardorf(a)alice-dsl.net> wrote:
Any ideas as to how to get it to recognize JACK in /usr/local/lib64/
?
At compile time or runtime?
For compile time you might need to specify --libdir =/usr/lib64
For runtime you might need to change a hardcoded value somewhere.
Patrick Shirkey
Boost Hardware Ltd
8:40 a.m.
New subject: JackMix [was: LADI]
On 26/12/2009, "Patrick Shirkey" <pshirkey(a)boosthardware.com> wrote:
On 12/26/2009 10:18 PM, james morris wrote:
Compile time. --libdir fails also.
I've tried all sorts of variations of passing /usr/local/lib64 to scons,
but it always fails.
ie:
LIBS=/usr/local/lib64 scons
JACKLIBS=/usr/local/lib64 scons
JACK_LIBS=/usr/local/lib64 scons
etc etc etc
pkg-config does work:
musys2@Scrapyard:~/SRC/jackmix-0.4.1$ pkg-config --libs jack
-L/usr/local/lib64 -ljack -lpthread -lrt
here's the SConstruct file:
env = Environment( tools=['default', 'pkgconfig', 'qt4muc' ],
toolpath=['admin'] )
env.Replace( LIBS="" )
env.Replace( LIBPATH="" )
env['CXXFLAGS']+="-Wall -Werror -g -fpic"
tests = { }
tests.update( env['PKGCONFIG_TESTS'] )
conf = Configure( env, custom_tests=tests, conf_dir='cache',
log_file='cache/config.log' )
if not conf.CheckHeader( 'stdio.h', language="C" ):
Exit( 1 )
if not conf.CheckHeader( "iostream", language="C++" ):
Exit( 1 )
allpresent = 1
allpresent &= conf.CheckForPKGConfig()
pkgs = {
'jack' : '0.100.0',
'lash-1.0' : '0.5.1',
'QtCore' : '4.2',
'QtGui' : '4.2',
'QtXml' : '4.2',
}
for pkg in pkgs:
name2 =
pkg.replace("+","").replace(".","").replace("-","").upper()
env['%s_FLAGS' % name2] = conf.GetPKGFlags( pkg, pkgs[pkg] )
if env['%s_FLAGS'%name2] == 0:
allpresent &= 0
if not allpresent:
print "(At least) One of the dependencies is missing. I can't
go on without it..."
Exit( 1 )
env = conf.Finish()
env.MergeFlags( "-I#" )
env.MergeFlags( env["QTCORE_FLAGS"] )
## target processing is done in the subdirectory
env.SConscript(
dirs=['libcore','libqlash','libgui','backend','libmatrix','libelements','jackmix'],
exports="env" )
On 26/12/2009, "Ralf
Mardorf"<ralf.mardorf(a)alice-dsl.net> wrote:
Any ideas as to how to get it to recognize JACK in /usr/local/lib64/ ?
At compile time or runtime?
For compile time you might need to specify --libdir =/usr/lib64
8:50 a.m.
New subject: JackMix [was: LADI]
On 12/26/2009 11:40 PM, james morris wrote:
On 26/12/2009, "Patrick
Shirkey"<pshirkey(a)boosthardware.com> wrote:
^^^^^^^^^^^^^^^^^^^^^
Those two look like the vars to fix. Otherwise you could try installing
jack into /usr/local/lib or alternatively adding the path to
/etc/ld.so.conf
Patrick Shirkey
Boost Hardware Ltd
On 12/26/2009 10:18 PM, james morris wrote:
Compile time. --libdir fails also.
I've tried all sorts of variations of passing /usr/local/lib64 to scons,
but it always fails.
ie:
LIBS=/usr/local/lib64 scons
JACKLIBS=/usr/local/lib64 scons
JACK_LIBS=/usr/local/lib64 scons
etc etc etc
pkg-config does work:
musys2@Scrapyard:~/SRC/jackmix-0.4.1$ pkg-config --libs jack
-L/usr/local/lib64 -ljack -lpthread -lrt
here's the SConstruct file:
env = Environment( tools=['default', 'pkgconfig', 'qt4muc' ],
toolpath=['admin'] )
env.Replace( LIBS="" )
env.Replace( LIBPATH="" )
On 26/12/2009, "Ralf
Mardorf"<ralf.mardorf(a)alice-dsl.net> wrote:
Any ideas as to how to get it to recognize JACK in
/usr/local/lib64/ ?
At compile time or runtime?
For compile time you might need to specify --libdir =/usr/lib64
10:11 a.m.
New subject: JackMix [was: LADI]
On Sat, Dec 26, 2009 at 7:40 AM, james morris <james(a)jwm-art.net> wrote:
I've tried all sorts of variations of passing
/usr/local/lib64 to scons,
but it always fails.
ie:
LIBS=/usr/local/lib64 scons
JACKLIBS=/usr/local/lib64 scons
JACK_LIBS=/usr/local/lib64 scons
etc etc etc
you seem to be unaware that scons deliberately ignores everything in
your environment.
pkg-config does work:
then use it from within scons.
6:32 p.m.
New subject: JackMix [was: LADI]
On 26/12/2009, "Paul Davis" <paul(a)linuxaudiosystems.com> wrote:
I'm asking as a potential user of jackmix for a quick fix to get jackmix
to build when jack is installed in /usr/local/lib64. If anyone has built
jackmix with jack installed in this location could you please let me
know how you did it, thanks.
james.
On Sat, Dec 26, 2009 at 7:40 AM, james morris
<james(a)jwm-art.net> wrote:
I've tried all sorts of variations of passing
/usr/local/lib64 to scons,
but it always fails.
ie:
LIBS=/usr/local/lib64 scons
JACKLIBS=/usr/local/lib64 scons
JACK_LIBS=/usr/local/lib64 scons
etc etc etc
you seem to be unaware that scons deliberately ignores everything in
your environment.
pkg-config does work:
then use it from within scons.
I've tried
all sorts of variations of passing /usr/local/lib64 to scons,
but it always fails.
ie:
LIBS=/usr/local/lib64 scons
JACKLIBS=/usr/local/lib64 scons
JACK_LIBS=/usr/local/lib64 scons
etc etc etc
you seem to be unaware that scons deliberately ignores everything in
your environment.
pkg-config does work:
then use it from within scons.
27 Dec
27 Dec
3:19 a.m.
New subject: JackMix [was: LADI]
james morris wrote:
On 26/12/2009, "Paul Davis"
<paul(a)linuxaudiosystems.com> wrote:
I'm asking as a potential user of jackmix for a quick fix to get jackmix
to build when jack is installed in /usr/local/lib64. If anyone has built
jackmix with jack installed in this location could you please let me
know how you did it, thanks.
james.
I had a similar problem at runtime:
spinymouse-sudo@64studio:/usr/local/lib64$ jconvolver --help
jconvolver: error while loading shared libraries:
libzita-convolver.so.2: cannot open shared object file: No such file or
directory
spinymouse-sudo@64studio:/usr/local/lib64$ sudo ln -s
/usr/local/lib64/libzita-convolver.so.2.0.0 /usr/lib/libzita-convolver.so.2
spinymouse-sudo@64studio:/usr/local/lib64$ jconvolver --help
On command line:
Unknown option '--'.
Use '-h' to see all options.
Btw.:
spinymouse-sudo@64studio:/usr/local/lib64$ ls -l
/usr/local/lib64/libzita-convolver.so*
lrwxrwxrwx 1 root root 26 2009-12-23 17:04
/usr/local/lib64/libzita-convolver.so -> libzita-convolver.so.2.0.0
-rwxr-xr-x 1 root root 23968 2009-12-23 17:04
/usr/local/lib64/libzita-convolver.so.2.0.0
spinymouse-sudo@64studio:/usr/local/lib64$ ls -l /usr/local | grep lib
drwxr-xr-x 14 root root 12288 2009-12-27 07:51 lib
drwxr-xr-x 2 root root 4096 2009-12-27 07:39 lib64
spinymouse-sudo@64studio:/usr/local/lib64$ ls -l /usr | grep lib
drwxr-xr-x 214 root root 126976 2009-12-27 07:51 lib
drwxr-xr-x 34 root root 36864 2009-12-13 12:19 lib32
lrwxrwxrwx 1 root root 3 2009-04-21 15:23 lib64 -> lib
Okay, in my case it would be possible to run ./configure --prefix=/usr,
but I wished to have everything in /usr/local, that means the libs in
/usr/local/lib. The link has to be outside /local. Jconvolver is in /local.
Jc_Gui now is fine :).
Ciao,
Ralf
On Sat, Dec 26, 2009 at 7:40 AM, james morris
<james(a)jwm-art.net> wrote:
I've tried all sorts of variations of passing
/usr/local/lib64 to scons,
but it always fails.
ie:
LIBS=/usr/local/lib64 scons
JACKLIBS=/usr/local/lib64 scons
JACK_LIBS=/usr/local/lib64 scons
etc etc etc
you seem to be unaware that scons deliberately ignores everything in
your environment.
pkg-config does work:
then use it from
within scons.
I've
tried all sorts of variations of passing /usr/local/lib64 to scons,
but it always fails.
ie:
LIBS=/usr/local/lib64 scons
JACKLIBS=/usr/local/lib64 scons
JACK_LIBS=/usr/local/lib64 scons
etc etc etc
you seem to be unaware that scons deliberately ignores everything in
your environment.
pkg-config does work:
then use it from
within scons.
9:52 a.m.
New subject: JackMix [was: LADI]
On Sun, Dec 27, 2009 at 2:19 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
if you install libraries and want them to be found automatically when
a program runs, then the location that you installed them in has to be
known to ld.so, the runtime linker. that means that it has to be
defined in /etc/ld.so.conf or whatever directory-based equivalent of
that is used by your distro. once the location is defined, the ld.so
cache needs to be updated, an operation that can only be done by root.
man ld.so
man ldconfig
will reveal more.
I'm asking
as a potential user of jackmix for a quick fix to get jackmix
to build when jack is installed in /usr/local/lib64. If anyone has built
jackmix with jack installed in this location could you please let me
know how you did it, thanks.
james.
I had a similar problem at runtime:
28 Dec
28 Dec
2:48 p.m.
New subject: JackMix [was: LADI]
Paul Davis wrote:
On Sun, Dec 27, 2009 at 2:19 AM, Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
if you install libraries and want them to be found automatically when
a program runs, then the location that you installed them in has to be
known to ld.so, the runtime linker. that means that it has to be
defined in /etc/ld.so.conf or whatever directory-based equivalent of
that is used by your distro. once the location is defined, the ld.so
cache needs to be updated, an operation that can only be done by root.
man ld.so
man ldconfig
will reveal more.
Running ldconfig was the first I did, but you're right, I missed that
/usr/local/lib64 wasn't added to the configuration, resp. I should have
added a link, because for 64 Studio/ Ubuntu the 64bit libs are in
/usr/local/lib, resp. /usr/lib.
OT for this problem: However there seems to be a bug for the configure
or make file, because jconvolver wants libzita-convolver.so.2, but after
compiling and installing there were only
/usr/local/lib64/libzita-convolver.so -> libzita-convolver.so.2.0.0 and
libzita-convolver.so.2.0.0, thus even if I wouldn't have made this
mistake, a link /any/used/lib_path/libzita-convolver.so.2.0.0 ->
/any/used/lib_path/libzita-convolver.so.2 is missing and needs to be added.
spinymouse-sudo@64studio:/etc/ld.so.conf.d$ ls
kde4.conf libc.conf x86_64-linux-gnu.conf
spinymouse-sudo@64studio:/etc/ld.so.conf.d$ cat libc.conf
# libc default configuration
/usr/local/lib
spinymouse-sudo@64studio:/etc/ld.so.conf.d$ cat x86_64-linux-gnu.conf
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
spinymouse-sudo@64studio:/etc/ld.so.conf.d$ cat kde4.conf
/usr/lib/kde4/lib
Hm, /usr/lib, /usr/lib32 will be found by default? /usr/lib64 -> lib is
a link.
Anyway, I fixed it now:
spinymouse-sudo@64studio:/usr/local/lib64$ ls
libzita-convolver.so libzita-convolver.so.2.0.0
spinymouse-sudo@64studio:/usr/local/lib64$ sudo mv * /usr/local/lib
spinymouse-sudo@64studio:/usr/local/lib64$ cd ..
spinymouse-sudo@64studio:/usr/local$ sudo mv
/usr/lib/libzita-convolver.so.2 /usr/local/lib
spinymouse-sudo@64studio:/usr/local$ sudo rm -r lib64
spinymouse-sudo@64studio:/usr/local$ sudo ln -s /usr/local/lib
/usr/local/lib64
spinymouse-sudo@64studio:/usr/local$ sudo ldconfig
spinymouse-sudo@64studio:/usr/local$ jconvolver -h
Jconvolver 0.8.4
(C) 2006-2009 Fons Adriaensen <fons(a)kokkinizita.net>
Usage: jconvolver <options> <config file> {<connect file>}
Options:
-h Display this text
-v Print partition list to stdout [off]
-L <nframes> Try to compensate <nframes> latency
-M Use the FFTW_MEASURE option [off]
-N <name> Name to use as JACK client [jconvolver]
Thank you :).
Ralf
I'm
asking as a potential user of jackmix for a quick fix to get jackmix
to build when jack is installed in /usr/local/lib64. If anyone has built
jackmix with jack installed in this location could you please let me
know how you did it, thanks.
james.
I had a similar problem at runtime:
27 Dec
27 Dec
11:03 a.m.
New subject: JackMix [was: LADI]
On Saturday 26 December 2009 23:32:41 james morris wrote:
I'm asking as a potential user of jackmix for a
quick fix to get jackmix
to build when jack is installed in /usr/local/lib64. If anyone has built
jackmix with jack installed in this location could you please let me
know how you did it, thanks.
You could just try to ask the author (and not hide it in a very boring thread
about ladi...
As far as I see it, either PKG_CONFIG_PATH doesn't contain the directory where
your custom jack installation put its pc file. Or scons is not importing this
variable into its environment. And as I used to have a custom jack in $HOME
and had $HOME/lib/pkgconfig in PKG_CONFIG_PATH and that was found by scons
alright as far as I can remember, I am kind of thinking the first is the
problem.
Arnold
12:38 p.m.
New subject: JackMix [was: LADI]
You could just try to ask the author (and not hide it
in a very boring
Just not got round to it yet.
As far as I see it, either PKG_CONFIG_PATH doesn't
contain the directory >your custom jack installation put its pc file. Or scons is not
importing ME
Both PKG_CONFIG_PATH and /etc/ld.so.conf are setup. I have built numerous
software sources against jack successfully, including others which use
scons.
11:05 a.m.
New subject: JackMix [was: LADI]
On Saturday 26 December 2009 12:18:11 james morris wrote:
On 26/12/2009, "Ralf Mardorf"
<ralf.mardorf(a)alice-dsl.net> wrote:
Any ideas as to how to get it to recognize JACK in /usr/local/lib64/ ?
Tell pkg-config that /usr/local/lib64/pkgconfig is to be used. See the man-page
of pkg-config and look out for PKG_CONFIG_PATH...
Arnold
26 Dec
26 Dec
10:11 p.m.
Patrick Shirkey wrote:
Perhaps I should post this to a user list, sorry.
$ jack_mixer
Cannot load LASH python bindings, you want them unless you enjoy manual
jack plumbing each time you use this app
Traceback (most recent call last):
File "/usr/local/bin/jack_mixer", line 42, in <module>
from channel import *
File "/usr/local/bin/../share/jack_mixer/channel.py", line 20, in
<module>
import glib
ImportError: No module named glib
No GUI appears. It's build from git.
10:26 p.m.
Patrick Shirkey wrote:
Perhaps I should post this to a user list, sorry.
$ jack_mixer
Cannot load LASH python bindings, you want them unless you enjoy manual
jack plumbing each time you use this app
Traceback (most recent call last):
File "/usr/local/bin/jack_mixer", line 42, in <module>
from channel import *
File "/usr/local/bin/../share/jack_mixer/channel.py", line 20, in
<module>
import glib
ImportError: No module named glib
No GUI appears. It's build from git.
spinymouse-sudo@64studio:~$ sudo gedit
/usr/local/share/jack_mixer/channel.py
spinymouse-sudo@64studio:~$ jack_mixer
Cannot load LASH python bindings, you want them unless you enjoy manual
jack plumbing each time you use this app
Cannot connect to server socket err = No such file or directory
Cannot connect to server socket
JackActivationCount::Signal value = 0 ref = 2
JackActivationCount::Signal value = 0 ref = 2
New channel "776" volume mapped to CC#11
New channel "776" balance mapped to CC#12
Cleaning jack_mixer
After I commented out line 20 it seems to be fine.
10:28 p.m.
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> writes:
Patrick Shirkey wrote:
Perhaps I should post this to a user list, sorry.
$ jack_mixer
Cannot load LASH python bindings, you want them unless you enjoy manual
jack plumbing each time you use this app
Traceback (most recent call last):
File "/usr/local/bin/jack_mixer", line 42, in <module>
from channel import *
File "/usr/local/bin/../share/jack_mixer/channel.py", line 20, in
<module>
import glib
ImportError: No module named glib
No GUI appears. It's build from git.
Have you read the INSTALL file?
You need pygtk with cairo support and I guess this implies the python
glib module too.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
10:44 p.m.
Nedko Arnaudov wrote:
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
writes:
IIUC what I found in the internet, glib is missing for Ubuntu Hardy (64
Studio 3.0-beta3). Hm, now I only have the .deb package build by
checkinstall, I'll clone from git within the next days again and read
INSTALL more carefully.
Patrick Shirkey wrote:
Perhaps I should post this to a user list, sorry.
$ jack_mixer
Cannot load LASH python bindings, you want them unless you enjoy manual
jack plumbing each time you use this app
Traceback (most recent call last):
File "/usr/local/bin/jack_mixer", line 42, in <module>
from channel import *
File "/usr/local/bin/../share/jack_mixer/channel.py", line 20, in
<module>
import glib
ImportError: No module named glib
No GUI appears. It's build from git.
Have you read the INSTALL file?
You need pygtk with cairo support and I guess this implies the python
glib module too.
22 Dec
22 Dec
3:17 p.m.
On Sun, 2009-12-20 at 13:13 +0100, torbenh wrote:
On Sun, Dec 20, 2009 at 11:23:54AM +0100, rosea
grammostola wrote:
This all seems a bit odd to me. Session handling is not necessarily
about what the community wants. It's about what the people implementing
the session handling system want. If that's in line with what other
people want then it will be used. If it's in line with what many people
want then it will become widespread. You can't please all of the people
all of the time.
I think the problem with jack session is nothing to do with consensus
within the general context of LAD and entirely to do with consensus
within the context of JACK. And it's no surprise that a consensus
wasn't reached because implementing session handling within JACK itself
is neither necessary or, I believe the right thing to do. I cannot
think of any reason why JACK would ever need awareness of session
handling.
As for LAD being dead, I think LV2 shows that it's still very much
alive.
--
Bob Ham <rah(a)bash.sh>
Gabriel M. Beddingfield wrote:
dunno... jack session is frozen now.
it took a huge flame war to find out some implications of the
requirements.
so basically i dont think we can reach consensus.
and sessionhandling is _only_ about consensus. its not a problem at all
to implement.
lad is dead. When I'm not in group 1, I'm hanging out
in group 4.
Inter-host and headless session management is important to
me, too.
I really do hope that Fons releases his code. :-)
@Fons, thanks for your reply. It seems that you're not planned to make a
session handler for the mass... That's not bad at all in many cases.
Good luck with it and I hope you decide to release your code.
Ok, roughly we have 4 groups now (assuming that we can call >1
individuals a group ;) )
Group 1 has spoken, group 3 and group 4.
What can we expect from group 2? Maybe some of the lash developers
belongs in this group?
Dave, Juuso, Bob Ham, ... ? What are your plans now?
4:02 p.m.
On Sat, 2009-12-19 at 23:19 +0100, fons(a)kokkinizita.net wrote:
given the quite hostile reactions
shown in recent threads, and the probably minute potential
user base, the chances that the results will be made public
are rather small.
I would strongly encourage you to release your work to the public.
Which is to say: can I have a copy please? :-)
--
Bob Ham <rah(a)bash.sh>
3:57 p.m.
On Sat, 2009-12-19 at 21:15 +0100, rosea grammostola wrote:
Bob Ham wrote:
> On Tue, 2009-11-24 at 16:53 +0100, Adrian Knoth wrote:
>
>> On Tue, Nov 24, 2009 at 08:53:02AM +0000, Bob Ham wrote:
>>
>>
>>> local sessions are a subset of the functionality provided by network
>>> sessions
>>>
>> If you want to have network transparency inside the audio framework,
>> this perspective might be true.
>>
>
> I do want that.
1) The 'one app with plugins' group.
2) The people who likes to work with different, small
Jack applications
(ams, aeolus, epichord etc.). These people are interested in a session
handler. But they think dbus is the wrong approach, it is to limited for
them, or it is not the right thing for the Linux platform in their opinion.
3) Group 3 is the same as group 2, BUT they have
chosen dbus as
solution. It's the LADI group.
As Fons noted, there is a fourth group of people who are interested in
network-wide audio session handling, for various purposes. This is
actually the most important group as far as I'm concerned because their
goals are a superset of the second and third groups' goals.
We can expect that group 3 will build a session
handler for us. LADI is
in active development and they already made some progress.
Now I'm wondering, what can we expect from group
2?
From group 2 and 4, you can probably expect something.
I have designs for an OSC-based system, JIZZ, that has been mentioned as
the successor to LASH. It exists quite clearly in my mind. I've also
made some designs on paper and put them here:
http://pkl.net/~node/software/lash/lash-2.jpeg
Unfortunately, I don't have the time to refine the design, produce a
protocol and implement it. I'm currently working toward an MSc degree.
It's possible that I may continue work on JIZZ at some point in the
foreseeable future after completing my MSc. It's also possible that I
may work toward a PhD, in which case it's unlikely I'll have time to
work on JIZZ, at least within a useful time frame.
However, Florian Faber recently communicated with me privately based on
this thread and seemed to have similar ideas to mine. Particularly,
using OSC over TCP and mDNS for service advertisements. From that
communication, it also seemed as though Florian might have the time and
energy to produce something. I don't know what will come of that
though; Florian?
Fons also has similar ideas (or did in the past.) Particularly, about
using OSC and also about focusing on the protocol rather than the
implementation. Fons has already commented on his own activity.
--
Bob Ham <rah(a)bash.sh>
4:19 p.m.
On 12/23/2009 06:57 AM, Bob Ham wrote:
On Sat, 2009-12-19 at 21:15 +0100, rosea grammostola
wrote:
Interesting choice of name. The more times you say it the funnier it
becomes...
What were you thinking?
Patrick Shirkey
Boost Hardware Ltd
Bob Ham wrote:
> On Tue, 2009-11-24 at 16:53 +0100, Adrian Knoth wrote:
>
>
>> On Tue, Nov 24, 2009 at 08:53:02AM +0000, Bob Ham wrote:
>>
>>
>>
>>> local sessions are a subset of the functionality provided by network
>>> sessions
>>>
>>>
>> If you want to have network transparency inside the audio framework,
>> this perspective might be true.
>>
>>
> I do want that.
>
1) The 'one app with plugins' group.
2) The people who likes to work with different,
small Jack applications
(ams, aeolus, epichord etc.). These people are interested in a session
handler. But they think dbus is the wrong approach, it is to limited for
them, or it is not the right thing for the Linux platform in their opinion.
3) Group 3 is the same as group 2, BUT they have
chosen dbus as
solution. It's the LADI group.
As Fons noted, there is a fourth group of people who are interested in
network-wide audio session handling, for various purposes. This is
actually the most important group as far as I'm concerned because their
goals are a superset of the second and third groups' goals.
We can expect that group 3 will build a session
handler for us. LADI is
in active development and they already made some progress.
Now I'm wondering, what can we expect from
group 2?
From group 2 and 4, you can probably expect something.
I have designs for an OSC-based system, JIZZ, that has been mentioned as
the successor to LASH. It exists quite clearly in my mind. I've also
made some designs on paper and put them here:
http://pkl.net/~node/software/lash/lash-2.jpeg
Unfortunately, I don't have the time to refine the design, produce a
protocol and implement it. I'm currently working toward an MSc degree.
It's possible that I may continue work on JIZZ at some point in the
foreseeable future after completing my MSc. It's also possible that I
may work toward a PhD, in which case it's unlikely I'll have time to
work on JIZZ, at least within a useful time frame.
However, Florian Faber recently communicated with me privately based on
this thread and seemed to have similar ideas to mine. Particularly,
using OSC over TCP and mDNS for service advertisements. From that
communication, it also seemed as though Florian might have the time and
energy to produce something. I don't know what will come of that
though; Florian?
Fons also has similar ideas (or did in the past.) Particularly, about
using OSC and also about focusing on the protocol rather than the
implementation. Fons has already commented on his own activity.
7:40 p.m.
On Wed, 2009-12-23 at 07:18 +1100, Patrick Shirkey wrote:
It resulted from some childishness between Dave Robillard and myself. I
was mocking Dave's insulting description of my intended work as
"masturbatory coding." The slightly tenuous acronym stands for JACK
Internetworked Zen Zounds :-)
--
Bob Ham <rah(a)bash.sh>
On 12/23/2009 06:57 AM, Bob Ham wrote:
I have designs
for an OSC-based system, JIZZ,
Interesting choice of name. The more times you say it the funnier it
becomes...
What were you thinking?
23 Dec
23 Dec
6:58 a.m.
On Tue, Dec 22, 2009 at 07:57:27PM +0000, Bob Ham wrote:
It exists quite clearly in my mind. I've also
made some designs on
paper and put them here:
http://pkl.net/~node/software/lash/lash-2.jpeg
Worst draft I've ever seen. If you can't even be bothered to clearly
write down your goals...
Sorry, I cannot comment any further, it's just ridiculous.
SCNR
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
9:08 a.m.
On Wed, 2009-12-23 at 11:58 +0100, Adrian Knoth wrote:
On Tue, Dec 22, 2009 at 07:57:27PM +0000, Bob Ham
wrote:
There seems to be some confusion here. Those are some sketches from my
personal notebook to aid in my thinking. They were scanned in and put
on a web server to supplement IRC discussions in the past. They were
posted here in an effort to fully communicate the amount and status of
work on JIZZ.
These sketches are not a "draft" of any kind document. Their content is
not meant to aid in the communication of ideas to fellow LAD members.
You are absolutely right, I haven't been bothered to clearly write down
the goals, or any other ideas related to JIZZ, that currently exist
in my head. Alas, my time here is finite.
--
Bob Ham <rah(a)bash.sh>
It exists quite clearly in my mind. I've
also made some designs on
paper and put them here:
http://pkl.net/~node/software/lash/lash-2.jpeg
Worst draft I've ever seen. If you can't even be bothered to clearly
write down your goals...
9:43 a.m.
On Wed, 23 Dec 2009, Bob Ham wrote:
There seems to be some confusion here. Those are some sketches from my
Bob... the end of the message was "SCNR" which means "Sorry,
Could Not Resist." I think he was just ribbing you.
-gabriel
It exists quite clearly in my mind. I've also
made some designs on
paper and put them here:
http://pkl.net/~node/software/lash/lash-2.jpeg
Worst draft I've ever seen. If you can't even be bothered to clearly
write down your goals...
9:59 a.m.
On Wed, 2009-12-23 at 07:43 -0600, Gabriel M. Beddingfield wrote:
On Wed, 23 Dec 2009, Bob Ham wrote:
There seems to be some confusion here. Those are some sketches from my
Bob... the end of the message was "SCNR" which means "Sorry,
Could Not Resist." I think he was just ribbing you.
I can see now. D'oh! :-)
--
Bob Ham <rah(a)bash.sh>
It exists quite clearly in my mind. I've also
made some designs on
paper and put them here:
http://pkl.net/~node/software/lash/lash-2.jpeg
Worst draft I've ever seen. If you can't even be bothered to clearly
write down your goals...
24 Nov
24 Nov
6:11 p.m.
On Mon, Nov 23, 2009 at 02:17:18PM +0100, Adrian Knoth wrote:
I've been in several studios with tons of
expensive equipment, however,
all this stuff was packed in a single room, usually around a decent
mixing console or a computer with multichannel audio I/O (ProTools,
Tascam, RME, whatever).
Next time you are near a big digital Midas console try to
have a look inside. It's a collection of DSP boxes connected
by network links. Just count the Cat5 cables.
Not that I'd advocate this as the best solution, and the
reason why Midas are doing this is not entirely technical.
But it's reality as well.
On the digital side, all these sites had total recall,
that is, they've
opened the mixing session in ProTools and all the plugins had their
settings right. That's the reason why you usually don't want analog
outboard equipment, but if need be, even that sometimes provided total
recall (SSL consoles, some newer FX gear, preamps and some on).
When I was an active sound engineer (which was the '80s and early
'90s) most of that didn't exist. The people working at that time
were quite capable of setting up or recreating a mixing session
in a minimum of time even if it was all manual and you had to plug
some cables on a patchbay. They could do this because instead of
relying on automation they actually knew what they were doing,
and capable of separating essentials from frills and hype.
And some of the best selling and renowned music of all times was
created such 'primitive' technology. Anyone who claims he can't
work unless it's Protools, or fully automated or integrated, or
whatever such requirements is in my eyes just a one trick pony.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
23 Nov
23 Nov
12:57 p.m.
On Monday 23 November 2009, Bob Ham wrote:
On Sat, 2009-11-21 at 09:45 -0500, Paul Davis wrote:
Hop hip hooray! Someone with an overview of the problem, and some
understanding of the issues.
I have only a very small oar in this water as I represent just another sample
of the fabled 'user'. One who has been lurking here for many years, hoping
someone will pluck his magic twanger and linux audio will Just Work(TM)
forevermore. As all of these lists readers are aware of, that hasn't
happened.
But what I see all too often here are the clashes of personalities because
each one thinks his idea should trump all others and be universally adopted
by all. This D-Bus thing is typical. And when someone points out its
weaknesses, he is more likely to be treated like somebody burning a religious
book than as someone trying to steer to progress of this stateless ship.
So, I suggest that at the next audio summit, the discussion MUST be centered
on the design of a messaging bus/protocol that is usable by all if enough
pride can be swallowed by the protagonists, lay out the structures needed so
that _everyone_ has a usable tool, and come home and write it!
The present situation, while far better than it was in 1997-8 when I did my
first linux install, is still nowhere near a Just Works(TM) condition. And
what I read in my lurking here for much of a decade, is scarey. So little
mention of the system the top distros are shoving down our throats,
pulseaudio, as if its being somehow profane to even mention it. Hey, we all
live on this same planet, remember?
So little co-operation and so much time spent whipping the horses that are
trying to draw and quarter this thing called linux audio, each somehow
thinking that when their team has pulled off its little piece, it will
somehow be converted to a majority holding. Like a 2nd place winner in a
gunfight, it won't happen.
So lets start from scratch and build this universal bus, one that can handle
a system with more than one piece that claims to be audio capable, in
addition to being _local_ network transparent. And then all the rest of the
various factions here should get on this bus and use it.
You can, and probably will, ignore me. In fact I expect it based on my
observations so far.
Just an old (75) farts $0.02, who hopes he lives long enough to see it work.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
<https://www.nrahq.org/nrabonus/accept-membership.asp>
"Conversion, fastidious Goddess, loves blood better than brick, and feasts
most subtly on the human will."
-- Virginia Woolf, "Mrs. Dalloway"
I don't really care at all about the
technology inside a Linux session
handling "toolkit", although clearly it would be nicer if it worked on
all Linux systems. What I care about is the complete lack of any
stable API that a developer of an application that would participate
in this could use and have some confidence in. Do I believe that using
dbus as an IPC mechanism makes sense in this case, and that therefore
"the API" is really just a set of dbus names and semantics? Well, i'm
agnostic about that
I'd like to comment on this issue in order to clarify and also to
explain why, as Nedko stated in his original email, I gave no support to
D-Busification efforts.
One of the goals of LADCCA, LASH and even LADISH is to enable
network-wide session management. A D-Bus connection enables
communication between remote objects on a single bus. However, that bus
is limited to a single host. Buses cannot span hosts. In order to
implement a network-aware session management system using D-Bus, there
must necessarily be one of only two approaches.
The first approach is to have one bus on one host which all clients and
servers on all hosts connect to. This is a star topology which has
inherent weaknesses in terms of resilience. I believe the robustness
needed for a usable networked audio session cannot be provided using an
IPC mechanism with a single point of failure.
The second option is to have multiple buses; for each session client and
server to open multiple D-Bus connections. However, this introduces
another layer of addressing. In order for messages to be passed to a
remote object, not only must you know the address of the object but the
address of the bus to which it is connected. This completely undermines
the use of D-Bus. D-Bus is an IPC mechanism for communication with
remote objects that doesn't allow communication with remote objects on
remote hosts.
I have never understood why D-Bus was even considered for a network-wide
audio session system. It seems to me to be a case of all problems
looking like a nail when you have a hammer.
7:49 a.m.
On Fri, 2009-11-20 at 23:21 -0500, Paul Davis wrote:
I am personally appalled by the debacle that LASH
turned into.
Ditto.
Stemming from a proposal made years ago (by Bob Ham, I
believe), LASH
has gone more or less nowhere. It has never arrived at a stable,
congruent and consistent specification, even via a header file. The
people working on the project have appeared to a casual observer like
myself to be in constant turnover and/or constantly redesigning the
entire system with a claim that this time it will be done right. The
project is, quite frankly, a joke when compared to what has been
managed with ALSA, LADSPA, JACK and even something like DSSI.
I think maybe the problem is in using the word 'project'. I don't think
this word really applies. Which seems to be what you're saying but then
I'm not sure anyone has really claimed such. The tarballs that have
been released always seem to have been in some sense an RFC rather than
a final product.
You could argue that early ALSA et al. releases were RFCs but then those
*projects* had a constant list of maintainers and were the receipt of a
relatively uninterrupted devotion of time. Really, the name "LASH" is
just a label for a set of source files that have been shared amongst
several different projects that have come and gone over time, with each
project having different goals, different maintainers and largely being
the work of one particular person. Unfortunately, each project has
continued to use the name "LASH".
Certainly session management is an important issue
when using a weakly
connected set of cooperating applications, and it remains almost
entirely unsolved. I personally have no faith that any of the work on
LASH has moved us notably closer to an actual solution to this issue,
although I will grant that it has helped some developers to get a
better grasp on what some of the issues actually are, and for that I
suppose we must be grateful.
I think LASH has moved us notably closer. It has crystallised the issue
of session management within the community. Its presence has changed
the design and implementation of software; most significantly, Non comes
to mind but it has had a subtle influence in a wider sphere as well.
This doesn't mean much to the bedroom musician or the studio producer
sat behind Studio64 but it does mean something and I think it's unfair
to say it isn't noteworthy. Before LASH, the upper limit of the Linux
Audio community's session management 'technology' consisted of custom
shell scripts. That limit is now higher.
Bob
--
Bob Ham <rah(a)bash.sh>
20 Nov
20 Nov
11:50 p.m.
On Fri, Nov 20, 2009 at 3:15 PM, Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
(hopefully you've all read what Nedko wrote...)
Nedko,
I can't comment on the technical merits or drawbacks of your project,
but I can say that as a user who wants Linux audio to be easier to
manage, the LADI(sh) project is one that I've been keeping a close eye
on. When I first began using Linux for audio several years ago, LASH
was one of the exciting things that I thought set it apart from other
platforms... and I was saddened to discover that very few programs
supported it, and at that time there was no "dashboard" program to
control it aside from the command line. Even now, as you've
mentioned, LADISH doesn't offer features beyond existing tools (yet)
and is still in the "preview" stage. That's the only thing that has
held me back from testing... which I suppose is a catch-22 situation.
When you release preview 2 of LADISH, I'll be sure to try it out. I'd
like to see hacking continue on it, and when you've got some more
tangible results to show off its functionality (maybe post some
screencasts somewhere?) perhaps more of the community will jump
onboard.
Sean
21 Nov
21 Nov
12:17 a.m.
Hi Nedko - I agree wholeheartedly with you are trying to achieve and think
your work could be quite important to the linux audio community
I have gone as far as running and testing (g)ladish - So far I haven't been
able to anything really useful to with it. I noticed that the next milestone
is supposed to provide methods for launching apps within ladish (am I right
in thinking that applications started in this manner gain some support for
basic session management even if they are not specifically written to do
so?) and I was waiting on that do some more extensive testing.
5463
days inactive
5510
days old
linux-audio-dev@lists.linuxaudio.org
134 comments
30 participants
participants (30)
-
adi＠drcomp.erfurt.thur.de -
Adrian Knoth
-
alex stone -
Arnold Krille -
Bob Ham -
Chris Cannam -
Christopher Cherrett -
Danni Coy -
Dave Phillips -
David Robillard -
Florian Faber -
fons＠kokkinizita.net -
Gabriel M. Beddingfield -
Gene Heskett -
hermann -
james morris -
James Warden -
Jostein Chr. Andersen -
Loki Davison -
Louigi Verona -
Nedko Arnaudov -
Patrick Shirkey -
Paul Davis -
Ralf Mardorf -
rosea grammostola -
Rui Nuno Capela -
Sean Corbett -
Thorsten Wilms -
torbenh -
Victor Lazzarini