New Update sadness: no more stem export

[Johannes]

First off all: Thanks for the ongoing development of Mixbus and the good things in 3.7.
And thanks for the warning note in the description that stem export of mixbusses is no longer possible.

Unfortunately this kills my workflow.

I do surround mixes using the mixbusses as outputs. I used to export them as channels into the final 5.1/7.1 wav file. Worked like a charm.
Having to export each mixbuss now soloed via the master is a time consuming, error prone process (and the master will alter the sound!).

Yes, I know, that Mixbus is not (yet) a surround console. But all stem-workflows I can think of (e.g. stem mastering) depend on export of the mixbusses.
Unless I'm missing something the drop of stem export in 3.7 is a serious step back.
I don't know what kind of technical limitation has lead to that. If correct alignment of master *and* mixbusses is not possible at the same time, I'd like to have the option to do *either* master *or* mixbusses.

What to other think about the issues? Any advices how to deal with it for now (other then sticking with 3.6 or going back to Logic)?

Johannes

[Studio Saturn]

Let the party started

[Jostein]

What to other think about the issues? Any advices how to deal with it for now (other then sticking with 3.6 or going back to Logic)?

Johannes

I haven't exported stems for one and a half year or so and has been doing this by muting all track but one and one bus during exporting, but this has to be a bug?

Personally, I don't like the idea of using Mixbuses for stem export, so I added 8 stereo busses in order to use them for stem export, then I just feed audio to them from the Mixbuses I wanted, but they did not show up in the export stem dialog.

Then I added 8 ordinary audio stereo tracks and feed them with audio from the Mixbuses. They showed up in the export stem dialog, but the exported wav files was flat (no sound).

Both the created busses and audio tracks had sound, the meters was working and I could listen to them. The audio track's meters was running during the export. What is happening here? Is it a bug, did I miss something or is it no way of exporting stems in one command?

EDIT: Well, I guess that the upgrade mail answer all my thoughts:

"+ NOTE: due to technical limitations, it is now only possible to export Tracks, not buses, in the Stem Export dialog. If you want to export the mixbuses as individual files, please solo each mixbus and use “Session->Export to Audio File” to generate time-aligned mixbus outputs through the master bus. This guarantees that all resulting track, mixbus and master output files will align with each other."

[Hendrik Gundlach]

Harrison is a hardware mixingdeskspecialist! So they act like this in most cases!

[DamHert]

Stem Exports of some audio tracks doesn't work either if you add the parameter to apply track/mixbus processing.
I send a report to Mixbus and they are investigate it.

[Ben@Harrison]

@Johannes, currently the only correct way to export mixbuses is to solo each mixbus, and export it through the Master bus.

Inside the Harrison Mixbus bus-summing engine, the latency compensation for the mixbuses is done in the master bus, when they are summed. So if you exported a mixbus from the stem dialog, it wasn't going through the master and wasn't latency-compensated. For many situations this didn't matter, but there were a few users who exported stems and tried to mix them with tracks which had the -same- material, and this isn't supported. So for now, we decided it is better to remove the feature, than to cause further confusion. We will re-instate that feature, with latency-compensation someday in the future.

@DamHert, I was not able to recreate your problem here, but we will investigate it further next week.

[Domino]

Maybe an interim option would be to allow the export and add riff dtim info to correct the latency offset? Or even trim the exported files..

[Hendrik Gundlach]

@Johannes, currently the only correct way to export mixbuses is to solo each mixbus, and export it through the Master bus.

Inside the Harrison Mixbus bus-summing engine, the latency compensation for the mixbuses is done in the master bus, when they are summed. So if you exported a mixbus from the stem dialog, it wasn't going through the master and wasn't latency-compensated. For many situations this didn't matter, but there were a few users who exported stems and tried to mix them with tracks which had the -same- material, and this isn't supported. So for now, we decided it is better to remove the feature, than to cause further confusion. We will re-instate that feature, with latency-compensation someday in the future.
..

@ben, why woudnt be an note about the compensation problem on busstems a better decission, then taking/stealing away usual workflow for other 'few users'?

[Ben@Harrison]

@Hendrik: The proper fix is to allow mixbuses to be exported in the stem dialog, with correction. It was our intent to have it working for v3.7, but shortly before launch we found some subtle problems that we couldn't work around. So we decided it was better to remove it for now. We'll keep working on it.

-Ben

[x42]

Maybe an interim option would be to allow the export and add riff dtim info to correct the latency offset? Or even trim the exported files..

The problem is not the mechanisms but policy: Tracks & Busses currently only know their own latency and upstream/downstream latency, but not latency of siblings which can run in parallel. Long story short: The bus itself does not know the correct offset for stem-export.
As Ben mentioned currently the only way around would be to run the session N times once for every bus in which case the bus' own latency is all that's needed, but that's a rather ugly workaround and not reasonable to maintain.

There is an ongoing redesign for latency-compensation but it's a rather major change so not something for a minor point release.

It was a tough decision to simply remove/hide the option for the time being. The main case for it: It never worked properly and should not have been exposed in the first place. So strictly speaking it's not removing a feature. I'm sorry if that cases you some inconvenience, but we'll get there in the end.