http://blog.gmane.org/gmane.comp.audio.jack.ladish hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.audio.jack.ladish/379 <pre>Thank you :) -- Marc-Olivier Barre XMPP ID : marco-qY6+oKxccOnaOVYouRjCbQ&lt; at &gt;public.gmane.org www.MarcOChapeau.org </pre> Marc-Olivier Barre 2012-05-09T15:29:57 http://comments.gmane.org/gmane.comp.audio.jack.ladish/370 <pre>ahoy Nedko &amp; co. after an update, i noticed that laditray had stopped running. from the error, it looked like it needed dev-python/pyyaml. i added it to the laditools-9999.ebuild (attached) and it seems to be working now. if this is indeed a dependency, perhaps you can update the master ebuilds in the ladi overlay? thanks as always for the great software. peace, w PS. maybe the non-live ebuilds will need the same dependency info? # Copyright 1999-2010 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ EAPI="3" inherit distutils git-2 DESCRIPTION="LADITools is a set of tools to improve desktop integration and user workflow of Linux audio systems" HOMEPAGE="http://www.marcochapeau.org/software/laditools" EGIT_REPO_URI="git://git.marcochapeau.org/laditools.git" LICENSE="GPL-3" SLOT="0" KEYWORDS="" IUSE="" PYTHON_DEPEND="2:2.6" RDEPEND="dev-lang/python dev-python/pyyaml &gt;=dev-python/enum-0.4.4 &gt;=media-sound/jack-audio-connection-kit-0.109.2</pre> Wayne 2012-03-29T15:27:54 http://comments.gmane.org/gmane.comp.audio.jack.ladish/362 <pre>github provides useful features for colaboration so I created set of LADI related repos there: https://github.com/LADI repo.or.cz is not deprecated, and stays as alternative to github. </pre> Nedko Arnaudov 2012-01-14T17:42:51 http://comments.gmane.org/gmane.comp.audio.jack.ladish/360 <pre>Hi, a question about lash-compat. My understanding is that it enables old programs that need /usr/include/lash to compile, and perhaps even work better (L2 instead of L1/0) under ladish. It now seems that Debian is dropping lash-compat from their packaging of ladish [1], because it is "not needed any more". True, many old LASH programs have compile-time flags to disable LASH. Is this a good thing? Are old LASH programs better of as L0 (by compiling them with --disable-lash or whatever) or as L2 (using lash-compat)? [1] http://anonscm.debian.org/gitweb/?p=pkg-multimedia/ladish.git;a=summary </pre> Dan Muresan 2012-01-03T09:33:48 http://comments.gmane.org/gmane.comp.audio.jack.ladish/358 <pre>Hi, I was thinking about adding in Gladish a simple "Tools/Transport" sub-menu (Start, Stop, Rewind). It's annoying to start a separate qjackctl or gjacktransport client just for these simple tasks. However, looking at the jack2 source, I see that dbus/controller_iface_transport.c seems to be an empty stub. Nedko, am I misreading that? Can jackdbus affect the transport? </pre> Dan Muresan 2012-01-02T06:27:54 http://comments.gmane.org/gmane.comp.audio.jack.ladish/352 <pre>Greetings. Where can I find documentation for ladish_control ? </pre> Jonathan E. Brickman 2011-11-28T02:53:45 http://comments.gmane.org/gmane.comp.audio.jack.ladish/350 <pre>ladish initial roadmap was set more than two years ago and like it or not, some things have changed since then. The most important thing is JACK session that was released earlier this year. It gained some popularity and seems to be looked for, despite its drawbacks. So the the next ladish release will have JACK session and LASH support. These were originally planned for preview 5 (ladish-0.5) but are here already. The export/import feature was planned for preview 4 (ladish-0.4) but there seems to be little demand for it. The other feature that was planned for 0.5, libladish, is not forgotten and its goal is still valid - to provide the perfect session management API. Unfortunately JACK session introduction caused big disturbance in The Force that lowered expectations, promotes ignorance and attempts to reject the path of perfection. So libladish is moving forward to future perfect, maybe even post-1.0. From now on the roadmap will not try to cover long term goals anymore, except for the 2.0 feature set (mu</pre> Nedko Arnaudov 2011-10-11T02:08:49 http://comments.gmane.org/gmane.comp.audio.jack.ladish/338 <pre>Dear Nedko, I'm running into BUG 161 (compiling from GIT) Is there any possibility to get araound that or can I provide any help or information to fix this? Thanks, Holger </pre> Holger 2011-09-14T20:17:47 http://comments.gmane.org/gmane.comp.audio.jack.ladish/331 <pre>When an ALSA-Midi-only app is started in a room, a2j creates the Jack-bridged MIDI port in the studio, not in the room. How should this be handled? Even worse, some apps auto-connect to system:capture_*. If they are started in a room, it is then impossible to disconnect them using (g)ladish. There should be some work-around for such apps (even if one could argue they are "broken"). I can't help but notice that there are some circumstances when the "room abstraction" breaks down. </pre> Dan Muresan 2011-08-21T19:45:29 http://comments.gmane.org/gmane.comp.audio.jack.ladish/327 <pre>ahoy Nedko, just wondering if you saw this warning about the laditools-9999.ebuild: Calculating dependencies / * * "/var/lib/layman/ladi/media-sound/laditools/laditools-9999.ebuild": * Deprecation Warning: Usage of distutils.eclass in packages not supporting installation * for multiple Python ABIs in EAPI &lt;=2 is deprecated and will be banned on 2011-06-01. * The ebuild needs to be fixed. Please report a bug, if it has not been already reported. maybe it just needs EAPI=2 set? peace, w </pre> Wayne 2011-07-04T11:35:02 http://comments.gmane.org/gmane.comp.audio.jack.ladish/313 <pre>Hi ! First of all, thanks for the work to gladish-team !!! So, my probem is: i can use the 2 front inputs (mic &amp; guitar) through Qjackctl perfectly, when it works when it wants (3 times for many more tries) on Gladish. Does anyone have hints ?! Thanks per advance, and please forgive my poor english ! </pre> isi up 2011-06-10T09:24:04 http://comments.gmane.org/gmane.comp.audio.jack.ladish/300 <pre>Hi, I notice that (g)ladish(?) notices jack clients that are started outside ladish, and if I connect them on the canvas, these connections are remembered the next time the relevant client shows up. However, this only works as long as the client always shows up with the same client / port names. Some clients (e.g. jack.play) don't have options to set the jack client name, and jack assigns them the app name + some random string. This prevents (g)ladish's matching mechanism from noticing such clients and restoring their connections. Is there some way to work around this? Short of starting clients in (g)ladish of course. In qjackctl's patchbay for example there was a very useful feature to match ports using a regex. Actually, I'm not even sure where the existing feature (restoring connections even for clients started outside ladish) is implemented. I can't find the relevant client names in the studio xml file, but it somehow works. </pre> Dan Muresan 2011-05-28T19:35:47 http://comments.gmane.org/gmane.comp.audio.jack.ladish/289 <pre>Tarball containing D-Bus patched jack 0.120.2 is available here: http://nedko.arnaudov.name/soft/jack/dbus/ http://nedko.arnaudov.name/soft/jack/dbus/jack-audio-connection-kit-dbus-0.120.2.tar.gz http://nedko.arnaudov.name/soft/jack/dbus/jack-audio-connection-kit-dbus-0.120.2.tar.gz.sig A patch against vanilla 0.120.2 is available here: http://nedko.arnaudov.name/soft/jack/dbus/jack-audio-connection-kit-0.120.2-dbus.patch After applying the patch you have to run autoreconf. D-Bus modifications add optional autodetected support for the D-Bus based server control system. D-Bus is object model that provides IPC mechanism. D-Bus supports autoactivation of objects, thus making it simple and reliable to code a "single instance" application or daemon, and to launch applications and daemons on demand when their services are needed. * Simplified single thread model for control and monitor applications. Various D-Bus language bindings make it trivial to write control and monitor applications using script</pre> Nedko Arnaudov 2011-05-27T23:31:56 http://comments.gmane.org/gmane.comp.audio.jack.ladish/287 <pre>Hello all, First of all I should let you all know that I'm working on a synth-centric live CD that will use Ladish for its session management functionality, so thanks for all your hard work. I've been casually following the Ladish mailing list but will probably get more involved now that I have made some progress getting the live CD going. However in both the live environment and my development workstation, I'm having some trouble: I'm getting a message that the Ladish daemon has crashed when I try to add an app either via the menu option or ladish_control on the command line. Any ideas on what could cause it? Here is a stacktrace from ~/.log/ladish/ladish.log, if it helps (using 0.3 from the release tarball, built on ArchLinux): Tue May 24 09:57:06 2011: run_custom('ardour', shell, 'ardour2', 0) called Tue May 24 09:57:06 2011: ------- Tue May 24 09:57:06 2011: new_app command. opath='/org/ladish/Studio', name='ardour', shell, commandline='ardour2', level=0) called Tue May 24 09:57:06 2011: [31mERRO</pre> Sean Corbett 2011-05-24T14:12:16 http://comments.gmane.org/gmane.comp.audio.jack.ladish/237 <pre>Hi, I noticed that apps in Level 1 are not started in any particular directory. In fact, there are no directories associated with studios, unlike in lash. So I thought, wouldn't the following be a good way to solve save-file naming for Level 1 apps: * each studio gets an automatically created directory (like in lash) * each app instance also gets a new directory, withing the studio directory. Ladish runs apps in their respective directories. * when a level 1 app saves, it can write to any number of files, with whatever names, in the directory where it was started, * when a level 1 app starts, it tries to restore its state from the directory it was started This way the user doesn't have to pick any file names or manage any directories. Multiple app instances can coexist, since each is given a separate directory inside the studio. In fact, this is almost as good as Level 2, and apps don't need to learn any special API. Perhaps this has been discussed -- I couldn't find any links. Or perhaps I misunders</pre> Dan Muresan 2011-05-12T20:56:24 http://comments.gmane.org/gmane.comp.audio.jack.ladish/236 <pre>Hi, is there any documentation for rooms (I couldn't find any)? AFAICT, the status is: * rooms, once set up, work -- audio and MIDI are routed properly * apps can be added to rooms only via ladish_control * new room templates can only be created (and described) by editing XML files Is this correct? </pre> Dan Muresan 2011-05-12T20:36:31 http://comments.gmane.org/gmane.comp.audio.jack.ladish/233 <pre>I guess no-one ever used anything but xterm for the terminal, but in general, "x-terminal-emulator -e" expects an executable + arguments, NOT a shell command, as daemon/loader.c provides. The attached (trivial) patch should fix that. Note that even xterm, when passed a shell command, needs to execute it... in a shell. So the optimization to skip "$SHELL -c" for terminal-bound programs was acomplishing exactly one thing: it forced xterm to decide its own shell instead of giving it the user-specified shell from the Ladish settings. Trying to use urxvt for the terminal command was quite an unpleasant experience. At some point Ladish got confused about the state of the (not-started) application and got stuck in a "Waiting for process to terminate" loop -- which at the time I didn't realize (wasn't looking at the logs). In its confused state, ladish ignores all commands from the user to kill / stop / remove the broken app. I tried to "reactivate" jack, ladishd, whatever I could from the laditray menu, but I thi</pre> Dan Muresan 2011-05-07T11:21:14 http://comments.gmane.org/gmane.comp.audio.jack.ladish/227 <pre>I've updated the jack2 "ladi" git branch to have the 1.9.7 code. You can see what is new in 1.9.7 here: http://jackaudio.org/node/53 The no-self-connect branch is now 1.9.7 based as well. The ladi-experimental branch now has the trunk svn r4255 code. ATM the ladi and ladi-experimenta branches have have two differences From the mainstream versions: 1. the no-self-connect changeset 2. waf modification that makes the jack2 waf script usable when the jack2 source tree is in a subdirectory of another project that uses waf for building </pre> Nedko Arnaudov 2011-04-02T12:36:55 http://comments.gmane.org/gmane.comp.audio.jack.ladish/226 <pre>ahoy all, after updating to latest+greatest from the LADI overlay, LADITray does not start but gives the following error: Traceback (most recent call last): File "/usr/bin/laditray", line 21, in &lt;module&gt; import pygtk ImportError: No module named pygtk i am no Python expert, but i started the Python interpreter and issued a simple "import pygtk" command, which succeeded. so pygtk seems to be installed, but LADITray cannot find it. what debugging can i try with a Python program? peace, W </pre> Wayne 2011-04-01T19:44:40 http://comments.gmane.org/gmane.comp.audio.jack.ladish/223 <pre>Stephane is going to release 1.9.7 soon and asked us to verify that it works fine in LADI setups. It works fine on my machine but more hammering will be useful I think. The jack2 svn trunk (r4230) is merged into the ladi-experimental branch. Please test it. As usual, if you want/need the no-self-connect option, use either the no-self-connect branch or the ladi-experimental branch. When 1.9.7 is out, the ladi branch will have same code as the ladi-experimental branch. A reminder what branch is for what: * no-self-connect - has the no-self-connect functionality only * ladi - what is currently recommended for ladish setups. It contains the latest jack2 release code plus any additions that are useful for ladish setups. * ladi-experimental - as ladi but has the [almost] latest svn trunk code. </pre> Nedko Arnaudov 2011-03-28T21:18:46 http://comments.gmane.org/gmane.comp.audio.jack.ladish/215 <pre>ahoy Nedko, first, sorry for the perpetual overlay questions about JACK. i am obviously still trying to get a handle on how this all fits together. i was trying to build the latest Ardour 3 to test with my LADISH setup, but upon trying to build it, i get the following configure error: Checking for new jack_port_type_get_buffer_size : missing - a version of JACK that supports jack_port_type_get_buffer_size() is required to compile Ardour3 i am using the JACK 2.9999 live ebuild (jack-audio-connection-kit-2.9999.ebuild) from the LADISH overlay, just updated today. my question is whether the JACK ebuild from the LADISH overlay tracks the latest from JACK and just patches it with the LADISH stuff, or whether the LADISH repo needs to be updated to a newer JACK? from my limited ebuild experience, it looks like the later. i am not exactly sure which version of JACK i am running anyway, as the jack_control does not return a version AFAICT. thanks as always for the help. peace, w </pre> Wayne 2011-03-05T22:08:22 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.audio.jack.ladish