Thread: [Audacity-devel] Mac Xcode project
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Paul L. <pau...@bo...> - 2013-01-14 18:51:43
|
I've made some changes to the Xcode project file, I hope that they're correct. The default now is to build with libsoxr as the only resampling library. There are two other targets defined, one of which uses libsamplerate only and the other libresample. Is this the expected build configuration or should a mixture of the libraries be possible? As far as I can tell the default build (which is what the nightlys are) seems to work. I can only natively test on Intel at the moment so while the PPC build gives every impression of working I cannot personally test it. Kindest Regards, Paul. |
From: Vaughan J. <va...@au...> - 2013-01-14 20:54:41
|
On 1/14/2013 10:50 AM, Paul Livesey wrote: > I've made some changes to the Xcode project file, I hope that they're correct. Greek to me. > > The default now is to build with libsoxr as the only resampling library. There are two other targets defined, one of which uses libsamplerate only and the other libresample. > > Is this the expected build configuration or should a mixture of the libraries be possible? Yes, that's what we should supply. Other configurations are "at your peril" and DIY. > > As far as I can tell the default build (which is what the nightlys are) seems to work. I can only natively test on Intel at the moment so while the PPC build gives every impression of working I cannot personally test it. > > Kindest Regards, > > Paul. Thanks, Vaughan |
From: Martyn S. <mar...@gm...> - 2013-01-15 01:38:21
|
Hi Paul Out of interest (and I'm mostly Win-only), how dependent is the Mac build on the various linux build process stuff? That is, on 'config' and all those *nix things that I do not understand. Is the x-code stuff independent of that? Thanks Martyn On 14/01/2013 18:50, Paul Livesey wrote: > I've made some changes to the Xcode project file, I hope that they're correct. > > The default now is to build with libsoxr as the only resampling library. There are two other targets defined, one of which uses libsamplerate only and the other libresample. > > Is this the expected build configuration or should a mixture of the libraries be possible? > > As far as I can tell the default build (which is what the nightlys are) seems to work. I can only natively test on Intel at the moment so while the PPC build gives every impression of working I cannot personally test it. > > Kindest Regards, > > Paul. > > > ------------------------------------------------------------------------------ > 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: Paul L. <pau...@bo...> - 2013-01-15 13:31:22
|
On 15 Jan 2013, at 01:38, Martyn Shaw wrote: > Hi Paul > > Out of interest (and I'm mostly Win-only), how dependent is the Mac > build on the various linux build process stuff? That is, on 'config' > and all those *nix things that I do not understand. Is the x-code > stuff independent of that? > > Thanks > Martyn Hi Martyn, The Xcode project is a bit of a halfway house or worst of all worlds type affair! It is ofttimes not for the faint of heart, especially if you're trying to support a variety of OSX platforms. The configure scripts are required and are used to generate config.h, Makefiles and sometimes other things. The Makefiles (which are useful in setting up the Xcode project when things fail) are ignored, the config.h files are often modified on the fly afterwards and then Xcode build things as it sees fit (with a few pointers and a bit of help from us). In a similar way to Visual Studio all the source files need to be added to the Xcode project as we don't use the Configure generated Makefiles and so any files added or removed from the project (or any of the used libraries) causes a build failure. It's a little bit fragile truth be told. One of the biggest problems is building universal binaries (binaries that run on both Intel and PPC platforms). Intel is little endian but PPC is big. The preprocessor defines macros for whether it's in Intel or PPC mode but most of the configure scripts for the used libraries do not support universal builds so we have to modify their output after they've finished. The latest version of Xcode (4.x) doesn't support PPC or any version of the OS pre 10.5 (I think, might even be 10.6) (PPC was last supported on 10.5 and Intel first appeared on 10.4) so we're stuck with using Xcode 3.x which from memory doesn't work on Lion or Mountain Lion (or at least doesn't support PPC on those platforms without a *lot* of hand waving). I hope this helps. Any other questions then please do ask. Paul. > > On 14/01/2013 18:50, Paul Livesey wrote: >> I've made some changes to the Xcode project file, I hope that they're correct. >> >> The default now is to build with libsoxr as the only resampling library. There are two other targets defined, one of which uses libsamplerate only and the other libresample. >> >> Is this the expected build configuration or should a mixture of the libraries be possible? >> >> As far as I can tell the default build (which is what the nightlys are) seems to work. I can only natively test on Intel at the moment so while the PPC build gives every impression of working I cannot personally test it. >> >> Kindest Regards, >> >> Paul. >> |
From: Vaughan J. <va...@au...> - 2013-01-16 00:46:41
|
Thanks, Paul. The important thing for 2.0.3 is, I think, will there be any impact on the Mac release (candidates) if we don't release tarballs this time around? - Vaughan On 1/15/2013 5:30 AM, Paul Livesey wrote: > On 15 Jan 2013, at 01:38, Martyn Shaw wrote: > >> Hi Paul >> >> Out of interest (and I'm mostly Win-only), how dependent is the Mac >> build on the various linux build process stuff? That is, on 'config' >> and all those *nix things that I do not understand. Is the x-code >> stuff independent of that? >> >> Thanks >> Martyn > > Hi Martyn, > > The Xcode project is a bit of a halfway house or worst of all worlds type affair! It is ofttimes not for the faint of heart, especially if you're trying to support a variety of OSX platforms. > > The configure scripts are required and are used to generate config.h, Makefiles and sometimes other things. The Makefiles (which are useful in setting up the Xcode project when things fail) are ignored, the config.h files are often modified on the fly afterwards and then Xcode build things as it sees fit (with a few pointers and a bit of help from us). > > In a similar way to Visual Studio all the source files need to be added to the Xcode project as we don't use the Configure generated Makefiles and so any files added or removed from the project (or any of the used libraries) causes a build failure. It's a little bit fragile truth be told. > > One of the biggest problems is building universal binaries (binaries that run on both Intel and PPC platforms). Intel is little endian but PPC is big. The preprocessor defines macros for whether it's in Intel or PPC mode but most of the configure scripts for the used libraries do not support universal builds so we have to modify their output after they've finished. The latest version of Xcode (4.x) doesn't support PPC or any version of the OS pre 10.5 (I think, might even be 10.6) (PPC was last supported on 10.5 and Intel first appeared on 10.4) so we're stuck with using Xcode 3.x which from memory doesn't work on Lion or Mountain Lion (or at least doesn't support PPC on those platforms without a *lot* of hand waving). > > I hope this helps. Any other questions then please do ask. > > Paul. > > >> >> On 14/01/2013 18:50, Paul Livesey wrote: >>> I've made some changes to the Xcode project file, I hope that they're correct. >>> >>> The default now is to build with libsoxr as the only resampling library. There are two other targets defined, one of which uses libsamplerate only and the other libresample. >>> >>> Is this the expected build configuration or should a mixture of the libraries be possible? >>> >>> As far as I can tell the default build (which is what the nightlys are) seems to work. I can only natively test on Intel at the moment so while the PPC build gives every impression of working I cannot personally test it. >>> >>> Kindest Regards, >>> >>> Paul. >>> > |
From: Martyn S. <mar...@gm...> - 2013-01-16 01:44:52
|
Thanks Paul! That is very informative! I don't have a Mac, but if I did it would be difficult for me to become a devel, I feel. On 16/01/2013 00:46, Vaughan Johnson wrote: > Thanks, Paul. The important thing for 2.0.3 is, I think, will there be > any impact on the Mac release (candidates) if we don't release tarballs > this time around? That really is a good question, but may not be exactly the right question. A better question may be 'would there be an impact on the Mac release if all the Linux stuff ('automake' etc.) wasn't up-to-date?'. > - Vaughan > > > On 1/15/2013 5:30 AM, Paul Livesey wrote: >> On 15 Jan 2013, at 01:38, Martyn Shaw wrote: >> >>> Hi Paul >>> >>> Out of interest (and I'm mostly Win-only), how dependent is the Mac >>> build on the various linux build process stuff? That is, on 'config' >>> and all those *nix things that I do not understand. Is the x-code >>> stuff independent of that? >>> >>> Thanks >>> Martyn >> >> Hi Martyn, >> >> The Xcode project is a bit of a halfway house or worst of all worlds type affair! It is ofttimes not for the faint of heart, especially if you're trying to support a variety of OSX platforms. That sounds like a nightmare! Why do we do it like that? >> The configure scripts are required Do they just stay the same, mostly? and are used to generate config.h, Makefiles and sometimes other things. The Makefiles (which are useful in setting up the Xcode project when things fail) are ignored, the config.h files are often modified on the fly afterwards and then Xcode build things as it sees fit (with a few pointers and a bit of help from us). >> >> In a similar way to Visual Studio all the source files need to be added to the Xcode project as we don't use the Configure generated Makefiles and so any files added or removed from the project (or any of the used libraries) causes a build failure. It's a little bit fragile truth be told. And many thanks for keeping it up to date! >> One of the biggest problems is building universal binaries (binaries that run on both Intel and PPC platforms). Intel is little endian but PPC is big. The preprocessor defines macros for whether it's in Intel or PPC mode but most of the configure scripts for the used libraries do not support universal builds so we have to modify their output after they've finished. The latest version of Xcode (4.x) doesn't support PPC or any version of the OS pre 10.5 (I think, might even be 10.6) (PPC was last supported on 10.5 and Intel first appeared on 10.4) so we're stuck with using Xcode 3.x which from memory doesn't work on Lion or Mountain Lion (or at least doesn't support PPC on those platforms without a *lot* of hand waving). I hear you, and sympathise. It sounds like a complete pain! I assume that the problems are in supporting older versions of OS, but how old are they and is it really worth the bother? Would it be better to ditch the older versions and have more people who could compile for later/current versions of the OS, using the later OS? I think that means dropping support for PPC (and you have to appreciate that I don't know what that means). We have to drop older / less supported versions of operating systems as time goes by, as we have dropped 98/ME support after 2.0.0 (long overdue). http://en.wikipedia.org/wiki/OS_X#Version_10.6:_.22Snow_Leopard.22 has it that they dropped support for PPC in 2009. So why are we there? Could we move into the new decade and have a system that allows people to compile Audacity themselves on a modern machine, with no reference to PPC? What would that take? From what I understand, if I went out today and bought a new Mac I couldn't become an Audacity devel without downgrading my OS and investigating older versions of stuff. That does not seem like a position we should be in. How do we get out of that? I'm 'Mr. More Questions Than Answers' tonight, me! TTFN Martyn >> I hope this helps. Any other questions then please do ask. >> >> Paul. >> >> >>> >>> On 14/01/2013 18:50, Paul Livesey wrote: >>>> I've made some changes to the Xcode project file, I hope that they're correct. >>>> >>>> The default now is to build with libsoxr as the only resampling library. There are two other targets defined, one of which uses libsamplerate only and the other libresample. >>>> >>>> Is this the expected build configuration or should a mixture of the libraries be possible? >>>> >>>> As far as I can tell the default build (which is what the nightlys are) seems to work. I can only natively test on Intel at the moment so while the PPC build gives every impression of working I cannot personally test it. >>>> >>>> Kindest Regards, >>>> >>>> Paul. >>>> >> > > ------------------------------------------------------------------------------ > Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery > and much more. Keep your Java skills current with LearnJavaNow - > 200+ hours of step-by-step video tutorials by Java experts. > SALE $49.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122612 > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Vaughan J. <va...@au...> - 2013-01-16 06:08:23
|
> On 16/01/2013 00:46, Vaughan Johnson wrote: >> Thanks, Paul. The important thing for 2.0.3 is, I think, will there be >> any impact on the Mac release (candidates) if we don't release tarballs >> this time around? > > That really is a good question, but may not be exactly the right > question. A better question may be 'would there be an impact on the > Mac release if all the Linux stuff ('automake' etc.) wasn't up-to-date?'. Yes, thanks, better focus. Overall, I meant to ask, is 2.0.3 ready for Mac rc1 or not? - V |
From: Gale A. <ga...@au...> - 2013-01-16 07:56:39
|
| From Vaughan Johnson <va...@au...> | Tue, 15 Jan 2013 22:08:48 -0800 | Subject: [Audacity-devel] Mac Xcode project > Overall, I meant to ask, is 2.0.3 ready for Mac rc1 or not? I'll take a look sometime during the day. It would be great if Bill can do so too. I believe it's OK, I tested the addition of higher supported sample rates a while ago. The thing that has changed would be the move to libsoxr Time Track resampling. Gale |
From: Gale A. <ga...@au...> - 2013-01-16 19:02:57
|
| From Bill Wharrie <bi...@go...> | Wed, 16 Jan 2013 12:40:30 -0500 | Subject: [Audacity-devel] Mac rc1 for 2.0.3 [was: Mac Xcode project] > > On 16/01/2013, at 2:55 AM, Gale Andrews <ga...@au...> wrote: > > > > > | From Vaughan Johnson <va...@au...> > > | Tue, 15 Jan 2013 22:08:48 -0800 > > | Subject: [Audacity-devel] Mac Xcode project > >> Overall, I meant to ask, is 2.0.3 ready for Mac rc1 or not? > > > > I'll take a look sometime during the day. It would be great if > > Bill can do so too. > > > > I believe it's OK, I tested the addition of higher supported > > sample rates a while ago. The thing that has changed would > > be the move to libsoxr Time Track resampling. > > Computer is iMac 27" late 2012, 2.7 GHz quad-core i5 with 8 GB RAM. > > The Jan 16 nightly shows libsoxr as the only resampling library enabled. A quick test with a time track shows that it works. I have no way of objectively assessing the quality of the resampling. Playback is continuous with the default real-time resampler. Exporting a 38-minute stereo track to AIF takes 8 seconds if not time warped, and 30 seconds when warped and using the default highest-quality resampler. The AIF was copied into the project and the project quality was 32-bit float/44100. Many thanks for testing, Bill. > There's a quirk when using Tracks > Resample on a track with multiple clips. Not a blocker, just an observation. In the "Resample" dialog, the progress bar goes from zero to complete for each clip (so if the track has 6 clips, the progress bar will do its thing 6 times). The time remaining is meaningless. Also, for a stereo track, the Resample dialog shows "Resampling track 1" then "Resampling track 2" but I understand this is expected for stereo tracks. I believe that is covered here: http://bugzilla.audacityteam.org/show_bug.cgi?id=200 . > The project rate dropdown menus show up to 384000 Hz sampling rate. Recording my internal microphone at that rate works. According to Audio MIDI Setup my machine supports 96000 Hz sampling rates for the internal devices (microphone, line input and line output). Setting my internal mic and Audacity to 96000 and then recording at 96000 works. > > Any other tests needed? Can't think of anything offhand. I'll have a quick random test myself now but won't write again unless I find major issues. Gale |
From: Bill W. <bi...@go...> - 2013-01-16 20:28:26
|
On 16/01/2013, at 2:01 PM, Gale Andrews <ga...@au...> wrote: > > | From Bill Wharrie <bi...@go...> > | Wed, 16 Jan 2013 12:40:30 -0500 > | Subject: [Audacity-devel] Mac rc1 for 2.0.3 [was: Mac Xcode project] >> >> On 16/01/2013, at 2:55 AM, Gale Andrews <ga...@au...> wrote: >> >>> >>> | From Vaughan Johnson <va...@au...> >>> | Tue, 15 Jan 2013 22:08:48 -0800 >>> | Subject: [Audacity-devel] Mac Xcode project >>>> Overall, I meant to ask, is 2.0.3 ready for Mac rc1 or not? >>> >>> I'll take a look sometime during the day. It would be great if >>> Bill can do so too. >>> >>> I believe it's OK, I tested the addition of higher supported >>> sample rates a while ago. The thing that has changed would >>> be the move to libsoxr Time Track resampling. >> >> Computer is iMac 27" late 2012, 2.7 GHz quad-core i5 with 8 GB RAM. >> >> The Jan 16 nightly shows libsoxr as the only resampling library enabled. A quick test with a time track shows that it works. I have no way of objectively assessing the quality of the resampling. Playback is continuous with the default real-time resampler. Exporting a 38-minute stereo track to AIF takes 8 seconds if not time warped, and 30 seconds when warped and using the default highest-quality resampler. The AIF was copied into the project and the project quality was 32-bit float/44100. Just realized that the Quality Prefs settings have nothing to do with this. AFAICT there is meant to be a single var-rate resampler used for both real-time and export operations when using a Time Track. -- Bill > > Many thanks for testing, Bill. > > >> There's a quirk when using Tracks > Resample on a track with multiple clips. Not a blocker, just an observation. In the "Resample" dialog, the progress bar goes from zero to complete for each clip (so if the track has 6 clips, the progress bar will do its thing 6 times). The time remaining is meaningless. Also, for a stereo track, the Resample dialog shows "Resampling track 1" then "Resampling track 2" but I understand this is expected for stereo tracks. > > I believe that is covered here: > http://bugzilla.audacityteam.org/show_bug.cgi?id=200 . > > >> The project rate dropdown menus show up to 384000 Hz sampling rate. Recording my internal microphone at that rate works. According to Audio MIDI Setup my machine supports 96000 Hz sampling rates for the internal devices (microphone, line input and line output). Setting my internal mic and Audacity to 96000 and then recording at 96000 works. >> >> Any other tests needed? > > Can't think of anything offhand. I'll have a quick random test > myself now but won't write again unless I find major issues. > > > > > Gale > > > > ------------------------------------------------------------------------------ > Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery > and much more. Keep your Java skills current with LearnJavaNow - > 200+ hours of step-by-step video tutorials by Java experts. > SALE $49.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122612 > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Gale A. <ga...@au...> - 2013-01-16 22:52:10
|
| From Bill Wharrie <bi...@go...> | Wed, 16 Jan 2013 15:28:19 -0500 | Subject: [Audacity-devel] Mac rc1 for 2.0.3 [was: Mac Xcode project] > > On 16/01/2013, at 2:01 PM, Gale Andrews <ga...@au...> wrote: > > > > > | From Bill Wharrie <bi...@go...> > > | Wed, 16 Jan 2013 12:40:30 -0500 > > | Subject: [Audacity-devel] Mac rc1 for 2.0.3 [was: Mac Xcode project] > >> > >> On 16/01/2013, at 2:55 AM, Gale Andrews <ga...@au...> wrote: > >> > >>> > >>> | From Vaughan Johnson <va...@au...> > >>> | Tue, 15 Jan 2013 22:08:48 -0800 > >>> | Subject: [Audacity-devel] Mac Xcode project > >>>> Overall, I meant to ask, is 2.0.3 ready for Mac rc1 or not? > >>> > >>> I'll take a look sometime during the day. It would be great if > >>> Bill can do so too. > >>> > >>> I believe it's OK, I tested the addition of higher supported > >>> sample rates a while ago. The thing that has changed would > >>> be the move to libsoxr Time Track resampling. > >> > >> Computer is iMac 27" late 2012, 2.7 GHz quad-core i5 with 8 GB RAM. > >> > >> The Jan 16 nightly shows libsoxr as the only resampling library enabled. A quick test with a time track shows that it works. I have no way of objectively assessing the quality of the resampling. Playback is continuous with the default real-time resampler. Exporting a 38-minute stereo track to AIF takes 8 seconds if not time warped, and 30 seconds when warped and using the default highest-quality resampler. The AIF was copied into the project and the project quality was 32-bit float/44100. > > Just realized that the Quality Prefs settings have nothing to do with this. AFAICT there is meant to be a single var-rate resampler used for both real-time and export operations when using a Time Track. > > -- Bill At present only one resampling library can be enabled in a build. That library is libsoxr in releases and for a default self-compiled build on any platform. Whatever library is enabled, changing Prefs converter qualities does not affect var-rate resampling (as you say). Libsoxr var-rate uses a single, dedicated quality level for var-rate (so it's the same quality for playing or rendering Time Tracks). Hoping I've mastered all that, I cleared the Manual P1's about this, so please verify you're happy. I slightly fudged the "single" referred to above, given the other two resampling libraries use different var-rate qualities for playback and render, but I think it's clear enough. Gale |
From: Vaughan J. <va...@au...> - 2013-01-17 03:03:56
|
On 1/16/2013 2:51 PM, Gale Andrews wrote: > | From Bill Wharrie <bi...@go...> > | Wed, 16 Jan 2013 15:28:19 -0500 >> On 16/01/2013, at 2:01 PM, Gale Andrews <ga...@au...> wrote: >>> | From Bill Wharrie <bi...@go...> >>>> On 16/01/2013, at 2:55 AM, Gale Andrews <ga...@au...> wrote: >>>>> | From Vaughan Johnson <va...@au...> >>>>> | Tue, 15 Jan 2013 22:08:48 -0800 >[...] > At present only one resampling library can be enabled in a build. That > library is libsoxr in releases and for a default self-compiled build on > any platform. > > Whatever library is enabled, changing Prefs converter qualities > does not affect var-rate resampling (as you say). > > Libsoxr var-rate uses a single, dedicated quality level for var-rate > (so it's the same quality for playing or rendering Time Tracks). > > Hoping I've mastered all that, I cleared the Manual P1's about > this, so please verify you're happy. Looks right to me. Thanks, V |
From: Bill W. <bi...@go...> - 2013-01-16 17:40:39
|
On 16/01/2013, at 2:55 AM, Gale Andrews <ga...@au...> wrote: > > | From Vaughan Johnson <va...@au...> > | Tue, 15 Jan 2013 22:08:48 -0800 > | Subject: [Audacity-devel] Mac Xcode project >> Overall, I meant to ask, is 2.0.3 ready for Mac rc1 or not? > > I'll take a look sometime during the day. It would be great if > Bill can do so too. > > I believe it's OK, I tested the addition of higher supported > sample rates a while ago. The thing that has changed would > be the move to libsoxr Time Track resampling. Computer is iMac 27" late 2012, 2.7 GHz quad-core i5 with 8 GB RAM. The Jan 16 nightly shows libsoxr as the only resampling library enabled. A quick test with a time track shows that it works. I have no way of objectively assessing the quality of the resampling. Playback is continuous with the default real-time resampler. Exporting a 38-minute stereo track to AIF takes 8 seconds if not time warped, and 30 seconds when warped and using the default highest-quality resampler. The AIF was copied into the project and the project quality was 32-bit float/44100. There's a quirk when using Tracks > Resample on a track with multiple clips. Not a blocker, just an observation. In the "Resample" dialog, the progress bar goes from zero to complete for each clip (so if the track has 6 clips, the progress bar will do its thing 6 times). The time remaining is meaningless. Also, for a stereo track, the Resample dialog shows "Resampling track 1" then "Resampling track 2" but I understand this is expected for stereo tracks. The project rate dropdown menus show up to 384000 Hz sampling rate. Recording my internal microphone at that rate works. According to Audio MIDI Setup my machine supports 96000 Hz sampling rates for the internal devices (microphone, line input and line output). Setting my internal mic and Audacity to 96000 and then recording at 96000 works. Any other tests needed? -- Bill > > > > > Gale > > ------------------------------------------------------------------------------ > Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery > and much more. Keep your Java skills current with LearnJavaNow - > 200+ hours of step-by-step video tutorials by Java experts. > SALE $49.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122612 > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Vaughan J. <va...@au...> - 2013-01-17 03:01:18
|
On 1/16/2013 9:40 AM, Bill Wharrie wrote: > > On 16/01/2013, at 2:55 AM, Gale Andrews <ga...@au...> wrote: > >> >> | From Vaughan Johnson <va...@au...> >> | Tue, 15 Jan 2013 22:08:48 -0800 >> | [...] > > The Jan 16 nightly shows libsoxr as the only resampling library enabled. A quick test with a time track shows that it works. I [...] Thanks for testing. > > There's a quirk when using Tracks > Resample on a track with multiple clips. Not a blocker, just an observation. In the "Resample" dialog, the progress bar goes from zero to complete for each clip (so if the track has 6 clips, the progress bar will do its thing 6 times). The time remaining is meaningless. Also, for a stereo track, the Resample dialog shows "Resampling track 1" then "Resampling track 2" but I understand this is expected for stereo tracks. Wasn't that also true before libsoxr integration? > > [...] > > Any other tests needed? Thanks, Bill! - Vaughan |
From: Gale A. <ga...@au...> - 2013-01-17 10:00:36
|
| From Vaughan Johnson <va...@au...> | Wed, 16 Jan 2013 19:01:39 -0800 | Subject: [Audacity-devel] Mac rc1 for 2.0.3 [was: Mac Xcode project] > On 1/16/2013 9:40 AM, Bill Wharrie wrote: [...] > > There's a quirk when using Tracks > Resample on a track with multiple clips. Not a blocker, just an observation. In the "Resample" dialog, the progress bar goes from zero to complete for each clip (so if the track has 6 clips, the progress bar will do its thing 6 times). The time remaining is meaningless. Also, for a stereo track, the Resample dialog shows "Resampling track 1" then "Resampling track 2" but I understand this is expected for stereo tracks. > > Wasn't that also true before libsoxr integration? Yes. Nothing to do with libsoxr integration as far as I know. Gale |
From: Paul L. <pau...@bo...> - 2013-01-16 14:06:33
|
I'll try and answer as much as I can but I'm on a client site and away from anything that looks like a Mac. On 16 Jan 2013, at 01:44, Martyn Shaw <mar...@gm...> wrote: > Thanks Paul! That is very informative! I don't have a Mac, but if I > did it would be difficult for me to become a devel, I feel. > > On 16/01/2013 00:46, Vaughan Johnson wrote: >> Thanks, Paul. The important thing for 2.0.3 is, I think, will there be >> any impact on the Mac release (candidates) if we don't release tarballs >> this time around? > > That really is a good question, but may not be exactly the right > question. A better question may be 'would there be an impact on the > Mac release if all the Linux stuff ('automake' etc.) wasn't up-to-date?'. The configure scripts are needed for the Mac build so if things aren't up to date they need to be generated. By default Macs come with the automake tools but they're not necessarily that recent. Historically they've needed a little tweaking in system config files to get them working but I think that's no longer necessary. >> >> >> On 1/15/2013 5:30 AM, Paul Livesey wrote: >>> On 15 Jan 2013, at 01:38, Martyn Shaw wrote: >>> >>>> Hi Paul >>>> >>>> Out of interest (and I'm mostly Win-only), how dependent is the Mac >>>> build on the various linux build process stuff? That is, on 'config' >>>> and all those *nix things that I do not understand. Is the x-code >>>> stuff independent of that? >>>> >>>> Thanks >>>> Martyn >>> >>> Hi Martyn, >>> >>> The Xcode project is a bit of a halfway house or worst of all worlds type affair! It is ofttimes not for the faint of heart, especially if you're trying to support a variety of OSX platforms. > > That sounds like a nightmare! Why do we do it like that? Most of this comes from or is related to building universal binaries. There are a lot of very serviceable Macs out there with a PPC processor (running Tiger or Leopard) that would like to run Audacity. In an ideal world the build process would be the same as on Linux but many of the libraries don't natively support multiple architectures/cross compiling so we use Xcode to deal with it and the resulting mess. > >>> The configure scripts are required > > Do they just stay the same, mostly? Once generated we don't touch them but do modify the files they produce. > > and are used to generate config.h, Makefiles and sometimes other > things. The Makefiles (which are useful in setting up the Xcode > project when things fail) are ignored, the config.h files are often > modified on the fly afterwards and then Xcode build things as it sees > fit (with a few pointers and a bit of help from us). >>> >>> In a similar way to Visual Studio all the source files need to be added to the Xcode project as we don't use the Configure generated Makefiles and so any files added or removed from the project (or any of the used libraries) causes a build failure. It's a little bit fragile truth be told. > > And many thanks for keeping it up to date! A pleasure. > >>> One of the biggest problems is building universal binaries (binaries that run on both Intel and PPC platforms). Intel is little endian but PPC is big. The preprocessor defines macros for whether it's in Intel or PPC mode but most of the configure scripts for the used libraries do not support universal builds so we have to modify their output after they've finished. The latest version of Xcode (4.x) doesn't support PPC or any version of the OS pre 10.5 (I think, might even be 10.6) (PPC was last supported on 10.5 and Intel first appeared on 10.4) so we're stuck with using Xcode 3.x which from memory doesn't work on Lion or Mountain Lion (or at least doesn't support PPC on those platforms without a *lot* of hand waving). > > I hear you, and sympathise. It sounds like a complete pain! I assume > that the problems are in supporting older versions of OS, but how old > are they and is it really worth the bother? Would it be better to > ditch the older versions and have more people who could compile for > later/current versions of the OS, using the later OS? I think that > means dropping support for PPC (and you have to appreciate that I > don't know what that means). > Supporting older versions of the OS is not a problem, at least once wxMac is built (but that can be an entirely different world of pain). Currently everything back to Tiger is supported. The problem is supporting multiple architectures. We currently build a "fat" Audacity binary that contains PPC and x86 binaries. It's theoretically possible to add in x86_64 and PPC64 binaries as well but I'm not touching that can of worms. > We have to drop older / less supported versions of operating systems > as time goes by, as we have dropped 98/ME support after 2.0.0 (long > overdue). > > http://en.wikipedia.org/wiki/OS_X#Version_10.6:_.22Snow_Leopard.22 > has it that they dropped support for PPC in 2009. So why are we > there? Could we move into the new decade and have a system that > allows people to compile Audacity themselves on a modern machine, with > no reference to PPC? What would that take? To convert the project file to the latest version of Xcode, remove the PPC stuff and give it a general tidy up is probably a few hours work. However, there are a *lot* of PPC Macs out there. The alternative is to try and use the configure script to build everything. It's possible but nowhere near as nice from a development point of view where the Xcode IDE is very useful. > > From what I understand, if I went out today and bought a new Mac I > couldn't become an Audacity devel without downgrading my OS and > investigating older versions of stuff. That does not seem like a > position we should be in. How do we get out of that? > After a few pointers from Leland earlier in the week I see it's now relatively easy to trick Lion/Mountain Lion into installing Xcode 3. This is the last version of the compiler that can build for PPC. So with a brand new Mac you can install Xcode 3 with only a small wave of the hand and build everything. I haven't tested this but Leland thinks that it works. Certainly the x86 side of things does. The PPC side is on my list of things to test this weekend. Building wxMac correctly is still a trial though. It's tricky on Snow Leopard and I've no idea what Lion/Mountain Lion are like. I've posted a few tips on the forums as to what's required but still everybody gets it wrong as there's so much to go wrong! > I'm 'Mr. More Questions Than Answers' tonight, me! > Please, ask away. The more people who know about the intricacies of the Mac build system the better. At least then if a recurrence of the events of November 1st 2011 happen the building of Mac binaries can continue in my absence. Paul |
From: Martyn S. <mar...@gm...> - 2013-01-17 23:52:24
|
Thanks Paul, great explanation of why we need the universal binary and the consequences of the Linux build not being working. Please let us know the outcome of your Xcode 3 on Mountain Lion experiment - if successful it would be great to add it to http://wiki.audacityteam.org/wiki/Release_Process/Mac or similar so that it is preserved for all. TTFN Martyn On 16/01/2013 14:05, Paul Livesey wrote: > I'll try and answer as much as I can but I'm on a client site and away from anything that looks like a Mac. > > On 16 Jan 2013, at 01:44, Martyn Shaw <mar...@gm...> wrote: > >> Thanks Paul! That is very informative! I don't have a Mac, but if I >> did it would be difficult for me to become a devel, I feel. >> >> On 16/01/2013 00:46, Vaughan Johnson wrote: >>> Thanks, Paul. The important thing for 2.0.3 is, I think, will there be >>> any impact on the Mac release (candidates) if we don't release tarballs >>> this time around? >> >> That really is a good question, but may not be exactly the right >> question. A better question may be 'would there be an impact on the >> Mac release if all the Linux stuff ('automake' etc.) wasn't up-to-date?'. > > The configure scripts are needed for the Mac build so if things aren't up to date they need to be generated. By default Macs come with the automake tools but they're not necessarily that recent. Historically they've needed a little tweaking in system config files to get them working but I think that's no longer necessary. > >>> >>> >>> On 1/15/2013 5:30 AM, Paul Livesey wrote: >>>> On 15 Jan 2013, at 01:38, Martyn Shaw wrote: >>>> >>>>> Hi Paul >>>>> >>>>> Out of interest (and I'm mostly Win-only), how dependent is the Mac >>>>> build on the various linux build process stuff? That is, on 'config' >>>>> and all those *nix things that I do not understand. Is the x-code >>>>> stuff independent of that? >>>>> >>>>> Thanks >>>>> Martyn >>>> >>>> Hi Martyn, >>>> >>>> The Xcode project is a bit of a halfway house or worst of all worlds type affair! It is ofttimes not for the faint of heart, especially if you're trying to support a variety of OSX platforms. >> >> That sounds like a nightmare! Why do we do it like that? > > Most of this comes from or is related to building universal binaries. There are a lot of very serviceable Macs out there with a PPC processor (running Tiger or Leopard) that would like to run Audacity. In an ideal world the build process would be the same as on Linux but many of the libraries don't natively support multiple architectures/cross compiling so we use Xcode to deal with it and the resulting mess. > >> >>>> The configure scripts are required >> >> Do they just stay the same, mostly? > > Once generated we don't touch them but do modify the files they produce. > >> >> and are used to generate config.h, Makefiles and sometimes other >> things. The Makefiles (which are useful in setting up the Xcode >> project when things fail) are ignored, the config.h files are often >> modified on the fly afterwards and then Xcode build things as it sees >> fit (with a few pointers and a bit of help from us). >>>> >>>> In a similar way to Visual Studio all the source files need to be added to the Xcode project as we don't use the Configure generated Makefiles and so any files added or removed from the project (or any of the used libraries) causes a build failure. It's a little bit fragile truth be told. >> >> And many thanks for keeping it up to date! > > A pleasure. > >> >>>> One of the biggest problems is building universal binaries (binaries that run on both Intel and PPC platforms). Intel is little endian but PPC is big. The preprocessor defines macros for whether it's in Intel or PPC mode but most of the configure scripts for the used libraries do not support universal builds so we have to modify their output after they've finished. The latest version of Xcode (4.x) doesn't support PPC or any version of the OS pre 10.5 (I think, might even be 10.6) (PPC was last supported on 10.5 and Intel first appeared on 10.4) so we're stuck with using Xcode 3.x which from memory doesn't work on Lion or Mountain Lion (or at least doesn't support PPC on those platforms without a *lot* of hand waving). >> >> I hear you, and sympathise. It sounds like a complete pain! I assume >> that the problems are in supporting older versions of OS, but how old >> are they and is it really worth the bother? Would it be better to >> ditch the older versions and have more people who could compile for >> later/current versions of the OS, using the later OS? I think that >> means dropping support for PPC (and you have to appreciate that I >> don't know what that means). >> > > Supporting older versions of the OS is not a problem, at least once wxMac is built (but that can be an entirely different world of pain). Currently everything back to Tiger is supported. The problem is supporting multiple architectures. We currently build a "fat" Audacity binary that contains PPC and x86 binaries. It's theoretically possible to add in x86_64 and PPC64 binaries as well but I'm not touching that can of worms. > >> We have to drop older / less supported versions of operating systems >> as time goes by, as we have dropped 98/ME support after 2.0.0 (long >> overdue). >> >> http://en.wikipedia.org/wiki/OS_X#Version_10.6:_.22Snow_Leopard.22 >> has it that they dropped support for PPC in 2009. So why are we >> there? Could we move into the new decade and have a system that >> allows people to compile Audacity themselves on a modern machine, with >> no reference to PPC? What would that take? > > To convert the project file to the latest version of Xcode, remove the PPC stuff and give it a general tidy up is probably a few hours work. However, there are a *lot* of PPC Macs out there. The alternative is to try and use the configure script to build everything. It's possible but nowhere near as nice from a development point of view where the Xcode IDE is very useful. > >> >> From what I understand, if I went out today and bought a new Mac I >> couldn't become an Audacity devel without downgrading my OS and >> investigating older versions of stuff. That does not seem like a >> position we should be in. How do we get out of that? >> > > After a few pointers from Leland earlier in the week I see it's now relatively easy to trick Lion/Mountain Lion into installing Xcode 3. This is the last version of the compiler that can build for PPC. So with a brand new Mac you can install Xcode 3 with only a small wave of the hand and build everything. I haven't tested this but Leland thinks that it works. Certainly the x86 side of things does. The PPC side is on my list of things to test this weekend. > > Building wxMac correctly is still a trial though. It's tricky on Snow Leopard and I've no idea what Lion/Mountain Lion are like. I've posted a few tips on the forums as to what's required but still everybody gets it wrong as there's so much to go wrong! > >> I'm 'Mr. More Questions Than Answers' tonight, me! >> > Please, ask away. The more people who know about the intricacies of the Mac build system the better. At least then if a recurrence of the events of November 1st 2011 happen the building of Mac binaries can continue in my absence. > > Paul > ------------------------------------------------------------------------------ > Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery > and much more. Keep your Java skills current with LearnJavaNow - > 200+ hours of step-by-step video tutorials by Java experts. > SALE $49.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122612 > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Paul L. <pau...@bo...> - 2013-01-18 02:19:41
|
On 17 Jan 2013, at 23:52, Martyn Shaw wrote: > Thanks Paul, great explanation of why we need the universal binary and > the consequences of the Linux build not being working. > > Please let us know the outcome of your Xcode 3 on Mountain Lion > experiment - if successful it would be great to add it to > http://wiki.audacityteam.org/wiki/Release_Process/Mac or similar so > that it is preserved for all. > I broke out an old PPC mini this evening for some testing. The results so far are good. I have some changes to the Xcode project file to commit (with thanks to Leland) to fix resampling on PPC. Somehow I put in universal binary fixes for libsamplerate but forgot libsoxr. There's also a small fix for building on Lion/Mountain Lion. I tried running a signed binary on a PPC running Leopard and it worked fine. Xcode 3 installed nicely on my Lion box (I don't have anything running Mountain Lion at the moment), I'm still tweaking my wxMac build script but it built universal. After building and installing pkg-config and cmake, Audacity has also built universal on Lion and runs on a PPC box (including resampling). That's all for tonight but the practical upshot is that with very little hand waving Audacity can be built universal on Lion/Mountain Lion. Paul. |
From: Leland <le...@au...> - 2013-01-18 03:27:22
|
On 1/17/2013 8:18 PM, Paul Livesey wrote: > > That's all for tonight but the practical upshot is that with very little hand waving Audacity can be built universal on Lion/Mountain Lion. > I'm gonna do a wiki page that describes the steps to set it up. What's funny about that is that I've never done a wiki page. :-D Leland |
From: Vaughan J. <va...@au...> - 2013-01-18 09:13:56
|
Thanks, Paul. But please don't commit anything without discussion after code freeze has been announced. That's what the freeze means. No problem in this instance, I think, but it certainly can be. - Vaughan On 1/17/2013 6:18 PM, Paul Livesey wrote: > On 17 Jan 2013, at 23:52, Martyn Shaw wrote: > >> Thanks Paul, great explanation of why we need the universal binary and >> the consequences of the Linux build not being working. >> >> Please let us know the outcome of your Xcode 3 on Mountain Lion >> experiment - if successful it would be great to add it to >> http://wiki.audacityteam.org/wiki/Release_Process/Mac or similar so >> that it is preserved for all. >> > > I broke out an old PPC mini this evening for some testing. The results so far are good. > > I have some changes to the Xcode project file to commit (with thanks to Leland) to fix resampling on PPC. Somehow I put in universal binary fixes for libsamplerate but forgot libsoxr. There's also a small fix for building on Lion/Mountain Lion. > > I tried running a signed binary on a PPC running Leopard and it worked fine. > > Xcode 3 installed nicely on my Lion box (I don't have anything running Mountain Lion at the moment), I'm still tweaking my wxMac build script but it built universal. After building and installing pkg-config and cmake, Audacity has also built universal on Lion and runs on a PPC box (including resampling). > > That's all for tonight but the practical upshot is that with very little hand waving Audacity can be built universal on Lion/Mountain Lion. > > Paul. > |
From: Paul L. <pau...@bo...> - 2013-01-18 10:30:45
|
Sent from my iPad On 18 Jan 2013, at 09:14, Vaughan Johnson <va...@au...> wrote: > Thanks, Paul. But please don't commit anything without discussion after > code freeze has been announced. That's what the freeze means. No problem > in this instance, I think, but it certainly can be. Sorry about that. Last thing I saw on list was that the code freeze had been temporarily postponed. I knew it was on the way but thought I could get the PPC crash fix in for before it started. Paul. |
From: Vaughan J. <va...@au...> - 2013-01-18 20:57:53
|
On 1/18/2013 2:29 AM, Paul Livesey wrote: > > On 18 Jan 2013, at 09:14, Vaughan Johnson <va...@au...> wrote: > >> Thanks, Paul. But please don't commit anything without discussion after >> code freeze has been announced. That's what the freeze means. No problem >> in this instance, I think, but it certainly can be. > > Sorry about that. Last thing I saw on list was that the code freeze had been temporarily postponed. I knew it was on the way but thought I could get the PPC crash fix in for before it started. Good effort, and I don't think it's any problem this time. I announced "2.0.3 code/string freeze is ON!" at about 00:30 GMT, and your commit was a couple hours after that, so you may just not have received the announcement in time. Thanks, Vaughan |
From: Rob S. <aq...@ya...> - 2013-01-18 21:13:54
|
----- Original Message ----- > From: Vaughan Johnson <va...@au...> > I announced "2.0.3 code/string freeze is ON!" at about 00:30 GMT, and > your commit was a couple hours after that, so you may just not have > received the announcement in time. For the future, a 'stability' branch could be created on which to finalize the release. This would mean that folk would have to make a concious effort to commit to it, and also that commits for the following release could carry on uninterrupted. Any fixes made on the stability branch are usually merged back to trunk when the work on the branch ends. Just an idea :) Cheers, Rob |
From: Vaughan J. <va...@au...> - 2013-01-20 04:21:11
|
On 1/18/2013 1:13 PM, Rob Sykes wrote: >> From: Vaughan Johnson <va...@au...> >> I announced "2.0.3 code/string freeze is ON!" at about 00:30 GMT, and >> your commit was a couple hours after that, so you may just not have >> received the announcement in time. > > > For the future, a 'stability' branch could be created on which to finalize the release. This would mean that folk would have to make a concious effort to commit to it, and also that commits for the following release could carry on uninterrupted. Any fixes made on the stability branch are usually merged back to trunk when the work on the branch ends. Just an idea :) > Thanks, Rob. Rather avoid the effort. We've rarely had this much trouble observing the freeze (vs delays from last-minute-discovered issues), so I'd rather avoid the extra effort. - V |
From: Leland <le...@au...> - 2013-01-19 12:08:51
|
On 1/17/2013 9:27 PM, Leland wrote: > On 1/17/2013 8:18 PM, Paul Livesey wrote: >> >> That's all for tonight but the practical upshot is that with very little hand waving Audacity can be built universal on Lion/Mountain Lion. >> > I'm gonna do a wiki page that describes the steps to set it up. What's > funny about that is that I've never done a wiki page. :-D > My first attempt at a wiki page from scratch: http://wiki.audacityteam.org/wiki/Building_On_Mac I believe I'll need to scale the images, but I can't be a good judge of that since my display and font sizes are configured for my bad eyeball. And I have some spacing issues, but it's bed time... Leland |