linuxaudio.org

On 12/23/2009 06:27 AM, Patrick Shirkey wrote:

quoted text
> On 12/23/2009 01:32 AM, Gabriel M. Beddingfield wrote:

>

>> On Tue, 22 Dec 2009, alex stone wrote:

>>

>>

>>

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

>>>

>>>

>> So, if 'Foomatic DAW' saves state with a one-liner like

>> this:

>>

>>

>>

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

>

>

>    

integrated desktop window manager functionality
That should be on some packaging and promo material somewhere real soon now.
>

quoted text
> Cheers.

>

> --

>

> Patrick Shirkey

> Boost Hardware Ltd

>

>

>

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev