Hi Tim :)
i've read through all of your mails, and can mainly agree with you. Just a few things for now, more will follow until next week, I think. Am 23.01.2014 schrieb Tim E. Real: > We currently don't really have our own 'audio thread' > apart from Jack's process callback, do we... that's true, the audio thread IS the jack-callback-thread. > Rule of thumb, as you say Flo: The GUI should be de-coupled from audio > so that almost NOTHING in the GUI needs to wait for ANYTHING. > Careful timing, queuing, signaling, and stream inhibiting upon mouse presses, > will help. Can you please elaborate more on 'timing' and 'stream inhibiting'? > I guess what I'm saying is don't be too critical of the path chosen... Well, the path itself is to be criticized. What I'm not too critical about is the people who made this path happen ;). It wasn't too obvious that all this will implode at some point, so nobody is to blame here. But it did implode, so we need to analyse our mistakes made. > I believe we can make our process engine proper in... a few weeks, > after discussing to make sure we know what we're doing and it'll > work. > If you want to start a new branch I'll try to work out some details and let's > talk about how to do this. I think it would be relatively straight forward... I'm not sure whether we should try to fix MusE 2.0. I think, we should really start from scratch, with an empty project, and write it from bottom up again. If it turns out that we can copy'n'paste most of it, then that's cool. If it turns out that we cannot, then MusE is really in need of a rewrite at these places. There would be no point in "trying to fix" it then. I want to get away from this "greedy" development attitude (not meant pejorative, but like in "greedy algorithm"): We never give away a feature that we already have, and therefore try to get the best out of *what we have*. We should, however, get the best out of "what's possible". I think that we are caught in a local maximum, and we need to let go first, and can then approach the global maximum. Also, most importantly: I would not start right now. We should -- probably the first time in MusE's life -- make a draft. A design paper, you know, something like "If the GUI wants to do $things, it MUST do $stuff. During this, it SHOULD display a progress indicator. This MAY be..." After we have this design document, we proof-read it. And then we let jack developers and/or LAD proof-read it. And then we proof-read it again and THEN, we start coding. Benefits from this: The design paper almost doubles as documentation. Interested coders can quickly get a grip on MusE and support us. Please, let's not make the same mistake again. Let's think about what to do, make a complete specification. That way we notice issues like "clone parts interfere with audio streams" early, and not when it's already too late. I'd say, few weeks might be too optimistic, but I think we can do this in less than 8 weeks. A fair tradeoff for a shiny, new, well-designed MusE with an intuitive user interface :). > Thus I give you... Undo "Trees". That would be great :) But implementing this is postponed, we have more important and work-intensive stuff to do, okay? Of course, we should already draft its design, so there are no bad surprises later on. > Git, CVS, version control Another great idea, but same thing ;) BTW, What programming languages do all of you speak fluently? There might be languages that are more appropriate for writing GUI code than C++ (?), just a thought. Greetings, and looking forward to a overwhelming MusE 3, Florian
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
_______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
