From: Alexandre P. <av...@al...> - 2003-06-26 09:41:18
|
Greetimgs, To get another stuff out in the open... What are our plans a propos documentation? I could do translation of it into Russian, if a completed documentation is ready at least a month before 1.0 stable release. My humble opinion is not to deal with xmldiff :-) -- Alexandre Prokoudine ALT Linux Documentation Team JabberID: av...@al... |
From: Silvan <dmm...@us...> - 2003-06-26 15:29:19
|
On Thursday 26 June 2003 05:40 am, Alexandre Prokoudine wrote: > Greetimgs, > > To get another stuff out in the open... > What are our plans a propos documentation? > I could do translation of it into Russian, if a completed > documentation is ready at least a month before 1.0 stable release. > > My humble opinion is not to deal with xmldiff :-) I don't know what anyone else is planning, but I agree with you on the timeframe. I think we should pick a feature set, stick to it rigidly, say "that will be 1.0" and then crack down on the docs. As you say, this needs to be done *well* in advance of 1.0 so that the doc writers and translators have time to do their bit, and the whole thing can ship as a complete package. -- Michael McIntyre USDA zone 6b in SW VA, USA Silvan <dmm...@us...> Linux Druid ----------[ registered Linux user #243621 ]--------- http://www.geocities.com/Paris/Rue/5407/index.html |
From: Richard B. <bo...@bo...> - 2003-06-27 14:57:20
|
On Thursday 26 June 2003 4:28 pm, Silvan wrote: > I think we should pick a feature set, stick to it rigidly, say "that > will be 1.0" and then crack down on the docs. Well we have a feature set - it's control rulers and that's it really. There are a few more things I have in mind now but they're all quite small - mostly it's tidying up and bug fixing though. When control rulers are completed we should go for 0.9.5 as soon as we can after that. After the 0.9 debacle we should then plan for a 0.9.6 release week or two after that maybe but essentially there wil be no more feature development from that point onwards. So after 0.9.5 it's bugs, performance and documentation. Ok, things have pushed out a bit but ball park figures I have in mind now are: 0.9.5 - End of July 0.9.6 - Mid August - at this point start beta testing in earnest. 1.0 - Whenever it's complete. Maybe by the end of September, maybe later. If things push on too far without a release we can have another point release. So yeah, our feature list is mostly complete but there has to come a time soon when that includes all small features - that includes all new dialogs (SimpleEventEdit, EventFilter) and features outstanding (Print organisation, segment colouring, process/jack control, synchronisation). We need a list of all these and detail people to take ownership for them - perhaps we can organise this through sf as the feature requests are a bit underused at the moment. R |
From: Alexandre P. <av...@al...> - 2003-06-27 15:03:37
|
On Fri, 27 Jun 2003 15:20:48 +0100 Richard Bown <bo...@bo...> wrote: > When control rulers are completed we should go for 0.9.5 as soon > as we can after that. After the 0.9 debacle we should then plan > for a 0.9.6 release week or two after that maybe but essentially > there wil be no more feature development from that point onwards. > So after 0.9.5 it's bugs, performance and documentation. So, tablature support from KGuitar will be a post-1.0 stuff if ever? > Ok, things have pushed out a bit but ball park figures I have in > mind now are: > > 0.9.5 - End of July > 0.9.6 - Mid August - at this point start beta testing in earnest. > 1.0 - Whenever it's complete. Maybe by the end of September, > maybe later. > If things push on too far without a release we can have > another point release. I see > So yeah, our feature list is mostly complete but there has to come > a time soon when that includes all small features - that includes > all new dialogs(SimpleEventEdit, EventFilter) and features > outstanding (Print organisation, segment colouring, process/jack > control, synchronisation). Yes, I think that we really need printing improved --- the way RG prints now is not sufficient for an end-user, if we/you are aim to implement feature requests :-) -- Alexandre Prokoudine ALT Linux Documentation Team JabberID: av...@al... |
From: Chris C. <ca...@al...> - 2003-06-27 15:31:24
|
Alexandre Prokoudine wrote: > So, tablature support from KGuitar will be a post-1.0 stuff if ever? Post-1.0, yes. Some time, almost certainly. Chris |
From: Richard B. <bo...@bo...> - 2003-06-27 15:37:57
|
On Friday 27 June 2003 4:03 pm, Alexandre Prokoudine wrote: > So, tablature support from KGuitar will be a post-1.0 stuff if ever? Yes. I think it'll be a lovely project to integrate/mimic/work with in future but it's certainly on the periphery of the features at the moment. Our primary concern is getting a stable and working fully functioned ssequener and notation editor out there - then we can start having fun (and as far as I'm concerned tab stuff is the "next stage"). > Yes, I think that we really need printing improved --- the way RG > prints now is not sufficient for an end-user, if we/you are aim to > implement feature requests :-) Printing is good if you fiddle about with lilypond - at the moment we need to either improve native printing or better integrate lilypond output. R |
From: Chris C. <ca...@al...> - 2003-06-27 15:36:50
|
Richard Bown wrote: > Well we have a feature set - it's control rulers and that's it really. > There are a few more things I have in mind now but they're all quite > small - mostly it's tidying up and bug fixing though. Some things I'd like to get done: * Finish this banks/variations business. Tidy up audio instrument parameter box. * Sort out what to do about ALSA ports -- do we create one per connection so that people can use aconnect? That could be quite a bit of work. Also some careful work needed with things like device names and instrument handling, which still isn't really done right. * A few more features like general file merging. * Notation still lacks a few things that I think are essential, largely to do with managing the timings of notes and chords, though also e.g. bracketing staves, repeats etc. I'd _love_ to do performable ornaments for 1.0 but I'm not optimistic. * Tempo map editing. Tempo and time signature editing just isn't there at all yet really, and it does rather need to be. I'm also still thinking about the experimental branch shmfile stuff. What's your feeling about that these days? I sort of have a suspicion that we might be better off in the long run if we just merged it across to HEAD pretty much right away and then hammered on it for a bit. Chris |
From: Richard B. <bo...@bo...> - 2003-06-27 15:59:14
|
On Friday 27 June 2003 4:36 pm, Chris Cannam wrote: > * Finish this banks/variations business. Tidy up audio > instrument parameter box. Ayup. > * Sort out what to do about ALSA ports -- do we create one per > connection so that people can use aconnect? That could be > quite a bit of work. Also some careful work needed with things > like device names and instrument handling, which still isn't > really done right. I think it's fine as it is really. > * A few more features like general file merging. Ok, one thing I've forgotten is multiple document support. > * Tempo map editing. Tempo and time signature editing just > isn't there at all yet really, and it does rather need to be. Yes. > I'm also still thinking about the experimental branch shmfile stuff. > What's your feeling about that these days? I sort of have a > suspicion that we might be better off in the long run if we just > merged it across to HEAD pretty much right away and then hammered > on it for a bit. We might well do - what I suggest we do then is pick a date - make sure everything builds and then tag the tree before the merge. Then you, me and G all hammer it for as long as it takes to get it working and if we come across anything insumountable we've not thought about we roll back. I've updated docs/task_lists/1.0_release.txt with some of these plus some notes I took from the show regarding features and bugs. After we've added current tasks I think maybe we should all work from this one file so we all know where we stand. Plan? R |
From: Guillaume L. <gla...@te...> - 2003-06-30 17:03:41
|
On Friday 27 June 2003 17:47, Richard Bown wrote: > We might well do - what I suggest we do then is pick a date - make sure > everything builds and then tag the tree before the merge. Then you, me > and G all hammer it for as long as it takes to get it working and if we > come across anything insumountable we've not thought about we roll back. > > I've updated docs/task_lists/1.0_release.txt with some of these plus some > notes I took from the show regarding features and bugs. After we've added > current tasks I think maybe we should all work from this one file so we > all know where we stand. > > Plan? Yes (sorry, just acknowledging here). -- Guillaume http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2003-06-27 16:06:15
|
Richard Bown wrote: > On Friday 27 June 2003 4:36 pm, Chris Cannam wrote: >> * Sort out what to do about ALSA ports -- do we create one per >> connection so that people can use aconnect? That could be >> quite a bit of work. Also some careful work needed with things >> like device names and instrument handling, which still isn't >> really done right. > > I think it's fine as it is really. Which part? >>I'm also still thinking about the experimental branch shmfile stuff. >>What's your feeling about that these days? I sort of have a >>suspicion that we might be better off in the long run if we just >>merged it across to HEAD pretty much right away and then hammered >>on it for a bit. > > We might well do - what I suggest we do then is pick a date - make sure > everything builds and then tag the tree before the merge. Then you, me > and G all hammer it for as long as it takes to get it working and if we > come across anything insumountable we've not thought about we roll back. Yeah. First I'll get the experimental branch actually playing again. I can handle the CVS merge when the time comes -- it will take a little care but I know how to approach it. Chris |
From: Richard B. <bo...@bo...> - 2003-06-27 16:43:42
|
On Friday 27 June 2003 5:05 pm, Chris Cannam wrote: > Richard Bown wrote: > > On Friday 27 June 2003 4:36 pm, Chris Cannam wrote: > >> * Sort out what to do about ALSA ports -- do we create one per > >> connection so that people can use aconnect? That could be > >> quite a bit of work. Also some careful work needed with things > >> like device names and instrument handling, which still isn't > >> really done right. > > > > I think it's fine as it is really. > > Which part? Oh sorry - I forgot to go back to that part of the reply. I s'pose what I mean is it works well now for the easy cases and it should just be a low priority. > Yeah. First I'll get the experimental branch actually playing again. > I can handle the CVS merge when the time comes -- it will take a > little care but I know how to approach it. We need to bear in mind that moving the metronome and event filtering down to the sequencer at that stage might well makes a lot of sense too (and the whole shared mem thing more efficient). Or not. Indeed as for other asynchronous events - we can just use the existing sendMappedEvent over DCOP (as they at least are non blocking). There is still _one_ remaining DCOP contention issue to do with picking of audio plugin whilst playing. I'm presuming that once we've got rid of the frequent blocking calls() (getSequencerSlice()) then this will sort itself out too. R |
From: Chris C. <ca...@al...> - 2003-06-27 19:16:58
|
On Friday 27 Jun 2003 4:09 pm, Richard Bown wrote: > We need to bear in mind that moving the metronome and event > filtering down to the sequencer at that stage might well makes a > lot of sense too (and the whole shared mem thing more efficient). =20 Yes, and it occurred to me that we could quite easily put the=20 MappedDevice things in shared memory too and wipe out practically the=20 entire syncDevices overhead. Chris |
From: Silvan <dmm...@us...> - 2003-06-27 22:07:42
|
On Friday 27 June 2003 11:19 am, Richard Bown wrote: > moment. Our primary concern is getting a stable and working fully > functioned ssequener and notation editor out there - then we can start > having fun (and as far as I'm concerned tab stuff is the "next stage"). Tab stuff would be a most nifty addition indeed, but I agree that it should wait. Having a fully-functional notation editor at this stage is debatable. It does some things well, and some things poorly. The biggest deficiency is... > Printing is good if you fiddle about with lilypond - at the moment we > need to either improve native printing or better integrate lilypond > output. ...printing! What *do* we want to do with that? After Chris revamped the print engine a bit ago, it looks almost passable. Bar lines are funky looking, and ties/slurs aren't terribly pretty, but it stands somewhere above my 10-year-old Cakewalk, and I could play from one of those scores. Add some title/composer info at the top of the page, and take care of the things that make it give up and die, and it's not bad. OTOH we have Lilypond. I worked my ass off to try to get that up to par as a fire and forget print filter, but it isn't there. It's very hit or miss, and when it misses, it misses badly, yielding garbage so fouled up that it's virtually impossible to understand what went wrong well enough to correct it by hand and produce a usable file. Unless something magic happens, I just don't see the existing algorithm getting good enough to make the grade as a hands-off print filter. I've been tossing around ideas for a new algorithm, but that would be an enormous undertaking, and I'm almost certain to run into new and different problems along the way. At the end of the day, I just don't think it's going to be possible to translate Rosegarden into Lilypond reliably enough for this purpose. So my vote is that Lilypond export is offered for those who are willing to work around its limitations; to fix the problems manually, to "jiggle" things in their compositions so that the export can do a better job, etc. I see it being offered as a convenience feature, not as an integrated engine for printing. -- Michael McIntyre USDA zone 6b in SW VA, USA Silvan <dmm...@us...> Linux Druid ----------[ registered Linux user #243621 ]--------- http://www.geocities.com/Paris/Rue/5407/index.html |
From: Alexandre P. <av...@al...> - 2003-06-28 13:11:12
Attachments:
rg-printing.png
|
On Fri, 27 Jun 2003 17:58:19 -0400 Silvan <dmm...@us...> wrote: > So my vote is that Lilypond export is offered for those who are > willing to work around its limitations; to fix the problems > manually, to "jiggle" things in their compositions so that the > export can do a better job, etc. I see it being offered as a > convenience feature, not as an integrated engine for printing. Just a small flowchart in attachment... -- Alexandre Prokoudine ALT Linux Documentation Team JabberID: av...@al... |
From: Silvan <dmm...@us...> - 2003-06-27 22:08:56
|
On Friday 27 June 2003 10:20 am, Richard Bown wrote: > Well we have a feature set - it's control rulers and that's it really. > There are a few more things I have in mind now but they're all quite > small - mostly it's tidying up and bug fixing though. OK, hand in hand with the control rulers, we need named controllers in the studio. Is anyone working on that? I think it's a must have before 1.0 personally. I think I can do it if no one has time/inclination. The infrastructure would be very similar to the existing program name stuff; just slightly less complicated. I'm figuring one bank of controllers per device. Plus probably a hard coded minimum default set to handle old files which have no controllers defined. I've been thinking of a new, separate dialog that's a simplified version of the bank editor, but this could conceivably be added directly to the bank editor too. Once they're in the studio, then the control rulers could make use of user named stuff pretty easily. We'd have to think about what to do with the instrument parameters box though. Ideally, I'd like to see that be configurable as well, where the user has howevermany slots, and gets to pick which slot is hooked to which controller in the studio. That can probably wait until after 1.0 though. Anyway, I can probably do all this, but if I do it, it will take me at least a month to get it working. I'd be setting an unrealistic goal if I said otherwise. Any one of you can get there before me, but if you have bigger things to work on, I feel like it's within my reach. -- Michael McIntyre USDA zone 6b in SW VA, USA Silvan <dmm...@us...> Linux Druid ----------[ registered Linux user #243621 ]--------- http://www.geocities.com/Paris/Rue/5407/index.html |
From: Richard B. <bo...@bo...> - 2003-06-28 08:40:11
|
On Friday 27 June 2003 10:16 pm, Silvan wrote: > OK, hand in hand with the control rulers, we need named controllers > in the studio. Yes - "controller management" basically allowing us to define controllers and their appearance on the instrument parameter box and control rulers. And yes, this should be another studio dialog. Something like "Manage controllers". I'll work with you on this one but yes it's essential for 1.0 too. R |
From: Silvan <dmm...@us...> - 2003-06-29 00:14:08
|
On Saturday 28 June 2003 04:28 am, Richard Bown wrote: > And yes, this should be another studio dialog. Something like "Manage > controllers". I'll work with you on this one but yes it's essential for 1.0 > too. Should I take that to mean I should go ahead and start, or should I go do something else for awhile? I'm not clear on what "I'll work with you on this one" means for me to do, and I don't want to piss you off. I guess I should make my personal todo list public too... I've been working on a tasks_mm file to help organize my thoughts, but since you just said we should all work from a central list, and since I won't presume to add to that, I'll just post mine here: * event filter dialog filter events from selection in notation/matrix views get working in matrixview, then move to notation view [DONE except for debugging pitchbend] * document event filter dialog in RG manual * look at other updates for RG manual * import studio from file/use default instead of imported studio when loading, to satisfy my desire to see effective "global" instrument settings [stubbed out in local tree, but no implementation] * implement Pitch in lilypondio in parallel with existing methods, so we can eventually wean it off of the junky code it currently uses. [partially implemented in local copy, but incomplete] * look at the "Chord" class for Lilypond and see how it might help resolve the weird "measures that just don't add up" problems I've been seeing * named controllers for studio with associated bankeditor-like dialog * find decent home for event filter toolbar icons * fix step recording icon? little feet would be more intuitive to me than the arrow thing Chris came up with * completely rewrite tutorial for 1.0, using fewer/smaller pixmaps, better organization, possibly converting to LDP docbook format -- Michael McIntyre USDA zone 6b in SW VA, USA Silvan <dmm...@us...> Linux Druid ----------[ registered Linux user #243621 ]--------- http://www.geocities.com/Paris/Rue/5407/index.html |
From: Richard B. <bo...@bo...> - 2003-06-29 09:33:09
|
On Sunday 29 June 2003 1:13 am, Silvan wrote: > On Saturday 28 June 2003 04:28 am, Richard Bown wrote: > > And yes, this should be another studio dialog. Something like > > "Manage controllers". I'll work with you on this one but yes it's > > essential for 1.0 too. > > Should I take that to mean I should go ahead and start, or should I > go do something else for awhile? I'm not clear on what "I'll work > with you on this one" means for me to do, and I don't want to piss > you off. No, do go ahead. I'll just chip in with some code or help you out with it or whatever. What I was trying to say was I'd thought about this too that's all. > I guess I should make my personal todo list public too... I've been > working on a tasks_mm file to help organize my thoughts, but since > you just said we should all work from a central list, and since I > won't presume to add to that, I'll just post mine here: Well what's the point of having a central list if we all don't use it? No, please do add these to the 1.0 list otherwise it's hard to keep track of whats finished and what isn't. Not that I expect C and G to use it at all because they hate me trying to organise them. R |
From: Silvan <dmm...@us...> - 2003-06-29 15:18:11
|
On Sunday 29 June 2003 05:21 am, Richard Bown wrote: > No, do go ahead. I'll just chip in with some code or help you out > with it or whatever. What I was trying to say was I'd thought about > this too that's all. OK. I'll get started when I can, which probably means I'll get more accomplished Monday night/Tuesday morning than today. Busy weekend with family reunions and baseball games and whatnot, and I just took on some paying logo design stuff with a short deadline that will likely eat up most of my time today. (But it's *paying* which is pretty damn cool.) > Well what's the point of having a central list if we all don't use it? > No, please do add these to the 1.0 list otherwise it's hard to keep > track of whats finished and what isn't. Not that I expect C and G to > use it at all because they hate me trying to organise them. Well, I'll stay out of that last bit. I'll add my stuff to the main list in due course then. -- Michael McIntyre USDA zone 6b in SW VA, USA Silvan <dmm...@us...> Linux Druid ----------[ registered Linux user #243621 ]--------- http://www.geocities.com/Paris/Rue/5407/index.html |