[v1.1.20] Named inputs lost


I think I have an issue with the inputs of tracks with the lastest version (1.1.20). All my named input have disapeer and I’m not able now to assign an input from my x32 compact in my project if I don’t use the workaround that I found.
I think it could be in link with the fact of I have switched of driver but I don’t sure.
After the update to the 1.1.20, I have opened my project with ASIO4ALL driver (before the update, I was connected to my x32 and X-USB ASIO Driver) and now, after the update, when I’m connected to my x32 with the X-USB ASIO Driver, I’m not able to retrieve my inputs used the last time that I have used my x32.

I have a second problem maybe linked to the first, the popup in tracks view to create a named output that appear after in connection view appear only if I have selected previously a named output (that I need to recreate in connections view because the popup don’t appear in a first time) for this specific track.
Note that I need to restart this process for all tracks that I need to assign an input.


This will recreate ports to known ports (if any) of that device. So if you once assigned your named Input “Mic 1” to x32 input 1, then later to “ASIO4All microphone” or whatever, the next time you switch to x32 it should find it. VST Live remembers up to 32 assignments for each port so you can swap hardware w/o having to worry, given you once saved it on that system. The key to this is to keep the visual name of used ports, and not change it if you save the same project with different setups.
That all beeing said, I don’t quite understand your problem in the first place.

Ports are saved in the project, so I’d be surprised if those would vanish. The selection menu shows both known ports, and those provided by the selected device. Make sure your device is selected in the Hub when you start VST Live, and before you load your project.

That sounds wrong (given what I just said). Also we didn’t change much in that area. Did you svae the same project when the Asio4All driver was selected? Even then, it should work when the x32 is selected thereafter, but you will probably have to reload the project. If it still doesn’t work, you could send us your project (just the .vlprj file) so we can analyse if ports have been saved correctly.

Could not reproduce this (if understood correctly; you talk about audio tracks, right?), all the more it would help if we could examine your project, thanks!

I have cleaned up all user data, create a new project and recreated all inputs and outputs and now it’s seems to be finally ok (including in the old project). I wonder if it was not linked to a crash that I have in the previous version but I can’t be sure (I unfortunately deleted the old crash dumps (v1.1.10) thinking that I will no longer need them). For now, I don’t have any crash with the new version, I’ll let you know here if I have the problem again.

Sorry if I’m not really clear, English is not my native language.
I’m not able to reproduce it now with the old project but I have switch on a second computer with the new project (I used the first computer to create the project) and I’m able to reproduce a similar thing :
The first time that I have produced this type of issue, it was with my X32 driver but here, it’s with ASIO4ALL as you can see.

Also, I don’t understand why the input/output is still created if I click on cancel. For this part, this is maybe not a bug but It doesn’t seem very intuitive to me and we don’t have the way to really cancel the initial click if it’s an error, we should go to connections windows for that and it makes useless clicks I think.

You can find here the 2 projects if needed (“Concert 8 Janvier 2022” is the initial project) :
projects.zip (922.9 KB)

Thanks for the files, will analyse asap.

It just means that you have not changed the name (which you should). It will then (Cancel) use the hardware ports’ name. You can change it at any time with Devices/Connections. If you hit it accidently, set to “(nc)” again.

Can’t reproduce this one no matter what. There used to be an older bug like this but that’s been fixed a while ago. But maybe it is related:
Finally found a problem with ports, thanks to your project. At least in my place, it removes ports that are not beeing used in the project; but as I don’t have your device, it will remove all of your Kick, Snare bottom and whatever Inputs you created for your device, such that the Input name appears in the track, but the port is not available anymore. We will fix removal of ports with the next version. Which is what your issue was all about in the first place, thanks for helping to figure this out.

1 Like

Ok thanks. I take advantage of this subject to bring up two others points that I observed :

  • The first concerns the value of the tempo. It does not seem to bé saved systematically since the last version (saving this parameter seems to work randomly).
  • For the second point, I set up buttons on my x32 in midi (I use play/stop, record, next song and previous song). If I’m playing (or recording I guess) a song, sometimes I want to go to the next song without stopping the music first. In this case, I regularly observe random behavior. sometimes when I’ve just started the track I can skip to the next one and other times nothing happens. I noticed that it was often just after starting a song that it happens

Tempo is set per Song and saved and loaded properly. Do you use tempo maps?

You cannot jump to another Song while transport is running. You may jump to Parts within the currently playing Song randomly, to change and fire Layers and Stacks etc, but that will not change the transport position either.

I’m not sure that what you would like to say by “tempo maps” but I can reproduce it with a new simple project (only one song, nothing else) :
Capture d’écran 2022-11-29 125845

  • Create the project
  • Change the tempo as in the capture
  • Save the project
  • Close VST live
  • Reopen it, the tempo has been lost (sometimes), the tempo value is set to 120 in place of 133

Ok, in this case I think this is a bug:
Here the action that I have triggered (all theses actions is triggered by differents buttons mapped on my x32) :

  • Play Starlight
  • Next song (I suppose it’s here that is not normal from what you told me)
  • Next song (nothing happens here)
  • Stop

You are correct, when issued via MIDI (Actions), you can select a different Song while transport is running. We will prevent that in the future and possibly add a preference for that. Usually you don’t want that to happen on stage deliberately, but sometimes it comes in handy during rehearsal.

1 Like

Thank you, I think it’s a good idea to have the possibility to enable or disable this, it can be usefull.

I’m sorry but i’m a real bugs magnet :smiley: , I just have found a new one :

  • Play a song
  • Try to edit the tempo of this song
  • The windows (and sound) is freezed

Do you have any idea when the next version will be released ? Because I need to do some recordings with my band (12 december) to prepare a live in January and I starting to wonder if I will be able to do that with VST live :frowning: . I’m annoyed because currently I can’t do what I need due to the differents bugs that I have listed (the most annoying being the differents routing problems that I have) and it’s too bad because the promises of this software are really great.

Edit : I am not able to identify it concretely at the moment but I wonder if for the routings issues that I have, there is not a problem with the setup windows (the windows opened at startup). Sometimes I have the feeling that it loses the selected midi inputs and the same thing for the main audio output. I say that because regularly I find myself with the main output which arrives in my input 1 whereas I was supposed to have configured it to go in input 15/16 of my x32. But this is maybe linked to the same issue that you have find in my project, I can’t be sure.

Can’t reproduce. But this has been reported before and tested against the upcoming version so it’s probably been fixed then.

Planned for mid December.

As long as you don’t change anything here and just open your project, all should be fine. Only if you create a new project should this have any effect.

This should be fixed with the new 1.1.30 version ?
I don’t really know if the fix is in the changelog but I continue to have the same issue with the new version (I just tested). Do not hesitate to ask me for more information if necessary.


Changing a Song while transport is running is deliberately prohibited so to not accidently disrupt the current Song.

Yes, I know but actually I can go to the next song during another song is playing. For that, I trigger action “next song” using a midi command. It work often one time and after, the trigger of action stop to work including if I stop the song currently playing.

Will have to check because we explicitly supressed it in this very version.