Re: [LAD] Summercode 2008: LASH, pt. 2
Dave Robillard wrote: I'm not sure if this is what Juuso meant, but Jack definitely needs something like a simple key/value metadata system for ports. I second that. Especially if some of the metadata could be user-assigned (via configuration or otherwise). Example use - to mark the MIDI ports as primary/secondary keyboard, drum pads, control surface etc. And, possibly, device models and/or MIDI specification they conform to (GM, XG, GS, GM2, non-GM-based etc). Or to mark audio inputs as coming from a MIDI device that is connected to a selected (computer's) MIDI output. Then, for example, I could configure JACK to recognize that on my machine, system:midi_playback_4 is connected to MIDI In of an instrument that has its audio output connected to system:capture_3 and system:capture_4. This information might then be used by sequencer applications to be able to create bounce audio tracks automatically when creating MIDI tracks. The goal is to let the user configure everything once and have all applications behaving reasonably by default. I think we've already been discussing that, and you had some sort of system like this in mind. Just my usual tangential crap :) While it has nothing to do with LASH, I thought it might be an additional argument for adding metadata support to JACK in foreseeable future. Krzysztof ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Summercode 2008: LASH, pt. 2
On Sun, 2008-01-27 at 12:33 +0200, Nedko Arnaudov wrote: Juuso Alasuutari [EMAIL PROTECTED] writes: - Jackdbus needs a port settings interface. what is this? the patchbay interface? I.e. connect/discconect ports, get clients/ports, get current connections, get notifications about graph changes? I'm not sure if this is what Juuso meant, but Jack definitely needs something like a simple key/value metadata system for ports. Most of the long standing jack annoyances/problems (like proper configurable auto-connect behaviour) are trivially solved given this. -DR- ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Summercode 2008: LASH, pt. 2
On Sun, 2008-01-27 at 12:33 +0200, Nedko Arnaudov wrote: * User interface standard recommendation (documentation). fit: -5 I dont think this is in the scope of LASH. IMHO, such plans fit much more to PHAT project. I think such a standard would just start with what labels to use for LASH related actions and how to organise menu items. It could contain one or the other layout recommendation or how to handle certain scenarios regarding notifications and dialogs. So all things with a clear relation to LASH. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Summercode 2008: LASH, pt. 2
Juuso Alasuutari [EMAIL PROTECTED] writes: Here's a list of all LASH suggestions expressed so far, as well as some new ones. It's quite a bunch, and it goes without saying that this is NOT A PLAN; no sane person would actually try to cram all of these into an application. If my application gets chosen for Summercode I'll only be concentrating on a few key things (to be announced later, maybe after another brainstorm). Great work so far! Having those in one place is quite useful. It allows easy spoting of common goals where developers can cooperate. So, please take this as a memo, and please do comment. The internet doesn't contain enough ASCII yet. I'll use -5 .. 0 .. +5 numbers to express how well each things fits my personal view. Here they go: Suggested changes to internal structure: * Interact with JACK using the JACK D-Bus interface. Lashd no longer required to be a libjack client. fit: +5 - Jackdbus needs a port settings interface. what is this? the patchbay interface? I.e. connect/discconect ports, get clients/ports, get current connections, get notifications about graph changes? * Interact with LASH clients using D-Bus (change liblash's transport to use D-Bus). fit: +2 - What if the client has its own D-Bus event loop and wants to manually handle the LASH protocol? We need an option to also allow this. Here I'm affraid of some technical problems. What if app uses some dbus binding that hides everything? And how lash dbus code will be executed in app using glib/qt bindings. Also I expect other audio related dbus functionality to become more widely used and we could try to coordinate this now: * http://ll-plugins.sourceforge.net/dbus/midiinput.html (curently bound to JACK MIDI, but easlity extendable). * JACK Synthesizer Manager Proposal (using D-Bus)? * Replace liblash's server interface with a LASH D-Bus interface. LASH control applications no longer required to be liblash clients. - Requires API change. fit: +4 Given the low availablitity of such applications (about 3 of them, some of them probably in stalled state), I'd be bold here. * Certificates and encryption for communication protocol. - What the communication protocol refers to is another question... fit: +1 D-Bus authentication mechanisms should be used here probably. * OSC (?) If for lash client - lash server protocol: fit: -1 * Server rewrite in C++. fit: +2 * Client lib rewrite in GObject. fit: -2 I'm against using GObject, not against making it more OO internally. * Server rewrite in Python fit: +4 * Strip support for ALSA (make LASH - JACK specific) fit: +2 API change suggestions: * Break it? How? When? - Probably unavoidable eventually. fit: -5 Don't break current client API. We have have enough lashified apps we know about and nobody knows how much lashified apps we dont know about. Still we should make alternative client interface to be used in new apps. Existing lashified apps can be switched to the new api if someone has motivation to do this. Still we cannot be sure that we know all existing lashified apps. Also, this will fsck up distro packagers, with result being low adoption. IMHO, if we provide better alternative API, most developers will use it instead (in most cases). Thus: * Provide new *alternative* API: fit: +4 * Remove the server interface from liblash. Controlling LASH will happen through a D-Bus interface. - Dave Robillard has expressed that the current interface separation makes it difficult to write a LASH control application which is at the same time a LASH client (Patchage). fit: +4 * Mandate that LASH clients shall not modify any external port connections. - Actually enforce this using JACK ACL? (A partial solution, doesn't help with ALSA and others.) fit: +4 * Make the save directory static to clients unless a change notification is sent. What is this? * More generic patch system API. What is this? * Use callbacks instead of current event framework. fit: +3 * Add test disk operation function; the server can ask the client to test if it can actually read from and write to the specified directory. Why is this needed? Feature addition suggestions: * Lashd should capture clients' stdout and stderr and keep log(s) in the project dir. - One common log file or per-client ones? One common per-user (lashd is per-user process) log file. Use prefixes to distinguish between each client output and stdout/stderr. fit: +5 * Preserve/restore JACK settings other than port connections. - Make this optional; the user must be able to tell LASH to not touch any JACK settings. fit: +5 - Should this be the responsibility of a JACK controller app? fit: -3 - LASH being able to restart JACK server in the bad thing happens. The same way it can restart lash clients. fit: +5 * Export/import session; create or unpack a tarball of the session directory. fit: +4 * Light
[LAD] Summercode 2008: LASH, pt. 2
Here's a list of all LASH suggestions expressed so far, as well as some new ones. It's quite a bunch, and it goes without saying that this is NOT A PLAN; no sane person would actually try to cram all of these into an application. If my application gets chosen for Summercode I'll only be concentrating on a few key things (to be announced later, maybe after another brainstorm). So, please take this as a memo, and please do comment. The internet doesn't contain enough ASCII yet. Suggested changes to internal structure: * Interact with JACK using the JACK D-Bus interface. Lashd no longer required to be a libjack client. - Jackdbus needs a port settings interface. * Interact with LASH clients using D-Bus (change liblash's transport to use D-Bus). - What if the client has its own D-Bus event loop and wants to manually handle the LASH protocol? We need an option to also allow this. * Replace liblash's server interface with a LASH D-Bus interface. LASH control applications no longer required to be liblash clients. - Requires API change. * Certificates and encryption for communication protocol. - What the communication protocol refers to is another question... * OSC (?) * Server rewrite in C++. * Client lib rewrite in GObject. API change suggestions: * Break it? How? When? - Probably unavoidable eventually. * Remove the server interface from liblash. Controlling LASH will happen through a D-Bus interface. - Dave Robillard has expressed that the current interface separation makes it difficult to write a LASH control application which is at the same time a LASH client (Patchage). * Mandate that LASH clients shall not modify any external port connections. - Actually enforce this using JACK ACL? (A partial solution, doesn't help with ALSA and others.) * Make the save directory static to clients unless a change notification is sent. * More generic patch system API. * Use callbacks instead of current event framework. * Add test disk operation function; the server can ask the client to test if it can actually read from and write to the specified directory. Feature addition suggestions: * Lashd should capture clients' stdout and stderr and keep log(s) in the project dir. - One common log file or per-client ones? * Preserve/restore JACK settings other than port connections. - Make this optional; the user must be able to tell LASH to not touch any JACK settings. - Should this be the responsibility of a JACK controller app? * Export/import session; create or unpack a tarball of the session directory. * Light save functionality; clients can reference files outside the session directory. * Managing of non-LASH apps. * Preserve clients' X11 properties, such as window position, screen, workspace, etc. * Ability to merge sessions. * Support for multi-host sessions. - Should the LASH-client protocol support this directly (socket-based connections), or - should LASH daemons on different machines be able to connect with one another (master session slave sessions)? * Save the client data in $client_dir under a sub-dir to prevent the client from overwriting config files. * Support for dictating client loading order, and which other clients need to be loaded before a client can load. - Alternative solution/scheme: client priorities. * Track naming * Guaranteed save directory availability * Graded saves. (Different kinds of saves? How many different kinds?) * Networked audio (audio/MIDI ports over network). * User interface standard recommendation (documentation). * Automatic client installation/in-built package manager. Juuso ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
