"solo" more than one track

New Features and requests for new features
Anorton
Posts: 307
Joined: June 20th, 11:13 am

"solo" more than one track

Post by Anorton »

I'd like to be able to "solo" multiple tracks. It would really help with mixing/remixing.
Keith
Posts: 70
Joined: October 3rd, 1:25 pm
Location: Nashville, TN

Re: "solo" more than one track

Post by Keith »

I could see this feature being useful as MT continues to develop. Maybe a choice in settings of either cancel or latching.
DavePDX
Posts: 102
Joined: May 1st, 12:15 am

Re: "solo" more than one track

Post by DavePDX »

+1 I would find it very useful.
User avatar
pwnified
Posts: 1565
Joined: August 17th, 9:41 pm

Re: "solo" more than one track

Post by pwnified »

Actually, the reason it's an exclusive solo is because of performance reasons. Any soloed track needs to pull from the file, apply fx and mix in realtime. But devices are much more powerful now, so we could probably get 2 or more soloed tracks on 3GS or later devices without performance problems. Would it help to have 2 soloed tracks (and any more than that would 'unsolo' the oldest one)?
Image
Keith
Posts: 70
Joined: October 3rd, 1:25 pm
Location: Nashville, TN

Re: "solo" more than one track

Post by Keith »

I don' think two or three channels would be helpful. It probably would give people something to complain about. Personally I would not include it until it could be totaly functional.
DavePDX
Posts: 102
Joined: May 1st, 12:15 am

Re: "solo" more than one track

Post by DavePDX »

I would find it helpful even with just 2 or 3 tracks, but I agree with Keith that many users would find it frustrating or confusing.

I'm curious though. There's no problem muting one or two tracks and having the rest playing. Isn't that effectively the same thing as having multiple solo tracks? I understand that in code they may be done differently, but I'm wondering if there's some way to do soloing in a way similar to multiple muting.
Last edited by DavePDX on November 12th, 10:11 pm, edited 1 time in total.
Anorton
Posts: 307
Joined: June 20th, 11:13 am

Re: "solo" more than one track

Post by Anorton »

2 or 3 would help me too.
User avatar
pwnified
Posts: 1565
Joined: August 17th, 9:41 pm

Re: "solo" more than one track

Post by pwnified »

DavePDX wrote:I'm curious though.
A bit hard to explain. Basically multitrack uses a cache of all the tracks in one. You could think of it as a mixdown, and when it plays back, it simply just plays this pre-rendered mixdown. This is the reason why multitrack is so smooth and efficient; most of the time, it hasn't much to do just play the mixdown. This is in contrast to other multitrack apps. They all render and process and mix each and every track at all times. MultiTrack takes advantage of an optimization which uses background threads to update this 'cache' or 'mixdown'. It needs to put rendered tracks into it, and also take out old rendered tracks (tracks that changed). It keeps this cache updated, and relies on the fact that you're not going to be changing all the tracks at the same time. So instead of doing the same processing over and over like other multitrackers, MultiTrack DAW caches the processing so that it doesn't have to repeat the same computations. Some other daws have 'freeze tracks', however this doesn't even come close to the way multitrack does it, because they have a separate freeze track for each track, which basically 'bakes in' the FX but it still needs to mix them and it uses at least double the filespace (or more).

I came up with this algorithm because of my game programming background. Some of you might remember a game 'Quake' written by id software (John Carmack). This game is the epiphany of optimization, with some of the most exciting and beautiful optimizations ever created. Highly influential, it's the reason I got into programming. Although Quake uses a hefty pre-processing step which happens before the game is even run, multitrack is more dynamic since the data is always changing. As Terje Mathisen has said and Carmack has quoted "All programming is an exercise in caching", words to live by. Could never be more true for the app 'MultiTrack DAW'

There are tradeoffs, as with any optimization, mostly they trade computation for pre-computation. In multitracks case it trades processing for filespace. All 'pre-computation' takes place in the background while the app is running and while you're not doing anything (or when waiting for controls to unfold, yes every little bit helps). There is also an 'Optimizing' phase that happens once on first project load, to build the initial cache. Other apps (like four track) actually have 4 file streams that get filled out whether you use them or not, and also does brute force rendering, this is probably the worst you can do in terms of processing/wasted filespace.

So anyways, this cache in multitrack is updated with the volume/pan/mute/fx settings of each track, on a block by block basis, and there is a 3 second lag from when it gets updated to when you hear the changes come out the speakers. There needed to be some compensation for this, so another system is used for tracks that have changed or are being recorded on. They preempt the cache and happen in the CoreAudio callback thread so that changes are heard immediately.

When you solo a track it doesn't use the cache at all, it just uses the traditional method of brute force rendering each track. If it didn't do this it would need another solo 'bus'. But more importantly, it doesn't modify the cache, all mute settings are retained. Unmuting any track (or unsoloing the only soloed track) in this mode will bring back the previous mute configuration, and start pulling from the cache again.

Thinking about the worst case, where all 24 stereo tracks are soloed (without a cache bus), it would have to brute force render and pull data from all those file streams. Which is simply impossible even on an iPad 2. The device doesn't have the file bandwidth to pull from 24 stereo streams (16 bit, 44khz). You could do some optimization where the cache is used for up to half the tracks and the other half are brute force, but it would then need to support 12 stereo, which is pushing it with todays hardware. You might be able to break the cache into power of 2 tracks counts and pull tracks out of some cache and put them into others. That would get complicated.

So it could support more than 2 soloed tracks, but I think it gets a little weird when tracks start to be 'unsoloed' at some arbitrary count. With 2 soloed tracks, at least there is some semblance of when they become unsoloed.

So I hope this explanation isn't too long/boring, but it's fun to talk about. It's crazy that such a simple looking product could have so much more going on inside than you could ever tell by looking at it. To be honest, a lot of games are the same way. To be a game programmer, you have to be an expert in every programming field imaginable. After doing game programming, you can do anything :D
Image
DavePDX
Posts: 102
Joined: May 1st, 12:15 am

Re: "solo" more than one track

Post by DavePDX »

Wow, thanks much for taking the time to give such a detailed response. It goes a long way toward explaining why MT is such a stable and smooth user experience! And as always, thanks for putting your priorities to that instead of merely piling on features and glitz, as is so fashionable these days.
Keith
Posts: 70
Joined: October 3rd, 1:25 pm
Location: Nashville, TN

Re: "solo" more than one track

Post by Keith »

What Dave said. Can i get college credit for reading the entry on soloing?