ladish

This release marks end of the preview series. It brings three new uservisible features - virtual graph manipulation, LASH support andjack-session support.Virtual graph manipulation allows to perform these operations: * Split (create new client and ... [More] move capture ports to the the new   client) * Join (move ports of one clients to another client and remove the   first client) * New client * Move port * Rename client * Rename port * Remove (empty) clientThe added LASH and jack-session support allows apps to be run in roomsat LASH or jack-session level. jack-session support requiresjack-1.9.8.= Download =The tarballs are available at the usual location: * http://ladish.org/download/ * http://ladish.org/download/ladish-1-with-deps.tar.bz2 * http://ladish.org/download/ladish-1-with-deps.tar.bz2.sig * http://ladish.org/download/ladish-1.tar.bz2 * http://ladish.org/download/ladish-1.tar.bz2.sigThere are two tarballs. ladish-1-with-deps.tar.bz2 is 5.3 MiB andbundles the major dependencies that are usually needed for runningladish: * flowcanvas * LADI Tools * a2jmidid * jack2All of these are either development (git/svn) versions or releaseversions that are patched to work better with ladish. The last releasedversions of these dependencies are expected work with ladish. The mostserious “incompatibility” is that the jack2 mainline is missing theno-self-connect changeset. This changeset adds option to jack thatallows prevention of jack apps self connection to “hardware” ports(usually system:playback_N). As such self-connecting apps are not rareat all, without it, the studio/room separation is not-effective andthe workflow can get very confusing.If you are compiling the software by yourself, then you shouldprobably use this “fat” tarball.The ladish-1.tar.bz2 tarball is 586 KiB and contains only ladishitself. It is expected to be used mainly by packagers.= Known issues =If you want to use yoshimi-0.060.10, beware that its jack-sessionimplementation is broken. As a workaround, in gladish settings dialog,“JS delay” can be set to few seconds instead of the default 0. Twoseconds should work in most cases. For more info, checkhttp://ladish.org/ticket/187= More info on the ladish project =Homepage: http://ladish.org/LADI Session Handler or simply ladish is a session management systemfor JACK applications on GNU/Linux. Its aim is to allow you to havemany different audio programs running at once, to save their setup,close them down and then easily reload the setup at some othertime. ladish doesn’t deal with any kind of audio or MIDI data itself;it just runs programs, deals with saving/loading (arbitrary) data andconnects JACK ports together. It can also be used to move entiresessions between computers, or post sessions on the Internet fordownload. Check the project goals for more info. Project goals: * Save and restore sets of JACK (audio and MIDI) enabled   applications. * Provide JACK clients with virtual hardware ports, so projects can   be transferred (or backups restored) between computers running   different hardware and backups.  * Don’t require session handling library to be used. There is no need   of such library for restoring connections between JACK clients. * Flow canvas based GUI. Positions of elements on the canvas are   saved/restored. * Allow clients to use external storage to save its state. This   includes storing internal state to non-filesystem place like memory   of a hardware synth. This also includes storing client internal   state (client project data) in a way that is not directly bound to   ladish project.  * Import/export operations, as opposed to save/load. Save/load   operate in current system and may cause saving data outside of   project itself (external storage). Import/export uses/produces   “tarball” suitable for transferring session data over network to   other computer or storing it in a backup archive. * Hierarchical or tag-based organization of projects. * List of JACK applications. Applications are always started through   ladish to have restored runtime environment closer to one existed   before project save. * Distributed studio - network connected computers. Netjack   configuration is part of the studio and thus is saved/restored. * Collaborate with the X11 window manager so window properties like   window position, virtual desktop and screen (multimonitor) are   saved/restored. [Less]

This release marks end of the preview series. It brings three new uservisible features - virtual graph manipulation, LASH support andjack-session support.Virtual graph manipulation allows to perform these operations: * Split (create new client and ... [More] move capture ports to the the new   client) * Join (move ports of one clients to another client and remove the   first client) * New client * Move port * Rename client * Rename port * Remove (empty) clientThe added LASH and jack-session support allows apps to be run in roomsat LASH or jack-session level. jack-session support requiresjack-1.9.8.= Download =The tarballs are available at the usual location: * http://ladish.org/download/ * http://ladish.org/download/ladish-1-with-deps.tar.bz2 * http://ladish.org/download/ladish-1-with-deps.tar.bz2.sig * http://ladish.org/download/ladish-1.tar.bz2 * http://ladish.org/download/ladish-1.tar.bz2.sigThere are two tarballs. ladish-1-with-deps.tar.bz2 is 5.3 MiB andbundles the major dependencies that are usually needed for runningladish: * flowcanvas * LADI Tools * a2jmidid * jack2All of these are either development (git/svn) versions or releaseversions that are patched to work better with ladish. The last releasedversions of these dependencies are expected work with ladish. The mostserious “incompatibility” is that the jack2 mainline is missing theno-self-connect changeset. This changeset adds option to jack thatallows prevention of jack apps self connection to “hardware” ports(usually system:playback_N). As such self-connecting apps are not rareat all, without it, the studio/room separation is not-effective andthe workflow can get very confusing.If you are compiling the software by yourself, then you shouldprobably use this “fat” tarball.The ladish-1.tar.bz2 tarball is 586 KiB and contains only ladishitself. It is expected to be used mainly by packagers.= Known issues =If you want to use yoshimi-0.060.10, beware that its jack-sessionimplementation is broken. As a workaround, in gladish settings dialog,“JS delay” can be set to few seconds instead of the default 0. Twoseconds should work in most cases. For more info, checkhttp://ladish.org/ticket/187= More info on the ladish project =Homepage: http://ladish.org/LADI Session Handler or simply ladish is a session management systemfor JACK applications on GNU/Linux. Its aim is to allow you to havemany different audio programs running at once, to save their setup,close them down and then easily reload the setup at some othertime. ladish doesn’t deal with any kind of audio or MIDI data itself;it just runs programs, deals with saving/loading (arbitrary) data andconnects JACK ports together. It can also be used to move entiresessions between computers, or post sessions on the Internet fordownload. Check the project goals for more info. Project goals: * Save and restore sets of JACK (audio and MIDI) enabled   applications. * Provide JACK clients with virtual hardware ports, so projects can   be transferred (or backups restored) between computers running   different hardware and backups.  * Don’t require session handling library to be used. There is no need   of such library for restoring connections between JACK clients. * Flow canvas based GUI. Positions of elements on the canvas are   saved/restored. * Allow clients to use external storage to save its state. This   includes storing internal state to non-filesystem place like memory   of a hardware synth. This also includes storing client internal   state (client project data) in a way that is not directly bound to   ladish project.  * Import/export operations, as opposed to save/load. Save/load   operate in current system and may cause saving data outside of   project itself (external storage). Import/export uses/produces   “tarball” suitable for transferring session data over network to   other computer or storing it in a backup archive. * Hierarchical or tag-based organization of projects. * List of JACK applications. Applications are always started through   ladish to have restored runtime environment closer to one existed   before project save. * Distributed studio - network connected computers. Netjack   configuration is part of the studio and thus is saved/restored. * Collaborate with the X11 window manager so window properties like   window position, virtual desktop and screen (multimonitor) are   saved/restored. [Less]

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 ... [More] , despite its drawbacks. So the the next ladish release will have JACK session and LASH support.These were originally planned for preview 5 (ladish-0.5) but are here already. The export/import feature was planned for preview 4 (ladish-0.4) but there seems to be little demand for it. The other feature that was planned for 0.5, libladish, is not forgotten and its goal is still valid - to provide the perfect session management API. Unfortunately JACK session introduction caused big disturbance in The Force that lowered expectations, promotes ignorance and attempts to reject the path of perfection. So libladish is moving forward to future perfect, maybe even post-1.0. From now on the roadmap will not try to cover long term goals anymore, except for the 2.0 feature set (multihost sessions). The 0.5 milestone is removed and 0.4 is redefined. The next release will be ladish-0.4 (preview 4). Given that even in its current state ladish serves its main goals, the release after 0.4 may be 1.0. After the 1.0 release I’ll switch to integer version numbering. To me this approach makes much sense for projects driven by a single man. 2.0 milestone will be renamed to “Distributed studio” to better reflect the availability expectations - when it’s ready. New releases will be rolled out when the codebase has enough important changes. [Less]

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 ... [More] , despite its drawbacks. So the the next ladish release will have JACK session and LASH support.These were originally planned for preview 5 (ladish-0.5) but are here already. The export/import feature was planned for preview 4 (ladish-0.4) but there seems to be little demand for it. The other feature that was planned for 0.5, libladish, is not forgotten and its goal is still valid - to provide the perfect session management API. Unfortunately JACK session introduction caused big disturbance in The Force that lowered expectations, promotes ignorance and attempts to reject the path of perfection. So libladish is moving forward to future perfect, maybe even post-1.0. From now on the roadmap will not try to cover long term goals anymore, except for the 2.0 feature set (multihost sessions). The 0.5 milestone is removed and 0.4 is redefined. The next release will be ladish-0.4 (preview 4). Given that even in its current state ladish serves its main goals, the release after 0.4 may be 1.0. After the 1.0 release I’ll switch to integer version numbering. To me this approach makes much sense for projects driven by a single man. 2.0 milestone will be renamed to “Distributed studio” to better reflect the availability expectations - when it’s ready. New releases will be rolled out when the codebase has enough important changes. [Less]

I’m glad to announce the new ladish ability - to act as a jack session manager. If you want to try it out, you have to use latest git version of ladish and latest svn/git version of jack2. jack-session apps are supported in rooms/projects only. If ... [More] you want to give feedback or have questions, use the #ladi IRC Channel on  FreeNode  IRC network and/or the ladish mailing list. [Less]

I’m glad to announce the new ladish ability - to act as a jack session manager. If you want to try it out, you have to use latest git version of ladish and latest svn/git version of jack2. jack-session apps are supported in rooms/projects only. If ... [More] you want to give feedback or have questions, use the #ladi IRC Channel on  FreeNode  IRC network and/or the ladish mailing list. [Less]

I’m glad to announce that LASH support in ladish is now fully functional. Apps can be started at level “LASH” (the two others are L0 and L1). The LASH API/protocol provides three high-level commands - quit, save and restore. All three commands are ... [More] implemented in ladish version of liblash, and ladishd (the ladish daemon) calls them when appropriate. I’ve used D-Bus for IPC. The liblash implementation can be used standalone as well. Once the app initializes liblash, a D-Bus object is created. The object implements three methods that match the three commands mentioned above. During liblash initialization, a method call to ladishd is made to provide some parameters, of which only the process id (aka pid) is actually used by ladishd. The call does not wait for reply and does not care if it will succeed or not. Strictly speaking this initial registration call can be avoided by watching for new object registrations and querying the process id from the D-Bus bus daemon. I’ve chosen the manual registration approach because it was simpler to implement and because it does not have practical drawbacks. Next step in supporting L2 protocols (LASH and jack-session) should be improved tracking of app save/restore and start/stop states. Intermediate states like “starting”, “stopping”, “registered”, “saving”, “saved”, “restoring” and “restored” app states will give useful visual feedback. Studios and projects also need to report “modified” state. They get modified when one changes connections and/or start/stop apps. Of course, apps need “modified” state as well but no existing session protocol allows apps to report whether their internal state is modified or not. It will be part of L3, hopefully before 2020. If you want to try the LASH support, you have to use latest git version of ladish. If you find any issues - please report them. [Less]

I’m glad to announce that LASH support in ladish is now fully functional. Apps can be started at level “LASH” (the two others are L0 and L1). The LASH API/protocol provides three high-level commands - quit, save and restore. All three commands are ... [More] implemented in ladish version of liblash, and ladishd (the ladish daemon) calls them when appropriate. I’ve used D-Bus for IPC. The liblash implementation can be used standalone as well. Once the app initializes liblash, a D-Bus object is created. The object implements three methods that match the three commands mentioned above. During liblash initialization, a method call to ladishd is made to provide some parameters, of which only the process id (aka pid) is actually used by ladishd. The call does not wait for reply and does not care if it will succeed or not. Strictly speaking this initial registration call can be avoided by watching for new object registrations and querying the process id from the D-Bus bus daemon. I’ve chosen the manual registration approach because it was simpler to implement and because it does not have practical drawbacks. Next step in supporting L2 protocols (LASH and jack-session) should be improved tracking of app save/restore and start/stop states. Intermediate states like “starting”, “stopping”, “registered”, “saving”, “saved”, “restoring” and “restored” app states will give useful visual feedback. Studios and projects also need to report “modified” state. They get modified when one changes connections and/or start/stop apps. Of course, apps need “modified” state as well but no existing session protocol allows apps to report whether their internal state is modified or not. It will be part of L3, hopefully before 2020. If you want to try the LASH support, you have to use latest git version of ladish. If you find any issues - please report them. [Less]

So I’m back from seashore because the weather and I’m going to dedicate rest of my vacation to Linux Audio software. The tempting goals are JACK MIDI support for QMidiArp, support for multiclient apps in ladish, jack-session support in jackdbus and ... [More] ladish, and LASH support in ladish. For JACK MIDI QMidiArp, close cooperation with Frank Kober is required but he is in summer mood. Implementing support for multiclient apps makes more sense after or along with adding jack-session support in ladish, because jack-session is designed to support multiclient apps. So I started implementing it, the org.jackaudio.SessionManager interface is now pushed to the js-dbus branch at repo.or.cz jack2 repo. Unfortunately it does not work, all methods fail at JACK API level. I suspect that the session manager API in jack2 is not implemented for in-process (server side) clients, like the one that jackdbus uses. This suspicion is yet to be proven though. Hopefully Stephane Letz will investigate whats going on soon. Until then, I’m thinking about what IPC mechanism would be best for communication between lash-enabled apps and ladish daemon. Original lash implementation used custom messages over sockets, but then 0.6 series switched to D-Bus. I was not really happy with D-Bus used for this because I didn’t and still don’t see any benefits. The old custom IPC code worked well. The situation for ladish is however different. I don’t have legacy IPC code and I cannot easily adapt the LASH one. So I have to either implement a custom IPC mechanism or use some ubiquitous one. And despite the myths flying around, there is only one that matches the requirements - D-Bus. So it looks it is time for some D-Bus research. First I have to research how D-Bus will behave if there are two “clients”. Some time I’ve asked about this on IRC and the suggestion that I got is to use dedicated D-Bus connection in liblash. I’d like to prove this before implementing ladish`s liblash over D-Bus. The other topic is async D-Bus calls. As it is now, all D-Bus calls in jackdbus and ladish are synchronous. This is problematic when the call can take long time to execute. For example with (some?) FireWire devices JACK server start can take several seconds. As it is now, the D-Bus loop of services are stalled. No other method calls are possible until the slow operation ends. When this happens UI apps that call methods in jackdbus or ladishd from their main threads are frozen and it is possible that method calls will timeout at client side. The issue will happen during jack-session save too, if some app takes long time to save, or even worse, fails to send reply to jack. It is less likely for jack-session that it is for LASH because jack-session reply has real info in it, as opposed to LASH “save done” reply that does not have any real info. Several LASH apps were (and maybe still are) buggy - they didn’t send the reply event. And then the even worse things happened, LASH became unusable. From what I known about jack-session is that it will freeze just like LASH did. Waiting for “save done” reply event that will never be received. But lets pray that I’m wrong and put this problem aside. The goal is to not block the D-Bus main loop of jackdbus and ladish services. The method call request actually defers execution to a background/worker thread. When the blocking call finishes, it sends the method call reply back, from the background/worker thread. The callers are not stalled as well, they just don’t wait for the reply but are notified when the method call is done. I’ve read on several blog-like and tutorial like places that this is supposed to work. I’d like to verify that such low-level D-Bus async approach actually works though. Alternative would be to implement async semantics over sync calls. Such approach however will prevent existence of clients that want to be simple and kind of stupid, by calling methods async-capable methods synchronously. [Less]

So I’m back from seashore because the weather and I’m going to dedicate rest of my vacation to Linux Audio software. The tempting goals are JACK MIDI support for QMidiArp, support for multiclient apps in ladish, jack-session support in jackdbus and ... [More] ladish, and LASH support in ladish. For JACK MIDI QMidiArp, close cooperation with Frank Kober is required but he is in summer mood. Implementing support for multiclient apps makes more sense after or along with adding jack-session support in ladish, because jack-session is designed to support multiclient apps. So I started implementing it, the org.jackaudio.SessionManager interface is now pushed to the js-dbus branch at repo.or.cz jack2 repo. Unfortunately it does not work, all methods fail at JACK API level. I suspect that the session manager API in jack2 is not implemented for in-process (server side) clients, like the one that jackdbus uses. This suspicion is yet to be proven though. Hopefully Stephane Letz will investigate whats going on soon. Until then, I’m thinking about what IPC mechanism would be best for communication between lash-enabled apps and ladish daemon. Original lash implementation used custom messages over sockets, but then 0.6 series switched to D-Bus. I was not really happy with D-Bus used for this because I didn’t and still don’t see any benefits. The old custom IPC code worked well. The situation for ladish is however different. I don’t have legacy IPC code and I cannot easily adapt the LASH one. So I have to either implement a custom IPC mechanism or use some ubiquitous one. And despite the myths flying around, there is only one that matches the requirements - D-Bus. So it looks it is time for some D-Bus research. First I have to research how D-Bus will behave if there are two “clients”. Some time I’ve asked about this on IRC and the suggestion that I got is to use dedicated D-Bus connection in liblash. I’d like to prove this before implementing ladish`s liblash over D-Bus. The other topic is async D-Bus calls. As it is now, all D-Bus calls in jackdbus and ladish are synchronous. This is problematic when the call can take long time to execute. For example with (some?) FireWire devices JACK server start can take several seconds. As it is now, the D-Bus loop of services are stalled. No other method calls are possible until the slow operation ends. When this happens UI apps that call methods in jackdbus or ladishd from their main threads are frozen and it is possible that method calls will timeout at client side. The issue will happen during jack-session save too, if some app takes long time to save, or even worse, fails to send reply to jack. It is less likely for jack-session that it is for LASH because jack-session reply has real info in it, as opposed to LASH “save done” reply that does not have any real info. Several LASH apps were (and maybe still are) buggy - they didn’t send the reply event. And then the even worse things happened, LASH became unusable. From what I known about jack-session is that it will freeze just like LASH did. Waiting for “save done” reply event that will never be received. But lets pray that I’m wrong and put this problem aside. The goal is to not block the D-Bus main loop of jackdbus and ladish services. The method call request actually defers execution to a background/worker thread. When the blocking call finishes, it sends the method call reply back, from the background/worker thread. The callers are not stalled as well, they just don’t wait for the reply but are notified when the method call is done. I’ve read on several blog-like and tutorial like places that this is supposed to work. I’d like to verify that such low-level D-Bus async approach actually works though. Alternative would be to implement async semantics over sync calls. Such approach however will prevent existence of clients that want to be simple and kind of stupid, by calling methods async-capable methods synchronously. [Less]