View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0007071ardourfeaturespublic2016-10-12 19:462022-09-12 17:08
Reportercolinf Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version5.X git (version in description) 
Summary0007071: MIDI tracks not available for stem export
DescriptionMIDI tracks aren't available in the list of tracks offered for stem export (they're specifically excluded, in fact). Being able to render MIDI tracks without faffing around with extra buses would be quite handy.
Additional InformationI made a half-baked trivial patch to make this work: it works exporting audio outputs from MIDI tracks, but obviously exports nothing when exporting region contents of MIDI tracks. I'm not sure what should happen in that case: I imagine implementing a full-blown MIDI export would be a non-trivial task, but it feels a bit weird to have tracks visible in the stem export dialogue that will only be exported when 'track outputs' is selected.
TagsNo tags attached.

Relationships

has duplicate 0007606 new Unable to export MIDI tracks as stems 
related to 0007838 new Offline Rendering for Midi Tracks 

Activities

colinf

2017-09-05 11:01

updater  

midi-stem-export.patch (1,213 bytes)    
diff --git a/gtk2_ardour/export_channel_selector.cc b/gtk2_ardour/export_channel_selector.cc
index 9043da312..4dd2fb587 100644
--- a/gtk2_ardour/export_channel_selector.cc
+++ b/gtk2_ardour/export_channel_selector.cc
@@ -651,6 +651,7 @@ TrackExportChannelSelector::select_none ()
 void
 TrackExportChannelSelector::track_outputs_selected ()
 {
+	fill_list();
 	update_config();
 }
 
@@ -676,13 +677,27 @@ TrackExportChannelSelector::fill_list()
 		}
 	}
 	for (RouteList::iterator it = routes.begin(); it != routes.end(); ++it) {
-		if (boost::dynamic_pointer_cast<AudioTrack>(*it)) {
-			if (!(*it)->active ()) {
-				// don't include inactive tracks
+		if (!(*it)->active ()) {
+			// don't include inactive tracks
+			continue;
+		}
+		if (!boost::dynamic_pointer_cast<Track>(*it)) {
+			// not a track, we've already handled it
+			continue;
+		}
+
+		if (track_output_button.get_active()) {
+			if ((*it)->output()->n_ports().n_audio() <= 0) {
+			// track has no audio outputs
+				continue;
+			}
+		} else {
+			// can only do pre-processor export of audio tracks for now
+			if (!boost::dynamic_pointer_cast<AudioTrack>(*it)) {
 				continue;
 			}
-			add_track (*it);
 		}
+		add_track (*it);
 	}
 }
midi-stem-export.patch (1,213 bytes)   

paul

2018-07-04 12:23

administrator   ~0020335

Colin - do you think we should still apply this patch?

colinf

2018-07-04 12:37

updater   ~0020337

The patch is definitely no more than half-baked: it'll allow MIDI tracks to be selected in the stem export dialogue even if 'Apply track/bus processing' isn't ticked, but then the export won't produce anything for those tracks. Ideally, it should export a MIDI file in that case. Otherwise, at least it should not allow MIDI tracks to be selected for an export that wouldn't produce an audio file.

I toyed with the idea of refreshing the list of tracks when 'Apply track/bus processing' is toggled, so that MIDI tracks would only appear when it's enabled, but I seem to remember finding some annoying snag with that scheme: I think it was that all tracks became unselected for export when the list is refreshed, but I can't remember for sure: it was a long time ago...

colinf

2019-03-20 23:42

updater   ~0020616

Remarkably, the patch still seems to apply cleanly. I'll look back into this when I have a spare moment or two.

unfa

2020-01-30 14:50

reporter   ~0020941

Could this be merged into 6.0?

x42

2020-01-30 15:04

administrator   ~0020942

> Could this be merged into 6.0?

Not unless it'll be fully baked by then :) Maybe 6.1 is more likely at this point.

colinf

2020-01-30 15:12

updater   ~0020943

I really will try to find a few spare moments to poke at this...

I wonder whether adding SMF export will be any simpler following commits 22da7793 .. b83ef099?

colinf

2020-02-07 20:13

updater   ~0020954

I've looked at what might be involved in adding MIDI file export, and it looks non-trivial: the export code seems to have the assumption that it's dealing with audio baked in pretty deeply. I'm sure it's doable, but I wonder whether it's the best target for the amount of effort it seems likely to take, or whether just audio export from MIDI tracks covers a sufficient majority of the use cases to make tweaking the UI to make it clear that that's what is supported is enough.

paul

2020-02-07 20:21

administrator   ~0020955

What I'd like to see for MIDI is basically just "put an SMF file corresponding to this region somewhere outside the session". It won't cover 100% of the issues, but it will cover a lot of them. I don't think it should in anyway connected with the current export code.

colinf

2020-02-08 14:04

updater   ~0020956

Paul: so you're happy for, and would prefer, 'Stem Export' to remain audio-only? That's good as far as I'm concerned: I'd started off changing ARDOUR::AudioPort to ARDOUR::Port in gtk2_ardour/export_channel_selector.{cc|h} and chasing the compile errors to find out what else needed to change, but the depth of that rabbit-hole quickly became clear...

I'll have a go at working out a way of presenting MIDI tracks in the stem export UI to make it clear that export is audio-only, then.

marcan

2020-04-06 04:36

reporter   ~0021203

Just to note down IRC discussion: the patch attached here *does* in fact hide MIDI tracks from export when "Apply track/bus processing" isn't ticked. The main remaining UI issue seems to be that toggling that checkbox now clears the track selections, as the list is re-populated.

It would be nice to see this land in 6.0, seeing as it's a rather big win (you can't stem export MIDI synths at all without creating duplicate buses for everything as it stands, which is a huge PITA) even in its current state.

I'm attaching a patch with the merge conflict against master fixed, but I think colinf has his own version.
allow-stem-midi-export.patch (1,426 bytes)    
commit 681387f8c049e3e329e9fd88ce9516035ef77540
Author: Hector Martin <marcan@marcan.st>
Date:   Sun Apr 5 21:04:18 2020 +0900

    Allow stem export of MIDI tracks

diff --git a/gtk2_ardour/export_channel_selector.cc b/gtk2_ardour/export_channel_selector.cc
index 2e59e4c140..84be504f72 100644
--- a/gtk2_ardour/export_channel_selector.cc
+++ b/gtk2_ardour/export_channel_selector.cc
@@ -680,6 +680,7 @@ TrackExportChannelSelector::select_none ()
 void
 TrackExportChannelSelector::track_outputs_selected ()
 {
+	fill_list();
 	update_config();
 }
 
@@ -707,13 +708,27 @@ TrackExportChannelSelector::fill_list()
 		}
 	}
 	for (RouteList::iterator it = routes.begin(); it != routes.end(); ++it) {
-		if (boost::dynamic_pointer_cast<AudioTrack>(*it)) {
-			if (!(*it)->active ()) {
-				// don't include inactive tracks
+		if (!(*it)->active ()) {
+			// don't include inactive tracks
+			continue;
+		}
+		if (!boost::dynamic_pointer_cast<Track>(*it)) {
+			// not a track, we've already handled it
+			continue;
+		}
+
+		if (track_output_button.get_active()) {
+			if ((*it)->output()->n_ports().n_audio() <= 0) {
+				// track has no audio outputs
+				continue;
+			}
+		} else {
+			// can only do pre-processor export of audio tracks for now
+			if (!boost::dynamic_pointer_cast<AudioTrack>(*it)) {
 				continue;
 			}
-			add_track (*it, cs.selected (*it));
 		}
+        add_track (*it, cs.selected (*it));
 	}
 }
allow-stem-midi-export.patch (1,426 bytes)   

colinf

2020-04-11 12:55

updater   ~0021306

I've been thinking a bit more about how the UI for stem exports, and this case in particular, should work. Refreshing the list of tracks & busses whenever 'Apply Track/Bus Processing' is toggled to only show the applicable ones doesn't feel quite right to me, especially since it has the side-effect of clearing the selection too. I mean, it's not disastrous, but I think it could be better...

Ideas I've come up with so far:
(a) remove the overall "Apply Track/Bus Processing" tick-box, and add it as a 3-way export choice (off/no processing/processing) for each track/bus individually instead. I have actually had to make stem exports of projects in the past where I wanted some tracks exported with processing and some without, so this would be useful to me, at least.
(b) remove the overall "Apply Track/Bus Processing" tick-box, and add two tick-boxes for each track/bus to enable no processing/processing respectively for each track/bus. Use-cases for exporting the same thing both with and without processing are probably a bit more contrived, and this might be rather more involved to implement, but maybe there's some use to it?
(c) disable/grey out MIDI tracks/busses in the list when the overall "Apply Track/Bus Processing" tick-box is not ticked.

Or something else? What do people think?

ahellquist

2020-04-15 13:11

reporter   ~0021361

If Midi is one of the weaker sides of Ardour, I think flawless export/import of midi-data is of significant importance to be able to use other tools as many people do and use Ardour for the excellent audio handling .. Setting up busses and target tracks to be able to "export" midi is far beyond what most people would accept so I wold vote for some kind of solution to the export problem.

Also, I think people would expect to find midi-export at the same place current audio exports are handeld.

just my 2c

PipeManMusic

2020-07-02 16:16

reporter   ~0024560

I'll plus one for this, having to export multichannel backing tracks I need to use stems with processing, not having a way to do this for midi tracks makes the workaround of using another bus fairly complicated and clunky since you have to manually verify routing is correct, it also clutters up the session for little reason.

x42

2020-07-02 16:26

administrator   ~0024561

@colinf I think (a) and (b) are not good solutions. You either export raw recorded material to continue work in another DAW, or stem-export the final mix for a client.
Allowing a mix of both will only lead to mistakes being made by users.

As side note: technically it would also hard to implement, the raw-export (no processing) is handled by adding a "capture processor" to each track. Ardour does not run the full graph.

colinf

2020-07-02 16:30

updater   ~0024562

@x42: so (c) it is, then, unless anyone else comes up with a better idea before I get around to implementing it.

Daniele1971

2022-04-09 15:04

reporter   ~0026379

Any news ? Can we expect to be fixed/implemented in Ardour-7 ?

paul

2022-04-09 15:06

administrator   ~0026380

We do want to provide this feature but it's not likely to be a part of 7.0

colinf

2022-09-12 17:08

updater   ~0026576

Stem export of SMF implemented by the indefatigable Robin Gareus in 5d590a1c & preceding commits, in a definitely-not-half-baked fashion: thanks!

Issue History

Date Modified Username Field Change
2016-10-12 19:46 colinf New Issue
2017-09-05 11:01 colinf File Added: midi-stem-export.patch
2018-06-26 11:57 colinf Relationship added has duplicate 0007606
2018-07-04 12:23 paul Note Added: 0020335
2018-07-04 12:37 colinf Note Added: 0020337
2019-03-20 23:42 colinf Note Added: 0020616
2019-11-14 17:16 colinf Relationship added related to 0007838
2020-01-30 14:50 unfa Note Added: 0020941
2020-01-30 15:04 x42 Note Added: 0020942
2020-01-30 15:12 colinf Note Added: 0020943
2020-02-07 20:13 colinf Note Added: 0020954
2020-02-07 20:21 paul Note Added: 0020955
2020-02-08 14:04 colinf Note Added: 0020956
2020-04-06 04:36 marcan File Added: allow-stem-midi-export.patch
2020-04-06 04:36 marcan Note Added: 0021203
2020-04-11 12:55 colinf Note Added: 0021306
2020-04-15 13:11 ahellquist Note Added: 0021361
2020-07-02 16:16 PipeManMusic Note Added: 0024560
2020-07-02 16:26 x42 Note Added: 0024561
2020-07-02 16:30 colinf Note Added: 0024562
2022-04-09 15:04 Daniele1971 Note Added: 0026379
2022-04-09 15:06 paul Note Added: 0026380
2022-09-12 17:08 colinf Status new => closed
2022-09-12 17:08 colinf Resolution open => fixed
2022-09-12 17:08 colinf Note Added: 0026576