Glenn Fricker/SMG MixBus 32c Review

[syklopz]

https://youtu.be/27Omd3pMOok

Just released!!

[Jostein]

A very good and reasonable review. I share his opinions about live monitoring and tempo ramp but I probably have been too used to make workarounds. I really like that he notice this with fresh ears and mind.

I find it strange that the tempo ramp function doesn't show up before now. I asked about it back in 2011 in the Ardour forum and no one there except for a musician or two seemed to really understand the importance about variable tempo, they also used workarounds. I find Glen's complaining about workarounds very reasonable because this single topic is really big from a musical point of view.

But I'm sure that the live monitoring issue also will be fixed in the future, moving Mixbus a divine step upwards. IMO, Mixbus' mixing capabilities are better than anyone, the editing system is great and the tracking is almost there. I do use Mixbus for tracking and I'm thrilled that the tempo ramping is coming. No more need for tedious recording and adjustments of click tracks.

[dustinnr]

I thought it was a great review.
To me, the single biggest thing he said was how quickly and easily he was able to come up with a good mix, and used almost no plugins doing so.
I also like that he seemed to have tried to do that, rather than simply replicate his process and plugins from a different DAW - which sort of defeats the point.

And, I liked that he appreciated how cool some of the plugins are.

[the C.L.A.]

I share his opinions about live monitoring and tempo ramp but...

His issue was actually about importing tempo maps from Midi files - not tempo ramps.

Following the development of Ardour closely, I'd say ramps required a major rewrite of some underlying mechanisms. Work on tempo map import started a few weeks ago and might currently still be ongoing to make it work with a variety of Midi files - but doesn't seem to be that big of a deal as the ramps were. So both will likely be available in Mixbus 4.

Anyway... It's always interesting to see what different priorities different people have. I personally like to monitor via hardware for the lowest possible latency. But that might differ between monitoring for the artist and the engineer - latter might prefer to monitor through the "console"...

One thing that I personally would like to see are some advanced comping tools and improved take management - although for my current stuff I can mostly do without.

[jonetsu]

Yes, pretty good review of the mixing part and the two plugins. I must agree that I'm doing as much editing a spossible in Bitwig since for what I do I consider it part of the compositional/arranging part anyways, an then use Mixbus 32C for mixing, with other, light, editing when needed.

So far I haven't used punch in/out but got a footswitch for the Faderport to do so eventually. Following a recent thread here I tried it and was very surprised that the audio drops when it's the most needed eg. when the part being replaced is actually played ! So no punch in/out still for a while.

[Ben@Harrison]

@jonetsu:

Your comment: "the audio drops when it's the most needed eg. when the part being replaced is actually played" is a misinterpretation, I think.

In an auto-punch, Mixbus -stops- playing the existing material, and instead monitors the live input, when the punch-in happens. We think this is best for most users, BUT it does require that you have a monitoring path (either through your interface device, or some other path thru mixbus) so you can hear yourself playing along with the solo -before- you hit the punch-point.

Admittedly it would be nice to do this all within one track. There are other cases - such as overwriting a drum midi part - where you want to monitor both the input and the playback; so we are working on that for a future release.

Best,
-Ben

[Jostein]

I share his opinions about live monitoring and tempo ramp but...

His issue was actually about importing tempo maps from Midi files - not tempo ramps.

?

The consequence of no tempo ramps = no import of tempo maps

[the C.L.A.]

His issue was actually about importing tempo maps from Midi files - not tempo ramps.

?

The consequence of no tempo ramps = no import of tempo maps

I think that assumption is plain wrong. You could have multiple tempos in one track without ramping them - so you could also still import them. Also I'm not sure if SMFs (standard Midi files) actually know of the concept of ramping - haven't bothered to look that up.

To my knowledge, in addition to that, different DAWs tend to ramp tempos in different ways, so the results would possibly not match 100%, anyway.

[Jostein]

His issue was actually about importing tempo maps from Midi files - not tempo ramps.

?

The consequence of no tempo ramps = no import of tempo maps

I think that assumption is plain wrong. You could have multiple tempos in one track without ramping them - so you could also still import them. Also I'm not sure if SMFs (standard Midi files) actually know of the concept of ramping - haven't bothered to look that up.

To my knowledge, in addition to that, different DAWs tend to ramp tempos in different ways, so the results would possibly not match 100%, anyway.

Yes, I'm of course aware that I can have multiple tempos in one track. But drifting in tempo and gradual changes like rallentando is extremely tedious and time consuming without tempo ramping. As I understand it, this kind of tempo changes are also a important part of what tempo mapping does?

EDIT: I add this link: https://en.wikipedia.org/wiki/Tempo_map

[the C.L.A.]

Yes, I'm of course aware that I can have multiple tempos in one track. But drifting in tempo and gradual changes like rallentando is extremely tedious and time consuming without tempo ramping. As I understand it, this kind of tempo changes are also a important part of what tempo mapping does?

EDIT: I add this link: https://en.wikipedia.org/wiki/Tempo_map

Yes, I agree that ramping the tempo manually would be very tedious. Though in the image in your link the tempo seems to be changed in steps as well, instead of some smooth ramp. So no idea if that might have been created manually as well.