HISTORY LOGIC suggestion

Damir

Hi Peter, my mothers day gig worked perfectly thanks to ST3, now i thought i would try using SAVE in history, well it was not easy or logical, why?

Firstly when i chose save, it gave me ALL as one option, then it gave me a particular date of performance option,
i chose the particular date of this gig on the 14th, but as it saved it to my playlists i could not immediately find it , after a bit of searching as i have a large count of playlists i found it under H where it said HISTORY 2023-05-15 15:28:32, , now this is not what i expected SONGS SINCE 14 May 2023 as thats what it said in the option so i expected the exact same naming in the Playlists, this then confused me even more because i was not expecting HISTORY to be the first writing of the new playlist which then placed it way down the list with no clue to what and where it was, to top it all of it then placed HISTORY 2023-05-15 15:28:32 naming of this file , so not only has it placed it somwhere i had no idea where it also placed the wrong date of that history playlist , as it actually renamed it and placed the current date and time of when i actually was looking at the history, now by chance this was the next day but it could be weeks out, which makes no sense at all because if i was to create multiple playlists from a long history i would have no idea which history is which as they would all be labeled the same with varying timestamp, this is no help at all, on top of all that i would never use year month day time order as we all know what year and month we are in TO ME DAY MONTH YEAR ORDER WITH A TIMESTAMP AT THE END AND THEN WRITE HISTORY LAST, this way when you save history having a day being a number will most likely place it at the begining of the playlists which will be easily found , i would then make sure whatever you name the SAVE option to be the same as what you end up in PLAYLISTS, example 14 / 05 / 2023 HISTORY this then is exactly what you get in Playlists, so making it simple and easy to find, we are not interested to when we are actually creating playlists Date from history but we are interested to which history date we are working with and this is the date that should remain in the naming of new playlists, we can then relate to which history dates we are working with till we decide to rename them to create a new playlist.

I hope this makes sense, but what i was actually trying to do was print out my history of my gig as i discovered this non logical mess, because you cant just print a list in history i was forced to create a playlist but then when you export the playlist in to a simple text and you find this text file if you press on it you expect the text to open up in a text editor, but no this file now immediately loads itself back to ST3, this makes no sense as normally you want to open this file see it then print it, why would you want instantly to reload it back to ST3 it makes no sense, at least an option to choose which function you want, the only way i actually stumbled on how to print the history is to long press on this file then choose Quick Look then it actually gave me an option to print.
This is so hard to do and it should be as simple as when you hit SAVE in history you should also get a print option and just hit it and its done.
At the moment as i have pointed out you need to be a mind reader and a genious to print a history selection.

Soon i will give iCloud a good test but the app seems to be very stable on both ipad and iphone, so great work.
Cheers Damir

peter

I think it is much easier to find these playlists when they all start with "History" and the current timestamp. You want to rename these after creation anyway.

Damir

peter thats if you are aware they start with HISTORY at the moment you have no idea where to look as the files are a saved with SONGS FROM 14 may , in playlists you have no clue that its H you are looking for to find this history plus its then the wrong history date not related to the day of the gig but the date you happen to use history , this has no relationship to anything, and if you want to create multiple playlists from the history list you have no idea to which file is to do with which history list in the playlist, all you have is a timestamp to recognise different playlists, this is no help at all, and by being a numeric day from 1 to 31 first there is a lot more chance it will be at the begining of playlists than having a H TO LOOK FOR THAT YOU ARE NOT AWARE OF.
You are looking at it from already knowing its logical operation point of view i am looking at it from a first time users point of view.

Damir

peter You want to rename these after creation anyway.

Thats the last thing i want to do , i would want to go home and look at it possibly days after while preparing for next gigs , by then the dates would all be wrong and without meaning with current logic in place.

Damir

peter I think it is much easier to find these playlists when they all start with "History" and the current timestamp. You want to rename these after creation anyway.

Hi Peter, perhaps i didnt explain myself clearly in the previous writings,
I believe there are two reasons for history,
One is on stage you can easily find a previous song you played and play it again and that works fine.

The other reason is if you have had a great gig due to a great song selection order and you have a similar gig comming up you can easily use history to create the new gig, now this is a great thing, BUT it is not well implemented in how it is used, the thing to remember is we relate to the great gig by date and name of gig, so this has to be preserved in our workflow otherwise we loose track of whats going on , especially if we are trying to use history a number of days later or perhaps weeks later.
When using history we might want a printout of a particular gig, this should be available as a primary choice , if we then want to create a new playlist from history it should be also easily done by date as it is now except when its created the new playlist needs to be a thing we can relate to and thats the date of the actual original gig not the todays date and time as this has nothing to do with it, it also creates a problem if you happen to be creating two gigs from history as they both end up the same name with a slightly different time stamp, which means nothing to us if we have gone to lunch and come back to work on the new playlists you have no idea which is which, the existing way of lableing is the issue.
We dont need time stamp , we need the DATE example 14 / 05/ 2023 HISTORY , thats all and this then to transfer to the actual playlist, which will also place it at the top of the list beeing numeric as all our playlists are probably named , so then when we get presented with the new playlist immediately we can then examine it tweak it and then rename it to the next gig.
Now this then gives us clear knowledge of which history we are dealing with no matter how many gigs we decide to work on in one day.

Your existing logic fails because it changes the nameing and date to a playlist which unless you read the instructions you will not find the playlist very easily as it gets thrown in to the H History area which is way down the playlists list and you have no idea what it was named and you also loose track of which gig you are dealing with.

I hope this makes better sense

All we need is
14/05/2023 HISTORY in SAVE
and
14/05/2023 HISTORY in PLAYLISTS

Another thing i did not check but would be great if it could be done is if you start a gig at a particular date and time like 14/05/2023 time 2200 and you finish the gig 15/05/2023 time 0300 it would be great if that gets treated as one gig not two different gigs beeing a different date, perhaps allow a 12 hour window for each gig so if your gig starts on the 14th at 2200 it is treated as one gig till the 15th 1000, that way your history will always contain the whole gig when choosing the primary date, if your gig goes over 12 hours then its treated as another gig.

This would then package all gigs in to slots and not have new gigs interfere with old gigs, that way history really becomes a useful HISTORY TOOL not just a last gig tool.