Thread: [Audacity-devel] Getting back in to the swing
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Leland <le...@au...> - 2008-09-16 03:21:39
|
I need to get back into Audacity mode as I'm starting to get the shakes...I need my fix! :-) I won't be able to do a lot just yet (my wife it trying to finish some songs for a Christmas CD and I make too much noise), but I can certainly get some things done. So, where are we? What are we going to do about the GSoC code? Mark it all experimental? Go ahead and leave it "mainstream"? What's the current link to list of bugs? Are we at a point where we can say no more new stuff and start working toward on a real non-beta release? What I have on my to-do list: 1) Finish up that external module that I've been working on 2) Work with a couple of folks to get a BWF external module created 3) Get the LV2 stuff to build on Windows None of those are for a release version, but I "promised" to do them, so I figure I'd better get 'em done. Leland |
From: James C. <cr...@in...> - 2008-09-16 12:33:33
|
Leland wrote: > I need to get back into Audacity mode as I'm starting to get the > shakes...I need my fix! :-) I won't be able to do a lot just yet (my > wife it trying to finish some songs for a Christmas CD and I make too > much noise), but I can certainly get some things done. > > So, where are we? What are we going to do about the GSoC code? Mark it > all experimental? Go ahead and leave it "mainstream"? What's the > current link to list of bugs? Are we at a point where we can say no > more new stuff and start working toward on a real non-beta release? > Thanks Leland! My take is that for the 1.3.7. beta we only consider enabling a GSoC feature if the student who wrote it is around to polish it and/or bypass aspects that don't yet work smoothly. We don't have the bandwidth to do that on our own. Our four show stoppers are here: http://www.audacityteam.org/wiki/index.php?title=Release_Checklist That page also has high profile (P2) bugs that need to be swatted or release noted. It seems like a lot, but it actually comes down to us being much more organised about collecting and prioritising bugs than we have been in the past (thanks Gale). There are also two big topics that need open discussion: * Updating the installer to cater for the modular build. * Packaging help with Audacity Are we feature freezed? I don't know. I'd like to get the preferences smart-help in, but seriously question whether I have time to do it. It will depend on what target date we set. Does anyone else want to list things, GSoC or otherwise, they'd aim to get into 1.3.7? Then we can make a decision. If Vaughan and Gale agree, and no one else objects, I'd like to elect Vaughan Gale and me to the 'bug rating council'. For a bug to change its rating or its description to expand in scope, or a new P2 or P1 arrive, two out of three of us have to vote in favour. This should very strongly discourage the moving goalpost problem we have had previously. The bugs we address for the release should therefore essentially be the ones we know about now. --James. |
From: Gale A. <ga...@au...> - 2008-09-16 19:33:11
|
| From James Crook <cr...@in...> | Tue, 16 Sep 2008 13:33:31 +0100 | Subject: [Audacity-devel] Getting back in to the swing > Leland wrote: > > I need to get back into Audacity mode as I'm starting to get the > > shakes...I need my fix! :-) ... > 1) Finish up that external module that I've been working on > 2) Work with a couple of folks to get a BWF external module created > 3) Get the LV2 stuff to build on Windows > None of those are for a release version, but I "promised" to do them, > so I figure I'd better get 'em done. You could probably add to that list building a FFmpeg binary for the Mac folks, analogous to LRN's that we have for Windows. It looks as if it may well need your wizardry to do it =:) > > So, where are we? What are we going to do about the GSoC code? Mark it > > all experimental? Go ahead and leave it "mainstream"? What's the > > current link to list of bugs? Are we at a point where we can say no > > more new stuff and start working toward on a real non-beta release? > > > Thanks Leland! > > My take is that for the 1.3.7. beta we only consider enabling a GSoC > feature if the student who wrote it is around to polish it and/or bypass > aspects that don't yet work smoothly. We don't have the bandwidth to do > that on our own. Probably so, though as I noted recently to the Team, the "consumers" feel they have waited a long time for a new stable release, GSoC has delayed that further, so they would like "something" from GSoC in the new stable (even, I'd suggest, if it adds a month and we have to do it ourselves). > Our four show stoppers are here: > > http://www.audacityteam.org/wiki/index.php?title=Release_Checklist There is one recently reported crashing bug I have not yet noted there which would probably be regarded as P2, given there may be a simple way to stop it happening. It occurs if you enter a negative three digit value in "Change Speed", then Preview. The OK" button is already greyed out in that case. Preview isn't, but probably should be. If you do Preview, an "Unhandled Exception" dialogue appears and any of the "Abort, Retry, Ignore" choices crash out Audacity. Sometimes "Change Tempo" and "Change Pitch" has a similar problem. There is no "Unhandled Exception" dialogue when you Preview, but for me Audacity tends to freeze after preview if the track is more than a few minutes long. With all three effects, once the OK button is greyed out, moving the slider back does not re-enable the button, which should probably also be fixed. > That page also has high profile (P2) bugs that need to be swatted or > release noted. It seems like a lot, but it actually comes down to us > being much more organised about collecting and prioritising bugs than we > have been in the past (thanks Gale). > > There are also two big topics that need open discussion: > > * Updating the installer to cater for the modular build. > * Packaging help with Audacity I guess we know this, but packaging help would be rated as important by the users. There are plenty that complain about this lack in the Beta, even though we say there is no included help. > ... If Vaughan and Gale agree, and no one else objects, I'd like to elect > Vaughan Gale and me to the 'bug rating council'. For a bug to change > its rating or its description to expand in scope, or a new P2 or P1 > arrive, two out of three of us have to vote in favour. This should very > strongly discourage the moving goalpost problem we have had previously. > The bugs we address for the release should therefore essentially be the > ones we know about now. I agree that realistically we probably shouldn't be aiming to fix bugs below P2, though I think P3 rated bugs should continue to be Release Noted, and added to the Known Issues Wiki page, especially given it would be quite a bit of work to undo that decision now. Relevant to that, James added as a P2 " Truncate Silence leaves tail of unmodified Audio" but neither James or I can now replicate that, so it was demoted to P5. But I do get issues on a few tracks with Truncate Silence deleting audio at the end of the track where it shouldn't (but can't figure the scenario that makes it happen). As this was Release Noted when a P2, I suggest re-promoting it to P3. If we think the "Council" is a good idea, I guess a new Wiki page is the best place to propose any new P2 and P1 bugs for addition to the Checklist, or to propose a ratings change for an existing bug. Vaughan and James could add a watch to that page. We still have to log new issues at P3 or below somewhere on the Wiki. I have a few of those to add as well. So we either add them as P3 to P5 on the Checklist, or to "Release Checklist Not Aiming". I suggest it's a better discipline to add these to the Checklist proper, so they get a rating and a decent wording. The "Not Aiming" Checklist tends to be used for developer-suggested "Feature Enhancements" as much as for bugs. Is that a good use of this page, or are these better managed in the Feature Requests page? . I suspect leave "as is" due to the work involved in moving them? Gale |
From: David R. S. <dav...@sh...> - 2008-09-17 02:49:55
|
Hi Leland, welcome back! Ummmm... I'm probably mixed up here. To me bwf means brainwave frequencies, I assume you're talking about something else. Cuz a year or more ago I wrote a Nyquist plug to manipulate bwf using so-called 'entrainment', the plug and help file are at http://www.shellworld.net/~davidsky/bitone2.zip How out-to-lunch am I? *grin* David -- David R. Sky http://www.shellworld.net/~davidsky/ >> Leland wrote: >>> I need to get back into Audacity mode as I'm starting to get the >>> shakes...I need my fix! :-) ... >> 2) Work with a couple of folks to get a BWF external module created |
From: Gale A. <ga...@au...> - 2008-09-17 17:23:34
|
| From "David R. Sky" <dav...@sh...> | Tue, 16 Sep 2008 19:49:55 -0700 (PDT) | Subject: [Audacity-devel] Getting back in to the swing >> Leland wrote: >> Work with a couple of folks to get a BWF external module created > > Ummmm... I'm probably mixed up here. To me bwf means brainwave > frequencies, I assume you're talking about something else... Hi David This is about supporting Broadcast Wave Format: http://en.wikipedia.org/wiki/Broadcast_Wave_Format This format supports timestamp metadata which is considered essential by many broadcasters and audio archivists. Audacity will currently import BWF, but it neither reads nor writes its specific metadata. Gale |
From: Leland <le...@au...> - 2008-09-17 06:32:49
|
Gale Andrews wrote: > | From James Crook <cr...@in...> > | Tue, 16 Sep 2008 13:33:31 +0100 > | Subject: [Audacity-devel] Getting back in to the swing >> Leland wrote: >>> I need to get back into Audacity mode as I'm starting to get the >>> shakes...I need my fix! :-) ... >> 1) Finish up that external module that I've been working on >> 2) Work with a couple of folks to get a BWF external module created >> 3) Get the LV2 stuff to build on Windows >> None of those are for a release version, but I "promised" to do them, >> so I figure I'd better get 'em done. > > You could probably add to that list building a FFmpeg binary for the Mac > folks, analogous to LRN's that we have for Windows. It looks as if it > may well need your wizardry to do it =:) > Will do. Leland |
From: Leland <le...@au...> - 2008-09-17 06:32:11
|
David R. Sky wrote: > Hi Leland, welcome back! > > Ummmm... I'm probably mixed up here. To me bwf means brainwave > frequencies, I assume you're talking about something else. Cuz a year or > more ago I wrote a Nyquist plug to manipulate bwf using so-called > 'entrainment', the plug and help file are at > Hey David, I saw a bit ago that you were back in the saddle. That's Great! In the case BWF stands for Broadcast Wave Format. It's sort of an extension to the "standard" WAV format, but with several extensions. There's a project in Africa that could really use this feature and I intend to code it up as an external module. And we will be able to use it to get ideas on how to really implement this new fangled external module thing. Leland |
From: David R. S. <dav...@sh...> - 2008-09-17 07:33:31
|
Thanks leland. Well, there's at least one thing in common between your bwf and my bwf - they both involve waves. *waving with a groan* Wikipedia has an explanation. David On Wed, 17 Sep 2008, Leland wrote: > Hey David, > > I saw a bit ago that you were back in the saddle. That's Great! > > In the case BWF stands for Broadcast Wave Format. It's sort of an > extension to the "standard" WAV format, but with several extensions. > There's a project in Africa that could really use this feature and I > intend to code it up as an external module. And we will be able to use > it to get ideas on how to really implement this new fangled external > module thing. > > > Leland > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > |
From: Dawson W. <wri...@gm...> - 2008-09-17 06:46:09
|
James Crook wrote: > > Our four show stoppers are here: > > http://www.audacityteam.org/wiki/index.php?title=Release_Checklist That first P1issue (Noise Removal) happens when the project rate is set to any value below 20480 Hz, which causes the int value, mMinSignalBlocks, to round down to 0 at the top of EffectNoiseRemoval::Initialize(). When EffectNoiseRemoval::GetProfile() runs, the value of start is set to the same value as mHistoryLen and since mSpectrums has mHistoryLen float-pointers allocated, it tries to set the float value of min to the float of the dereferenced pointer in the array entry (using the value of start as the index) one past the end causing the access violation. (Hope that made sense.) Setting the project sample rate to 20480 or above, will set mMinSignalBlocks to 1 or higher and will not result in the violation. Either a warning should come up saying a project must have a sample rate of at least 20480Hz before noise removal profile is performed or the math and code in effects/NoiseRemoval.cpp needs to be reviewed and changed. It may just be a typo somewhere. I don't know the algorithm for noise removal so I will just pass my observation to someone who does. :-) Disregard if this information is already known (and being worked on) and I apologize for the bother. Thanks, Dawson |
From: Gale A. <ga...@au...> - 2008-09-17 17:38:56
|
| From Dawson Written <wri...@gm...> | Wed, 17 Sep 2008 01:46:17 -0500 | Subject: [Audacity-devel] Getting back in to the swing (Observation of a P1 issue, Bug #286: Noise Removal) > James Crook wrote: > > > > Our four show stoppers are here: > > > > http://www.audacityteam.org/wiki/index.php?title=Release_Checklist > That first P1issue (Noise Removal) happens when the project rate is set > to any value below 20480 Hz, which causes the int value, > mMinSignalBlocks, to round down to 0 at the top of > EffectNoiseRemoval::Initialize(). When EffectNoiseRemoval::GetProfile() > runs, the value of start is set to the same value as mHistoryLen and > since mSpectrums has mHistoryLen float-pointers allocated, it tries to > set the float value of min to the float of the dereferenced pointer in > the array entry (using the value of start as the index) one past the end > causing the access violation. (Hope that made sense.) > > Setting the project sample rate to 20480 or above, will set > mMinSignalBlocks to 1 or higher and will not result in the violation. > > Either a warning should come up saying a project must have a sample rate > of at least 20480Hz before noise removal profile is performed or the > math and code in effects/NoiseRemoval.cpp needs to be reviewed and > changed... Thanks, Dawson. I'll link to your comments from the checklist. IMO the maths needs changing. When people import a file for the first time, the project rate should change to respect the rate of that file, if different, and it could be a low sample rate file. The project rate change happens on Windows, though I gather it may not work on Linux, and it's currently a P2 issue on the Checklist to get this working consistently on all platforms. Gale ' |
From: Martyn S. <mar...@go...> - 2008-09-22 22:47:16
|
Thanks for that Dawson, useful analysis! I had a look at the code and committed a fix - mMinSignalBlocks should clearly (to me at least) not be less than 1. That's the bug fixed (although noise removal parameters at lower sampling rates should perhaps be revisited by an interested party in the distant future). Unless anybody has any more useful information, I think that clears a P1 and Bugzilla Bug 286. I'm getting back into it myself, and find that I hadn't even updated to HEAD on my main (win) box for 3 weeks - shocking! Things are slowly setting at work now, so should have more time. TTFN Martyn Dawson Written wrote: > James Crook wrote: >> Our four show stoppers are here: >> >> http://www.audacityteam.org/wiki/index.php?title=Release_Checklist > That first P1issue (Noise Removal) happens when the project rate is set > to any value below 20480 Hz, which causes the int value, > mMinSignalBlocks, to round down to 0 at the top of > EffectNoiseRemoval::Initialize(). When EffectNoiseRemoval::GetProfile() > runs, the value of start is set to the same value as mHistoryLen and > since mSpectrums has mHistoryLen float-pointers allocated, it tries to > set the float value of min to the float of the dereferenced pointer in > the array entry (using the value of start as the index) one past the end > causing the access violation. (Hope that made sense.) > > Setting the project sample rate to 20480 or above, will set > mMinSignalBlocks to 1 or higher and will not result in the violation. > > Either a warning should come up saying a project must have a sample rate > of at least 20480Hz before noise removal profile is performed or the > math and code in effects/NoiseRemoval.cpp needs to be reviewed and > changed. It may just be a typo somewhere. I don't know the algorithm for > noise removal so I will just pass my observation to someone who does. :-) > > Disregard if this information is already known (and being worked on) and > I apologize for the bother. > > Thanks, > Dawson > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Gale A. <ga...@au...> - 2008-09-23 18:00:35
|
| From Martyn Shaw <mar...@go...> | Mon, 22 Sep 2008 23:48:47 +0100 | Subject: [Audacity-devel] Getting back in to the swing (Observation of a P1 issue, Bug #286: Noise Removal) > Thanks for that Dawson, useful analysis! > > I had a look at the code and committed a fix - mMinSignalBlocks should > clearly (to me at least) not be less than 1. That's the bug fixed > (although noise removal parameters at lower sampling rates should > perhaps be revisited by an interested party in the distant future). > > Unless anybody has any more useful information, I think that clears a > P1 and Bugzilla Bug 286. Thanks, Martyn, verfied here (also on Windows), so unless someone shouts in the next 12 hours or so that the fix does not work on Mac or Linux, I'll remove the P1 and Bugzilla items. Gale |
From: Vaughan J. <va...@au...> - 2008-09-23 17:34:54
|
Did anybody see this when I posted it previously? I just got a bounceback from audacity-devel, 4 days after I sent it! - Vaughan Vaughan Johnson wrote: > James, thanks for directing this toward a release. > > I think the next date we should target is October 23, 2 days before > GSoC Mentor Summit, a beta with GSoC code in it, as you suggested. As > it's a beta, I think we primarily need to make the GSoC code decisions > and complete those features. I think the "polish" issue can be decided > case-by-case. Even if the student doesn't do it, if we can do it > fairly readily, I think it's better to include the feature. > > If we can't handle all the Essentials and P1's, I think we should try > to fix the crash P1's and still target October 23. Then, I think we > should get on a much more frequent release schedule, at least once per > quarter (although I'd say the next one can come out sooner if we need > another month to polish). As I wrote, I find the beta/stable > distinction less compelling than it used to be, but I think the > discipline of more frequent releases will make them generally more > stable. > > Btw, isn't this going to be 1.3.6, not 1.3.7? We never posted the > 1.3.6 alphas as releases, nor a 1.3.6 beta, so unless we're sick of > that number... > > - Vaughan > |
From: Martyn S. <mar...@go...> - 2008-09-23 22:36:23
|
Hi Vaughan I didn't see this, probably 'cos it didn't arrive, possibly due to a full inbox. I agree that we should go for a release PDQ. I thought I'd look at the 'Repair' P1 next. Can you get the win installer issue with dlls? TTFN Martyn Vaughan Johnson wrote: > Did anybody see this when I posted it previously? I just got a > bounceback from audacity-devel, 4 days after I sent it! > > - Vaughan > > > Vaughan Johnson wrote: >> James, thanks for directing this toward a release. >> >> I think the next date we should target is October 23, 2 days before >> GSoC Mentor Summit, a beta with GSoC code in it, as you suggested. As >> it's a beta, I think we primarily need to make the GSoC code decisions >> and complete those features. I think the "polish" issue can be decided >> case-by-case. Even if the student doesn't do it, if we can do it >> fairly readily, I think it's better to include the feature. >> >> If we can't handle all the Essentials and P1's, I think we should try >> to fix the crash P1's and still target October 23. Then, I think we >> should get on a much more frequent release schedule, at least once per >> quarter (although I'd say the next one can come out sooner if we need >> another month to polish). As I wrote, I find the beta/stable >> distinction less compelling than it used to be, but I think the >> discipline of more frequent releases will make them generally more >> stable. >> >> Btw, isn't this going to be 1.3.6, not 1.3.7? We never posted the >> 1.3.6 alphas as releases, nor a 1.3.6 beta, so unless we're sick of >> that number... >> >> - Vaughan >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Vaughan J. <vau...@sb...> - 2008-09-24 18:45:52
|
Ahem, as I wrote, I think the Essentials and P1 issues should be *after* getting the agreed-on GSoC code up and running "polished", possibly even in the release after this one, which should focus on GSoC code. But yes, I'll look into the installer issues as I posted before, because we can't post installers without it. So, what GSoC code is in/out, and what are the issues with the "in" GSoC code, that we need to get polished? - V Martyn Shaw wrote: > Hi Vaughan > > I didn't see this, probably 'cos it didn't arrive, possibly due to a > full inbox. > > I agree that we should go for a release PDQ. I thought I'd look at > the 'Repair' P1 next. Can you get the win installer issue with dlls? > > TTFN > Martyn > > Vaughan Johnson wrote: > >> Did anybody see this when I posted it previously? I just got a >> bounceback from audacity-devel, 4 days after I sent it! >> >> - Vaughan >> >> >> Vaughan Johnson wrote: >> >>> James, thanks for directing this toward a release. >>> >>> I think the next date we should target is October 23, 2 days before >>> GSoC Mentor Summit, a beta with GSoC code in it, as you suggested. As >>> it's a beta, I think we primarily need to make the GSoC code decisions >>> and complete those features. I think the "polish" issue can be decided >>> case-by-case. Even if the student doesn't do it, if we can do it >>> fairly readily, I think it's better to include the feature. >>> >>> If we can't handle all the Essentials and P1's, I think we should try >>> to fix the crash P1's and still target October 23. Then, I think we >>> should get on a much more frequent release schedule, at least once per >>> quarter (although I'd say the next one can come out sooner if we need >>> another month to polish). As I wrote, I find the beta/stable >>> distinction less compelling than it used to be, but I think the >>> discipline of more frequent releases will make them generally more >>> stable. >>> >>> Btw, isn't this going to be 1.3.6, not 1.3.7? We never posted the >>> 1.3.6 alphas as releases, nor a 1.3.6 beta, so unless we're sick of >>> that number... >>> >>> - Vaughan >>> >>> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> audacity-devel mailing list >> aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > |
From: Martyn S. <mar...@go...> - 2008-09-24 22:43:54
|
Ah, I see what you mean now, sorry. No harm done. I'm proposing 'On-Demand Loading' should be in. Michael is still around, it all works (I think), there is documentation, and it was developed on a Mac and tested on Win so a low chance of platform-specific problems. I'm not aware of any polishing needed. My next choice would be 'Label Track Enhancements'. Again documented, and does what it says (as far as I know), but may be seen to 'not work' with the Time Shift Tool; probably just a documentation issue. This would possibly have more impact on more users? I'm thinking more people use labels than very long files? Again I don't know of any polishing required. HTH Martyn Vaughan Johnson wrote: > Ahem, as I wrote, I think the Essentials and P1 issues should be *after* > getting the agreed-on GSoC code up and running "polished", possibly even > in the release after this one, which should focus on GSoC code. But yes, > I'll look into the installer issues as I posted before, because we can't > post installers without it. > > So, what GSoC code is in/out, and what are the issues with the "in" GSoC > code, that we need to get polished? > > - V > > Martyn Shaw wrote: >> Hi Vaughan >> >> I didn't see this, probably 'cos it didn't arrive, possibly due to a >> full inbox. >> >> I agree that we should go for a release PDQ. I thought I'd look at >> the 'Repair' P1 next. Can you get the win installer issue with dlls? >> >> TTFN >> Martyn >> >> Vaughan Johnson wrote: >> >>> Did anybody see this when I posted it previously? I just got a >>> bounceback from audacity-devel, 4 days after I sent it! >>> >>> - Vaughan >>> >>> >>> Vaughan Johnson wrote: >>> >>>> James, thanks for directing this toward a release. >>>> >>>> I think the next date we should target is October 23, 2 days before >>>> GSoC Mentor Summit, a beta with GSoC code in it, as you suggested. >>>> As it's a beta, I think we primarily need to make the GSoC code >>>> decisions and complete those features. I think the "polish" issue >>>> can be decided case-by-case. Even if the student doesn't do it, if >>>> we can do it fairly readily, I think it's better to include the >>>> feature. >>>> >>>> If we can't handle all the Essentials and P1's, I think we should >>>> try to fix the crash P1's and still target October 23. Then, I think >>>> we should get on a much more frequent release schedule, at least >>>> once per quarter (although I'd say the next one can come out sooner >>>> if we need another month to polish). As I wrote, I find the >>>> beta/stable distinction less compelling than it used to be, but I >>>> think the discipline of more frequent releases will make them >>>> generally more stable. >>>> >>>> Btw, isn't this going to be 1.3.6, not 1.3.7? We never posted the >>>> 1.3.6 alphas as releases, nor a 1.3.6 beta, so unless we're sick of >>>> that number... >>>> >>>> - Vaughan >>>> >>>> >>> ------------------------------------------------------------------------- >>> >>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>> challenge >>> Build the coolest Linux based applications with Moblin SDK & win >>> great prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the >>> world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> audacity-devel mailing list >>> aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >>> >>> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> audacity-devel mailing list >> aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> >> > |
From: Martyn S. <mar...@go...> - 2008-09-24 22:57:10
|
Martyn Shaw wrote: > Ah, I see what you mean now, sorry. No harm done. > > I'm proposing 'On-Demand Loading' should be in. Michael is still > around, it all works (I think), there is documentation, and it was > developed on a Mac and tested on Win so a low chance of > platform-specific problems. I'm not aware of any polishing needed. > > My next choice would be 'Label Track Enhancements'. Again documented, > and does what it says (as far as I know), but may be seen to 'not work' > with the Time Shift Tool; probably just a documentation issue. This > would possibly have more impact on more users? I'm thinking more people > use labels than very long files? Again I don't know of any polishing > required. Except perhaps that 'link' icon? Didn't we have a graphic designer offering services a few days ago? Martyn > HTH > Martyn > > Vaughan Johnson wrote: >> Ahem, as I wrote, I think the Essentials and P1 issues should be >> *after* getting the agreed-on GSoC code up and running "polished", >> possibly even in the release after this one, which should focus on >> GSoC code. But yes, I'll look into the installer issues as I posted >> before, because we can't post installers without it. >> >> So, what GSoC code is in/out, and what are the issues with the "in" >> GSoC code, that we need to get polished? >> >> - V >> >> Martyn Shaw wrote: >>> Hi Vaughan >>> >>> I didn't see this, probably 'cos it didn't arrive, possibly due to a >>> full inbox. >>> >>> I agree that we should go for a release PDQ. I thought I'd look at >>> the 'Repair' P1 next. Can you get the win installer issue with dlls? >>> >>> TTFN >>> Martyn >>> >>> Vaughan Johnson wrote: >>> >>>> Did anybody see this when I posted it previously? I just got a >>>> bounceback from audacity-devel, 4 days after I sent it! >>>> >>>> - Vaughan >>>> >>>> >>>> Vaughan Johnson wrote: >>>> >>>>> James, thanks for directing this toward a release. >>>>> >>>>> I think the next date we should target is October 23, 2 days before >>>>> GSoC Mentor Summit, a beta with GSoC code in it, as you suggested. >>>>> As it's a beta, I think we primarily need to make the GSoC code >>>>> decisions and complete those features. I think the "polish" issue >>>>> can be decided case-by-case. Even if the student doesn't do it, if >>>>> we can do it fairly readily, I think it's better to include the >>>>> feature. >>>>> >>>>> If we can't handle all the Essentials and P1's, I think we should >>>>> try to fix the crash P1's and still target October 23. Then, I >>>>> think we should get on a much more frequent release schedule, at >>>>> least once per quarter (although I'd say the next one can come out >>>>> sooner if we need another month to polish). As I wrote, I find the >>>>> beta/stable distinction less compelling than it used to be, but I >>>>> think the discipline of more frequent releases will make them >>>>> generally more stable. >>>>> >>>>> Btw, isn't this going to be 1.3.6, not 1.3.7? We never posted the >>>>> 1.3.6 alphas as releases, nor a 1.3.6 beta, so unless we're sick of >>>>> that number... >>>>> >>>>> - Vaughan >>>>> >>>>> >>>> ------------------------------------------------------------------------- >>>> >>>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>>> challenge >>>> Build the coolest Linux based applications with Moblin SDK & win >>>> great prizes >>>> Grand prize is a trip for two to an Open Source event anywhere in >>>> the world >>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>> _______________________________________________ >>>> audacity-devel mailing list >>>> aud...@li... >>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >>>> >>>> >>> >>> ------------------------------------------------------------------------- >>> >>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>> challenge >>> Build the coolest Linux based applications with Moblin SDK & win >>> great prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the >>> world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> audacity-devel mailing list >>> aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >>> >>> >> > |
From: Gale A. <ga...@au...> - 2008-09-25 07:32:20
|
Hi Martyn Thanks for fixing the P1 crash when repairing a newly created section of short audio - we now disallow selecting the entire length of it. Does this leave a residual lower priority bug to fix, i.e. the cause of the former crash, or is the some reason we can never repair the whole of a new length of audio? In your error message: "The Repair effect needs some data to go on. Please select an area to repair with some audio on at least one side (the more the better)" I'm guessing most people will in fact already have the entire length selected, and if what they did wasn't a mistake, may actually want to repair the entire length. Is "Please select a region to repair inside the track, or repair the original region" clearer (as well as shorter)? Gale |
From: Gale A. <ga...@au...> - 2008-09-25 09:05:39
|
| From Martyn Shaw <mar...@go...> | Wed, 24 Sep 2008 23:45:16 +0100 | Subject: [Audacity-devel] Getting back in to the swing > I'm proposing 'On-Demand Loading' should be in. Michael is still > around, it all works (I think), there is documentation, and it was > developed on a Mac and tested on Win so a low chance of > platform-specific problems. I'm not aware of any polishing needed. > > My next choice would be 'Label Track Enhancements'. Again documented, > and does what it says (as far as I know), but may be seen to 'not > work' with the Time Shift Tool; probably just a documentation issue. > This would possibly have more impact on more users? I'm thinking more > people use labels than very long files? Again I don't know of any > polishing required.... Except perhaps that 'link' icon? Didn't we have a graphic > designer offering services a few days ago? Below are what I have down as "bugs" with the GSoC projects. With regard to labels, I think I'd regard having to select the label track to move the labels with the audio as a bug, given you can do that anyway with linking off. It possibly needs multiple selecting of labels too, which may seem a gap to the user as the feature is otherwise quite complete. I think there are apparent (inevitable?) inconsistencies not yet documented (e.g. cutting only the audio cuts the label, but pasting into audio and label does not paste the label, plus the cross-pasting issues). Good idea about the link icon. Shall I mention that to him? I think you're right more users would benefit from label tracks than OD, even though OD is more finished within its current limits. For the same reason, I'd like to see FFmpeg in (probably excluding the custom exporter). The obvious rationale is the large number of users who want to import WMA and M4A (iTunes/iPod/iPhone) directly into Audacity. I'm sure these are a much larger group than the people wanting to work with long PCM files. What do we think about categorising just the built-in menus (the minimal functionality we have now on Windows)? I think this would be quite popular, though needs more sensible grouping than we have now. I think though it might need a Preference (personally I find the extra navigation outweighs the benefits). And longer term, I think being able to allocate shortcuts to "your favourite plug-ins" would actually be much more popular still. Gale P3 (GSoC) Sticky labels: * When a Time Track is present, audio is not pasted into all tracks, leading to desynchronisation. * Labels do not move when time-shifting clips. P3 (GSoC) Residual FFmpeg issues: * MP4 files renamed to MOV will not play in Windows iTunes or QuickTime - so remove MOV extension from M4A filter * "Select file(s) for batch processing..." dialogue lacks "All Supported files" and "FFmpeg-compatible files" filters * Importing FFmpeg formats when FFmpeg library missing should raise the "FFmpeg not found" error, not the generic "not supported" error * In non-FFmpeg builds, attempting to import FFmpeg-supported formats should give an error that suggests downloading FFmpeg P3 (GSoC) On-Demand: if FFmpeg library installed, on-demand loading of audio files does not start until normal load of video files completes, if the video file names precede those of the audio files. P3 (Windows only) (GSoC) LV2: * LADSPA plug-ins not categorisable despite compiling with USE_LIBLRDF defined and installing RDF data files in Audacity data directory. * The slv2 library needed for LV2 support does not build. > > Vaughan Johnson wrote: > > Ahem, as I wrote, I think the Essentials and P1 issues should be *after* > > getting the agreed-on GSoC code up and running "polished", possibly even > > in the release after this one, which should focus on GSoC code. But yes, > > I'll look into the installer issues as I posted before, because we can't > > post installers without it. > > > > So, what GSoC code is in/out, and what are the issues with the "in" GSoC > > code, that we need to get polished? |
From: Gale A. <ga...@au...> - 2008-09-24 00:34:41
|
| From Vaughan Johnson <va...@au...> | Tue, 23 Sep 2008 10:05:05 -0700 | Subject: [Audacity-devel] Getting back in to the swing > Did anybody see this when I posted it previously? I just got a > bounceback from audacity-devel, 4 days after I sent it! Did not see it locally or in Nabble archive either. > James: My take is that for the 1.3.7. beta we only consider enabling a GSoC > feature if the student who wrote it is around to polish it and/or > bypass aspects that don't yet work smoothly. We don't have the bandwidth to do > that on our own. > > Btw, isn't this going to be 1.3.6, not 1.3.7? We never posted the > > 1.3.6 alphas as releases, nor a 1.3.6 beta, so unless we're sick of > > that number... I got the impression James meant 1.3.7 there, (i.e. after 1.3.6 Beta), with 1.3.7 as release candidate being the point we decide what if anything of GSoC goes in. I think the Beta being considered for Oct.23rd should be 1.3.6, to avoid confusion of those who actually don't know anything about our alphas. Gale |
From: Martyn S. <mar...@go...> - 2008-09-25 23:56:48
|
I'm really struggling here using web gmail and off-thread posts and questios not near the source on this Eee (it's bad enough on a proper machine) but... >> polishing required.... Except perhaps that 'link' icon? Didn't we have a graphic >> designer offering services a few days ago? ................... > > Good idea about the link icon. Shall I mention that to him? Yes, I think that's what I meant. > I think you're right more users would benefit from label tracks than > OD, even though OD is more finished within its current limits. > I don't see it as either/or choice. > For the same reason, I'd like to see FFmpeg in (probably excluding the > custom exporter). The obvious rationale is the large number of users > who want to import WMA and M4A (iTunes/iPod/iPhone) directly into > Audacity. I'm sure these are a much larger group than the people > wanting to work with long PCM files. True enough. I haven;t really followed the lenghy discussions about all the details. 'Polishing; definietly required here. > What do we think about categorising just the built-in menus (the > minimal functionality we have now on Windows)? I think this would be > quite popular, though needs more sensible grouping than we have now. > I think though it might need a Preference (personally I find the extra > navigation outweighs the benefits). So you want it in for others but you want to turn it off for yourself? OK, it's a personal thing (and yet more prefs). I find the current (debug build) arrangement of built-in effects hard to navigate. And longer term, I think being able > to allocate shortcuts to "your favourite plug-ins" would actually be > much more popular still. But that would be off-topic on this thread. TTFN Martyn > > > Gale > > > P3 (GSoC) Sticky labels: > > * When a Time Track is present, audio is not pasted into all tracks, leading > to desynchronisation. > * Labels do not move when time-shifting clips. > > P3 (GSoC) Residual FFmpeg issues: > > * MP4 files renamed to MOV will not play in Windows iTunes or QuickTime - > so remove MOV extension from M4A filter > * "Select file(s) for batch processing..." dialogue lacks "All Supported files" > and "FFmpeg-compatible files" filters > * Importing FFmpeg formats when FFmpeg library missing should raise the > "FFmpeg not found" error, not the generic "not supported" error > * In non-FFmpeg builds, attempting to import FFmpeg-supported formats > should give an error that suggests downloading FFmpeg > > > P3 (GSoC) On-Demand: if FFmpeg library installed, on-demand loading of > audio files does not start until normal load of video files > completes, if the video file names precede those of the audio files. > > > P3 (Windows only) (GSoC) LV2: > > * LADSPA plug-ins not categorisable despite compiling with USE_LIBLRDF > defined and installing RDF data files in Audacity data directory. > * The slv2 library needed for LV2 support does not build. > > > >> >> Vaughan Johnson wrote: >> > Ahem, as I wrote, I think the Essentials and P1 issues should be *after* >> > getting the agreed-on GSoC code up and running "polished", possibly even >> > in the release after this one, which should focus on GSoC code. But yes, >> > I'll look into the installer issues as I posted before, because we can't >> > post installers without it. >> > >> > So, what GSoC code is in/out, and what are the issues with the "in" GSoC >> > code, that we need to get polished? > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Gale (A. Team) <ga...@au...> - 2008-09-26 06:10:52
|
>From Martyn in reply to Gale > I'm really struggling here using web gmail and off-thread posts and > questios not near the source on this Eee (it's bad enough on a proper > machine) but... Yes only a few of my several posts today made it to the list, and some are in Nabble but not in my inbox.... So am sending this to you privately as well. >> I think you're right more users would benefit from label tracks than >> OD, even though OD is more finished within its current limits. > I don't see it as either/or choice. Neither do I, except insofar we only have finite time, and how much we can do to polish each project may depend on whether that particular student is around. >> What do we think about categorising just the built-in menus (the >> minimal functionality we have now on Windows)? I think this would be >> quite popular, though needs more sensible grouping than we have now. >> I think though it might need a Preference (personally I find the extra >> navigation outweighs the benefits). >So you want it in for others but you want to turn it off for yourself...? That's it, but I think it may be one of these things that you quite strongly like, or don't. And some feedback on that would be good. >> And longer term, I think being able to allocate shortcuts to "your >> favourite >> plug-ins" would actually be much more popular still. > But that would be off-topic on this thread. Sure, if we went into that in detail. But I thought it worth pointing out once (here) that there seems more user interest in the shortcuts idea as a way of managing plug-ins, than in categorising them. Gale -- View this message in context: http://n2.nabble.com/Getting-back-in-to-the-swing-tp1091787p1120139.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Martyn S. <mar...@go...> - 2008-09-22 23:09:03
|
Hiya Leland! I've been a bit off-topic recently also, and looking forward to some more bug-fixing and stuff over the next few months (just fixed one tonight). I'd like to get rid of #define EXPERIMENTAL_RULER_AUTOSIZE and make it main-stream, any problems with that anybody? It's been enabled since late June / early July so had GSoC eyes over it without complaint. I'm going to prioritise the checklist, I guess, although the external modules thing is interesting as I'd like to get my convolution effect in there somehow. TTFN Martyn Leland wrote: > I need to get back into Audacity mode as I'm starting to get the > shakes...I need my fix! :-) I won't be able to do a lot just yet (my > wife it trying to finish some songs for a Christmas CD and I make too > much noise), but I can certainly get some things done. > > So, where are we? What are we going to do about the GSoC code? Mark it > all experimental? Go ahead and leave it "mainstream"? What's the > current link to list of bugs? Are we at a point where we can say no > more new stuff and start working toward on a real non-beta release? > > What I have on my to-do list: > > 1) Finish up that external module that I've been working on > 2) Work with a couple of folks to get a BWF external module created > 3) Get the LV2 stuff to build on Windows > > None of those are for a release version, but I "promised" to do them, so > I figure I'd better get 'em done. > > Leland > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Michael C. <mc...@gm...> - 2008-09-23 01:03:26
|
FYI, I'm still around and will be able to handle any on-demand bugs that pop up. There are currently none that I know of, but correct me if I'm wrong. Given the current discussion would it be better to wait to checkin FLAC changes? The worry is that they may bring about new bugs, even if the flac part is not built for release, because the addition of FLAC may cause some slight On-Demand structural changes that introduce bugs. I have been working on my experimental synth sourceforge project, but I think I'll be able to get some work done on Audacity again in a few weeks. Michael |
From: Gale A. <ga...@au...> - 2008-09-23 17:53:18
|
| From "Michael Chinen" <mc...@gm...> | Mon, 22 Sep 2008 21:03:12 -0400 | Subject: [Audacity-devel] Getting back in to the swing > FYI, I'm still around and will be able to handle any on-demand bugs that pop > up. There are currently none that I know of, but correct me if I'm wrong. Hi Michael For want of any better system, I have the GSoC bugs in the Checklist as "P3". For OD we have: * if FFmpeg library installed, on-demand loading of audio files does not start until normal load of video files completes, if the video file names precede those of the audio files However I understand you can't replicate this because of the difficulty finding/building a FFmpeg binary for Mac. We still have the issue that OD does not work if using the optional FFmpeg importer (that is, if "FFmpeg-compatible files" is set in the import window). I currently have that marked as a "known issue" in the README on the basis people may wonder why it does not work, but not as a bug for the Checklist (more a "missing feature")? > Given the current discussion would it be better to wait to checkin FLAC > changes? The worry is that they may bring about new bugs, even if the flac > part is not built for release, because the addition of FLAC may cause some > slight On-Demand structural changes that introduce bugs. I think my 2p is that FLAC is still a relatively fringe format - if the decision was taken to try and include OD in 1.4, WAV/AIFF are more important, and work now. Gale |