View Issue Details

IDCategoryLast Update
0004656bugs2012-01-31 15:52
ReportercolinfAssigned To 
Reproducibilityalways 
Status newResolutionopen 
Product Version 
Fixed in Version 
Summary0004656: aux sends not restored with session template
DescriptionEven if aux sends are defined in a session saved as a template, creating a new session from that template won't create them.
TagsNo tags attached.

Relationships

related to 0005814 new Using sends in templates does not get added properly in new sessions 

Activities

paul

2012-01-31 02:02

administrator   ~0012718

This is a rather complex issue. The session may not contain the target of the aux send, and worse, the target is specified as an ID, not a name, which means we cannot try to find it.

Changed target to 3.X because its really part of the overall "aux send" issue.

colinf

2012-01-31 11:27

updater   ~0012722

I can't see how it should be possible to create a session template with an aux send but without its corresponding target. I suppose matching multiple aux sends with their potential targets would still be a problem if there's no way of finding the name of the target for a given send.

Would it be a 'good enough' solution just to save aux sends in session templates, and use their names to determine their targets when creating a session from a template?

I know that would break if a send was renamed, but it'd be better than nothing. Maybe 'Save as template' could even warn about that case?

paul

2012-01-31 15:10

administrator   ~0012723

1) i missed that this was for a session template. that makes things a bit easier, maybe. i'm not 100% sure that the object IDs will all be restored, but i think they are.

2) there's some fairly deep work to be done to make aux sends/busses really work in the way that they should. i'd rather focus on a superficial fix for now. it could be that this is really just a missing couple of lines of code.

colinf

2012-01-31 15:52

updater   ~0012724

This one-liner makes aux sends get saved in (both session and route) templates:

Index: libs/ardour/route.cc
===================================================================
--- libs/ardour/route.cc (revision 11397)
+++ libs/ardour/route.cc (working copy)
@@ -1914,7 +1914,7 @@
             boost::shared_ptr<InternalSend> is;
 
             if ((is = boost::dynamic_pointer_cast<InternalSend> (*i)) != 0) {
- if (is->role() == Delivery::Aux || is->role() == Delivery::Listen) {
+ if (is->role() == Delivery::Listen) {
                     continue;
                 }
             }

Now, if I save a template with aux sends, sessions created from that template get the aux sends back, so yes, the IDs do come back the same.

The downside is that creating a route from a route template with aux sends saved with this patch causes errors like:

"rvrb - cannot find any track/bus with the ID 295 to connect to".

It'd be lovely if routes knew whether they're being created from a template, so they could search for their aux send targets by name rather than by ID, but even without any other changes I don't think the behaviour of complaining about unconnectable aux sends when creating a route from a template is any worse than silently discarding the aux sends when the template is saved.

Issue History

Date Modified Username Field Change
2012-01-25 16:13 colinf New Issue
2012-01-26 08:53 cth103 cost => 0.00
2012-01-26 08:53 cth103 Target Version => 3.0-beta3
2012-01-31 02:02 paul Note Added: 0012718
2012-01-31 02:02 paul Target Version 3.0-beta3 => 3.X
2012-01-31 11:27 colinf Note Added: 0012722
2012-01-31 15:10 paul Note Added: 0012723
2012-01-31 15:52 colinf Note Added: 0012724
2014-01-09 12:08 colinf Relationship added related to 0005814