I’m still missing a “master song list”. My main problem is: If you create a new song in a playlist for a single gig and don’t remember to put it in your main list, it’s gone if you remove the gig setlist after the gig is done.
For me, it would be much more convenient, logical and less risky if you would distinguish between:
a “Songlist” where you add, remove and work on songs for your band and where it’s also clear that if you delete a song, it’s not just removing it from the current setlist but it’s gone for good. All of your bands songs are in there.
a “Setlist” for every gig you do with just certain songs in a specific order. If you remove a song from this list, it’s still in your “Songlist”
I attached some example how this could look in VST live:
I´ve found that if one changes the order of songs in left zone even if changes to project are saved that setlist songs order is not updated. I have to save as a new setlist.
It´s not the behaviour I´d expect.
You are raising an interesting topic. Stumbled here myself; will add a “Sync” button to have the current setlist (we call it “Playlist” to distinguish it from “Setlists”) synced to the selected setlist. This way, all changes to the Playlist are reflected in that Setlist and vice versa. It would be default when you have no setlists yet.
To me that might be confusing, your mileage may vary. Also, we need that top of the Playlist space for something else
Also, VST Live then checks if there are no setlists at all (as with “New”), it then sets Sync active and crates a default setlist.
We were wondering about the order of columns, you prefer to have Songs left and Setlists right. But as this editor is about setlists, and most operations are layed out left to right, we’ll keep it that way even though your view makes sense as well.
Let’s say I create a playlist for Gig 1 with song A, B and C.
For Gig 2, we play song B, C and a new song D.
If I now load the Gig 2 setlist and remove the setlist of Gig 1, song A would be gone from the project file.
If I would do it the other way around, I would lose song D, or do I misunderstand the new setlist editor?
With up to 60 songs in multiple setlist it’s super easy to lose track.
My suggestion would be to always have all songs (A, B, C and D) in a master playlist/songlist that cannot be deleted (you can just delete single songs from it, and then they also disappear from all setlists).
We are going in cycles here, that’s exactly the scenario I described above. For a Gig I have to always load a setlist into the playlist, so the playlist is always just a temporary thing. So the only way to don’t lose songs is to have it in at least one setlist.
If we have a song that we don’t play in full 2023, chances are high that it’s just gone when someone deletes the 2022 setlists.
All would be easily solved by having a song list where all setlists are created from that is NOT just the merge of all setlists like currently implemented, but a standalone list where you can create and remove songs.
I will now just do a workaround with having a setlist with the name “Master Songlist” and I try to make sure that I add every new song to it too. And if a band member deletes it by accident when working on the setlists, he will be punished with 30 whip lashes.
If I ever expect to play a song ever again, it will be in my 1966 setlist. You can also save and load Songs seperately.
For your thinking, we need to be able to delete a Song from the Songs list (middle column), otherwise one can never get rid of a Song at all. If we do that, we need another mode “lock Songs” or whatever to prevent Songs from beeing removed from the Songs list when its last reference is removed. That makes it more complicated, two more objects (delete and lock) to be added.
Also, when playing a setlist from long ago you can just load that project, no?
Don’t get me wrong, I see your point but also hate to add possible pitfalls, tasks, and things to remember, manage, or go wrong.
A compromise could be that a Song remains in the Songs List until the project is closed. It is still there anyway unless you purged undo.
We could keep Songs in the list until they are explicitly deleted. Or maybe even better, when VST Live detects that the last reference of a Song was removed, it could ask (with don’t show again option) whether to delete that Song or not, would that be ok with you?
To be honest, I think your current concept with the setlists is hard to understand. It’s usable, but it has quite some learning curve where you delete stuff just because you don’t get the concept behind it - can be quite some bad experience.
For me personally, dividing into a single “Songlist” and one or more Setlists you fill with the songs of the Songlist is way easier to understand and straight forward. Then you could also be safe that messing with the setlists will never delete any songs from the project.
Songlist-Features would be:
Add new song to project
Delete song from project (…“are you sure?”)
Setlist-Features would be:
Add song (from Songlist), drag&drop
Remove song (with a minus)
For this to work properly, the mentioned switch to switch the Playlist between Songlist and current Setlist would also be required though.
In the end I can just make suggestions, but I take what I get and arrange to it in the end
If sync is activated, that is exactly what we have.
That’s what I do already all the time. I think “Project” can be misleading. If no objections let’s call the currently active list “Playlist” (colored list to the left of the main view).
When a new Song is added to the Project, it will be added in the Playlist. This will not be changed for obvious reasons. If Sync is on, that will also update the current Setlist. When you remove a Song from the current setlist and Sync is on, it will also be removed from the Playlist. I can’t see how that is any different from what you suggest, or why that is harder to understand, maybe you can elaborate. But we will not change the way Songs are added or removed, that would be very confusing.
Most peolple don’t need setlists at all, because you can just save the project as “Setlist257”.