michaelrmmiller

I live nearby and drive past it nearly every day. It’s been fascinating watching its construction. They’ve done a very good job not impacting traffic and only closed down the highway late at night for a week or two.

Those offerings exist as well. See East West Composer Cloud (https://www.soundsonline.com/composercloud) and Musio (https://musio.com/) (full disclaimer: I did some work on the latter). There are also related offerings like Splice for loops and Output Arcade (https://output.com/get-arcade/).

WASAPI has been available since Windows Vista. It isn’t its own set of drivers but rather a unifying layer for the WDM driver and the preceding mishmash of Windows audio APIs (MME, DirectAudio, etc). WASAPI supports low ish latencies with Exclusive Mode and then something like 10ms buffering in Shared Mode through the Windows audio server, I recall.

Put another way: any Windows audio device supports WASAPI unless it only ships with an ASIO driver which is unlikely, even in the pro audio space.

Orchestration also means something different these days for most film, TV and game composers compared to the traditional definition. Traditionally, orchestration would be taking a piano or short score and expanding it to be played by an orchestra. Nowadays, almost all media composers create full digital mock-ups of the music first with the entire orchestra and then some. Orchestration then is mostly a process of transcription, typesetting and adjustments for live ensemble so the recording and performance accurately conveys the intent. John Williams and Howard Shore are two of the old guard who write short scores with notes for the orchestrator about what to do. Nearly everyone else is writing for the full ensemble and orchestrating as they go. Then the orchestrators translate that to traditional music notation so it can be played.

Absolutely! My email is in my bio. Reach out and we can find a time to chat via whatever medium is comfortable.

If you have specialized in a sub-discipline, it can be an entry point without prior game dev experience or shipped titles. For me, my background in and love of audio and music programming made me desirable despite a lack of game dev roles. Turns out there is a severe lack of audio programming talent across the entire industry (we are looking for more at Naughty Dog as well!). Other specializations within graphics, physics and AI may also be ways to bypass the typical, Catch-22-like requirements for prior game dev experience.

The old generalizations about lower salaries and higher hours are no longer true across the board, by the way. As the industry is maturing, a lot of that is changing and the culture around things like crunch is changing for the better.

There are a few different models at play: surround sound like 5.1, 7.1, ambisonics and the 7.1.4 Atmos static bed; and object-based where mono point source sounds are attached to a location. The former traditional models can be interpreted as individual objects positioned at the speaker locations and folded down to stereo passing through the HRTF that way. It’s a mixed signal so it really is at the end of the chain. For object-based, those are more precisely located but have other downsides (e.g. they break our mixing concepts for things like compression and reverb) and each object would need to be upmixed to binaural stereo through the HRTF.

Higher order ambisonics strikes a pretty good balance in terms of spatial resolution while still being a mixed signal. You can then pair it with objects for specific highlights. Atmos is a 7.1.4 static bed plus dynamic objects, so similar idea. In either case, most of these 3D sound systems support very few dynamic objects. For example, Windows Sonic only supports 15 dynamic objects on Xbox: https://docs.microsoft.com/en-us/windows/win32/coreaudio/spa...

Nothing public I’m aware of, unfortunately. I wish they talked about it publicly in more technical detail.

That chip is responsible for much more than HRTFs too. It can handle a huge amount of 3D audio-related DSP effects and decoding which are all way more compute intensive than the HRTF, which is performed once at the very end of the signal chain for the headphones.

Very true for PCs but it’s starting to shift with both consoles and receivers with Atmos decoders. For example, the PS5 has a custom audio DSP chip with 3D sound capabilities for reverberation, spatialization and more.

To add onto this very good explanation from Paul, in practice, audio processing graphs always rapidly decay into serial processing after starting out massively parallel. Most of the time, we are writing to a single output (i.e. speakers via your audio interface or a file). On top of that, some of the heaviest weight DSP happens on this final output stage (mastering chains with multiband compressors, linear phase equalizers, limiters etc.) So every 5.3ms (256 sample buffer @ 48kHz sample rate) we start massively parallel processing all the leaf nodes (audio tracks with sound files, virtual instruments and synths) and end up bottlenecking as the tree collapses into a line. Then we are stuck doing some of the most CPU intensive work on a single core since we can’t process the limiter DSP plug-in until the EQ finishes its work, for example.

We need to meet our real-time deadline or risk dropping buffers and making nasty pops and clicks. That mastering stage can pretty easily be the limiting (hah) step that causes us to miss the deadline, even if we processed hundreds of tracks in parallel moments before in less time.

The plug-in APIs (AudioUnits, VSTs, AAX) which are responsible for all the DSP and virtual instruments are also designed to process synchronously. Some plug-ins implement their own threading under the hood but this can often get in the way of the host application’s real-time processing. On top of that, because the API isn’t designed to be asynchronous, the host’s processing thread is tied up waiting for the completed result from the plug-in before it can move on.

Add on that many DSP algorithms are time-dependent. You can’t chop up the sample buffer into N different parts and process them independently. The result for sample i+1 depends on processing sample i first.

With good reason, too. A good portion of the Native Instrument software packages won't install because the installers themselves rely on 32-bit helpers. A savvy technical user can work around it by unpacking and excising the problematic portions from the installer scripts.

On the plus side, I've been running Kontakt 5 along with lots of other audio software since 10.15 beta 3 every day and most everything is working alright.

Some other observations:

• Pro Tools' QuickTime video plug-in prevents it from launching because it's a 32-bit only subprocess meant to interact with the now-defunct QuickTime framework. You can delete the plug-in from the application bundle and it will proceed and seems to be working normally.

• EastWest has a nasty crash in PLAY 6 that can be worked around temporarily by removing their internal word builder plug-in.

• Pretty much every iZotope plug-in as of September had a 32-bit non-pkg installer. The software works fine if you copy all the relevant parts from an install on another computer.

• MOTU hardware drivers for anything but the latest Pro Audio line won't work as the drivers are 32-bit at the moment (MIDI interfaces, CueMix-based audio interfaces).

As a former MOTU engineer who worked on the software side of the new interfaces, the built-in web server was really about cross-device and multi-user access, not avoiding CoreAudio. We still had to write CoreAudio server plug-ins for Thunderbolt and proxy the web server through the driver as well.

I hear they are planning to update their 32-bit drivers for the older MIDI and audio interfaces with the exception of the PCIe devices. (There are no existing Macs that can run Catalina and the old PCIe interfaces with the exception of the new Mac Pros, but there will be no driver so...)

Both. Students are required to take humanities classes as well as declare a concentration. Many often choose to minor or major in humanities alongside a science or engineering degree. A handful end up graduating with only a humanities degree. My high school physics professor actually graduated MIT with a writing degree before returning for a PhD in physics.

I myself double majored in Music Composition and Computer Science and have spent my career so far working at their intersection. The strength of their music department was a big part of the reason I applied to and attended MIT.

MOTU — ONSITE, INTERN or FULLTIME — Cambridge, MA (Harvard Square)

MOTU crafts industry-standard, award-winning audio technologies. We are known for our high-quality audio interfaces, our professional multi-track recording software, synthesizers, virtual instruments, and effects. Our products are depended upon by musicians like Beyoncé, Danny Elfman, Michael Giacchino, Alan Menkin, Pat Metheny, Alexandre Desplat, Pete Townshend, Cirque du Soleil and Madonna.

We're a small, dedicated team of engineers based right in Harvard Square in Cambridge, MA. We are a different sort of full-stack: from the UI down to the DSP, the drivers, the FPGA and the physical hardware and everything in between. Our latest AVB line of hardware is a networked audio device that can stream hundreds of channels over ethernet following the AVB IEEE standard with just .625ms latency. Each unit has an embedded linux server that allows users to control it and mix in realtime from any device with a browser. Our DAW, Digital Performer, is a standard for film, TV and game composers around the world.

We develop mostly in C++11/14, Python, CoffeeScript and JavaScript. They're not prerequisites by any means, though, and we're always excited to incorporate new technologies.

Interested in the future of digital audio and music creation? Feel free to contact me directly at [email protected].

Ah, good point! My code is pretty flawed... it's using new to allocate an SDL_Window! All of this is just aesthetics at a certain point and what you prefer. For me, I'd get bored writing make<SDL_Window, SDL_CreateWindow, SDL_DestroyWindow> over and over. One solution is to wrap that in a function make_window like you've done. The other would be to wrap it in a template function that uses traits to lookup the creator and deleter functions. Pretty much equivalent. I only slightly prefer the latter because it exposes the type of the object in the call.

Thanks for writing the article! I'm much more in this camp of writing thin resource management rather than full-blown wrappers. And even if I were writing a wrapper, I would use these same techniques you're exploring to manage the resource as a member. It removes the need for any boilerplate whatsoever and in one line expresses all you need to know about the semantics of the object.

True but that means you need a wrapper function for each type you want to create or you need to use the more general function, defeating the purpose.

It also obscures the type of the object. That can be okay if it's only used as a temporary local, but problematic if you ever need to store it as a member or return it from another function. The type signature is verbose and not very descriptive, either. Compare that to:

  namespace sdl2 {
    using window = std::unique_ptr<SDL_Window, deleter<decltype(SDL_DestroyWindow), SDL_DestroyWindow>>;
  }
  ...
  sdl2::window window{SDL_CreateWindow(...)};

If you wanted to do something like what they have, I would create a variant on C++14's std::make_unique. That could look like:

  template<typename T> struct deleter_traits;

  template<> struct deleter_traits<SDL_Window>
  {
    using custom_deleter = deleter<decltype(SDL_DestroyWindow), SDL_DestroyWindow>;
  }

  template<typename T, typename... Args> create_unique(Args&&... args)
  {
    return std::unique_ptr<T, typename deleter_traits<T>::custom_deleter>{new T(std::forward(args))};
  }

  sdl2::window window = create_unique<SDL_Window>(...);

That looks a lot cleaner to me, at least. And instead of having to write a new function for each type, you just add a new deleter_traits specialization.

(I haven't actually compiled any of this so it's probably riddled with syntax errors... hopefully the point still comes across!)

If you were creating a C++ wrapper, you still might prefer to use this same technique. Make the unique_ptr-wrapped resource a member of the wrapper instead of the raw resource. That would give the wrapper the same semantics as unique_ptr without any extra work. If you wanted shared ownership, use shared_ptr instead. Lastly, you wouldn't need to manually declare a destructor to free the resource.

In the end, I find it more readable to see unique_ptr and shared_ptr than raw resources. They describe more than just resource management.

The other downside to their approach is that you have to pass the function into the constructor every time you construct an object.

A similar alternative would be to template the deleter on the type of the function and then a specific function. This way you can wrap functions with non-void return values. Something like:

  template<typename FuncType, FuncType& F> struct deleter { ... };
  using unique_cptr = std::unique_ptr<void, deleter<decltype(free), free>>;

The other cool thing I learned recently is you can actually use the custom deleter to override the wrapped type by typedef'ing pointer in your deleter class. You can use this to wrap C-style file descriptors in a unique_ptr.

I have a girlfriend of eight years but no children to speak of yet. She's finishing up grad school but eventually should have a decent salary. That said, I definitely sympathize and it's a worry waiting on the horizon. We had long discussions about the future of this path and how I needed to be willing to take a step back and provide more if things weren't working out.

When I first brought up my career change, she wasn't on board because I didn't have a plan. But now that I am (more) sure of myself and know what I want to do and how, she is happy to support me and I'm exceedingly grateful for that. As long as you're communicating and your family is supporting you, I'd bet you can find a way to make it work.

I was reading about director Ang Lee a few months ago and found some inspiration in his career. After finishing grad school, he spent the next six years unemployed, writing a couple scripts at home and taking care of his two small children while his wife (a molecular biologist) worked. If he had given up then or if his family hadn't believed in him and supported him, he probably wouldn't be where he is now. Everyone's situation is different but I found hope and comfort in his backstory.

I actually just went through a lot of this. Despite loving my day job as a software engineer, it was so creatively exhausting and draining that by the end of the day, all I wanted was to relax. I couldn't find even the desire to work on the things I'm passionate about. I think that was the most upsetting part to me.

I'm very risk-averse but finally worked up the courage to quit and spend my time doing what I love: writing music. I'm slowly bleeding through my savings, but it's worth it. I wouldn't be able to live with myself if I never gave composing a fair shot. In the end, the biggest risk is actually to your ego. There's always another job out there, particularly if you're a software person.

I'm still nervous about the whole thing and worried about my prospects. I still procrastinate. But damn, I'm just much happier these days!

Finally made an account after years of lurking just to say this. Believe in yourself and take a leap. Sometimes it's just what you need to rediscover yourself.