Thread: [Audacity-devel] TimeTracks (was Re: [audacity] r12077 committed - commit a large patch by Maarten
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Martyn S. <mar...@gm...> - 2012-12-27 00:26:38
|
Hi there Sorry if I'm OT here, and things have been covered already, but I'm catching up after 10 days away. This looks like very interesting work by Maarten! And thanks for the review and commit Richard! Coupled with the resampling work from Rob I think we have a lot to be excited about for the next release! Additionally to all the other stuff as well. Just a few comments, and I haven't looked at the signal processing: I'm not sure if I'm 100% up to date here but I see that Envelope::Rescale does not have a definition in Envelope.h, unless I add it? It may be just me. On the GUI for TimeTracks now, the one that is greyed-out is the one that we currently have (lin/log v-scale). That's the same as Audio Tracks 'Waveform, Waveform (dB)...' etc., but I really don't find it obvious when I go to check what I'm looking at - I tend to think the more-highlighted one is the one I'm looking at and the greyed one/s are not available. I prefer all possible options to be not-greyed and a tick against the one I am using (like Mono, Left Channel, Right Channel, or in Set Rate). And/or some indication in the panel. I've seen the discussions of the on/off-ness of timetracks after a render and agree the the TT should then turn off. A button on the panel like the mute/solo would be good to turn it on/off. The log/lin interpolation could also have a button there, and so not have it on the menu. And the indications of the vertical scale (Linear / Logarithmic) do not actually say that they apply to the vertical scale. Maybe Scale:lin, Scale:log (with ticks) would be be more obvious? We do not seem to be allowing vertical zooming in the ruler, which would be useful, and more consistent with audio tracks. Would that be a good idea? I think so. But I should stop here. Great progress, a bit to go to get up to the standards of the audio tracks but a vast improvement on what we had! TTFN Martyn On 19/12/2012 21:51, aud...@go... wrote: > Revision: 12077 > Author: richardash1981 > Date: Wed Dec 19 13:49:25 2012 > Log: commit a large patch by Maarten Baert > maarten-baert<at>hotmail<dot>com to fix and improve time track > support. Several fix-me issues remain but none are new with this patch. > http://code.google.com/p/audacity/source/detail?r=12077 > > Modified: > /audacity-src/trunk/src/AudioIO.cpp > /audacity-src/trunk/src/AudioIO.h > /audacity-src/trunk/src/Envelope.cpp > /audacity-src/trunk/src/Envelope.h > /audacity-src/trunk/src/Mix.cpp > /audacity-src/trunk/src/Mix.h > /audacity-src/trunk/src/Resample.cpp > /audacity-src/trunk/src/Resample.h > /audacity-src/trunk/src/TimeTrack.cpp > /audacity-src/trunk/src/TimeTrack.h > /audacity-src/trunk/src/TrackArtist.cpp > /audacity-src/trunk/src/TrackPanel.cpp > /audacity-src/trunk/src/TrackPanel.h > /audacity-src/trunk/src/export/Export.cpp > /audacity-src/trunk/src/toolbars/TranscriptionToolBar.cpp > /audacity-src/trunk/src/widgets/Ruler.cpp > <snip> |
From: Maarten B. <maa...@ho...> - 2012-12-27 01:56:00
|
On 27/12/12 01:26, Martyn Shaw wrote: > I'm not sure if I'm 100% up to date here but I see that > Envelope::Rescale does not have a definition in Envelope.h, unless I > add it? It may be just me. I added Rescale, but removed it again because it wasn't needed anymore. It's not there anymore in the latest revision AFAIK. > We do not seem to be allowing vertical zooming in the ruler, which > would be useful, and more consistent with audio tracks. Would that be > a good idea? I think so. I intend to do that, it's just not finished yet. Maarten Baert |
From: Martyn S. <mar...@gm...> - 2012-12-29 01:02:46
|
On 27/12/2012 01:55, Maarten Baert wrote: > On 27/12/12 01:26, Martyn Shaw wrote: >> I'm not sure if I'm 100% up to date here but I see that >> Envelope::Rescale does not have a definition in Envelope.h, unless I >> add it? It may be just me. > I added Rescale, but removed it again because it wasn't needed anymore. > It's not there anymore in the latest revision AFAIK. OK, thanks. I guess I had a patch applied and wasn't actually at HEAD. >> We do not seem to be allowing vertical zooming in the ruler, which >> would be useful, and more consistent with audio tracks. Would that be >> a good idea? I think so. > I intend to do that, it's just not finished yet. Thanks! That would be great! TTFN Martyn > > Maarten Baert > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Gale (A. Team) <ga...@au...> - 2012-12-29 03:48:27
|
>> Gale wrote: >> I've found a repeatable problem I don't understand (tested on Windows 7 >> and Ubuntu). It isn't possible to drag or set an envelope point above a >> range of 200. > Maarten wrote: > Yes, that's a result of some code in the Envelope class that was intended > for wave tracks (which are limited to 2.0). This is why I need to make the > minimum and maximum value of Envelope adjustable. I'm still working on > that. Thanks, I can now set points up to 1000 after your "patch-envelope-range" patch (tested on Windows). Not sure if you know but although I can reopen projects with points set > 200 I cannot undo Time Track removal and have points > 200 respected. Any points > 200 are reset to 200 after undoing Time Track removal and then I cannot set further points > 200 in that track. Gale -- View this message in context: http://audacity.238276.n2.nabble.com/TimeTracks-was-Re-audacity-r12077-committed-commit-a-large-patch-by-Maarten-Baert-tp7557054p7557063.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Maarten B. <maa...@ho...> - 2012-12-29 15:16:15
Attachments:
patch-envelope-range-2.patch
|
On 29/12/12 04:48, Gale (Audacity Team) wrote: > Not sure if you know but although I can reopen projects with points set > > 200 > I cannot undo Time Track removal and have points > 200 respected. > > Any points > 200 are reset to 200 after undoing Time Track removal and then > I cannot set further points > 200 in that track. I see - I forgot to set the new range in the second constructor of TimeTrack, so when that one get's called you still get the old behaviour. I've attached a new patch. It's almost identical to the previous patch, I only added this: @@ -65,8 +66,9 @@ SetInterpolateLog(orig.GetInterpolateLog()); // this calls Envelope::SetInterpolateDB mEnvelope->Flatten(1.0); mEnvelope->Mirror(false); + mEnvelope->SetOffset(0); + mEnvelope->SetRange(0.1, 10.0); mEnvelope->Paste(0.0, orig.mEnvelope); - mEnvelope->SetOffset(0); mRuler = new Ruler(); mRuler->SetLabelEdges(false); Maarten Baert |
From: Richard A. <ri...@au...> - 2012-12-29 16:35:27
Attachments:
envelope-copy-const.patch
|
On Sat, 29 Dec 2012 16:16:05 +0100 Maarten Baert <maa...@ho...> wrote: > I see - I forgot to set the new range in the second constructor of > TimeTrack, so when that one get's called you still get the old > behaviour. I've attached a new patch. It's almost identical to the > previous patch, I only added this: > > @@ -65,8 +66,9 @@ > SetInterpolateLog(orig.GetInterpolateLog()); // this calls > Envelope::SetInterpolateDB > mEnvelope->Flatten(1.0); > mEnvelope->Mirror(false); > + mEnvelope->SetOffset(0); > + mEnvelope->SetRange(0.1, 10.0); > mEnvelope->Paste(0.0, orig.mEnvelope); > - mEnvelope->SetOffset(0); Is this the right range? Shouldn't the range of the new track be copied from the original, in case the source track has a wider range (which would be clipped by the paste into the narrower range track)? On top of commits including your patch I'm suggesting the attached. Richard |
From: Gale A. <ga...@au...> - 2012-12-29 22:30:16
|
| From Richard Ash <ri...@au...> | Sat, 29 Dec 2012 16:35:16 +0000 | Subject: [Audacity-devel] TimeTracks > On Sat, 29 Dec 2012 16:16:05 +0100 > Maarten Baert <maa...@ho...> wrote: > > I see - I forgot to set the new range in the second constructor of > > TimeTrack, so when that one get's called you still get the old > > behaviour. I've attached a new patch. It's almost identical to the > > previous patch, I only added this: > > > > @@ -65,8 +66,9 @@ > > SetInterpolateLog(orig.GetInterpolateLog()); // this calls > > Envelope::SetInterpolateDB > > mEnvelope->Flatten(1.0); > > mEnvelope->Mirror(false); > > + mEnvelope->SetOffset(0); > > + mEnvelope->SetRange(0.1, 10.0); > > mEnvelope->Paste(0.0, orig.mEnvelope); > > - mEnvelope->SetOffset(0); > > Is this the right range? Shouldn't the range of the new > track be copied from the original, in case the source track has a wider > range (which would be clipped by the paste into the narrower range > track)? > > On top of commits including your patch I'm suggesting the attached. Maarten, Trying what is committed now (unmodified HEAD) I get the same errors building Unicode Release on Windows that I told you about when trying V1 of patch-envelope-range (which built OK on Unicode Debug): 26>PCMAliasBlockFile.cpp 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2059: syntax error : '::' 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' 26>ODPCMAliasBlockFile.cpp 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2059: syntax error : '::' 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' At least, I assume this patch is the cause. Windows 7 x64, WxWidgets 2.8.12. Gale |
From: Leland <le...@au...> - 2013-02-27 03:37:57
|
Sorry guys, I just ran into this problem again and went to search for the resolution I'd found before and found y'alls questions. I'm running Windows 7 64-bit, VS 2008, and SDK V7.1A. I can't explain why it's happening here and not on y'alls machines. The problem only happens during Release Builds and only happens in: 1>SimpleBlockFile.cpp 1>..\..\..\src\blockfile\SimpleBlockFile.cpp(504) : error C2065: 'MAX_PATH' : undeclared identifier And I know how to "fix" it...just include "<wx/wx.h>". That's actually why most of the other source files don't run into the problem...at some point wx/wx.h get included. Still doesn't explain the problem. Leland On 1/10/2013 12:07 AM, Vaughan Johnson wrote: > Likewise, I'm not seeing this problem. Cleaned the whole directories, > rebuilt. > > So, Leland, which of your 3 suggestions do you think is best? > > I haven't had any of the recently reported build problems, updating > regularly from SVN. > > - V > > > On 1/9/2013 3:02 PM, Martyn Shaw wrote: >> Hiya Leland >> >> What OS are you on? This is now working fine on VS8 Win7 32-bit here, >> and I believe also on *nix. Are you on your Mac? >> >> TTFN >> Martyn >> >> On 09/01/2013 04:48, Leland Lucius wrote: >>> I'm getting it in: >>> >>> 6>SimpleBlockFile.cpp >>> 6>..\..\..\src\blockfile\SimpleBlockFile.cpp(502) : error C2065: >>> 'MAX_PATH' : undeclared identifier >>> >>> MAX_PATH is a well know size on Windows and I'd bet my right eye that >>> it'll never change. (My right eye doesn't work, so a pretty safe bet. :-D) >>> >>> How about just adding to Audacity.h: >>> >>> #ifdef __WXMSW__ >>> #include "configwin.h" >>> #if !defined(MAX_PATH) >>> #define MAX_PATH 260 >>> #endif >>> #undef PLATFORM_MAX_PATH >>> #define PLATFORM_MAX_PATH MAX_PATH >>> #endif >>> >>> Or even better, change all uses of MAX_PATH to PLATFORM_MAX_PATH and just: >>> >>> #ifdef __WXMSW__ >>> #include "configwin.h" >>> #undef PLATFORM_MAX_PATH >>> #define PLATFORM_MAX_PATH 260 >>> #endif >>> >>> If push comes to shove, just include "dynlib.h" or "wxprec.h" and use >>> preprocessed headers. >>> >>> Leland >>> >>> On 12/31/2012 1:58 PM, Martyn Shaw wrote: >>>> >>>> >>>> On 31/12/2012 13:29, Richard Ash wrote: >>>>> On Mon, 31 Dec 2012 02:29:16 +0100 >>>>> Maarten Baert <maa...@ho...> wrote: >>>>> >>>>>> On 31/12/12 00:55, Martyn Shaw wrote: >>>>>>> Also I note that std::max(...) is in use in several other places in >>>>>>> the Audacity code, without this problem. The only place that I see >>>>>>> the problem is in Envelope.h and that is also the only .h file in >>>>>>> which std::max(...) is used. Is that a coincidence, or a clue to >>>>>>> how to make the code more cross-platform? >>>>>> It only causes a problem when included from specific source files: >>>>>> PCMAliasBlockFile.cpp and ODPCMAliasBlockFile.cpp. These are two of >>>>>> the few files that include <windows.h> directly, rather than >>>>>> including wxWidgets headers. I assume these are simply the only files >>>>>> where Envelope.h and windows.h are included at the same time. I don't >>>>>> quite understand why the BlockFile-related code even has to include >>>>>> <windows.h> since they don't use any windows-specific functions. >>>>>> Would removing those break anything? >>>>> >>>>> I'd very much like to loose all the #includes of windows.h except where >>>>> the code is actually platform-dependent. I agree I can see no reason >>>>> why it is needed in any of the blockfile code. It seems to have been >>>>> added by Vaughan in 2008 for the switch to DLL (rather than static) >>>>> wxWidgets, although I can't see why, as most of the commit (r7435) is >>>>> adding precompilation header includes (which are all wx). >>>>> >>>>> Could someone on windows try removing all of them and see what breaks? >>>>> The only ones I image to be legitimate are VSTEffect.cpp / >>>>> FileNames.cpp / PlatformCompatibility.cpp which all encapsulate >>>>> platform differences. The rest are: >>>>> src/blockfile/ODPCMAliasBlockFile.cpp: #include <windows.h> >>>>> src/blockfile/ODDecodeBlockFile.cpp: #include <windows.h> >>>>> src/blockfile/PCMAliasBlockFile.cpp: #include <windows.h> >>>>> src/blockfile/SimpleBlockFile.cpp: #include <windows.h> >>>>> src/xml/XMLTagHandler.cpp: #include <windows.h> >>>> >>>> OK, I tried removing all the windows.h includes. The only ones that >>>> give compile errors were: >>>> 6>XMLTagHandler.cpp >>>> 6>..\..\..\src\xml\XMLTagHandler.cpp(44) : error C2065: 'MAX_PATH' : >>>> undeclared identifier >>>> 6>..\..\..\src\xml\XMLTagHandler.cpp(56) : error C2065: 'MAX_PATH' : >>>> undeclared identifier >>>> 6>..\..\..\src\xml\XMLTagHandler.cpp(84) : error C2065: 'MAX_PATH' : >>>> undeclared identifier >>>> 6>..\..\..\src\xml\XMLTagHandler.cpp(103) : error C2065: 'MAX_PATH' : >>>> undeclared identifier >>>> >>>> 6>FileNames.cpp >>>> 6>..\..\..\src\FileNames.cpp(241) : error C2065: 'WINAPI' : undeclared >>>> identifier >>>> 6>..\..\..\src\FileNames.cpp(241) : error C2065: 'getmodulehandleex' : >>>> undeclared identifier >>>> 6>..\..\..\src\FileNames.cpp(241) : error C4430: missing type >>>> specifier - int assumed. Note: C++ does not support default-int >>>> 6>..\..\..\src\FileNames.cpp(241) : fatal error C1903: unable to >>>> recover from previous error(s); stopping compilation >>>> >>>> so I put those 2 back in and it all compiles and runs on Release and >>>> Debug, and without any problems in Envelope.h. Shall we remove them >>>> from the code? >>>> >>>> TTFN >>>> Martyn >>>> >>>>> Richard >>>>> > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Vaughan J. <va...@au...> - 2013-02-27 04:42:30
|
Builds for me. - V On 2/26/2013 7:37 PM, Leland wrote: > Sorry guys, > > I just ran into this problem again and went to search for the resolution > I'd found before and found y'alls questions. > > I'm running Windows 7 64-bit, VS 2008, and SDK V7.1A. > > I can't explain why it's happening here and not on y'alls machines. The > problem only happens during Release Builds and only happens in: > > 1>SimpleBlockFile.cpp > 1>..\..\..\src\blockfile\SimpleBlockFile.cpp(504) : error C2065: > 'MAX_PATH' : undeclared identifier > > And I know how to "fix" it...just include "<wx/wx.h>". That's actually > why most of the other source files don't run into the problem...at some > point wx/wx.h get included. > > Still doesn't explain the problem. > > Leland > > On 1/10/2013 12:07 AM, Vaughan Johnson wrote: >> Likewise, I'm not seeing this problem. Cleaned the whole directories, >> rebuilt. >> >> So, Leland, which of your 3 suggestions do you think is best? >> >> I haven't had any of the recently reported build problems, updating >> regularly from SVN. >> >> - V >> >> >> On 1/9/2013 3:02 PM, Martyn Shaw wrote: >>> Hiya Leland >>> >>> What OS are you on? This is now working fine on VS8 Win7 32-bit here, >>> and I believe also on *nix. Are you on your Mac? >>> >>> TTFN >>> Martyn >>> >>> On 09/01/2013 04:48, Leland Lucius wrote: >>>> I'm getting it in: >>>> >>>> 6>SimpleBlockFile.cpp >>>> 6>..\..\..\src\blockfile\SimpleBlockFile.cpp(502) : error C2065: >>>> 'MAX_PATH' : undeclared identifier >>>> >>>> MAX_PATH is a well know size on Windows and I'd bet my right eye that >>>> it'll never change. (My right eye doesn't work, so a pretty safe bet. :-D) >>>> >>>> How about just adding to Audacity.h: >>>> >>>> #ifdef __WXMSW__ >>>> #include "configwin.h" >>>> #if !defined(MAX_PATH) >>>> #define MAX_PATH 260 >>>> #endif >>>> #undef PLATFORM_MAX_PATH >>>> #define PLATFORM_MAX_PATH MAX_PATH >>>> #endif >>>> >>>> Or even better, change all uses of MAX_PATH to PLATFORM_MAX_PATH and just: >>>> >>>> #ifdef __WXMSW__ >>>> #include "configwin.h" >>>> #undef PLATFORM_MAX_PATH >>>> #define PLATFORM_MAX_PATH 260 >>>> #endif >>>> >>>> If push comes to shove, just include "dynlib.h" or "wxprec.h" and use >>>> preprocessed headers. >>>> >>>> Leland >>>> >>>> On 12/31/2012 1:58 PM, Martyn Shaw wrote: >>>>> >>>>> >>>>> On 31/12/2012 13:29, Richard Ash wrote: >>>>>> On Mon, 31 Dec 2012 02:29:16 +0100 >>>>>> Maarten Baert <maa...@ho...> wrote: >>>>>> >>>>>>> On 31/12/12 00:55, Martyn Shaw wrote: >>>>>>>> Also I note that std::max(...) is in use in several other places in >>>>>>>> the Audacity code, without this problem. The only place that I see >>>>>>>> the problem is in Envelope.h and that is also the only .h file in >>>>>>>> which std::max(...) is used. Is that a coincidence, or a clue to >>>>>>>> how to make the code more cross-platform? >>>>>>> It only causes a problem when included from specific source files: >>>>>>> PCMAliasBlockFile.cpp and ODPCMAliasBlockFile.cpp. These are two of >>>>>>> the few files that include <windows.h> directly, rather than >>>>>>> including wxWidgets headers. I assume these are simply the only files >>>>>>> where Envelope.h and windows.h are included at the same time. I don't >>>>>>> quite understand why the BlockFile-related code even has to include >>>>>>> <windows.h> since they don't use any windows-specific functions. >>>>>>> Would removing those break anything? >>>>>> >>>>>> I'd very much like to loose all the #includes of windows.h except where >>>>>> the code is actually platform-dependent. I agree I can see no reason >>>>>> why it is needed in any of the blockfile code. It seems to have been >>>>>> added by Vaughan in 2008 for the switch to DLL (rather than static) >>>>>> wxWidgets, although I can't see why, as most of the commit (r7435) is >>>>>> adding precompilation header includes (which are all wx). >>>>>> >>>>>> Could someone on windows try removing all of them and see what breaks? >>>>>> The only ones I image to be legitimate are VSTEffect.cpp / >>>>>> FileNames.cpp / PlatformCompatibility.cpp which all encapsulate >>>>>> platform differences. The rest are: >>>>>> src/blockfile/ODPCMAliasBlockFile.cpp: #include <windows.h> >>>>>> src/blockfile/ODDecodeBlockFile.cpp: #include <windows.h> >>>>>> src/blockfile/PCMAliasBlockFile.cpp: #include <windows.h> >>>>>> src/blockfile/SimpleBlockFile.cpp: #include <windows.h> >>>>>> src/xml/XMLTagHandler.cpp: #include <windows.h> >>>>> >>>>> OK, I tried removing all the windows.h includes. The only ones that >>>>> give compile errors were: >>>>> 6>XMLTagHandler.cpp >>>>> 6>..\..\..\src\xml\XMLTagHandler.cpp(44) : error C2065: 'MAX_PATH' : >>>>> undeclared identifier >>>>> 6>..\..\..\src\xml\XMLTagHandler.cpp(56) : error C2065: 'MAX_PATH' : >>>>> undeclared identifier >>>>> 6>..\..\..\src\xml\XMLTagHandler.cpp(84) : error C2065: 'MAX_PATH' : >>>>> undeclared identifier >>>>> 6>..\..\..\src\xml\XMLTagHandler.cpp(103) : error C2065: 'MAX_PATH' : >>>>> undeclared identifier >>>>> >>>>> 6>FileNames.cpp >>>>> 6>..\..\..\src\FileNames.cpp(241) : error C2065: 'WINAPI' : undeclared >>>>> identifier >>>>> 6>..\..\..\src\FileNames.cpp(241) : error C2065: 'getmodulehandleex' : >>>>> undeclared identifier >>>>> 6>..\..\..\src\FileNames.cpp(241) : error C4430: missing type >>>>> specifier - int assumed. Note: C++ does not support default-int >>>>> 6>..\..\..\src\FileNames.cpp(241) : fatal error C1903: unable to >>>>> recover from previous error(s); stopping compilation >>>>> >>>>> so I put those 2 back in and it all compiles and runs on Release and >>>>> Debug, and without any problems in Envelope.h. Shall we remove them >>>>> from the code? >>>>> >>>>> TTFN >>>>> Martyn >>>>> >>>>>> Richard >>>>>> >> >> ------------------------------------------------------------------------------ >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >> MVPs and experts. ON SALE this month only -- learn more at: >> http://p.sf.net/sfu/learnmore_122712 >> _______________________________________________ >> audacity-devel mailing list >> aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Gale (A. Team) <ga...@au...> - 2013-03-18 02:07:19
|
Leland wrote: > I just ran into this problem again and went to search for the > resolution I'd found before and found y'alls questions. > > I'm running Windows 7 64-bit, VS 2008, and SDK V7.1A. > > I can't explain why it's happening here and not on y'alls machines. The > problem only happens during Release Builds and only happens in: > > 1>SimpleBlockFile.cpp > 1>..\..\..\src\blockfile\SimpleBlockFile.cpp(504) : error C2065: > 'MAX_PATH' : undeclared identifier > > > And I know how to "fix" it...just include "<wx/wx.h>". That's actually > why most of the other source files don't run into the problem...at some > point wx/wx.h get included. > > Still doesn't explain the problem. A user on the Forum on Windows 7, VS C++ 2008 Express had this issue too, but he said he was using the SDK V6.0a then updated to V7.1. Might that be relevant? My machine was a fresh installation of the V7.1 SDK then fresh installation of VS C++ 2008 Express. Your solution above compiles for me fine in Release and Debug builds. His solution FWIW was: Index: src/Audacity.h ==================================== --- src/Audacity.h (revision 12261) +++ src/Audacity.h (working copy) @@ -99,7 +99,7 @@ #ifdef __WXMSW__ #include "configwin.h" #undef PLATFORM_MAX_PATH -#define PLATFORM_MAX_PATH MAX_PATH +#define PLATFORM_MAX_PATH 260 #endif /* Magic for dynamic library import and export. This is unfortunately Gale -- View this message in context: http://audacity.238276.n2.nabble.com/TimeTracks-was-Re-audacity-r12077-committed-commit-a-large-patch-by-Maarten-Baert-tp7557054p7557856.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Vaughan J. <va...@au...> - 2013-03-19 05:24:52
|
On 3/17/2013 7:07 PM, Gale (Audacity Team) wrote: > Leland wrote: >> I just ran into this problem again and went to search for the >> resolution I'd found before and found y'alls questions. >> >> I'm running Windows 7 64-bit, VS 2008, and SDK V7.1A. >> >> I can't explain why it's happening here and not on y'alls machines. The >> problem only happens during Release Builds and only happens in: >> >> 1>SimpleBlockFile.cpp >> 1>..\..\..\src\blockfile\SimpleBlockFile.cpp(504) : error C2065: >> 'MAX_PATH' : undeclared identifier Again, not getting that error on rebuild debug or release, Windows 7 64bit, VS 2008, SDK 6 -- standard installation. Aren't SDK 7 and 7.1 primarily for MSVC 2010? Yes, there are articles about making it work with MSVC 2008, but I don't think it's mainstream, right? And we discussed long ago the very good reasons to not convert to MSVC 2010, right? What was actually broken about min and max or wxMin and wxMax? Why is this taking so much attention? What does this have to do any more with "Time Tracks" (original and continuing subject until this msg)? This thread has strayed so far... what's the continuing point? >> >> >> And I know how to "fix" it...just include "<wx/wx.h>". That's actually >> why most of the other source files don't run into the problem...at some >> point wx/wx.h get included. So why not do that? MAX_PATH is Windows specific. I don't know why there was such an effort to purge wx.h a few months ago. Platform issues are what it's supposed to handle, right? >> >> Still doesn't explain the problem. > > A user on the Forum on Windows 7, VS C++ 2008 Express had this issue too, > but he said he was using the SDK V6.0a then updated to V7.1. Might that be > relevant? My machine was a fresh installation of the V7.1 SDK then fresh > installation of VS C++ 2008 Express. > > Your solution above compiles for me fine in Release and Debug builds. His > solution FWIW was: > > Index: src/Audacity.h > ==================================== > > --- src/Audacity.h (revision 12261) > +++ src/Audacity.h (working copy) > @@ -99,7 +99,7 @@ > #ifdef __WXMSW__ > #include "configwin.h" > #undef PLATFORM_MAX_PATH > -#define PLATFORM_MAX_PATH MAX_PATH > +#define PLATFORM_MAX_PATH 260 > #endif > Bad solution. It duplicates a platform-specific constant in our code. If the platform constant changes, we would have to update. Yes, unlikely in this case, but bad practice. -1. - V |
From: Maarten B. <maa...@ho...> - 2012-12-30 00:05:14
|
On 29/12/12 23:30, Gale Andrews wrote: > Maarten, > > Trying what is committed now (unmodified HEAD) I get the same > errors building Unicode Release on Windows that I told you about > when trying V1 of patch-envelope-range (which built OK on Unicode > Debug): > > 26>PCMAliasBlockFile.cpp > 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' > 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2059: syntax error : '::' > 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' > 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' > 26>ODPCMAliasBlockFile.cpp > 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' > 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2059: syntax error : '::' > 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' > 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' > > At least, I assume this patch is the cause. > > Windows 7 x64, WxWidgets 2.8.12. I already replied to that (off-list), did you miss it? > I've seen similar errors before. Some windows headers define the > macros 'min' and 'max', which obviously interfere with the functions > std::min and std::max - you get something like std::((a < b)? a : b). > You could add something like '#ifdef min #undef min #endif' to the top > of Envelope.h. I'm not sure why it only happens in Release mode though. I haven't added this in my patch though, I haven't tried building on Windows so I don't really know whether this will solve your issue or just create other problems elsewhere. Maarten Baert |
From: Leland L. <ll...@ho...> - 2013-01-01 08:36:29
|
On 12/29/2012 6:05 PM, Maarten Baert wrote: > On 29/12/12 23:30, Gale Andrews wrote: >> Maarten, >> >> Trying what is committed now (unmodified HEAD) I get the same >> errors building Unicode Release on Windows that I told you about >> when trying V1 of patch-envelope-range (which built OK on Unicode >> Debug): >> >> 26>PCMAliasBlockFile.cpp >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2059: syntax error : '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> 26>ODPCMAliasBlockFile.cpp >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2059: syntax error : '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> >> At least, I assume this patch is the cause. >> >> Windows 7 x64, WxWidgets 2.8.12. > I already replied to that (off-list), did you miss it? >> I've seen similar errors before. Some windows headers define the >> macros 'min' and 'max', which obviously interfere with the functions >> std::min and std::max - you get something like std::((a < b)? a : b). >> You could add something like '#ifdef min #undef min #endif' to the top >> of Envelope.h. I'm not sure why it only happens in Release mode though. > I haven't added this in my patch though, I haven't tried building on > Windows so I don't really know whether this will solve your issue or > just create other problems elsewhere. > The max/min macros are being defined in WinDef.h. Adding NOMINMAX to the preprocessor definitions for the Audacity project will prevent the error from happening. Leland |
From: Martyn S. <mar...@gm...> - 2012-12-30 23:55:07
|
Hi Maarten I have the same problem as Gale had here, on Windows. On 30/12/2012 00:05, Maarten Baert wrote: > On 29/12/12 23:30, Gale Andrews wrote: >> Maarten, >> >> Trying what is committed now (unmodified HEAD) I get the same >> errors building Unicode Release on Windows that I told you about >> when trying V1 of patch-envelope-range (which built OK on Unicode >> Debug): >> >> 26>PCMAliasBlockFile.cpp >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2059: syntax error : '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> 26>ODPCMAliasBlockFile.cpp >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2059: syntax error : '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> >> At least, I assume this patch is the cause. >> >> Windows 7 x64, WxWidgets 2.8.12. > I already replied to that (off-list), did you miss it? >> I've seen similar errors before. Some windows headers define the >> macros 'min' and 'max', which obviously interfere with the functions >> std::min and std::max - you get something like std::((a < b)? a : b). >> You could add something like '#ifdef min #undef min #endif' to the top >> of Envelope.h. I'm not sure why it only happens in Release mode though. > I haven't added this in my patch though, I haven't tried building on > Windows so I don't really know whether this will solve your issue or > just create other problems elsewhere. adding the rather ugly: #ifdef min #undef min #endif #ifdef max #undef max #endif before double ClampValue(double value) { ... does enable me to compile Release here, but I note that in Envelope.h it does not make a difference if #include <algorithm> is in or out, implying to me that the declaration of algorithm is happening somewhere else. Also I note that std::max(...) is in use in several other places in the Audacity code, without this problem. The only place that I see the problem is in Envelope.h and that is also the only .h file in which std::max(...) is used. Is that a coincidence, or a clue to how to make the code more cross-platform? This may be a minor point on Gnu/Linux but is a bigger problem here on Win. Thanks Martyn (which is presumably pronounced the same as 'Maarten!) > Maarten Baert > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_123012 > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Maarten B. <maa...@ho...> - 2012-12-31 01:29:24
|
On 31/12/12 00:55, Martyn Shaw wrote: > but I note that in Envelope.h it does not make a difference if > #include <algorithm> is in or out, implying to me that the declaration > of algorithm is happening somewhere else. Yes, but if you remove it, it will fail to build on Mac in Debug mode according to Paul Livesey. > Also I note that std::max(...) is in use in several other places in > the Audacity code, without this problem. The only place that I see the > problem is in Envelope.h and that is also the only .h file in which > std::max(...) is used. Is that a coincidence, or a clue to how to make > the code more cross-platform? It only causes a problem when included from specific source files: PCMAliasBlockFile.cpp and ODPCMAliasBlockFile.cpp. These are two of the few files that include <windows.h> directly, rather than including wxWidgets headers. I assume these are simply the only files where Envelope.h and windows.h are included at the same time. I don't quite understand why the BlockFile-related code even has to include <windows.h> since they don't use any windows-specific functions. Would removing those break anything? Alternatively, moving the definition of ClampValue from Envelope.h to Envelope.cpp would also solve this problem, as long as Envelope.cpp doesn't include <windows.h>. Maarten Baert |
From: Richard A. <ri...@au...> - 2012-12-31 13:30:02
|
On Mon, 31 Dec 2012 02:29:16 +0100 Maarten Baert <maa...@ho...> wrote: > On 31/12/12 00:55, Martyn Shaw wrote: > > Also I note that std::max(...) is in use in several other places in > > the Audacity code, without this problem. The only place that I see > > the problem is in Envelope.h and that is also the only .h file in > > which std::max(...) is used. Is that a coincidence, or a clue to > > how to make the code more cross-platform? > It only causes a problem when included from specific source files: > PCMAliasBlockFile.cpp and ODPCMAliasBlockFile.cpp. These are two of > the few files that include <windows.h> directly, rather than > including wxWidgets headers. I assume these are simply the only files > where Envelope.h and windows.h are included at the same time. I don't > quite understand why the BlockFile-related code even has to include > <windows.h> since they don't use any windows-specific functions. > Would removing those break anything? I'd very much like to loose all the #includes of windows.h except where the code is actually platform-dependent. I agree I can see no reason why it is needed in any of the blockfile code. It seems to have been added by Vaughan in 2008 for the switch to DLL (rather than static) wxWidgets, although I can't see why, as most of the commit (r7435) is adding precompilation header includes (which are all wx). Could someone on windows try removing all of them and see what breaks? The only ones I image to be legitimate are VSTEffect.cpp / FileNames.cpp / PlatformCompatibility.cpp which all encapsulate platform differences. The rest are: src/blockfile/ODPCMAliasBlockFile.cpp: #include <windows.h> src/blockfile/ODDecodeBlockFile.cpp: #include <windows.h> src/blockfile/PCMAliasBlockFile.cpp: #include <windows.h> src/blockfile/SimpleBlockFile.cpp: #include <windows.h> src/xml/XMLTagHandler.cpp: #include <windows.h> Richard |
From: Martyn S. <mar...@gm...> - 2012-12-31 19:58:09
|
On 31/12/2012 13:29, Richard Ash wrote: > On Mon, 31 Dec 2012 02:29:16 +0100 > Maarten Baert <maa...@ho...> wrote: > >> On 31/12/12 00:55, Martyn Shaw wrote: >>> Also I note that std::max(...) is in use in several other places in >>> the Audacity code, without this problem. The only place that I see >>> the problem is in Envelope.h and that is also the only .h file in >>> which std::max(...) is used. Is that a coincidence, or a clue to >>> how to make the code more cross-platform? >> It only causes a problem when included from specific source files: >> PCMAliasBlockFile.cpp and ODPCMAliasBlockFile.cpp. These are two of >> the few files that include <windows.h> directly, rather than >> including wxWidgets headers. I assume these are simply the only files >> where Envelope.h and windows.h are included at the same time. I don't >> quite understand why the BlockFile-related code even has to include >> <windows.h> since they don't use any windows-specific functions. >> Would removing those break anything? > > I'd very much like to loose all the #includes of windows.h except where > the code is actually platform-dependent. I agree I can see no reason > why it is needed in any of the blockfile code. It seems to have been > added by Vaughan in 2008 for the switch to DLL (rather than static) > wxWidgets, although I can't see why, as most of the commit (r7435) is > adding precompilation header includes (which are all wx). > > Could someone on windows try removing all of them and see what breaks? > The only ones I image to be legitimate are VSTEffect.cpp / > FileNames.cpp / PlatformCompatibility.cpp which all encapsulate > platform differences. The rest are: > src/blockfile/ODPCMAliasBlockFile.cpp: #include <windows.h> > src/blockfile/ODDecodeBlockFile.cpp: #include <windows.h> > src/blockfile/PCMAliasBlockFile.cpp: #include <windows.h> > src/blockfile/SimpleBlockFile.cpp: #include <windows.h> > src/xml/XMLTagHandler.cpp: #include <windows.h> OK, I tried removing all the windows.h includes. The only ones that give compile errors were: 6>XMLTagHandler.cpp 6>..\..\..\src\xml\XMLTagHandler.cpp(44) : error C2065: 'MAX_PATH' : undeclared identifier 6>..\..\..\src\xml\XMLTagHandler.cpp(56) : error C2065: 'MAX_PATH' : undeclared identifier 6>..\..\..\src\xml\XMLTagHandler.cpp(84) : error C2065: 'MAX_PATH' : undeclared identifier 6>..\..\..\src\xml\XMLTagHandler.cpp(103) : error C2065: 'MAX_PATH' : undeclared identifier 6>FileNames.cpp 6>..\..\..\src\FileNames.cpp(241) : error C2065: 'WINAPI' : undeclared identifier 6>..\..\..\src\FileNames.cpp(241) : error C2065: 'getmodulehandleex' : undeclared identifier 6>..\..\..\src\FileNames.cpp(241) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 6>..\..\..\src\FileNames.cpp(241) : fatal error C1903: unable to recover from previous error(s); stopping compilation so I put those 2 back in and it all compiles and runs on Release and Debug, and without any problems in Envelope.h. Shall we remove them from the code? TTFN Martyn > Richard > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122412 > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Richard A. <ri...@au...> - 2012-12-31 20:52:35
|
On Mon, 31 Dec 2012 19:58:20 +0000 Martyn Shaw <mar...@gm...> wrote: > On 31/12/2012 13:29, Richard Ash wrote: > > On Mon, 31 Dec 2012 02:29:16 +0100 > > Could someone on windows try removing all of them and see what > > breaks? > OK, I tried removing all the windows.h includes. The only ones that > give compile errors were: > XMLTagHandler.cpp > ..\..\..\src\xml\XMLTagHandler.cpp(44) : error C2065: 'MAX_PATH' : > undeclared identifier [...] > > FileNames.cpp > ..\..\..\src\FileNames.cpp(241) : error C2065: 'WINAPI' : > undeclared > identifier > > so I put those 2 back in and it all compiles and runs on Release and > Debug, and without any problems in Envelope.h. Shall we remove them > from the code? Yes please. FileNames must be part of the portability stuff so use is legitimate, and I can't be bothered abstracting the concept of maximum path length from the XML handler, so it may as well stay. At least we loose the rest and that should solve the compile errors. Richard |
From: Martyn S. <mar...@gm...> - 2012-12-31 22:22:17
|
Done Martyn On 31/12/2012 20:52, Richard Ash wrote: > On Mon, 31 Dec 2012 19:58:20 +0000 > Martyn Shaw <mar...@gm...> wrote: >> On 31/12/2012 13:29, Richard Ash wrote: >>> On Mon, 31 Dec 2012 02:29:16 +0100 >>> Could someone on windows try removing all of them and see what >>> breaks? >> OK, I tried removing all the windows.h includes. The only ones that >> give compile errors were: >> XMLTagHandler.cpp >> ..\..\..\src\xml\XMLTagHandler.cpp(44) : error C2065: 'MAX_PATH' : >> undeclared identifier > [...] >> >> FileNames.cpp >> ..\..\..\src\FileNames.cpp(241) : error C2065: 'WINAPI' : >> undeclared >> identifier >> >> so I put those 2 back in and it all compiles and runs on Release and >> Debug, and without any problems in Envelope.h. Shall we remove them >> from the code? > Yes please. FileNames must be part of the portability stuff so use is > legitimate, and I can't be bothered abstracting the concept of maximum > path length from the XML handler, so it may as well stay. At least we > loose the rest and that should solve the compile errors. > > Richard > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122412 > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Leland L. <ll...@ho...> - 2012-12-31 23:46:22
|
On 12/29/2012 6:05 PM, Maarten Baert wrote: > On 29/12/12 23:30, Gale Andrews wrote: >> Maarten, >> >> Trying what is committed now (unmodified HEAD) I get the same >> errors building Unicode Release on Windows that I told you about >> when trying V1 of patch-envelope-range (which built OK on Unicode >> Debug): >> >> 26>PCMAliasBlockFile.cpp >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2059: syntax error : '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> 26>ODPCMAliasBlockFile.cpp >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2059: syntax error : '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> 26>c:\audacity svn\src\widgets\../Envelope.h(105) : error C2589: '(' : illegal token on right side of '::' >> >> At least, I assume this patch is the cause. >> >> Windows 7 x64, WxWidgets 2.8.12. > I already replied to that (off-list), did you miss it? >> I've seen similar errors before. Some windows headers define the >> macros 'min' and 'max', which obviously interfere with the functions >> std::min and std::max - you get something like std::((a < b)? a : b). >> You could add something like '#ifdef min #undef min #endif' to the top >> of Envelope.h. I'm not sure why it only happens in Release mode though. > I haven't added this in my patch though, I haven't tried building on > Windows so I don't really know whether this will solve your issue or > just create other problems elsewhere. > May I suggest using wxMax and wxMin instead? They are defined in wx/utils.h. Leland |
From: Maarten B. <maa...@ho...> - 2013-01-01 02:22:01
|
On 01/01/13 00:46, Leland Lucius wrote: > May I suggest using wxMax and wxMin instead? Those appear to be undocumented. Also, they are macros rather than functions. I prefer std::min and std::max because those are standard C++ functions. Unrelated: I've done some tests with lower values for mMaxPlaybackSecsToCopy (in AudioIO.cpp). The current value is 4 seconds, but I can lower this to 0.2 seconds before I get any kind of stuttering (and even then it's only at the start). So I think 1 second should work fine. Playback starts faster with lower values because less processing is needed before playback can start, which is especially noticeable with time tracks - if mMaxPlaybackSecsToCopy is set to 4, the delay is quite noticeable. Could someone do some tests with lower values for mMaxPlaybackSecsToCopy (AudioIO.cpp around line 1201) to see whether lower values also work on other platforms? I tested only on Linux. Maarten Baert |
From: Leland L. <ll...@ho...> - 2013-01-01 07:45:14
|
On 12/31/2012 8:21 PM, Maarten Baert wrote: > On 01/01/13 00:46, Leland Lucius wrote: >> May I suggest using wxMax and wxMin instead? > Those appear to be undocumented. Also, they are macros rather than > functions. I prefer std::min and std::max because those are standard C++ > functions. > Interesting that the "standard" C++ functions are giving issues. The wxMin/wxMax (Audacity does use wxWidgets ya know) are available in the 2.8 and 2.9 series, macros in 2.8 and templates in 2.9. I bet Unicode Release would actually build if you included "wx/utils.h" and changed to wxMin/wxMax. But, no biggie. I was able to get my build working here. Leland |
From: Martyn S. <mar...@gm...> - 2013-01-02 00:26:01
|
On 01/01/2013 02:21, Maarten Baert wrote: ... > Unrelated: ... Oh, please don't do that! Thanks Martyn |
From: Leland L. <ll...@ho...> - 2013-01-09 04:48:15
|
I'm getting it in: 6>SimpleBlockFile.cpp 6>..\..\..\src\blockfile\SimpleBlockFile.cpp(502) : error C2065: 'MAX_PATH' : undeclared identifier MAX_PATH is a well know size on Windows and I'd bet my right eye that it'll never change. (My right eye doesn't work, so a pretty safe bet. :-D) How about just adding to Audacity.h: #ifdef __WXMSW__ #include "configwin.h" #if !defined(MAX_PATH) #define MAX_PATH 260 #endif #undef PLATFORM_MAX_PATH #define PLATFORM_MAX_PATH MAX_PATH #endif Or even better, change all uses of MAX_PATH to PLATFORM_MAX_PATH and just: #ifdef __WXMSW__ #include "configwin.h" #undef PLATFORM_MAX_PATH #define PLATFORM_MAX_PATH 260 #endif If push comes to shove, just include "dynlib.h" or "wxprec.h" and use preprocessed headers. Leland On 12/31/2012 1:58 PM, Martyn Shaw wrote: > > > On 31/12/2012 13:29, Richard Ash wrote: >> On Mon, 31 Dec 2012 02:29:16 +0100 >> Maarten Baert <maa...@ho...> wrote: >> >>> On 31/12/12 00:55, Martyn Shaw wrote: >>>> Also I note that std::max(...) is in use in several other places in >>>> the Audacity code, without this problem. The only place that I see >>>> the problem is in Envelope.h and that is also the only .h file in >>>> which std::max(...) is used. Is that a coincidence, or a clue to >>>> how to make the code more cross-platform? >>> It only causes a problem when included from specific source files: >>> PCMAliasBlockFile.cpp and ODPCMAliasBlockFile.cpp. These are two of >>> the few files that include <windows.h> directly, rather than >>> including wxWidgets headers. I assume these are simply the only files >>> where Envelope.h and windows.h are included at the same time. I don't >>> quite understand why the BlockFile-related code even has to include >>> <windows.h> since they don't use any windows-specific functions. >>> Would removing those break anything? >> >> I'd very much like to loose all the #includes of windows.h except where >> the code is actually platform-dependent. I agree I can see no reason >> why it is needed in any of the blockfile code. It seems to have been >> added by Vaughan in 2008 for the switch to DLL (rather than static) >> wxWidgets, although I can't see why, as most of the commit (r7435) is >> adding precompilation header includes (which are all wx). >> >> Could someone on windows try removing all of them and see what breaks? >> The only ones I image to be legitimate are VSTEffect.cpp / >> FileNames.cpp / PlatformCompatibility.cpp which all encapsulate >> platform differences. The rest are: >> src/blockfile/ODPCMAliasBlockFile.cpp: #include <windows.h> >> src/blockfile/ODDecodeBlockFile.cpp: #include <windows.h> >> src/blockfile/PCMAliasBlockFile.cpp: #include <windows.h> >> src/blockfile/SimpleBlockFile.cpp: #include <windows.h> >> src/xml/XMLTagHandler.cpp: #include <windows.h> > > OK, I tried removing all the windows.h includes. The only ones that > give compile errors were: > 6>XMLTagHandler.cpp > 6>..\..\..\src\xml\XMLTagHandler.cpp(44) : error C2065: 'MAX_PATH' : > undeclared identifier > 6>..\..\..\src\xml\XMLTagHandler.cpp(56) : error C2065: 'MAX_PATH' : > undeclared identifier > 6>..\..\..\src\xml\XMLTagHandler.cpp(84) : error C2065: 'MAX_PATH' : > undeclared identifier > 6>..\..\..\src\xml\XMLTagHandler.cpp(103) : error C2065: 'MAX_PATH' : > undeclared identifier > > 6>FileNames.cpp > 6>..\..\..\src\FileNames.cpp(241) : error C2065: 'WINAPI' : undeclared > identifier > 6>..\..\..\src\FileNames.cpp(241) : error C2065: 'getmodulehandleex' : > undeclared identifier > 6>..\..\..\src\FileNames.cpp(241) : error C4430: missing type > specifier - int assumed. Note: C++ does not support default-int > 6>..\..\..\src\FileNames.cpp(241) : fatal error C1903: unable to > recover from previous error(s); stopping compilation > > so I put those 2 back in and it all compiles and runs on Release and > Debug, and without any problems in Envelope.h. Shall we remove them > from the code? > > TTFN > Martyn > >> Richard >> >> ------------------------------------------------------------------------------ >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >> MVPs and experts. SALE $99.99 this month only -- learn more at: >> http://p.sf.net/sfu/learnmore_122412 >> _______________________________________________ >> audacity-devel mailing list >> aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122412 > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Leland L. <ll...@ho...> - 2013-01-09 04:56:30
|
On 1/8/2013 10:48 PM, Leland Lucius wrote: > > If push comes to shove, just include "dynlib.h" or "wxprec.h" and use > preprocessed headers. > The reason these 2 work is because the include "wx/msw/private.h" and that defines MAX_PATH (yes, to 260). Leland |