I love seeing software that still has a 'Screenshots' section of their website. It's looked the same for as long as I've been using computers to record audio, starting with my high school band's demo over 15 years ago.

I could probably make fun of Audacity for not keeping up with the times, but if you look at other DAWs you'll see none are exactly bastions of good interface design. I got a little more serious about my music last year and decided I wanted to invest in a nice DAW, but after demoing I few I felt completely unimpressed. They're nearly identical to how they were 15 years ago, other than my PC being much more powerful.

I ended up just sticking with Reaper, and hoping something comes along someday to mix the industry up. Proprietary dongles and tiered versions of the exact same software with gimped features doesn't cut it for me. but if you look at other DAWs you'll see none are exactly bastions of good interface design What? Modern 'good interface design' (at least by HN standards) has almost nothing to say about complicated 1000+ feature apps. (In fact every time I rant that modern design sucks and that apps need more features the first response I usually get back is, 'but that's so much more testing! Do you know how many execution paths we'd have to manage???'

The parameter maps the mapped volumes from the source container to the container being launched. The /data directory only exists within our Redis container, however, because of -volumes-from our Ubuntu container can access the data. In this case, we're mapping our Redis container's volume to an Ubuntu container. An alternate approach is to use -volumes-from.

Well, that is kind of the point) Have you ever produced music with any of these tools? For one, their goals are different - FLStudio, for example, tries to be 'the fastest path from your brain to your speakers', and the interface seems as such and is loved for it.

Ableton intentionally crams everything into one screen because it is used as a performance tool - if you've seen any recent photos of Daft Punk et al performing, you'll see it running right there on a laptop, usually above the mixer or the CDJs. Cubase has kept an interface very similar to its original Atari 2600 (I think?) version, because people have been using that app for 30+ years now. Any time I see new-school UI designers' take on audio apps I cannot help but cringe. They are completely misunderstanding and underestimating their audience - audio is complicated and we need complex tools to do what we do.

I won a copy of Deluxe Music for Amiga in a music competition when I was a kid; I'd made the winning track in MED or OctaMED, and kept using MED/OctaMED even after winning Deluxe Music. I found Deluxe Music cartoonish and not capable of doing what I wanted. I dismissed it almost immediately. It felt like wearing gloves to compose after coming from trackers, where you had tick-precision (this was sort of a weird combination of interrupts and the BPM of your song, I don't remember the details now) control over everything like volume, pitch, arpeggiation, the Paula filter, etc. I think it's worth noting that Deluxe Music is distinctly not what modern DAWs look like, while Cubase kinda sorta is. Deluxe Music brought traditional music notation into the computer, which was great for folks who were comfortable with it, but you lose a lot of control and information visibility when you do that. And, of course, it requires your user to have some sort of formal music education.

There are still tools that'll work with traditional music notation, but very few people use them for composition. There's millions of copies of DAWs using a Cubase-ish sequencer-style interface in use every day. Seconding this.

Renoise is amazing. And extremely affordable compared to other DAWs. I originally picked it because its demo version doesn't have any of the more extreme limitations that make it very hard to actually create something. Only WAV export is disabled, which is fairly easy to work around if you must. Buying the license is totally worth it though, because it's cheap and you get the ability to easily records part of a track to another sample/instrument, which is a great workflow.

Being somewhat familiar with trackers was also a nice bonus, of course. Logic Audio (I started at v5) remains the most complex UI I have ever had to learn. It makes perfect sense to me now, but I long thought it was designed by sadists. I just did t understand the why of it. Any time I see new-school UI designers' take on audio apps I cannot help but cringe. They are completely misunderstanding and underestimating their audience - audio is complicated and we need complex tools to do what we do. Also worth mentioning is that many of these tools borrow elements from physical recording studios.

If you haven’t worked in a professionally wired studio, some of the abstractions seem dated and unnecessary. Replacing / reimagining them is not practical, as DAWs still need to run in these environments.

But try explaining that to someone who is just starting out chopping loops in their bedroom. I fully agree with the above. There's a truckload going on in all these interfaces. The thing people don't like here, which is absolutely true, is that if you want to use FLStudio, or Ableton, or even Cubase, and think you're going to succeed just by opening up the app and clicking around, you're wrong. You actually do need to use the tutorials and read the manual. (It's exactly the same if you buy any kind of complex pro audio hardware as well, from synths to guitar modelling tools like the Kemper Profiler.) In my experience the documentation for FLStudio and Live is great. Full on, stellar fantastic.

And there are a million quick tutorials from all kinds of people on YouTube to help. You just have to be willing to learn and invest the time to get the results you want. These things are not intended to be the audio equivalent of Instagram: for that you should look elsewhere (I'm not sure where actually). Assuming that comment isn't simply trolling.

GarageBand is certainly powerful, especially given it's deliberate limitation, and both myself and friends have used it to great effect, but Ableton Live it is not. If you look at Logic - which GarageBand is really a cut down version of - you see a similar degree of complexity to that in other professional level DAWs. Not everyone needs a professional level DAW, and even those who do wouldn't necessarily use one all the time: as I've said, I still use Audacity, and GarageBand on the iPad or iPhone is a super-handy tool.

The parent was commenting on people who ridiculously bleat on about the the UX of complex professional level audio tools, not suggesting there isn't a place for tools that are simpler. Huh, I could not disagree more. DAWs are some of the most well thought out, reliable software I use. For a relatively niche product it’s amazing to me that there are something like 10 very different but very high quality options to choose from. And they have changed a lot in 15 years. Not that long ago you pretty much had to use hardware synths and samplers to create electronic music and DAWs were just used for recording or mixing tracks.

Today you can create full tracks with just the included synths and samples, then you can play a live show straight from the same session, and there are tons of built in effects to get a great sounding mix. Plus details in the UI, routing tracks, editing audio and midi, beat detection of samples, etc are always improving with each release. I will grant you, a lot of the top companies (pro tools, logic, Cubase, ableton) were around in a similar form 15 years ago and some 25+ years ago, but that’s not totally crazy given how complex the software is. As for something new coming along to mix it up, I’m curious what type of changes would meet that criteria?

I’d say Ableton and more recently Bitwig (and I’m sure the argument could be made for many others that I’m less familiar with) have both done that. I got a little more serious about my music last year and decided I wanted to invest in a nice DAW, but after demoing I few I felt completely unimpressed.

They're nearly identical to how they were 15 years ago, other than my PC being much more powerful. That's not even remotely true.

Except if you mean 'they superficially look similar to what they did 15 years ago'. That's because their fundamental functions are of course still the same as 15 or 20 years ago: sequencing MIDI and audio. Same with NLE, what did you expect, some thought-to-song interface?

Building a solid design culture is extremely hard - in my experience having worked professionally as a designer and engineer, much more so than a solid engineering culture (which is already insanely hard). There’s a reason only a handful of organizations in the world succeed at both. I spent time volunteering for Gnome many years ago (2.x days), and it was extremely hard there, even though it had a reputation for being one of the most designer friendly open source projects.

It was a struggle to push for design considerations with obvious benefits such as accessibility - let alone anything remotely resembling aesthetics. The issue with open source is that ultimately, the project maintainers tend to be programmers with programmers’ priorities and views on design. Good design requires consistent, thoughtful sacrifice and compromise, and someone at the top to enforce it. If the open source UI squad makes recommendations that the Gimp maintainers choose to ignore, then what?

I did some free UI design for a game I found on the Pygame site a while back. At the time I was gainfully employed as a graphic designer, UI designer, and illustrator.

The artwork was gratefully received and I had a fun time working with the software developer. Here's what I think made it go well: - High visibility: The game was featured in the website sidebar. So I thought it'd be neat to contribute. Easy as HTML: Extract game zip file, edit Python files in a text editor, plug in my own filenames instead of the default ones. Start game, see my graphics. Developer was very open and friendly.

Just an IT guy with a hobby. I knew about the Pygame website already because I followed FOSS stuff. I don't know how many UI designers are browsing sites like that, but my guess is not many.

But imagine if they did: what are the chances their workflow would be as easy as it was for me? In a compiled language, forget it. I remember a few years back when suddenly it seemed like everything was on GitHub. My UI designer peers hated this and many still do. So it's far from inviting in many ways for a UI person, though I don't mean to suggest they couldn't hack it if they wanted to. They would show up wanting to find a download, and GutHub's UI was not set up like a typical private software website with a big 'Download' button or menu item.

It was off to the side, and I believe it said 'Clone or Download', and these people are thinking, 'is this some insider speak-am I at the right site?' And if you were just downloading, pretty soon you got told that you were ripping yourself off because downloading was so '80s, just clone the repo. Anyway you get the idea. All of a sudden tons of helpful UI resources were intermeshed with this GitHub ecosphere instead of living elsewhere, like on a lovingly-designed personal website with a pleasant UI that had not been mingled with versioning software. Well, most design people also have side projects, be it a Tumblr page or an endless supply of drawings that they just do to improve their drawing skills. But that's different from helping an (OSS) application look good.

For that, you have to make tons of mockups, iterate again and again, until you have something that looks good and consistent across the entire application. Ideally, you'd also want at least one other person to bounce ideas back and forth, and have an opinion about what you're doing. This is real work, which requires a lot of commitment upfront.

The equivalent of requiring a programmer to lay out the entire architecture before they write a single line of code. That's also something that mainly happens in a corporate environment, whereas for hobby projects it tends to lead to frustration. I agree this is a big job. Overhauling an existing application means a ton of work for both the designer and the developer. However the primary goal of designers should be making users work effectively. Building something that also looks good is a secondary goal.

Great designers achieve both goals. If skills or budget are not great, go for the primary. In the case of Audacity, I remember that I have to google how to silence a selection every time I get back to it after a break of several months. I guess this means that the primary goal is somewhat missed.

I used it semi-professionally (I was a paid DJ, but not as my primary source of income) for a couple years. 2.0 brings it very comfortably into competition with the best proprietary software, IMHO.

That's when it got timecoded vinyl support, good pitch shifting, and better beat-matching. Pros are probably still mostly using Serato or Traktor, but I don't think it's necessary. I used Traktor for a while but like Mixxx better. It's very good software. It had a lot of shortcomings in the 1.x releases, including stability issues, but I would definitely trust it for pro work today. Compared to digital vinyl with Serato, I found Mixx to be laggy (and more importantly, lacking of a dedicated next/previous track keys) with a low-end Pioneer DDJ SB. Track controls are replaced with a 'hot cue' function, which makes beatmatching without cuepoints unnecessarily cumbersome.

Don't recall if the UI had a dedicated next/prev track button but remapping the control scheme meant diving into some javascript datastructure that I wasn't in the right mindset to do at the time. Really wanted to like Mixxx but I could not see how I could perform with it. Ah, gotcha - I had been imagining you meant prev/next with respect to a playlist. I think you can do that in Mixxx using the 'cue' button. While playing, tapping 'cue' will rewind to the beginning of the track and pause; pressing 'cue' and holding it down will preview from the beginning. While previewing, you can press 'play' before releasing 'cue' in order to continue playing; otherwise, releasing 'cue' will rewind to the beginning and pause. So, you'd use a similar workflow: play from the beginning of the track and tweak until beatmatched, then press and hold 'cue' to rewind to the beginning and start playing from the first beat.

If it works, press 'play', release 'cue', and bring up the fader; if it didn't work, just release 'cue' to rewind, then try again. It's not hard to find others with problems. Look at the McElroy podcast archive: they alone lost numerous episodes because Audacity just didn't record any audio. My podcasting friends have ended up with corrupt Audacity save files (sometimes after a crash, sometimes just because), requiring a painful recovery process involving stitching together hundreds of scratch files. If it were just me, I'd agree with you.

But it's so common that I don't consider it a viable way to edit audio. Edit: in thinking about it, one of the friends I record with often actually records with both Audacity and another app, just because Audacity fails so often. That's a thought! I think that Reaper is the one to beat these days though, is there an essay or review of Sound Forge which would capture (comprehensively) what is to love about it? It'd be nice to decouple the UI from all the major open source sequencer and audio software, just leave some sort of pure data + Core Audio style innards and reconnect the UIs on top. I've taken a few cracks at this in private, but embarrassingly have a hard time getting much done on this particular project without anyone watching. I am not at home with my audio software but, off the top of my head, zooming and navigating a waveform in Sound Forge is SUPER efficient and intuitive, as mouse-wheel zooms and middle-click scrolls, and click-drag to edit individual samples.

You can quickly zoom into your work at a level of individual samples and them zoom out and see the whole waveform in only a few movements. My other favorite features are how editing doesn't rely on 'modes' like Audacity (I hate having to hit a button before I make a selection then another to do something else), and Sound Forge's selection logic itself: - the playback cursor will intelligently snap and loop on your selections (or not, depending on how you set the toggle), -the editing scrolls to follow your cursor as you are zoomed in, but not if you're currently editing something.

A lot of programs do this but I find their logic is terrible and I have to control automatic scrolling myself. This is very helpful for working on seamlessly looping material, as you can leave playback on loop and continue working at the very end of your selection without the UI losing your place - load and save in native formats without having to use some proprietary intermediary format (AUP). Whilst Ableton Live has long been my DAW of choice I've been using Audacity since around 2004 and still use it today. Mostly it's quick edits on game sound effects: changing sample rate, bit rate, topping and tailing, fading, exporting MP3s. When I master tracks in Ableton I also still use Audacity to export an MP3 version (that's probably just force of habit though - I imagine there's a better way of doing that these days). I realise I could automate the MP3 export from the command line but it's infrequent enough that using Audacity to do it, edit the tags, and suchlike is probably the easiest option. Live is a great DAW, and I really enjoyed FLStudio back when I used to run Windows at home, but for quickly hacking around with raw audio it's pretty hard to beat Audacity.

Great software, and good to see it still under active development. Well, for starters, the SHA256 signatures are on both the Audacity website and its FossHub page. You can check if both places match, which makes it less likely to be from an untrusted source. They even have a page explaining how to check the signature. If you're on macOS, before mounting a disk image the system will verify its checksum. Additionally, the default security settings only allows applications from the app store and identified developers. You can use the codesign tool (codesign -dv -verbose /Applications/Audacity.app) to verify the code signature as well as display the signing identity.

In this case, it's signed by Paul Licameli, which is the author of this blog post. With that said, it's not foolproof, as the TeamIdentifier is not publicly posted anywhere, someone could possibly create a Developer ID with his name.

I don't think anyone used Windows Sound Recorder for anything serious. It had a built in maximum record length for starters (I think to prevent piracy?). Sound Forge was my preferred editor for years before Audacity matured. Cool Edit was ok, but I seem to recall it had a bizarrely over-designed UI that made the thing feel more like a toy than a serious tool. Particularly when compared to the much older and more feature rich (at that time) Sound Forge.

It took a while before Cool Edit really became competitive and by that point I was already using Audacity. I do still miss some features of Sound Forge even now. Though I don't tend to do too much with audio editors these days compared to the stuff I was doing in the 90s and 00s. When I need 10s of tracks (multiple drum mics, bass, guitars, keyboards, vocal mics, effects, etc.), I prefer to use Cakewalk Sonar. I've also heard good things about Reaper which is pretty inexpensive.

I often end up using Audacity when I'm working on only one or very few tracks (e.g., a video voice over). It works quite nicely for basic edits, trimming, normalizing, etc. Without as much clutter (tempo, time signatures, measures, etc.) as some of the more music-oriented packages. With the addition of MIDI tracks, it sounds like Audacity is moving more in that direction but we'll see.

It's not that. MIDI!= PCM or any kind of audio data really Midi looks like (imagine someone playing two notes: a C then a D): C4 127 On C4 127 Off D4 127 On D4 127 Off (not literally, but that is the essence of MIDI) MIDI support means synthesizer support, which means VST support, which means now you need some sort of MIDI data editor, which means now you've got to work out all the weird timing shit with MIDI, and by this point you are better off with LMMS or FLStudio or Pro Tools or what-have-you.

Use the tool most fit for purpose.

On 30 Apr 2008, at 22:13, Richard Ash wrote: On Tue, 2008-04-29 at 19:11 +0100, Paul Livesey wrote: I can't get Twolame to build from the command line at all using the configure script. It's really just unhappy. Any chance of a more detailed description? We updated to the most recent libtwolame release because it included the patches need to build the previous release on OS X, so I've no idea what is wrong.

Next time I try a command line, configure build I'll record all the problems. For now, xcodebuild appears to work flawlessly.

I seem to remember trying to build the latest twolame from source and it worked fine so it might be that there are a differences between the two versions. Portaudio-v19 always wants to build against the 10.5 SDK if it's present rather than 10.4u. This appears to be a deliberate choice. A choice by the portaudio developers rather than us, as it's a straight import. Again, I don't see the problem with xcodebuild only configure. I can hack the configure script to work around this but it make automating the build process a pain.

If you can come up with a reasonable patch (to configure.in) then I'm willing to try and push it upstream into portaudio. It depends really on why the portaudio people went down the 10.5 route. The configure script actively looks for the 10.5 SDK and if it finds it, uses it. Apart from an option to explicitly set which SDK to use I'm not sure what else to do. I haven't done a full build on a Mac for a couple of months and as I volunteered to do some builds for the next release this is what I've found.

I'm compiling on an Intel machine running OSX Server 10.5.2 I can't get Twolame to build from the command line at all using the configure script. It's really just unhappy. Portaudio-v19 always wants to build against the 10.5 SDK if it's present rather than 10.4u. This appears to be a deliberate choice.

I can hack the configure script to work around this but it make automating the build process a pain. Building via XCode (or xcodebuild) works fine once the correct version and location of wxWidgets has been set, although by default it builds for the native architecture and current OS. I've had to change the architecture in the release configurations to 'i386 ppc' and set the 'Base SDK Path' to '10.4u' in all four. I've uploaded a build to Leland's server which I'm sure he'll make available for testing purposes. Once I've got the whole process scripted nightly builds shouldn't be a problem. On Tue, 2008-04-29 at 19:11 +0100, Paul Livesey wrote: I can't get Twolame to build from the command line at all using the configure script.

It's really just unhappy. Any chance of a more detailed description? We updated to the most recent libtwolame release because it included the patches need to build the previous release on OS X, so I've no idea what is wrong. Portaudio-v19 always wants to build against the 10.5 SDK if it's present rather than 10.4u. This appears to be a deliberate choice. A choice by the portaudio developers rather than us, as it's a straight import.

I can hack the configure script to work around this but it make automating the build process a pain. If you can come up with a reasonable patch (to configure.in) then I'm willing to try and push it upstream into portaudio. On 30 Apr 2008, at 22:13, Richard Ash wrote: On Tue, 2008-04-29 at 19:11 +0100, Paul Livesey wrote: I can't get Twolame to build from the command line at all using the configure script.

It's really just unhappy. Any chance of a more detailed description? We updated to the most recent libtwolame release because it included the patches need to build the previous release on OS X, so I've no idea what is wrong. Next time I try a command line, configure build I'll record all the problems.

For now, xcodebuild appears to work flawlessly. I seem to remember trying to build the latest twolame from source and it worked fine so it might be that there are a differences between the two versions. Portaudio-v19 always wants to build against the 10.5 SDK if it's present rather than 10.4u. This appears to be a deliberate choice. A choice by the portaudio developers rather than us, as it's a straight import.

Again, I don't see the problem with xcodebuild only configure. I can hack the configure script to work around this but it make automating the build process a pain. If you can come up with a reasonable patch (to configure.in) then I'm willing to try and push it upstream into portaudio. It depends really on why the portaudio people went down the 10.5 route.

The configure script actively looks for the 10.5 SDK and if it finds it, uses it. Apart from an option to explicitly set which SDK to use I'm not sure what else to do. You have to 'cd' to the libflac directory since the -disable-asm-optimizations option is passed down from the main configure. Mind you this isn't the optimum approach since the 'hand optimized' assembler is 'probably' faster and this causes that code not to be used. Maybe one day I'll try to figure out why the assembler doesn't like being position independent. Once you get past it you realize that twolame has a problem too: You can see that the configure actually works okay: configuring in lib-src/twolame (/Users/Yam/audacity/1.3/audacity/lib-src/twolame) configure: running /bin/sh./configure '-prefix=/usr/local' '-enable-static=yes' '-disable-shared' '-enable-unicode=no' '-enable-debug=yes' '-with-lib-preference=local,system' '-with-wx-version=2.8' '-disable-sqlite' '-disable-flac' '-disable-alsa' '-with-wx-config=/usr/local/bin/wx-config' '-with-pa-include=./portaudio-v19/include' -cache-file=/dev/null -srcdir=.

Checking build system type. I386-apple-darwin9.2.2 checking host system type. I386-apple-darwin9.2.2 checking target system type. I386-apple-darwin9.2.2 checking for a BSD-compatible install.

/usr/bin/install -c checking whether build environment is sane. Yes checking for a thread-safe mkdir -p.

Build/install-sh -c -d checking for gawk. No checking for mawk.

No checking for nawk. No checking for awk. Awk checking whether make sets $(MAKE).

Yes checking for gcc. Gcc checking for C compiler default output file name. A.out checking whether the C compiler works.

Yes checking whether we are cross compiling. No checking for suffix of executables.

Checking for suffix of object files. O checking whether we are using the GNU C compiler. Yes checking whether gcc accepts -g. Yes checking for gcc option to accept ISO C89. None needed checking for style of include used by make. GNU checking dependency style of gcc. Gcc3 checking for a BSD-compatible install.

/usr/bin/install -c checking whether ln -s works. Yes checking for a sed that does not truncate output. /usr/bin/sed checking for grep that handles long lines and -e. /usr/bin/grep checking for egrep. /usr/bin/grep -E checking for ld used by gcc.

/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld checking if the linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) is GNU ld. No checking for /usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld option to reload object files.r checking for BSD-compatible nm. /usr/bin/nm -p checking how to recognise dependent libraries. Passall checking how to run the C preprocessor. Gcc -E checking for ANSI C header files. Yes checking for sys/types.h. Yes checking for sys/stat.h.

Yes checking for stdlib.h. Yes checking for string.h. Yes checking for memory.h.

Re: Audacity 2.0 Build For Mac Pro

Yes checking for strings.h. Yes checking for inttypes.h. Yes checking for stdint.h. Yes checking for unistd.h.

Yes checking dlfcn.h usability. Yes checking dlfcn.h presence. Yes checking for dlfcn.h. Yes checking for g.

G checking whether we are using the GNU C compiler. Yes checking whether g accepts -g. Yes checking dependency style of g.

Gcc3 checking how to run the C preprocessor. G -E checking for g77. No checking for xlf. No checking for f77. No checking for frt. No checking for pgf77.

No checking for cf77. No checking for fort77. No checking for fl32. No checking for af77.

No checking for xlf90. No checking for f90.

No checking for pgf90. No checking for pghpf. No checking for epcf90. No checking for gfortran.

Re: Audacity 2.0 Build For Mac Download

No checking for g95. No checking for xlf95. No checking for f95. No checking for fort. No checking for ifort. No checking for ifc.

No checking for efc. No checking for pgf95. No checking for lf95. No checking for ftn. No checking whether we are using the GNU Fortran 77 compiler. No checking whether accepts -g.

No checking the maximum length of command line arguments. 196608 checking command to parse /usr/bin/nm -p output from gcc object. Ok checking for objdir.libs checking for ar. Ar checking for ranlib.

Ranlib checking for strip. Strip checking if gcc supports -fno-rtti -fno-exceptions. No checking for gcc option to produce PIC.fno-common checking if gcc PIC flag -fno-common works. Yes checking if gcc static flag -static works. No checking if gcc supports -c -o file.o. Yes checking whether the gcc linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) supports shared libraries. Yes checking dynamic linker characteristics.

Darwin9.2.2 dyld checking how to hardcode library paths into programs. Immediate checking whether stripping libraries is possible. Yes checking if libtool supports shared libraries.

Re: Audacity 2.0 Build For Mac Free

Yes checking whether to build shared libraries. No checking whether to build static libraries. Yes configure: creating libtool appending configuration tag 'CXX' to libtool checking for ld used by g. /usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld checking if the linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) is GNU ld. No checking whether the g linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) supports shared libraries. Yes checking for g option to produce PIC.fno-common checking if g PIC flag -fno-common works. Yes checking if g static flag -static works.

No checking if g supports -c -o file.o. Yes checking whether the g linker (/usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld) supports shared libraries. Yes checking dynamic linker characteristics. Darwin9.2.2 dyld checking how to hardcode library paths into programs. Immediate appending configuration tag 'F77' to libtool checking whether byte ordering is bigendian.

No checking for inline. Inline checking for short. Yes checking size of short. 2 checking for float. Yes checking size of float. 4 checking for sqrt in -lm. Yes checking for lrintf in -lm.

Yes checking for powf in -lmx. Yes checking for pkg-config. /opt/local/bin/pkg-config checking pkg-config is at least version 0.9.0. Yes checking for SNDFILE. No checking for sfcommand in -lsndfile. No checking for ANSI C header files.

(cached) yes checking malloc.h usability. No checking malloc.h presence. No checking for malloc.h. No checking assert.h usability.

Yes checking assert.h presence. Yes checking for assert.h. Yes checking for unistd.h. (cached) yes checking for inttypes.h. (cached) yes checking getopt.h usability.

Yes checking getopt.h presence. Yes checking for getopt.h. Yes configure: creating./config.status config.status: creating Makefile config.status: creating twolame.pc config.status: creating doc/Makefile config.status: creating libtwolame/Makefile config.status: creating frontend/Makefile config.status: creating simplefrontend/Makefile config.status: creating build/config.h config.status: executing depfiles commands red:/audacity/1.3/audacity$ But, when you try to do the make, you get: cd.

&& /bin/sh /Users/Yam/audacity/1.3/audacity/lib-src/twolame/build/missing -run aclocal-1.10 cd. && /bin/sh /Users/Yam/audacity/1.3/audacity/lib-src/twolame/build/missing -run automake-1.10 -foreign cd. && /bin/sh /Users/Yam/audacity/1.3/audacity/lib-src/twolame/build/missing -run autoconf configure.ac:81: error: possibly undefined macro: ACCHECKLIB If this token and others are legitimate, please use m4patternallow. See the Autoconf documentation. Configure.ac:88: error: possibly undefined macro: ACCHECKHEADER configure.ac:92: error: possibly undefined macro: ACMSGWARN make:. configure Error 1.

On May 1, 2008 7:28:40 AM +0000 Richard Ash wrote: I think this is a CVS timestamp issue, and the underlying problem is that it is trying to rebuild the autotools build system generated files on a system that doesn't have autotools installed. This would explain why I don't see it (because I've got autotools). I suspect some judicious time stamp alterations would fix this. Ah yes, that rings a bell.

I've done that before. Will maybe try it in after I look at some of the other things. I think this one is genuinely an upstream problem, and probably mac-specific because it depends on both the arch and the binary object format I think. Yep, I believe you're right. It'll just take a little assembler coding, but I need to understand what the Mac PIC requirements are and why he doesn't like it. Since there's a workaround (don't use the assembler versions), then this'll go on the back burner after all the rest.