Hi Paul,
just had the time to read your docs regarding Unison design and I really
like it. As an abstract description it's very similiar to how LMMS is
supposed to work in the future (especially the resources section). I don't
know whether to agree or disagree about the migration to LV2 as I don't see
an immediate advantage over the existing approach + we have to deal with
dependencies on LMMS components (as you've mentioned already as well). I'd
rather cleanup/simplify the existing API (especially regarding FX plugins).
The dependency graph approach for rendering is very good and IMHO should be
hidden from the user for the most part (i.e. usage shouldn't differ too
much from what it is currently - I don't want to have to plug virtual wires
etc. (that's one of the reasons why I personally dislike JACK)).
So far.
Toby
2014/1/15 Paul Giblock <drfa...@gmail.com>
> Tobias:
>
> Thanks for your input! I know I contacted you regarding the Unison-Studio
> endeavor several years back (3?? Wow, time flies!) You are the main person
> holding LMMS together at this point, so I definitely do not want to
> distract you from keeping LMMS usable and integrating contributions from
> volunteers. LMMS is what it is. It is still version-1.0 regarding system
> design.
>
> I know you are unable to contribute to the uprising, or at least not until
> it is close to feature-parity with LMMS. However, I would appreciate some
> implementation and design input regarding my findings. Please consider
> these documents (others are welcome to comment as well!):
>
> - https://github.com/pgiblox/unison/blob/master/docs/basic_ideas.texi
> - https://github.com/pgiblox/unison/blob/master/docs/TODO.txt
>
> Some of these ideas are pipe-dreams, others are not well-formed, but I
> hope it gives some idea of where I'd like things to go. I hope you have
> some input based on struggles you've had with extending LMMS and, in
> particular, the resource framework.
>
> -- Paul
>
>
> On Wed, Jan 15, 2014 at 12:49 PM, Tobias Doerffel <
> tobias.doerf...@gmail.com> wrote:
>
>> Hi,
>>
>> 2014/1/15 Paul Giblock <drfa...@gmail.com>
>>
>>> Another thing that really bothered me about LMMS is that the projects
>>> are huge monolithic beasts. Therefore, I have additional thoughts regarding
>>> next-genreation project files, resource management, and a "proper"
>>> extension system. Essentially, projects are just containers, and extensions
>>> determine what is stored into the project.
>>>
>>
>> Very true. The current state is a result of 10 years evolutionary work
>> with many parts being a mess (even though things improved when we did the
>> model/view split) and for many parts dates back to times where my
>> programming experience/skills were very little compared to today. I'd like
>> to see new core concepts as well even though I wonder how we ever will be
>> able to crimp over the current UI and especially the current concept/core
>> structure (millions of existing projects!).
>>
>> Having said that I'd like to let decisions open from my side, as I
>> currently do not see myself able to help out on this matter. If there's
>> enough manpower for the revolution: please please go ahead and don't let
>> you stop! In the meantime I'll try to give my best to continue the
>> evolution of the current state and concentrate on pushing new UI features
>> so they might be helpful not only for future releases of the current core.
>> I hope that is ok with you :-)
>>
>> Toby
>>
>
>
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
LMMS-devel mailing list
LMMS-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lmms-devel
