Expression Maps not imported with Import Tracks from Project

With the Import > Tracks from Project feature, all other Channel and Inspector Settings (which I have checked in the import dialog) appear to be imported correctly, except for Expression Map assignments.

For large orchestral templates, having to manually re-assign every track’s expression map is extremely tedious. I think this issue is very easy to reproduce, but please let me know if I can help diagnose in any way. I would love to see this addressed, and I know it would enable much more practical orchestral template building for many composers.

Wondering if the issue here is that there is a project-level list of loaded expression maps and the Inspector Settings are just a reference into that list? Meaning this import tracks feature would need to be extended to first add (or match, if there is already map of the same name with identical configuration) any missing expression maps?

Hi,

This is missing since the very beginning of the Import from Project. The Expression Maps are part of the project, so I would expect, technically it shouldn’t be a problem to be able to import them from the project.

One interesting note – if you manually load all of the used expression maps into the destination project before performing the Import Tracks from Project, then the imported tracks do get assigned to the correct expression maps.

This is still tedious because you have to individually load all of the relevant expression map files and keep track of them yourself somewhere.

But it reinforces my theory that the inspector settings are being copied with the Import Tracks feature, but it just hasn’t been extended to also import any expression maps that aren’t already loaded into the destination project.

Hi,

It works for me here. It was a bug in Cubase 10.5.0, but it has been fixed for Cubase 10.5.10. Does your project come from Cubase 10.5.10+, please?

Also make sure the Expression map file is not read only, please.

This probably only make sense for folks that use a small to mid-sized number of Expression Maps and not folks with hundreds of them. I recently modified my main Templates and loaded all of the Expression Maps that I regularly/frequently use (a couple dozen-ish) even though most of them didn’t have their corresponding VSTi in the Template. That way when I load or import an Instrument, most of the time the Expression Map is already there. I’ve found that the 80/20 rule tends to apply for my use of Expression Maps - 80% of my Map use is preformed by 20% of the Maps I have. And it is really nice to just select the Map in the Inspector and not need to open the Expression Map Editor.

Hi,

Rodger, can you reproduce the bug, please? I can’t it works for me as expected here.

No I can’t reproduce it either.

I created a test source starting with a blank Project and adding 3 Instrument Tracks - one with Kontakt, another with EW Play & a third with the ARIA Player. Then I assigned appropriate Expression Maps to each Track before saving and closing.

Then I created a second blank Project and imported all three Tracks from the first Project. Every Imported Track’s Expression map came over just fine.

Before I created the test Projects I tried Importing from some older Projects and in some cases did not get the Maps. But it turned out those were all situations where the Instrument Tracks had been disabled after rendering to audio. So Importing a disable Track does not bring the map with it. But other than that the Maps Imported along with the Tracks.

File permissions?

@Martin.Jirsak and @raino see: 10.5 Expression Maps no longer retained - #15 by lokotus

I wonder if your expression maps are getting preserved because you have your instrument tracks outside of any folders.

It sounds like the issue might only manifest if your tracks are inside folders. I’m still running into this exact problem myself, and of course have all my tracks nested (several levels in most cases) in folders.

is there an issue number of the bug that expression maps are not preserved when tracks are inside a folder ? (import session data and xml export looses expression maps when the tracks are inside folders…)

is there an issue can number of the bug that expression maps are not preserved when tracks are inside a folder ? (import session data and xml export looses expression maps when the tracks are inside folders…) cubase 11 on win10…

Having exactly the same issue,
Tons of tracks from templates, all the expression maps are gone.
Please fix!

I can indeed confirm, as @tpoots mentioned, removing the folders makes it work :expressionless:
The little amount of care on some features is simply sad.

I have loads of tracks and expressions maps, I can’t just import one by one again, such a waste of time!
There is no bulk import either, as always, all the features half implemented, cutting corners everywhere :frowning:

The projects were saved with Cubase 11 from scratch, spent quite a few days re-doing my templates just to find out things are not working.

I don´t think that they don’t care. It must be insanely difficult to program. Last time I checked some programmers told me it is very difficult to make folders import from other projects (wondered why).
They probably already saw the potential issues…
They added this feature but as you see, its v1.0. Like all software related things, it need to get updated and debugged in the future and cant be prefect the first time…

Hi,

I can confirm this. Ih the MIDI/Instrument track is in a folder, the Expression Map is not imported to a project.

Reported to Steinberg. Thank you.

“Reported to Steinberg”. Here we are 2 years later and a lot of good it did.
I’m here for the same issue. I just spend a couple of days creating templates with expression maps and a very detailed folder structure and just now am discovering that none of my expression maps will load if the tracks/instruments are inside a folder? Just great.

Hey everybody. I have a solution that is not too tedious and you can import tracks along with their corresponding Expression maps loaded with your folder structure intact. Yay! It takes only a little bit of work on the front end, but then you can save as a template. Explained in the following:

How to import tracks a la carte from a template, with expression maps and with an intact folder structure.
The act of Importing track archives (that have tracks with expression maps), also imports the Expression maps into the project you’re working in. So if you take an entire template session and export all tracks at once as an XML file, then import THAT file Xml file into a new project (file-import-track archive), then delete what you just imported, the project will still retain all the maps you just imported. So now if you select any tracks (including folders) to import from your template session, it will import the tracks with folder structure and re-assign automatically all the expression maps to whatever you just imported. You don’t have to do anything one by one.
To prevent having to do this each time to avoid lengthy load times, you can just delete all the tracks you just imported from the track archive (which moves all the Emaps into the project), then save that as a project template. It will look like blank project upon opening but it will have all your expression maps that will automatically re-attach to whatever you import from your template.
Amazeballs.
It sounds a bit confusing, but just think of it like this. You’re only importing the XML containing all your template tracks into a project for the expression maps they contain. Once the maps are in a session, they automatically assign to whatever you pull in from your template. Once all the maps are in your project, just delete the archive tracks and save as a template and you never have to do it again, unless you add stuff to the template that you’re pulling from.
CAVEAT: Before you export as an XML file, make sure you enable any disabled tracks. You can disable them again before export. I don’t know why this is necessary, but I noticed it doesn’t export correctly with the maps unless I do this step. A pain I know, but really only needs to be done once.

Thanks for the workaround. What a pain, and so ignorant of Steinberg that this has carried on for so long. I just recently moved from Reaper only because of ATMOS and expression maps and I’m beginning to regret it.

Please help me understand your method:

What if your big main template consists of many nested folders. To create this empty xml file that you speak of ( that carries all the Emaps) do I have to take every single track out of their folders before I save it? Or are you saying everytime I work on my big template I also save an additional version of it with everything removed (ie select all, delete, save as) and then import that empty whole project (by ticking all boxes in import track archive dialog) before I then start to import the individual track archives from the same big template?

To be clear, my scenario’s could be

  1. I have an existing older song, done before I made my big template, and which I want to bring in a new track archive, with entire folder structure and emaps intact, from my individually saved track archives (derived from big template). I import the empty copy of the whole project and then import desired individual track archives.

  2. I created a new song and just want to bring in a few track archives (derived from my big template) with everything intact including emaps. Import empty big template first then import individual ones.

Really expression maps were one of the only things left in Cubendo that Steinberg had over every other DAW but now they have all caught up and surpassed it.
They are so important to a composer. In cubendo the window is narrow and you often cant see the entire list, you cant even select the articulations directly with your mouse.

And its the thing we need to see most when we are playing our parts in. The expression map window currently only in the inpsector column needs to be spawn-able, enlargeable, a big gui that we can bring up and interact with, a window that can be brought accross to another screen and ideally seen remotely using http or something. We also need it to recognise only keyswitches from a specific midi channel so that we can have another second keyboard to switch with but not on the same channel because often the switching notes run over the playable section (if you want to map everything like I do) .Reaper can do this sort of thing…sigh.