Copy track with layers from one project to another

Getting Stuff Done How do I .... ?
#1

I would like to export a track with all regions and layers to another project.

I know I can do a stem export, but it would be nice to import it directly.

Is it possible?

1 Like
Copy track with layers updated to Ardour/Mixbus 6
#2

There is no automated way to do this at this time.

If you are comfortable editing XML (text) files and understand filesystems, you could do it by hand-editing the session, but this is unsupported and undocumented.

Someone did put a significant amount of work into enabling this for Ardour 3.0 but the effort was abandoned before that release due to the number of changes to the session file format that took place.

#3

I’m familiar with scripting so I’ll give it a shot. Any docs
I can use for reference?

#4

I think it’s unreasonable to attempt copying track state between sessions or even trying to script it.

There’s Session::export_track_state() which is a less than half-baked attempt to export tracks. The hard part however is importing this into a target session.

For starters that requires the state of all relevant Sources, Playlists, and Regions, then rewrite it to ensure the IDs are unique, and do not conflict with any IDs of the target session. There are likely more constraints that need to be met before they could be safely merged…

#5

in my workflow I switch a lot between two computers: one in my studio and one laptop that is always with me.

the one in my studio is used just for recording, no effects, no additional buses, no rerouting.

the thing is I often have to rerecord something and the original project has evolved a lot, so I need to record a new track and be able to copy it to my second computer.

I’ll try to write a dirty-hacky script for me and if I come up with something I’ll publish it somewhere.

for now, the only relevant tags I need to worry are <Sources> , <Regions> and <Playlists>.
I assume I can safely ignore the rest. I’m I right?

EDITED: I need <Routes> too for tracks.

#6

What about rsync the project folders of the two computers? That should keep the two machines at the same project state.

#7

That’s certainly what I would do in these circumstances.

#8

I do that for all my projects (edited and unedited) but just for bakcups.
here I can’t overwrite projects because the project in my postproduction machine is heavily edited (track names, regions, exports, cleaning unused sources, removing parts and more) so projects aren’t equivalent anymore.

not trying to impose my POV here but I see a lot of use cases for my aproach, mostly centralized posproduction:

  • radio production: several projects doing tracks, one central computer doing final editing.
  • collaborative recording: recording on multiple studios sending tracks to a central studio.
  • economization (my use case): one cheap computer doing only recording stuff and another one doing postproduction work at home or secondary room

all this wouldn’t be necessary if I got just one final and exportable track but I find layering one of best features of ardour and I often use parts of “bad” takes (originally discarded) to complement the “good” ones.

thanks for your time!

#9

Quick question: can I assign IDs arbitrarily as long as they don’t collusion with others? or do you follow any pattern?

#10

They increase monotonically and there are ID and event counters in the <Session... tag.

#11

I was thinking about an offset added to original ID:

OFFSET="9000"
NEW_ID="$((ID + OFFSET))"

but if I do it this way all unused numbers will be ignored on new assets as you take always the higher one, right?

#12

Ardour does not automatically detect the largest used ID.
The next ID is the one from the <Session id-counter="..."> counter +1. It’s a 64bit integer.

It’s common that there are unused IDs in every session. it’s usually sparsely populated.

#13

I got the counter, now can you explain the difference between source-0 and master-source-0 ?

source-0="203" master-source-0="203"

thanks again for your time!

#14

master-source-* is the original. source-* may be modified (time-stretched) copy, if any:

Anyway, I highly recommend to just do this in Ardour itself. There is already existing infrastructure, and you can probably reuse large parts of the template API. Also keep in mind that Ardour’s Session XML format is not a stable interface, so using internal functions would ensure that it won’t get out of date with format changes.

#15

I did it. You can grab it and test it from here: https://gist.github.com/muzzol/5f5d27c155d6113069445c7d3b6910f2

Sorry Robin, I don’t have time for tinkering with LUA. I’m an experienced sysadmin and I’m fluent with bash but beyond that my knowledge and time is limited.

I’ve tested with ardour 5 and mixbus 5 and it works.
I’ve also tested mixbus 6 and it doesn’t work, so you’re totally right about changing formats, but let’s see if someone can take my hacky bash and make something more robust and integrated.

let me know if it works for you or (most probably) if you find any bug.

thanks for your time.

1 Like
#16

Wow, that is an impressive shell script.

I’d have either written it in C++ as a session-util, or in perl :slight_smile:

1 Like
#17

sorry for reusing this thread, Robin, if you think it’s better to open a new one I’ll do that.

I’m looking for a list of all ids you use for version.
Ardour (and mixbux) 6 uses 6000 so it’s easy to identify but ardour 5 uses 3002 and I find it rather confusing.

do you have a list of all values used?

as you may suspect I’m doing a new version of my script :slight_smile:
thanks in advance.

EDIT: I’ve found code for
3000
3001
3002
5000
6000

not sure if I’m missing some.

#18

The session file format has not changed since Ardour 3.
There was no need for Ardour 4 or 5 to convert sessions. You can load sessions created in Ardour 5 in Ardour 3.

This is analogous to library ABI versioning, which is different from the API.

#19

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.