[LAD] JACK Synthesizer Manager Proposal
Hi! Audun Halland and I have been thinking about a set of related problems. The first result is the following proposal, meant to gather feedback from the community. I'm posting about this to both LAD and LAU, but separately. Hopefully we can keep it technical here and have the user POV on LAU :) Please feel encouraged to come up with additional use cases and implementation ideas. You can read the following with a little bit of markup on http://thorwil.wordpress.com/2008/01/26/jack-synthesizer-manager-proposal/ or the same text right here: JSM, the JACK Synthesizer Manager We propose a programm that acts as a proxy between sequencing software and both software and hardware sythesizers. Among the goals are unified patch selection and making projects more portable. If we get the impression that the JSM is something that both developers and users will find handy and use, then development might start real soon. In this text, we avoid going into technical details to foster free thought and discussion. Use Cases 1. Patch selection Goal: Choose patches from all available hardware and software synthesizers. Giorgio uses a single means to select a patch among all patches of all of his software and hardware synthesizers. He uses meta-data to find the right patch. The right connections are made automatically. 2. Computer as syntheszier Goal: Use the computer as a compound synthesizer in a live performance. Hiromi has her keyboard connected to her laptop live on stage. She uses several soft-synths via keyboard-split and layering. A few selected parameters are bound to the wheels of the keyboard. After each song, she switches from one setup to the next with least effort. 3. Collaboration Goal: Exchange projects without having to change settings back and forth. Alice and Bob take turns on working on a project. They use different hardware but don't have to manually change connections and choose patches on each turn because of an abstraction layer. MIDI Interface Ports The problem with MIDI interface ports is that the hardware on the other side and its setup might change. Or be entirely different if people exchange projects. An abstraction layer can make this more comfortable to handle. The JSM takes care of the mapping between software ports and MIDI interface ports. It can work on a per MIDI channel level. Patches and Instrument Definitions Patches and controllers are chosen by name; the user doesn't have to deal with cryptic numbers. For kit-programms, name mappings are given (e.g. bass drum on C1). Patch selection happens by a single means, offering all available patches (JACK apps, plugins, hardware). Making the required MIDI and audio connections is automated as far as possible. Categorization Categories help to find the right patch among many. When exchanging projects, they help to replace unavailable patches with similar ones. Virtual/Compound Synthesizers From the outside, the computer can be dealt with like a single compound synthesizer. Different synthesizers can be triggered from ranges on a single keyboard (key splits). Synthesizers can be layered. The whole setup can be switched with programm changes. JACK to ALSA Bridge JSM could be the de facto JACK MIDI to ALSA MIDI bridge. No Jack SYSTEM midi ports, the jack world only sees the devices offered by JSM. -- Audun Halland and Thorsten Wilms ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] JACK Synthesizer Manager Proposal
On Sat, 2008-01-26 at 19:16 +0100, Dennis Schulmeister wrote: Just a litte question to better understand your idea. How would a sequencer request a certain patch on a certain channel on a certain port? I think the patch selection would be more part of the JSM than the sequencer, but the details must be figured out in collaboration with sequencer authors. So it wouldn't be the sequencer requesting a patch, but rather patch selection throughy the JSM, the JSM providing all necessary info to the sequencer and changing connections. With plain MIDI the sequencer would just send the appropriate control change / program change values on the given channel and midi port. Without knowing which device would interpret the values in which way. How would that be different with an abstraction layer? How could an abstraction layer assure that a given PC/CC value pair would always refer to a certain kind of patch? Regardless of the system and synthesizer setup employed. Obviously there would be some kind of translation. But who would define the translation rules? Who would define what kind of patches JSM can handle and which not. The JSM developers might come up with a snappy synth bass. All a user would have to do was to tell JSM how to select a snappy synth bass patch on a given synthesizer. But they might not come up with a blurry sound from space which sounds like a cat screaming when its tail gets clamped by the door. The user wouldn't be able to reliably select such a patch. Simply because it wouldn't be offered to him. On the other hand he could extend the translation rules to offer such a patch. But than again it wouldn't work on a foreign setup. The minimum the abstraction layer would do, is automatic switching between profiles. One per environment. This way you would not have to adapt everything on each iteration of working on a project in turns. Patch selections could be stacked. One selection for each environment. The next thing could be virtual ports to represent roles in the project. Roles like drum-module or lead-synth. Then replacing unavailable patches with patches that are similar as far as that can be discerned from meta-data. -- 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] JACK Synthesizer Manager Proposal
The minimum the abstraction layer would do, is automatic switching between profiles. One per environment. This way you would not have to adapt everything on each iteration of working on a project in turns. So the idea is to decouple patch selection from the sequencers. A sequencer would just send MIDI data to a MIDI port offered to it by JSM. JSM in turn would provide the necessary means to select a patch from any synthesizer available. So if Alice and Bob would work on a common project both would have their own profile defined for the project. They would need to do so both on their own. But at least it would be assured that each JSM MIDI port would have similar patches assigned. Then replacing unavailable patches with patches that are similar as far as that can be discerned from meta-data. Of course for such a feature an arbitrary large library of meta-data of all patches of all MIDI-capable synthesizers ever built and written would be needed. :) Yours sincerely, Dennis Schulmeister -- Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany Tel: +49 721/5978883 - Mob: +49 152/01994400 - eMail: [EMAIL PROTECTED] Now moved to the corridor: Hermes! (http://ncc-1701a.homelinux.net) (mostly German) http://www.windows3.de - http://www.denchris.de http://www.audiominds.com - http://www.motagator.net/bands/65 ___ 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 as a D-Bus service
On Friday 25 January 2008 18:27:10 Bob Ham wrote: On Fri, 2008-01-25 at 14:04 +0200, Juuso Alasuutari wrote: On Wednesday 23 January 2008 23:21:21 Bob Ham wrote: There's no reason to add a system-specific API layer to LASH itself. The abstraction could be done by a separate library entirely, eg libeasyjack. By system-specific API layer do you mean D-Bus? No, I mean JACK or ALSA or raw1394 or whatever. I'm talking about something like lash_easy_jack_client_t * lash_easy_jack_client(char *client_name, char *input_port_names[], char *output_port_names[], jack_callback_t *cb); In this case, there's no reason at all to have lash_ in there. Why bother with a long-reaching workaround like that? I understood this hypothetical libeasyjack to be something that would enable a program to be a JACK (libjack) client without actually having to fulfill the requirement of running with RT priority. But for our needs (setting connections, getting connection info, etc.) it's simply backwards to stubbornly hold on to keeping LASH a JACK client. There's a conceptually saner solution around the corner. The goal of jackdbus has never been to shield applications from JACK's bugs, and I regret that this conversation has revolved around that side effect for so long. Jackdbus allows more flexible controlling of JACK settings in a desktop environment, by desktop applications. Implementing this kind of interface makes sense for more than one reason. It's not about adding a system-specific API layer to LASH, it's about making use of an API layer in LASH because it fits the purpose well. To me, it seems like overengineering to design the LASH - client protocol with networks in mind. The lashd daemon can use D-Bus to communicate with clients, but that doesn't mean that several LASH daemons running on different computers couldn't communicate session events and data between eachother. The idea would be that all LASH - client connections would be local, but one session could be composed of several local LASH environments. The problem here is you then have two communication protocols; one for local D-Bus communication, and one for inter-host lashd communication. They're going to be communicating much the same information; client properties, port names, etc. To have two protocols would be unwieldy. For domain separation this makes sense. Why add weight to the the LASH - client protocol with things such as encryption which most users will never need? Don't get me wrong; inter-host communication is a great idea (for future implementation). But I think a local session protocol should be minimally burdened by the needs of a minority. Yet this is not the only reason I'm against a lashd - the entire world client protocol. Consider the following: If your session is spread across multiple networked computers, how will you be able to auto-launch all the clients if there are no per-host daemons involved? In other words, your master lashd can launch all the clients on the master host, but if you also want to launch remote clients you will need some kind of launcher daemon running on the remote computers. If there's a lashd running on each computer, the master lashd can tell the slave lashds to auto-launch their clients. It seems to me that adding this lashd-to-lashd layer between local domains is both friendlier for clients in terms of protocol complexity and also enables better control. But then again, why should LASH even be concerned with the connections between clients in the first place? That's pretty much it's raison d'etre :-) See the following, and note the file name: http://teasel.6gnip.net/~rah/why-ladcca.png OK, I see. :) There's three different ideas that could be surmised by patch system controller (at least that I can think of.) There's something like QJackCtl, which lets users adjust the settings of the patch system like the sample rate, period size, etc (and we're talking about something which does it on-the-fly, which doesn't exist yet.) Then there's LASH, which monitors port connections and manages their automatic reconnection when a session is restored. Then there's a patch bay, which allows the user to adjust the connections while a session is active. There are no inter-dependencies. They all provide distinct sets of functionality and hence should be separate programs. LASH is actually two separate sets of functionality in one system: automatic port reconnection, and non-X11 session management. So, LASH *does* leave the other stuff to a patch system; it leaves it to the other functionality in itself :-) It could be the case that the two sets of functionality in LASH can be separated into different systems but off the top of my head I'm not sure how inter-dependant they are. Specifically, I'm not sure whether session management is completely
[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
[LAD] [OT] LinuxSampler and GPL - some clarifications
Hi, I'd like to clarify a few questions regarding GPL and LinuxSampler. The GPL implicitly prohibits third parties from selling a computer program licensed under the terms of GPL, by only allowing the following, quoting GPL: ...if you distribute copies of such a program, whether gratis or for a fee... ... You may charge a fee for the physical act of transferring a copy... You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. Basically: 1. selling a computer program licensed under the terms of GPL and 2. charging a fee for distribution of a computer program licensed under the terms of GPL / charging for a physical act of transferring a copy are 2 entirely different things. When you sell a computer program you are charging for the costs(human resources - developers, designers; technical resources - computers etc) you have put into *developing a computer program* plus you are charging an adittional fee based on your estimation of value that your product would have on the market(offer/demand stuff) When you distribute a computer program or charge a fee for physical act of transferring a copy you are charging for the costs you have put into *distribution of a computer program* plus you are charging an additional fee based on your estimation of value that your *distribution service* would have on the market. This means that: 1. usage of a computer program licensed under the terms of GPL in a hardware product, whether modified or not, is not a distribution of a computer program licensed under the terms of GPL, and is thus prohibited by GPL. 2. usage of a computer program licensed under the terms of GPL, whether modified or not, in a software product, the intention of which is not to distribute a computer program licensed under the terms of GPL, is not a distribution of a computer program licensed under the terms of GPL, and is thus prohibited by GPL. No.1 of course has an exception, you would have to sell a computer that has a computer program licensed under the terms of GPL installed on it as a part of distribution, for the purpose of selling the computer(for example with preinstalled Linux distribution) No.2 has several scenarios: a) a distribution is an obvious case where a given computer program licensed under the terms of GPL is a part of a bigger software product, the sole purpose of which is to distribute, thus a distribution is fully GPL compliant whether made available for transfer at no charge, or selled as a package in stores. b) a scenario where computer program must not be modified in order to become part of another comuter program ...thus forming a work based on the Program... This means that if a computer program as a whole, whether modified or not, becomes part of another computer program at *source-code* level, then the terms of GPL apply to such derived work. You can derive a work from another at source code level(by modifying the original, by adding code to it while not modifying the original, or both) but you can also derive a work at binary level. And if fact, the GPL doesn't differentiate between source-code and binary level derived works: ...any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof... So suppose a software developer goes on developing a cool GUI for a computer program licensed under the terms of GPL which he intends to sell. The GUI talks to the GPLed computer program via some kind of IPC. He can claim that he's charging for his own program and distributing the GPLed computer program along with it, since the two are in fact 2 separate applications that communicate through IPC. This might be true, but consider the following - the GPLed computer program is capable of functioning as a standalone application, whereas the GUI application is practically useless without the GPLed computer program, ans is thus a derived work at *binary-level*. The GPL states, that ...in whole or in part contains or is derived from the Program..., which means, whether at source code level or binary level. This has the following consequences: A proprietary computer program that is not capable of functioning as a standalone computer program, and is communicating with a computer program licensed under the terms of GPL, in order to ensure its purpose and proper functioning, is a derived work under the terms of GPL, thus the terms of GPL apply to such work, and a software developer of such proprietary computer program is *also* violating the terms of GPL by not distributing the computer program licensed under the terms of GPL for the sole purpose of distributing it. So to summarize that with respect to LinuxSampler, the exception LinuxSampler is licensed under the GNU GPL with the exception that USAGE of the source code, libraries and applications
Re: [LAD] [OT] LinuxSampler and GPL - some clarifications
On 27/01/2008, Mlf Conv [EMAIL PROTECTED] wrote: So LinuxSampler is basically a pure GPLed computer program. Marek i'm not trying to add fuel to the fire or anything, but if this is the case, and the gpl protects against the sort of thing they are worried about anyway, why go through all the hassle of adding the clause that has obviously (whether deserved or not) caused so much controversy? wouldn't it be better to simply have a faq item stating that the gpl prohibits this behaviour anyway? i hope this comes across right without upsetting anyone, as it is obviously a delicate topic, and i am just trying to understand it better myself, not cause more issues :) porl ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
