You are here

Aux Send usage clarification

Hi Rui,

I've just returned to Qtractor after a work-enforced absence and am having problems with the Aux Send feature. Could you clarify the intended purpose of this feature please? Specifically, I'd like to find out the following:

1) As I understand things from your previous comments, Aux Sends are for internal routing and Inserts are for external. Is that correct?

2) When routing a signal from a Track (MIDI or Audio) via an Aux Send to an internal Bus (Duplex), where is the signal supposed to go after this? Does it automatically return to the Track and get routed through the Track's "Output" destination (as chosen in the "Track" dialogue box), or does it stay in the Bus (and therefore should be routed manually, via Connections or something)?

What I'm attempting to do is to send several tracks (either MIDI or Audio) to one Reverb Bus, via Aux Sends in the Tracks, so that they can share the same reverb plugin (with varying levels of gain via the Aux Send's dialogue box), then export this (and other tracks) via the Master Audio export.

I've been using the Mixer to set all this up (as you've told me to do previously) and, from checking there, the signal is registering in the Reverb Bus, but I can't hear any reverb effect. In order to hear it, I have to connect the Reverb Bus' outputs to system 1 & 2 in Connections. Is this what I should be doing?

In addition, when exporting the Master Audio output, the reverb is not present. To be able to export this, I have to export the _Reverb Bus_ output, which isn't much use to me as I'd like to (if possbible) have several shared Buses, all eventually ending up at the Master Audio out.

In short, I'm not at all sure how the system is supposed to work. I know from your previous comments that it's not an Ardour-style "anything to anywhere" system, but can't seem to work out what it's doing. FYI, the Inserts feature appears to be fine - I can route out to Jamin and back into Qtractor, then export, with no problem. It's just the internal routing that I'm stumped on.

Any help would be very much appreciated. I'm running 0.5.11.15 from SVN.

Forums: 
rncbc's picture

re. 1) As I understand things from your previous comments, Aux Sends are for internal routing and Inserts are for external. Is that correct?

yes.

re. 2) When routing a signal from a Track (MIDI or Audio) via an Aux Send to an internal Bus (Duplex), where is the signal supposed to go after this?

signal goes through the target bus output ports; yes, you'll have to connect them to whatever you do for listening or monitoring, or further processing (via the JACK graph outside of qtractor); yes, you can only export the output of one audio output bus at a time.

in summary, internal routing goes only on the forward direction, never feedback:

input -> input-bus -> tracks -> output-bus -> output

the purpose of aux-sends is to serve you to fork the signal path on its way to output; you can't have aux-sends from an output-bus to another output-bus--this might only work *iif* the originating bus appears *before* the destination bus. as buses are sorted in create order that will only work just by chance, not by design.

have a look back to the following diagrams:)

a. the aux-send plugin block-diagram:
b. the general bus / tracks diagram:
hth.
cheers

Thanks as ever for the quick, detailed reponse. I've been working with this again today after reading your comments and looking at the diagrams, but I'm still not sure if what I'm trying to do is possible.

My basic questions is - is it possible to have multiple tracks routed through different buses (e.g. strings reverb bus, brass reverb bus, percussion reverb bus etc), then have the output of all these buses end up at the Master Out (or anywhere else "convenient"), so that I can then export everything together (rather than export the individual buses)? If this is not possible using Aux Sends (which I'm using in order to control Send Gain) and Buses, is it possible via some other method?

From your response, I think I may be going about this in the wrong way, but if the above _is_ possible, I'm really not sure how to approach it. Again, any help would be very much appreciated.

rncbc's picture

re. is it possible to have multiple tracks routed through different buses (..) then have the output of all these buses end up at the Master Out (or anywhere else "convenient"), so that I can then export everything together ?
no, it is not possible, yet. audio track export only does its thing via one and only one single audio bus atm.
fwiw. sounds like kind of a new feature request to me :) file a ticket please, before oblivion takes its due :)

Thanks for the info - I've opened a ticket. I wasn't quite sure how you wanted it wording in terms of the actual method of addressing this, so have kept it quite general. I imagine it's a non-trivial thing to implement, but if you do get the time to look at this at any point, I think it'd be a big improvement.

In addition, after playing with the latest version for the last couple of days, I've discovered a small bug and thought of a couple of ideas for the piano roll (or rather, stolen them from Rosegarden :-)). I'll list them here - please let me know whether you're interested in them at all.

PIANO ROLL - QUICK-SAVE (bug)
When this window has focus, attempting to save with Ctrl-S does not work. If the user clicks on the main editor window to give it focus (leaving the piano roll window open/minimised) and presses Ctrl-S, saving will work and the piano roll window will then automatically appear in front of the main window. At this point, anything selected in the "Parameter Type" menu of the piano roll will reset to default. For example:

1) In piano roll, choose "Controller" in "Value Type" menu and "7 - Volume (coarse)" in "Parameter Type"
2) Make any kind of change in piano roll, to allow save operation
3) Click in the main Editor window to give it focus (leaving the piano roll window open/minimised), then press Ctrl-S to save. The piano roll will then come back into view
4) Note that "7 - Volume (coarse)" in "Parameter Type" has returned to the default, "0 - Bank Select (coarse)"
*I've tried a few "Parameter Type"/"Value Type" menu combinations and this seems to happen every time.

Pressing Ctrl-S while the piano roll has focus should (at least to my mind) save the project; no other options should change.

PIANO ROLL - SELECT ALL (feature idea)
In Rosegarden, holding Shift and selecting a piano key on the left of the piano roll selects all notes of that pitch. This is a very handy feature and I think something similar in Qtractor would be great.

PIANO ROLL - SHORTCUTS (feature idea)
In Rosegarden, pressing Ctrl and up/down arrow with a note/notes highlighted moves them up/down an octave. Again, a handy feature.

rncbc's picture

you never know whether it's trivial or not, unless you know the code inside out.
well, it's done already. svn trunk v0.5.11.16+ awaits your experience ;)

re. PIANO ROLL - QUICK-SAVE (bug)
yeah, confirmed. will look at it sooner than later... maybe already fixed on svn trunk of course ;).

re. PIANO ROLL - SELECT ALL (feature idea)
maybe i missed some, but click-n-drag on the (fake) piano keyboard on the left pane doesn't do it for you? and shift/ctrl will also select non-contiguous note lines, jfyi.

re. PIANO ROLL - SHORTCUTS (feature idea)
currently, holding shift/ctrl+arrow-keys will just scroll a slice (shift) or a page(ctrl); not sure whether option is intuitive enough. but i'll try :)

cheers

re. AUDIO EXPORT/MULTIPLE BUSES
Thank you indeed :-) I've just tested this out on 0.5.11.16 and was able to export multiple buses by selecting them in the Export Audio window. I'll do some more intensive testing to see if anything weird happens (e.g. when sending multiple buses out to JAMin etc) and report back if there are any problems. This new feature is a huge bonus for me personally and I think it should benefit a lot of others too.

re. PIANO ROLL - QUICK-SAVE (bug)
OK, will check back on this.

re. PIANO ROLL - SELECT ALL (feature idea)
Ah, I see - click and drag to the right! Didn't know about that. Yes, that's exactly what I was looking for.

re. PIANO ROLL - SHORTCUTS (feature idea)
If you think it's worth putting it, please do; if not, no problem. It's only a minor feature, but I found myself using it a lot in Rosegarden once I discovered it, so thought I'd mention it.

Thanks again for the ridiculously fast work :-)

Hi Rui,

I've finally had time to play with the multiple bus export feature and wanted to get your thoughts on the below observations. I'm now running 0.5.11.30.

----
1) AUDIO EXPORT/MULTIPLE BUSES
If you export multiple buses in which the signal is reasonably hot (though not clipping), when these are exported together, the exported file can easily clip. I first noticed this when using the limiter in JAMin, but after investigating further, I found that you can easily reproduce this without JAMin.

I imagine it's caused by the output of the buses being mixed together, making the overall signal louder? I'm not sure how you want the multiple bus feature to work exactly, but personally, I think it'd be nice if the multiple buses could be "collected" by the Master out bus - then you could just export this one bus. Doing it this way would also enable you to put all the stuff you want at the end of the chain (JAMin, goniometer, performing a mono check, whatever it may be) in one place, rather than duplicating everything in each bus. As I say, I'm not sure of your intentions for the buses, but I'd like to hear your thoughts on this.

2) PIANO ROLL - QUICK-SAVE
Not sure if you've actively addressed this, but FYI, here is the behaviour in this version:

- Ctrl-S with the piano roll window having focus doesn't perform a save (as per original bug)
- Ctrl-S with the main editor having focus does perform a save, bringing the piano roll window back to the foreground (as per original bug). However, the "Parameter Type" menu select will now not return to default (this part is fixed)

3) TEMPO MAP/MARKERS NOT RESTORING
There seems to be something fishy going on with Tempo Map/Markers but I haven't been able to track this down yet. In the time I've been using Qtractor, I've seen things not restoring the way they were upon re-opening a file. For example, if I use "Update" to change a previously inserted tempo, this change may not have saved upon re-opening; or after inserting/modifying multiple time signature changes, one or more might be missing upon re-opening. I've only had this happen on decent-sized projects and haven't been able to reproduce with a simple test project.

I know the above is a terrible attempt at a bug report, but do you have any ideas about how I can try to "break" this intentionally and so track down what's happening? I looked for similar issues on this forum and on Sourceforge and thought it might be connected to this bug, but I'm not quite sure:

http://sourceforge.net/p/qtractor/tickets/63/

However, what he says about multiple tempo changes making a mess of the tempo mappings does sound similar to what I've experienced. I also often have multiple tempo/time signature changes (partly caused by working around the lack of tempo ramping) and so have run into this problem.
----

Anyway, please let me know your thoughts on the above and if you need more info, any tickets opening etc.

rncbc's picture

re. 1) AUDIO EXPORT/MULTIPLE BUSES

yes. it's caused by the multiple buses output being mixed (added) straight together. fact is that the whole mix may well exceed the regular audio full-scale for floating-point sample data format, which is [-1.0, +1.0] (0dBfs) and when it does it get's hard-clipped when exporting/converting/writing into a non-float sample file format (eg. standard 16bit signed WAV).

you have two choices: a) dim out the output volume of each bus as much until the whole mix doesn't ever over 0dBfs, ever; you can monitor this with some external meter(ing or ppm), the connections of which replicate the converging multiple buses you're trying to export. b) export to a float sample file format (eg. ogg vorbis) where hard-clipping doesn't occur at the disk file data storage representation and you'll get the chance to control and overcome those clipping artifacts later on in the process chain eg. when ultimately rendering to DAC/soundcard, through simple attenuation (ie. volume/fader/whatever;))

re. 2) PIANO ROLL - QUICK-SAVE

pressing Ctrl+S while the MIDI clip editor is up just saves the MIDI file that you're working on that precise MIDI clip, not the whole qtractor session (or, if you prefer, project or song);

pressing Ctrl+S while the main window has focus is the way to save the whole show.

you might find it wrong, redundant or even confusing, but yay, that's the way it works :) unless, i'm missing the point or something in between :/

re. 3) TEMPO MAP/MARKERS NOT RESTORING

this needs more investigation; what exactly is not restoring and when? is it easily reproducible or just happens sometimes and hard to remember what and when?

make sure you get all comments from ticket #63: as repeat ad-nauseum: tempo/time-sig changes must only occur at bar measure positions; there's no way to work around that, i am sorry :) and tempo ramps are not supported either; use the timeshift MIDI tool to emulate accelerando/retardandos on individual MIDI clips, it's not possible to do it any other way, any time soon. sorry.

cheers

Thanks as ever for the quick reply. Sorry for the long post yet again, but...

1) AUDIO EXPORT/MULTIPLE BUSES
I'm not that familiar with the technicalities of file formats, but after a bit of research, I think I understand :-) I generally export to FLAC for archiving and convert to ogg for distribution, but it seems FLAC doesn't support floating point. So to confirm - if I were to switch to, say 32 bit float WAV and export a file which is clipped, do you mean that I can just lower the level of the sample to 0dB or below and this will preserve all the data? I've just done some tests in Audacity with clipped FLAC and 32 bit float WAV files and they do indeed behave very differently, the WAV file seemingly working OK.

Do you have any thoughts on the second part of the post ("Doing it this way... rather than duplicating everything in each bus")? At the moment, with multiple buses I'm having to connect each one to JAMin etc separately. Is this the intended way? Previously, when using Ardour, I had all the buses etc returning to the Master Out and just added one Insert to JAMin, which was very easy. It seems such an approach might not be possible in Qtractor?

2) PIANO ROLL - QUICK-SAVE
> you might find it wrong, redundant or even confusing, but yay, that's the way it works :)

Yes, I have been utterly confused by this :-) If by pressing Ctrl-S in the MIDI window I am actually saving the work I'm doing in that particular file, then that's fine (as it's the only file I'll be working on at that time). It's still confusing though, as pressing Ctrl-S with the MIDI window having focus doesn't remove the [modified] text from the window. So...

- Should [modified] disappear from the MIDI window upon pressing Ctrl-S (with the MIDI window having focus)?
- If I save "the whole show" in the main editor, open a MIDI window, make a change, then press Ctrl-S (with the MIDI window having focus), should [modified] disappear both from the MIDI window and the main window? Although I'm not saving "the whole show" here, I'm saving the only thing which is having an influence on it

Basically, I think the design as you've explained it is fine, but at the moment, there's no visual feedback as to whether the save has worked or not, which is confusing (at least to me).

3) TEMPO MAP/MARKERS NOT RESTORING
> what exactly is not restoring and when?

It's difficult to pin down as I often won't notice that something's gone wrong until much later, but I can give you my recollections/impressions (again, apologies for the vagueness). As I mentioned, if you could give me any hints on the kind of things I can try in order to "break" this, I'd appreciate it.

- I've seen both tempo and time signatures not restore correctly
- Sometimes entries will be present, but incorrect (e.g. tempo figure wrong); sometimes they'll be missing altogether. When things go wrong, it's often the way that not all entries are wrong - some can remain correct
- What seems to happen is that Qtractor can "remember" a previous setting for an entry, then incorrectly revert to this setting after other changes are made later. As time goes on and more changes are made, the problem worsens as Qtractor becomes "more confused"
- I suspect, though really am unsure, that using the "Update" button can throw things off. I've noticed that after making several changes and attempting to "Update", the button will sometimes be greyed out, when it should be active and ready, indicating that at least something isn't right here. Again, it's as if the tempo map is becoming "confused"
- I also suspect (though again am unsure) that making various changes, then returning to make changes in the middle of a list of ones you've already made, can throw things off
- In terms of entries going "missing" - as an example, a piece I was working on had about 6-7 tempo and time signature changes. After working on the file for a while, making saves/re-opening the file, I eventually discovered that only three of these changes remained in the Tempo Map/Markers box. I was unable to work out exactly when things had gone wrong
- The problem seems to happen mostly on re-loading a save, but I think there's a decent chance it's also happening while working on the file in the standard way (see next point)
- I'm reasonably sure I've seen the problem happen in realtime. When playing back MIDI files and following them in the MIDI editor, upon passing over a tempo/time sig mark (not sure which), I'm sure I've seen the window "jump" as the change is re-read (incorrectly?)
- I've tried making changes solely through View -> Tempo Map/Markers and solely by clicking the bar marker area above the MIDI tracks, but neither seems to be stable. Is there any difference in these methods?

> is it easily reproducible or just happens sometimes and hard to remember what and when?

As above, it's difficult to pin down. I've been trying to reproduce in a small test file to be able to send you a .qtz, but haven't been able to get anything so far. I also don't have any examples from previous projects, as due to their having become such a mess, I ended up removing as many of the changes as possible.

> tempo/time-sig changes must only occur at bar measure positions

Yes, I understand. This is no problem.

> use the timeshift MIDI tool to emulate accelerando/retardandos on individual MIDI clips

I did look into this feature previously but it wasn't quite what I needed, as using it throws off the bar lengths (I understand that this is what's it's supposed to be doing). Given that I'll likely still need to adjust the time signatures in order to put in things like brief pauses, and given that tempo changes can only occur in defined places, I think that using both features will make things a bit of a mess. I think I could live without tempo ramping if we could isolate and fix the non-restoring Tempo Map issue.

4) TEMPO DIALOGUE BOX UNNECESSARY PROMPT
Just found another small bug during today's tests.

- Right click MIDI clip -> Clip -> Tempo Adjust
- Cancel without making any changes
- "Some settings have been changed." prompt will appear unnecessarily
- n.b. the default settings in the dialogue box will be 90.0 4/4, regardless of the clip's properties. Even when proceeding as above on a clip of 90.0 4/4 (i.e. the same as the default settings), the prompt will still appear unnecessarily

It's very similar to this previous bug:

http://sourceforge.net/p/qtractor/tickets/49/

rncbc's picture

i'm not quite seeing this happening :/ would you care to detail the circumstances?

right-clicking on any clip and Clip/Time Adjust... (F7) then cancelling the dialog immediately doesn't prompt me to anything...

byee

ps. re. tempo map changes issue, i've just bumped into something that might be related to your worries; while exercising undo/redo over and across a loop of couple of clips, incidentally spreading over distinct tempo/time-sig regions, it started to behave a little strange and ended in a mess, like being non-idempotent at all (which is not by original design, i assure you:)) ... fwiw, latest svn trunk, v0.5.11.30...

pps. an then i could not reproduce the bump; still trying though... :/

ppps. and now back to the title subject: i got the Clip/Tempo Adjust dialog to prompt the unnecessary question after all o.O uhoh worms are crawling out of the can :)

Yes, the tempo/time sig thing is difficult to track down, but I'm glad you've seen something similar (and hopefully the actual cause). I'll keep on the lookout for this and, if you have any specific theories, I'd be happy to test them out.

Please let me know on the other points whenever you have time. I'll summarise them here to save you wading through all the above:

1) AUDIO EXPORT/MULTIPLE BUSES
Is it OK to export a clipped 32 bit float WAV, then bring the level down in Audacity later (i.e. no data loss occurs)?

When working with multiple buses and things at the end of the chain which apply to all buses (e.g. JAMin), do I have to send all these buses individually? Is there no way just to send everything in one go (i.e. previous workflow in Ardour)?

2) PIANO ROLL - QUICK-SAVE
When pressing Ctrl-S in the MIDI window, the [modified] text doesn't disappear, making it look like no saving of the clip has occurred. Are you OK with this? What should the behaviour be?

4) TEMPO DIALOGUE BOX UNNECESSARY PROMPT
I'm glad that you've reproduced this now (it's been 100% for me). Will check it in a subsequent version if you do make a fix.

Thanks again for your help.

rncbc's picture

Is it OK to export a clipped 32 bit float WAV, then bring the level down in Audacity later (i.e. no data loss occurs)?
yes, that's the kind of reasoning i've tried to explain earlier--non-float/integer sample formats will hard-clip every peak sample above 0dBfs, and they'll indeed store/write the distorted value into the file without mercy.

cheers

rncbc's picture

there's a mistake of mine earlier, sorry.

Ctrl+S is NOT defined as a one of keyboard shortcuts while on the MIDI clip editor window (aka. piano-roll editor), so pressing that particular key combination won't do anything at all if the MIDI editor window has focus (unless of course you re-define it through the Help/Shortcuts dialog).

Ctrl+S is only defined for the main tracks window and there it does save the "whole show" indeed.

byee

rncbc's picture

maybe already mitigated on svn trunk rev.3635+ (aka. v0.5.11.31)

byee

1) AUDIO EXPORT/MULTIPLE BUSES
Thanks very much for the confirmation.

2) PIANO ROLL - QUICK-SAVE
Ah, I see. I had no idea that the MIDI window shortcuts were handled separately. I've just added this and it's now working fine.

4) TEMPO DIALOGUE BOX UNNECESSARY PROMPT
Just tested in 0.5.11.31 and this appears to be fixed. Thanks.

It looks like there's just one thing left from my enormous list now. Please let me know whenever you have chance (no rush):

----
When working with multiple buses and things at the end of the chain which apply to all buses (e.g. JAMin), do I have to send all these buses individually? Is there no way just to send everything in one go (i.e. previous workflow in Ardour)?
----

> ...do I have to send all these buses individually?

Actually, thinking about this again, I don't suppose there's any way around this. It's quite fiddly, but I can live with it.

rncbc's picture

i seem to have found the culprit in my case. not sure if it's the same one of yours...

my case, where tempo was bumping in and there while playback was rolling, is somewhat due to external JACK transport sync.

funny (or not) fact, is that qtractor sometimes (quite randomly) gets confused by its own tempo/time-sig changes and in despair it blames as being issued externally and bang! changes the current running tempo time-sig as is. no questions asked.

anyway, it's been hopefully mitigated on v0.5.11.32+. but.... given its rare and unpredictable behavior i'd ask you humbly to whether it might be also your case.

cheers

Thanks for continuing the investigation :-) I've just grabbed 0.5.11.33 and will let you know if I encounter anything.

I tried to continue with the piece I've been battling with through the various bugs/routing issues I've been discussing with you, but ran into a new one today which is preventing me from continuing (unless I, say, export MIDI files and re-import into a new project). Basically, when recording the MIDI tracks to audio tracks, Qtractor will "jump" in a certain place, throwing the timings off (MIDI is fine; audio is out of synch). The playhead will physically freeze for a split second before continuing. It happens 100% (at least for me) and there's no xrun in Jack. This is something I've never seen before.

Do you have any thoughts on this? If you're interested in seeing the file, I could upload a .qtz to sourceforge, but it's hardly a "clean" file, as I've worked on it over numerous versions of Qtractor. It's also one of the files I had the tempo/time sig problems in (though I've now removed almost all of them, as I mentioned previously). However, the place where the audio jumps is, as far as I can remember, not one of the places where a tempo/time sig change occurred.

And a "bonus" :-) Qtractor segfaults 100% each time I try to remove 2 of the 4 Inserts I have in there, whether they're active or not.

Please let me know your thoughts.

rncbc's picture

If you're interested in seeing the file, I could upload a .qtz to sourceforge
yes. i'd be interested of course. please open a new ticket on the issue and upload the simplest session where the bug(s) still manifests

seeya

Thanks for this. Have just tried to upload the file to sourceforge, but it keeps timing out, possibly because the file is around 100MB (even though I've cut the audio right down). Do you happen to know the maximum upload size? I've looked through the help files but can't find any references to this.

I've also just discovered that the bug only occurs when recording WAV (which I switched to, as per our previous discussion), but not with FLAC. This is the main reason the file size is so large and would likely also explain why I've never seen the bug before.

And there's one more question today in my seemingly never-ending list, I'm afraid...
When importing a MIDI file, is Qtractor supposed to keep this MIDI file's tempo (and any changes) intact, or is this information supposed to be overriden by the tempo map of the project itself? At the moment, it seems that exporting a MIDI file keeps the tempo changes correctly, but when importing via Track -> Import Tracks -> MIDI, the tempo/tempo changes disappear. Is there any way to keep these intact? I had a look in the manual but couldn't find any references to other methods of importing.

rncbc's picture

gosh. 100MB is a lot for a ticket attachment ... no wonder sf.net times out :/

does the bug (glitch) really happens only when after recording to wav? maybe you can upload just the session as is prior to recording and tell which steps you do to connect and record later, presuming you're record-bouncing (record from qtractor own outputs). that should make a more viable file size, don't you think?

cheers

rncbc's picture

by now, you must know, that MIDI file's tempo map gets honored and imported only iif it's the first MIDI content to get loaded into the current session; if the current session already has one or more MIDI tracks, no matter if they're empty with no clips yet, the tempo map from the MIDI file being imported is simply discarded.

cheers

> no matter if they're empty with no clips yet

Ah, I see - thanks for confirming. I have a default template automatically loaded, which would explain this behaviour.

With regard to the audio "jump", I wanted to include the audio just in case you couldn't reproduce, but in any case, I've now opened a new ticket and uploaded a qtz with all audio stripped out. I've uploaded a separate audio file too though (please see bug for details).

Thanks again for all your help.

rncbc's picture

might have been fixed on todays svn trunk rev.3643+ (aka. v0.5.11.34+)

test && tell
cheers

Just tested in 0.5.11.34 and this looks fixed. Thanks very much.

I'm taking a class online and going through this today. So after working through how Qtractor's routing works, is it safe to say that all output buses go directly to hardware playback? So then the actual Master volume is my hardware mixer volume.

rncbc's picture

re. is it safe to say that all output buses go directly to hardware playback?

not necessarily. it only happens that way because the default Master output buses are auto-connected, which means that its ports are automatically connected to the first pair of system:playback_N ports. you can turn that off and manually connect those output ports to whatever you find appropriate. qtractor is just a client of the whole JACK sub-system, remember?

cheers

Hi Rui, thanks a lot for the job!

I'm a happy Qtractor user.
I followed the conversation between you and yuba.
I don't know if i have understood but really there's no way to connect every single bus i created to the master bus so that i can export my project in one shot?

Thanks in advance.
Vittorio

rncbc's picture

when exporting tracks (menu Track/Export Tracks...) you now have this option to mix-down (audio) or merge (MIDI) the output of multiple buses into a file--previously, it was about one and only one bus, usually Master.

hth.
cheers

Hi Vittorio,

FYI, the info from this thread is now in the wiki, together with a note on the clipping which may occur... and which gave me a fair shock when I first saw it :-)

Add new comment