[16:08] <TheMuso> c
[17:12] <azm> Hi. Just read blog post
[17:12] <azm> thats pity
[17:14] <JFo> azm, what blog post?
[17:15] <azm> http://dullass.blogspot.com/2010/08/state-of-ubuntu-studio-2010.html
[17:18] <azm> well at least I help with stayin in this chan for this moment
[17:38] <JFo> ScottL, nice blog post :)
[21:57] <stochastic> scott-work, are you around?
[21:57] <scott-work> stochastic: i am about to leave in 2.2496 secs
[21:57] <scott-work> s/secs/minutes
[21:57] <scott-work> 2.2495 minutes
[21:58] <scott-work> but i'll be home in approximately one hour though
[21:58] <stochastic> scott-work, okay, it's not that important, talk to you later
[21:58] <scott-work> stochastic: will you be around at that time, want to talk then?
[21:59] <stochastic> probably, but might be busy myself, ask me then
[21:59] <scott-work> righty-o !
[22:24] <stochastic> ScottL, I was just in the process of editing the workflow wiki and was about to include a workflow for creating soundtracks for movies (was going to put it in the audio section) when I realized there was one already created
[22:25] <stochastic> Not only is it in the video section of the page, but it uses Open Movie Editor in place of XJadeo (the app I normally use)
[22:26] <persia> stochastic, In the spirit of opinionated defaults, do you have a strong opinion why XJadeo is better than Open Movie Editor for that purpose?
[22:28] <stochastic> persia, yes, the intended purpose was to have a video playback that syncs with either jack's or ardour's timecode so that the audio editing can be done in sync with the video
[22:28] <persia> Excellent.  Let's make it better.
[22:28] <persia> My recommendation would be to send a mail to the list with both workflows and an argument why the one using XJadeo is better.
[22:29] <stochastic> Open Movie Editor is very large and has many more features than is required for this task, XJadeo is a basic stripped down player whose primary function is to sync with either jack or ardour's timecode
[22:29] <persia> It's not hard to switch, but I'd much rather just select one thing.
[22:29] <stochastic> me too
[22:29] <stochastic> persia, I'd like to hear your explanation as to why denemo should be removed in favour of mscore
[22:30] <persia> The other side of things is whether it's better to teach users to use several parts of Open Movie Editor, rather than several tools.  I'm a fan of the do-one-thing-well model rather than the everything-in-one-interface model, but it does make extra work for the docs folk.
[22:30] <persia> Oh, the main reason is that denemo is exceedingly painful to maintain, and sometimes rather broken when we try to release.
[22:31] <stochastic> I think most of the other features of Open Movie Editor are already duplicated in other pieces of software in the video task (OpenShot, Blender)
[22:32] <persia> That sounds like a compelling argument to make Open Movie Editor an alternative application, rather than one of the featured applications.
[22:33] <stochastic> re:Denemo, I have no attachment to Denemo, but am VERY attached to it's backend Lilypond (and the lilypond editor Frescobaldi) they have features that no other notation applications have and produce some of the most beautiful scores around - however they are not beginner friendly
[22:34] <persia> Denemo is frescobaldi except without the attention to detail
[22:35] <persia> But yeah, I agree lilypond is wonderful: I'm just not sure it's worth the effort to try to make it reasonable for new users when musescore is available, works with our stuff, and has an active upstream who have been involved with us for some time.
[22:35] <stochastic> Frescobaldi does not have a point-click interface, it's meant as an text editor with graphical display, Denemo tries to be a point-click interface for Lilypond
[22:36]  * stochastic will not be able to be convinced that we should drop Lilypond (but really couldn't care that much about which beginner-friendly editor we ship with)
[22:37] <stochastic> persia, I like your arguments for musescore, but I believe that it serves a different audience than Lilypond
[22:38] <persia> I agree.
[22:38] <persia> So, I don't want to drop lilypond from the archive, and I think it's worth us putting effort into testing it and making sure it's maintained.
[22:39] <persia> That said, I also think it's better to ship musescore in the images (if it works well enough), and encourage folk who need it to install lilypond later.
[22:39] <persia> Does my position make more sense now?
[22:39] <stochastic> yes
[22:40] <stochastic> ScottL, I know you're not home yet, but maybe it's something to consider keeping workflows on that wiki page that include applications not in Ubuntu Studio's metas
[22:40] <persia> I wonder if we oughtn't have two pages: "Recommended Workflows" and "Alternate Workflows"
[22:41] <persia> We can point folk at the Alternates if they need something the recommended ones don't service, if it's documented there.
[22:41] <persia> And we can review alternates each release to determine if we want to swap things around.
[22:41] <stochastic> I think two pages would be unnecessary, we just need to mark certain workflows with items like "Advanced" or "Install program X"
[22:42] <stochastic> nothing wrong with having an install step as part of the workflow
[22:42] <persia> I don't like "Advanced" because it scares folk off.  There are lots of folks who self-identify as newbies who have workflows that would need such tools.
[22:43] <stochastic> fair enough
[22:43] <persia> My main argument in favour of two pages is to reduce the scope of the primary docs to something that makes it translation-friendly.
[22:43] <persia> Once we have regularly updated docs and sufficient translators, then I'd be happy to expand to include off-image workflows by default.
[22:44] <persia> And, yeah, nothing wrong with the first step being to install something, I just think we ought to encourage folk to look at the things already working by default.
[22:45] <stochastic> my main argument in favour of one page would be that the page is still in early development stages and breaking it up may result in doubling of workflows and info
[22:46] <stochastic> I think we're still in the "brainstorm of workflows" time period
[22:46] <persia> Oh, then I completely agree with you, as long as we can separate/filter later once ScottL decides what belongs on the images.
[22:46] <stochastic> once the page is well developed, then we can start to sort it into "on-image" "off-image" workflows if needed
[22:47] <stochastic> and a second page may not be the best method, maybe just move those later workflows to a lower section of that page, as many users wouldn't visit a second page
[22:48] <stochastic> ^^ maybe
[22:48] <persia> Dunno.  That's the sort of detail decision I think is better left to whoever is willing to manage the documentation.
[22:48] <stochastic> fair enough
[22:49] <persia> Have to provide some incentive :)
[22:49] <stochastic> :)
[23:49] <ScottL> hi stochastic and persia, i would point out that zettberlin (i think) said that OpenMovieEditor isn't actively developed anymore
[23:49] <persia> An extra argument for not using it by default.  I'm liking this way of reviewing applications more and more
[23:50] <ScottL> :)
[23:50] <ScottL> i also see we need to remove the 'mscore' package and use 'musescore' in natty
[23:50]  * ScottL hopes he understands it correctly
[23:50] <persia> I think we'll inherit that from Debian, as it's still needed for squeeze uploads.
[23:51] <persia> s/uploads/upgrades/
[23:52] <ScottL> i really appreciate the effort from the community to help with the workflows, it's absolutely amazing and fascinating
[23:52] <ScottL> however if we used all the applications they suggested our image would be even bigger than it is now perhaps :P
[23:52] <persia> I think it's worth adding some direction based on the discussion stochastic and I had above about primary and alternate solutions.
[23:53] <persia> But that might need someone to be the documentation coordinator, etc. (ideal candidate would be willing to fill roles both in Ubuntu Studio and Ubuntu Docs, etc.)
[23:54] <persia> And then you can select some subset of workflows that would enable 80%+ supported use for identified audience, etc.