ODDecodeFlacTask.h and USE_LIBFLAC
|
|
Al Dimond
|
In one of my source trees I have configured --without-libflac, and when I try to
build I get an error that essentially boils down to: ondemand/ODDecodeFlacTask.h:35:28: error: FLAC++/decoder.h: No such file or directory ODDecodeFlacTask.h is included from Project.cpp, and is referenced in AudacityProject::OpenFile(). I can build in this tree by throwing "#ifdef USE_LIBFLAC" around those parts, but it's not really a great solution to have that sort of #ifdef in OpenFile(). Maybe OD can do something like what file importers do when some formats are available and others aren't. It's not exactly an urgent thing... I might be the only person in the world with an Audacity tree configured --without-libflac... - Al ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
Richard Ash (audacity-help)
|
On Fri, 2009-10-16 at 13:30 -0600, Al Dimond wrote:
> In one of my source trees I have configured --without-libflac, and when I try to > build I get an error that essentially boils down to: > > ondemand/ODDecodeFlacTask.h:35:28: error: FLAC++/decoder.h: No such file or > directory > > ODDecodeFlacTask.h is included from Project.cpp, and is referenced in > AudacityProject::OpenFile(). I can build in this tree by throwing "#ifdef > USE_LIBFLAC" around those parts, but it's not really a great solution to have > that sort of #ifdef in OpenFile(). Maybe OD can do something like what file > importers do when some formats are available and others aren't. It's not > exactly an urgent thing... I might be the only person in the world with an > Audacity tree configured --without-libflac... You might be the only developer regularly building like that (I'm not), but certainly not the only user, because every time Audacity releases a beta which doesn't build without optional libraries distro patches to fix that start coming in (I fixed the bug in 1.3.9 not long ago), so the reports are good. The gotya here is that if you have libflac on the system (I do) then it can be included even when disabled, and no compile error occurs - you have to build with libflac uninstalled to test this, which means build chroots and so on. I'll try and reproduce / fix this once my new machine (lots more disk space, four times as much CPU and RAM) is up and running and I can build audacity in less than an hour. In principal I think my approach would be to put the #ifdef USE_LIBFLAC magic in ondemand/ODDecodeFlacTask.h (i.e. make that header always includable - if no library headers then it's a very short header with only stubs in it) and keep project.cpp clean - we have to do something about the on-demand flac interface if it's disabled, but that should mimic what we do with the rest of the flac support when it's disabled (bearing in mind that we don't compile ondemand/ODDecodeFlacTask.cpp when flac is disabled). Richard ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
Michael Chinen
|
On Fri, Oct 16, 2009 at 11:20 PM, Richard Ash <[hidden email]> wrote:
> On Fri, 2009-10-16 at 13:30 -0600, Al Dimond wrote: >> In one of my source trees I have configured --without-libflac, and when I try to >> build I get an error that essentially boils down to: >> >> ondemand/ODDecodeFlacTask.h:35:28: error: FLAC++/decoder.h: No such file or >> directory >> >> ODDecodeFlacTask.h is included from Project.cpp, and is referenced in >> AudacityProject::OpenFile(). I can build in this tree by throwing "#ifdef >> USE_LIBFLAC" around those parts, but it's not really a great solution to have >> that sort of #ifdef in OpenFile(). Maybe OD can do something like what file >> importers do when some formats are available and others aren't. It's not >> exactly an urgent thing... I might be the only person in the world with an >> Audacity tree configured --without-libflac... from ImportFlac.cpp/h if this will help anyone. > > You might be the only developer regularly building like that (I'm not), > but certainly not the only user, because every time Audacity releases a > beta which doesn't build without optional libraries distro patches to > fix that start coming in (I fixed the bug in 1.3.9 not long ago), so the > reports are good. The gotya here is that if you have libflac on the > system (I do) then it can be included even when disabled, and no compile > error occurs - you have to build with libflac uninstalled to test this, > which means build chroots and so on. > > I'll try and reproduce / fix this once my new machine (lots more disk > space, four times as much CPU and RAM) is up and running and I can build > audacity in less than an hour. able to patch it up for a little while, and then I would need to bug one of you linux folk to verify anyway. > > In principal I think my approach would be to put the #ifdef USE_LIBFLAC > magic in ondemand/ODDecodeFlacTask.h (i.e. make that header always > includable - if no library headers then it's a very short header with > only stubs in it) and keep project.cpp clean - we have to do something > about the on-demand flac interface if it's disabled, but that should > mimic what we do with the rest of the flac support when it's disabled > (bearing in mind that we don't compile ondemand/ODDecodeFlacTask.cpp > when flac is disabled). Sounds good to me as long as mac xcode (and possibly PC) doesn't have to option to use these configure flags, since (I'm not positive, but) the project structure makes all the cpp files associated with the project compiile. I know the configure file runs at the head of the build, but I've never tried to mess with it. Michael > > Richard > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Richard Ash (audacity-help)
|
On Fri, 2009-10-16 at 23:49 +0200, Michael Chinen wrote:
> > (bearing in mind that we don't compile ondemand/ODDecodeFlacTask.cpp > > when flac is disabled). > Sounds good to me as long as mac xcode (and possibly PC) doesn't have > to option to use these configure flags, since (I'm not positive, but) > the project structure makes all the cpp files associated with the > project compiile. I know the configure file runs at the head of the > build, but I've never tried to mess with it. Windows builds all the files all the time, but in practise everyone seems to build from CVS and have all the libraries available, so I've stopped worrying. AFAIK Xcode runs configure and then uses the resulting Makefile to do compilation (I can't see any other good reasons to run configure), so should cope with conditional compilation of whole files fine. Richard ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Al Dimond
|
In reply to this post
by Richard Ash (audacity-help)
On Friday 16 October 2009 15:20:49 Richard Ash wrote:
> On Fri, 2009-10-16 at 13:30 -0600, Al Dimond wrote: > > In one of my source trees I have configured --without-libflac, and when I > > try to build I get an error that essentially boils down to: > > > > ondemand/ODDecodeFlacTask.h:35:28: error: FLAC++/decoder.h: No such file > > or directory > > > > ODDecodeFlacTask.h is included from Project.cpp, and is referenced in > > AudacityProject::OpenFile(). I can build in this tree by throwing > > "#ifdef USE_LIBFLAC" around those parts, but it's not really a great > > solution to have that sort of #ifdef in OpenFile(). Maybe OD can do > > something like what file importers do when some formats are available and > > others aren't. It's not exactly an urgent thing... I might be the only > > person in the world with an Audacity tree configured --without-libflac... > > You might be the only developer regularly building like that (I'm not), > but certainly not the only user, because every time Audacity releases a > beta which doesn't build without optional libraries distro patches to > fix that start coming in (I fixed the bug in 1.3.9 not long ago), so the > reports are good. The gotya here is that if you have libflac on the > system (I do) then it can be included even when disabled, and no compile > error occurs - you have to build with libflac uninstalled to test this, > which means build chroots and so on. > Ah, that makes sense. The "system" in question is a cross-compiling target, so the include path doesn't include /usr/include. If I wasn't cross-compiling and did a ./configure --without-libflac, would there be linking problems? It would find /usr/include/FLAC++/decoder.h, but I don't think it would link against the actual library, right? > I'll try and reproduce / fix this once my new machine (lots more disk > space, four times as much CPU and RAM) is up and running and I can build > audacity in less than an hour. > > In principal I think my approach would be to put the #ifdef USE_LIBFLAC > magic in ondemand/ODDecodeFlacTask.h (i.e. make that header always > includable - if no library headers then it's a very short header with > only stubs in it) and keep project.cpp clean - we have to do something > about the on-demand flac interface if it's disabled, but that should > mimic what we do with the rest of the flac support when it's disabled > (bearing in mind that we don't compile ondemand/ODDecodeFlacTask.cpp > when flac is disabled). > > Richard > > > --------------------------------------------------------------------------- > --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is > the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Richard Ash (audacity-help)
|
On Fri, 2009-10-16 at 17:38 -0600, Al Dimond wrote:
> Ah, that makes sense. The "system" in question is a cross-compiling target, > so the include path doesn't include /usr/include. > > If I wasn't cross-compiling and did a ./configure --without-libflac, would there > be linking problems? It would find /usr/include/FLAC++/decoder.h, but I don't > think it would link against the actual library, right? Correct - configure would take the library out of the linker flags, so it wouldn't be linked, but you would still be processing the header file during compilation, so if it's missing the compiler has problems. Richard ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Richard Ash (audacity-help)
|
In reply to this post
by Michael Chinen
On Sat, 2009-10-31 at 23:23 +0100, Michael Chinen wrote:
> On Fri, Oct 16, 2009 at 10:49 PM, Michael Chinen <[hidden email]> wrote: > > On Fri, Oct 16, 2009 at 11:20 PM, Richard Ash <[hidden email]> wrote: > >> On Fri, 2009-10-16 at 13:30 -0600, Al Dimond wrote: > >>> In one of my source trees I have configured --without-libflac, and when I try to > >>> build I get an error that essentially boils down to: > >>> > >>> ondemand/ODDecodeFlacTask.h:35:28: error: FLAC++/decoder.h: No such file or > >>> directory > >>> > >>> ODDecodeFlacTask.h is included from Project.cpp, and is referenced in > >>> AudacityProject::OpenFile(). I can build in this tree by throwing "#ifdef > >>> USE_LIBFLAC" around those parts, but it's not really a great solution to have > >>> that sort of #ifdef in OpenFile(). Maybe OD can do something like what file > >>> importers do when some formats are available and others aren't. It's not > >>> exactly an urgent thing... I might be the only person in the world with an > >>> Audacity tree configured --without-libflac... > > My bad. I believe much of that OD code was modeled on/copy-pasted > > from ImportFlac.cpp/h if this will help anyone. The real problem is these messages Project.cpp: In member function ‘void AudacityProject::OpenFile(wxString, bool)’: Project.cpp:2510: error: expected type-specifier before ‘ODDecodeFlacTask’ Project.cpp:2510: error: cannot convert ‘int*’ to ‘ODTask*’ in assignment Project.cpp:2510: error: expected `;' before ‘ODDecodeFlacTask’ and the code they come from. What the code is doing is coping with OD Flac blockfiles in the newly opened project. The question is, what do we do if the opening copy of Audacity doesn't have FLAC support? It's easy enough to say "don't instantiate the class then" in the code, but we need some sort of error handler that goes back up to the user and says "whoever saved this project had imported FLAC files but not copied dependecies when they saved, and you don't have FLAC support enabled, so I can't read this project properly" and then does something safe like close the project back down again so they can't break it. So this needs more than a bit of conditional compilation, it shows up a design issue - what do we do about tracks read from original files if the support library for original files is not available when the project is reloaded? This didn't use to matter at all because we only had read-from-original-file for libsndfile, and that's mandatory (although there are some build options to that for what formats work). So we haven't ever worried about this problem before. Richard ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Michael Chinen
|
On Mon, Nov 9, 2009 at 10:56 PM, Richard Ash <[hidden email]> wrote:
> On Sat, 2009-10-31 at 23:23 +0100, Michael Chinen wrote: >> On Fri, Oct 16, 2009 at 10:49 PM, Michael Chinen <[hidden email]> wrote: >> > On Fri, Oct 16, 2009 at 11:20 PM, Richard Ash <[hidden email]> wrote: >> >> On Fri, 2009-10-16 at 13:30 -0600, Al Dimond wrote: >> >>> In one of my source trees I have configured --without-libflac, and when I try to >> >>> build I get an error that essentially boils down to: >> >>> >> >>> ondemand/ODDecodeFlacTask.h:35:28: error: FLAC++/decoder.h: No such file or >> >>> directory >> >>> >> >>> ODDecodeFlacTask.h is included from Project.cpp, and is referenced in >> >>> AudacityProject::OpenFile(). I can build in this tree by throwing "#ifdef >> >>> USE_LIBFLAC" around those parts, but it's not really a great solution to have >> >>> that sort of #ifdef in OpenFile(). Maybe OD can do something like what file >> >>> importers do when some formats are available and others aren't. It's not >> >>> exactly an urgent thing... I might be the only person in the world with an >> >>> Audacity tree configured --without-libflac... >> > My bad. I believe much of that OD code was modeled on/copy-pasted >> > from ImportFlac.cpp/h if this will help anyone. > > The real problem is these messages > > Project.cpp: In member function ‘void AudacityProject::OpenFile(wxString, bool)’: > Project.cpp:2510: error: expected type-specifier before ‘ODDecodeFlacTask’ > Project.cpp:2510: error: cannot convert ‘int*’ to ‘ODTask*’ in assignment > Project.cpp:2510: error: expected `;' before ‘ODDecodeFlacTask’ > > and the code they come from. What the code is doing is coping with OD > Flac blockfiles in the newly opened project. The question is, what do we > do if the opening copy of Audacity doesn't have FLAC support? > > It's easy enough to say "don't instantiate the class then" in the code, > but we need some sort of error handler that goes back up to the user and > says "whoever saved this project had imported FLAC files but not copied > dependecies when they saved, and you don't have FLAC support enabled, so > I can't read this project properly" and then does something safe like > close the project back down again so they can't break it. > > So this needs more than a bit of conditional compilation, it shows up a > design issue - what do we do about tracks read from original files if > the support library for original files is not available when the project > is reloaded? This didn't use to matter at all because we only had > read-from-original-file for libsndfile, and that's mandatory (although > there are some build options to that for what formats work). So we > haven't ever worried about this problem before. Hi Richard, Thanks for looking into this, and sorry that it wasn't as simple as I hoped. You bring up a good point that I hadn't thought about. The case will occur less often than the case you describe - the FLAC dependency issue will only happen if the project is saved before the decoding completes. Once it completes the decode via the on-demand task mechanism, the project saved after that point will be opened using SimpleBlockFiles instead of ODDecodeBlockFiles, so it won't matter if the opening copy of Audacity has the FLAC libs. I agree that the issue handling on opening the project will be a trickier issue and a require a bit more design thinking. This is specially true since in this case the audio from FLAC that has been decoded prior to saving will be available - this leaves us (or the user) with several choices about what to do. Since this feature will be off for 2.0 should we just #ifdef it out with the _EXPERIMENTAL_OD_FLAC_ def? Michael > > Richard > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Richard Ash (audacity-help)
|
On Tue, 2009-11-10 at 02:07 +0100, Michael Chinen wrote:
> On Mon, Nov 9, 2009 at 10:56 PM, Richard Ash <[hidden email]> wrote: > > What the code is doing is coping with OD > > Flac blockfiles in the newly opened project. The question is, what do we > > do if the opening copy of Audacity doesn't have FLAC support? > > > > It's easy enough to say "don't instantiate the class then" in the code, > > but we need some sort of error handler that goes back up to the user and > > says "whoever saved this project had imported FLAC files but not copied > > dependecies when they saved, and you don't have FLAC support enabled, so > > I can't read this project properly" and then does something safe like > > close the project back down again so they can't break it. > > > > So this needs more than a bit of conditional compilation, it shows up a > > design issue - what do we do about tracks read from original files if > > the support library for original files is not available when the project > > is reloaded? This didn't use to matter at all because we only had > > read-from-original-file for libsndfile, and that's mandatory (although > > there are some build options to that for what formats work). So we > > haven't ever worried about this problem before. > > Hi Richard, > > Thanks for looking into this, and sorry that it wasn't as simple as I > hoped. You bring up a good point that I hadn't thought about. The > case will occur less often than the case you describe - the FLAC > dependency issue will only happen if the project is saved before the > decoding completes. Once it completes the decode via the on-demand > task mechanism, the project saved after that point will be opened > using SimpleBlockFiles instead of ODDecodeBlockFiles, so it won't > matter if the opening copy of Audacity has the FLAC libs. slightly confused with the read-from-original file feature for libsndfile, where the end result is aliasblockfiles). > I agree that the issue handling on opening the project will be a > trickier issue and a require a bit more design thinking. This is > specially true since in this case the audio from FLAC that has been > decoded prior to saving will be available - this leaves us (or the > user) with several choices about what to do. Since this feature will > be off for 2.0 should we just #ifdef it out with the > _EXPERIMENTAL_OD_FLAC_ def? I hadn't registered you intended this to be turned off for 2.0 (I don't have views either way, because my system libsndfile has FLAC support, and so my builds of Audacity use that for FLAC import and I never actually hit this code), but if so then I would definitely wrap it in that #ifdef - at least that way any project from the stable build will open in any copy of the stable build, even if it is theoretically possible to have a beta project that won't open with the stable release. If we are going to do this, can we change Experimental.h to turn this off soon, so we get to find any other problems this causes? Richard ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
Martyn Shaw-2
|
This sounds like it needs more thought than the time available.
Please #ifdef out for 2.0. Thanks Martyn Richard Ash wrote: > On Tue, 2009-11-10 at 02:07 +0100, Michael Chinen wrote: >> On Mon, Nov 9, 2009 at 10:56 PM, Richard Ash <[hidden email]> wrote: >>> What the code is doing is coping with OD >>> Flac blockfiles in the newly opened project. The question is, what do we >>> do if the opening copy of Audacity doesn't have FLAC support? >>> >>> It's easy enough to say "don't instantiate the class then" in the code, >>> but we need some sort of error handler that goes back up to the user and >>> says "whoever saved this project had imported FLAC files but not copied >>> dependecies when they saved, and you don't have FLAC support enabled, so >>> I can't read this project properly" and then does something safe like >>> close the project back down again so they can't break it. >>> >>> So this needs more than a bit of conditional compilation, it shows up a >>> design issue - what do we do about tracks read from original files if >>> the support library for original files is not available when the project >>> is reloaded? This didn't use to matter at all because we only had >>> read-from-original-file for libsndfile, and that's mandatory (although >>> there are some build options to that for what formats work). So we >>> haven't ever worried about this problem before. >> Hi Richard, >> >> Thanks for looking into this, and sorry that it wasn't as simple as I >> hoped. You bring up a good point that I hadn't thought about. The >> case will occur less often than the case you describe - the FLAC >> dependency issue will only happen if the project is saved before the >> decoding completes. Once it completes the decode via the on-demand >> task mechanism, the project saved after that point will be opened >> using SimpleBlockFiles instead of ODDecodeBlockFiles, so it won't >> matter if the opening copy of Audacity has the FLAC libs. > OK, I wasn't sure what happened to decoded files (and was getting > slightly confused with the read-from-original file feature for > libsndfile, where the end result is aliasblockfiles). > >> I agree that the issue handling on opening the project will be a >> trickier issue and a require a bit more design thinking. This is >> specially true since in this case the audio from FLAC that has been >> decoded prior to saving will be available - this leaves us (or the >> user) with several choices about what to do. Since this feature will >> be off for 2.0 should we just #ifdef it out with the >> _EXPERIMENTAL_OD_FLAC_ def? > > I hadn't registered you intended this to be turned off for 2.0 (I don't > have views either way, because my system libsndfile has FLAC support, > and so my builds of Audacity use that for FLAC import and I never > actually hit this code), but if so then I would definitely wrap it in > that #ifdef - at least that way any project from the stable build will > open in any copy of the stable build, even if it is theoretically > possible to have a beta project that won't open with the stable release. > > If we are going to do this, can we change Experimental.h to turn this > off soon, so we get to find any other problems this causes? > > Richard > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > audacity-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/audacity-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Michael Chinen
|
In reply to this post
by Richard Ash (audacity-help)
On Tue, Nov 10, 2009 at 9:58 PM, Richard Ash <[hidden email]> wrote:
> On Tue, 2009-11-10 at 02:07 +0100, Michael Chinen wrote: >> On Mon, Nov 9, 2009 at 10:56 PM, Richard Ash <[hidden email]> wrote: >> > What the code is doing is coping with OD >> > Flac blockfiles in the newly opened project. The question is, what do we >> > do if the opening copy of Audacity doesn't have FLAC support? >> > >> > It's easy enough to say "don't instantiate the class then" in the code, >> > but we need some sort of error handler that goes back up to the user and >> > says "whoever saved this project had imported FLAC files but not copied >> > dependecies when they saved, and you don't have FLAC support enabled, so >> > I can't read this project properly" and then does something safe like >> > close the project back down again so they can't break it. >> > >> > So this needs more than a bit of conditional compilation, it shows up a >> > design issue - what do we do about tracks read from original files if >> > the support library for original files is not available when the project >> > is reloaded? This didn't use to matter at all because we only had >> > read-from-original-file for libsndfile, and that's mandatory (although >> > there are some build options to that for what formats work). So we >> > haven't ever worried about this problem before. >> >> Hi Richard, >> >> Thanks for looking into this, and sorry that it wasn't as simple as I >> hoped. You bring up a good point that I hadn't thought about. The >> case will occur less often than the case you describe - the FLAC >> dependency issue will only happen if the project is saved before the >> decoding completes. Once it completes the decode via the on-demand >> task mechanism, the project saved after that point will be opened >> using SimpleBlockFiles instead of ODDecodeBlockFiles, so it won't >> matter if the opening copy of Audacity has the FLAC libs. > OK, I wasn't sure what happened to decoded files (and was getting > slightly confused with the read-from-original file feature for > libsndfile, where the end result is aliasblockfiles). > >> I agree that the issue handling on opening the project will be a >> trickier issue and a require a bit more design thinking. This is >> specially true since in this case the audio from FLAC that has been >> decoded prior to saving will be available - this leaves us (or the >> user) with several choices about what to do. Since this feature will >> be off for 2.0 should we just #ifdef it out with the >> _EXPERIMENTAL_OD_FLAC_ def? > > I hadn't registered you intended this to be turned off for 2.0 (I don't > have views either way, because my system libsndfile has FLAC support, > and so my builds of Audacity use that for FLAC import and I never > actually hit this code), but if so then I would definitely wrap it in > that #ifdef - at least that way any project from the stable build will > open in any copy of the stable build, even if it is theoretically > possible to have a beta project that won't open with the stable release. > > If we are going to do this, can we change Experimental.h to turn this > off soon, so we get to find any other problems this causes? There is a define called #define EXPERIMENTAL_OD_FLAC in the file already, and it is commented out. I've checked in code that bypasses the code you mentioned. If you have the code that fixes the libFLAC dependancies would you try it again? I'm afraid there may be a few other errors that you may have to use the #ifdef EXPERIMENTAL_OD_FLAC to get around. Michael ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Richard Ash (audacity-help)
|
On Wed, 2009-11-11 at 18:57 +0100, Michael Chinen wrote:
> There is a define called #define EXPERIMENTAL_OD_FLAC in the file > already, and it is commented out. > I've checked in code that bypasses the code you mentioned. If you > have the code that fixes the libFLAC dependancies would you try it > again? I'm afraid there may be a few other errors that you may have > to use the #ifdef EXPERIMENTAL_OD_FLAC > to get around. Turns out there is only one that matters, in the form of the include of the FLAC ondemand header, so I've put that include in the same conditional and it now builds fine without flac support (which duly causes FLAC imports to fall back on ffmpeg if it's available). So we can now cross this one off. I've altered Experimental.h to remove your comment about where to put the #define because it isn't true any more. Richard ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
|
Michael Chinen
|
On Sat, Nov 21, 2009 at 10:26 PM, Richard Ash <[hidden email]> wrote:
> On Wed, 2009-11-11 at 18:57 +0100, Michael Chinen wrote: >> There is a define called #define EXPERIMENTAL_OD_FLAC in the file >> already, and it is commented out. >> I've checked in code that bypasses the code you mentioned. If you >> have the code that fixes the libFLAC dependancies would you try it >> again? I'm afraid there may be a few other errors that you may have >> to use the #ifdef EXPERIMENTAL_OD_FLAC >> to get around. > > Turns out there is only one that matters, in the form of the include of > the FLAC ondemand header, so I've put that include in the same > conditional and it now builds fine without flac support (which duly > causes FLAC imports to fall back on ffmpeg if it's available). > > So we can now cross this one off. I've altered Experimental.h to remove > your comment about where to put the #define because it isn't true any > more. Looks good, Thanks, Richard. Michael ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
