Ok, that’s interesting. I’m getting a better picture of what’s going on with Audacity now.
In answer to one of the questions below… 16GB Mac mini 6.2 - 2012, Intel Core i7,2.3 GHz, Memory:16 GB. El-Capitan OSX 10.11.3 2TB Xcode 7.2.1 2TB: Drive 0:HGST HTS721010A9E630. Upper bay. Drive 1:ST1000LM024 HN-M101MBB. Lower Bay I have Memory Cleaner, but it’s stopped working for some reason and I haven’t had time to chase it up. Robert > On 27 Feb 2016, at 13:42, René J.V. Bertin <[email protected]> wrote: > > On Saturday February 27 2016 12:53:37 Robert Chalmers wrote: >> I don’t mean to mis-lead anyone. The issues I”m talking about are part of >> Audacity 2.1.2. Things like not being able to drag-highlight-scroll right in >> editing a track, and drag+highlight-dcroll left+edit only works sometimes. > > You mean they also exist in the official build that can be downloaded from > the Audacity homepage? > > I think the team is aware of a certain number of issues, many of which may be > side-effects of the significant number of changes they had to make to update > to wxWidgets 3. The fact that 2.1.1 works for you suggests that the issues > you're seeing are indeed related to that update. > But from what I understand there is also an issue with memory management > which means they use temporary files for about everything not involving > nyquist (FFT) filters (which in itself removes some of the benefits of > running 64 bits). > >> There also appears to be something about it that interferes with other >> running apps, in this case, iBooks running at the same time over the course >> of about half an hour gets slower and slower to scroll, untill it gives up >> all together and becomes unusable. If I close down Audacity 2.1.2, and close >> iBooks, then open iBooks again. It starts working as it should. Start up >> 2.1.2, and after half an hour there abouts - it caries - back comes the >> problem with iBooks. > > How much RAM do you have in your system? There's something called Memory > Cleaner in the App Store that can run automatic or regular attempts to > retrieve unused memory. > Either way it sounds like issues you should be reporting upstream. > >> So, I’m not talking about the macports build of Audacity - the current port >> installed fine, and lives in the macports folder in Applications, although >> it does read the cfg file in the “default” location of course. Which doesn’t >> seem to trouble it. > > Of course, it's supposed to behave just like official builds, apart from the > fact that it's more tied to the install location and of course is built in a > different way. > >> While I’m thinking of it - does the port install session create a log file >> anywhere of what it does when “port installing” - I’d like to see what’s >> happening. I am probably wrong, but I don’t remember it actualy compiling >> and building the Audacity part. All the rest, but that last bit just flicked >> by too quickly… > > You'd have noticed a build from source unless you have a really fast machine > or asked for a non-default variant. So you probably got a binary build, which > you can see as unpacking a tarball into /opt/local . To see what that > installed you can do `port contents audacity`. > To see what happens during the build, you can simply do `[sudo] port -v > destroot audacity` (sudo is optional here). That will fetch and patch the > sources, run configure, build, and then do a shadow install into `port work > audacity`/destroot. A logfile is created that shows even more than what > appears on the terminal during a verbose build; you can get the filename via > `port logfile audacity`. > >> So the reason/motivation is to “make it work” and remove that pesky hard >> coding so that updates to XCode and SDKs can be more easily followed and >> checked in the actual project. > > Remember that Xcode isn't really designed to support software with lots of > non-system dependencies and a build system based on autoconf. You're > basically limited to creating custom, shell-script based targets in an Xcode > project if you need to be able to build 3rd party libraries like Audacity > does. > > Your best bet might actually be to create a cmake-based build system. From > what I remember there has already been some work done on that. Cmake can > create Xcode projects, and that feature has been improved considerably in > recent versions. > >> Whick is one thing XCode is good for, Sou can see where everything is at a >> glance pretty much. > > Any self-respecting IDE can do the same, sometimes even from a Makefile.am . > I'd have had a much harder time first adapting Audacity 2.1.x to wxGTK on > Mac, and then 2.1.2 to 64 bits if I had not been able to open the full > project in KDevelop. > >> Does anyone know exactly what the calls are that require the 10.6 SDK? >> Shouldn’t it then just be a mission to update that code to the new SDK? > > Exactly, no, but you can take stock of this by studying my patches to see > what OS X-specific code is removed or put in conditional blocks. The Audacity > team made a pretty good start making the code build against either legacy > APIs or against modern ones so I didn't have to do much. At least not much > more than what I had already done. > Evidently QuickTime support is part of what gets lost when you drop 10.6 > support. Sadly that is just something one has to live with. > > R. Robert Chalmers [email protected] <mailto:[email protected]>.au Quantum Radio: http://tinyurl.com/lwwddov Mac mini 6.2 - 2012, Intel Core i7,2.3 GHz, Memory:16 GB. El-Capitan 10.11. XCode 7.2.1 2TB: Drive 0:HGST HTS721010A9E630. Upper bay. Drive 1:ST1000LM024 HN-M101MBB. Lower Bay
_______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
