2008/1/15, Luis Garrido <[EMAIL PROTECTED]>:
>
> > This basically will turn LS into soft of a powerful modular synth
> although
>
> It is your time and effort, so you are naturally very much entitled to
> do whatever you wish, and the community will be grateful if you share
> it with us. But, since you ask for opinions... Please consider
> anything written below as honest questions and opinions, with not a
> trace of irony among them.
>
> Sigh. We have a gajillion modular synths already. I could probably
> list more than twenty out of the top of my head. I guess they must be
> so much fun to program.
>

Sure there were tons of samplers around too, so why start working on LS in
the first place ?
The fact is that there are not yet so many high quality audio apps around
(how many open source samplers
do you know which achieve the complexity and completeness of LS?).
there are some modular synths around for linux but they are not good enough
to allow you to construct
an efficient and flexible sample engine which can compete with hardcoded
designs.

http://linux-sound.org/swss.html
>
> > and contains the implementation too, for example a C/C++ code fragment
> or
> > some pseudo code which can efficiently
> > translated into an executable.
>
> If you don't know it already, you might want to check out:
>
> http://chuck.cs.princeton.edu/


sure there are tons of such projects but often  not much can be reused,
either for technical
or license reasons. we want to maintain the LS license as it is and
therefore develop all our stuff
in house or alternatively we use code and libraries with compatible
licenses, LGPL, BSD etc.
We are not keen to reinvent the wheels over and over again but even though
there are many
projects around it rarely happens that you can reuse large parts of it for
your project and even
adapting the old codebase to your framework can consume more time than
writing it from scratch.

> With this system you could quite easily (often without any or little
> coding
> > at all) implement engines
> > for legacy formats like AKAI etc.
>
> Huh... That sounds more interesting. Can you please elaborate? How
> would that be significantly easier than reutilising the objects of the
> already existing LS codebase?


it is easier in the sense that you can drag around modules and create
connections, build hierarchies etc
rather than hand coding everything.


> Let's enlist which basic building blocks would be needed for our engine.
> > A few modules that come to mind:
> > - MIDI input/output
> > - audio input/output
> > -  oscillators
> > - filters
> > - envelope generators
> > - event generators / filters
> > - mathematical operators (adders, integrators etc)
> > - data type converters
>
> I assume that there is a sampling module somewhere. What would its
> capabilities be?


of course there will be a sample playback basic building block, it's
capabilities are yet to be defined,
just throw in your ideas and we will try to design it as flexible as
possible.

It seems an awful lot of work just to duplicate already existing
> stuff. Perhaps you can consider joining one of the ongoing projects in
> order to optimize community resources, but we know how those things
> turn out.


it is harder than it seems, each development group has different priorities,
often they are emotionally
attached to it and don't want to leave it in the cold because they join a
different project.
the LS dev group is still small but we have the advantage that we are more
flexible and come easier to
an agreement and can simply put forward an idea and implement it into code.
We are open to any kind of collaboration but collaboration with other groups
or reusing other project's code
is very hard to put in practice. The great advantage of a open source
project is that you do not have any deadlines
no sales department which dictates features with the sole goal to maximize
profit etc.
And even though development is a bit slower at times, nothing happens, the
code is not going away.
And given the fact that commercial developers work fulltime on a product and
employ several developers,
their development speed is not that great.
What is GS4 biggest innovation ? 64bit support, a few articulations more ?
Wow ! Lot's of development and man years of work.
Kontakt3 is not even a 64bit app. Peehaps NI does not know how to use the
64bit  data pointers ? Or is
the marketing department to blame ? Otherwise they will not be able to sell
K4 as it needs some new killer features.

64bit on windows in general is a joke as the only version which supports it
is Vista (apart from XP64 which does not count as it is hard
to get and not supported by most audio application developers etc).
Vista's performance is embarassing at best, and you can imagine how much M$
cares about the small audio/sampling market.
It is a real dilemma for commercial audio application developers.
We don't have this problem as LS now runs on any desktop operating system
and we let the user chose the platform that works best for him.

And given the fact that apps like Reaper work excellently under wine, the
natural upgrade path from XP is Linux.
As long as the performance is excellent why bother with Vista  once XP will
be discontinued.

I am sure you will have a great time designing and implementing it,
> but as a member of the community I can't say I am too excited about
> it.


I respect your opinion but after evaluating the current situation we came to
an agreement that
it does not make sense to work on a new monolithic engine anymore.


There is also the eternal issue of performance vs flexibility. Will
> the overload of communication between modules put a noticeable
> performance penalty compared to that of a monolithic system?


The goal is to achieve same as hardcoded design perforamance, this can be
leveraged
by letting the c compiler compiling and optimizing the various modules and
engines.
Since we are open source we can do it and exploit this advantage :)

My wish list? Not very important, this is FOSS, we code what we feel
> like, not what other people would like us to code. Anyway, I am more
> interested in realistic samplers, so I feel more the need for a
> powerful mature sampler editor and randomizing capabilities in a
> sampler engine. Hope I will have time and the drive to work on it at
> some time.


please define the features  of a realistic sampler and randomizing
capabilities.
all those features can be implemented to work within the new modular
framework.

Good luck,


thanks alot,  as always everyone is invited to join the club and make some
contributions.
every little bit counts.

... and the journey continues :)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Reply via email to