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