AIMP Forum

AIMP for PC => Skin Editor, Skin Engine => Вопросы / Questions => Topic started by: flynnz on July 20, 2023, 04:19:20

Title: Tape progression animation question
Post by: flynnz on July 20, 2023, 04:19:20
I did search for an answer to this first, but couldn't come up with an answer. Probably because of my wording. So hopefully my explaination makes sense.

By default the tape player animations all seem to be just the length of the song being played (how long it takes for the tape to go completely from one reel to the other), is there any way to make the timing match the length of a playlist instead? This would make it feel more inline with how a real tape cassette would function. Thanks!

Title: Re: Tape progression animation question
Post by: Black_AVP_Bim on July 20, 2023, 10:42:48
У скиноделов нет информации о позиции воспроизведения в плейлисте, поэтому реализовать это невозможно.
Задумайтесь сами на минутку: плейлист может динамически (налету) изменяться. Пользователь может изменить порядок сортировки, удалить или добавить треки в плейлист, переключиться на другой плейлист или вообще удалить его. Отследить всё это невозможно, да и не имеет смысла. Плейлист может содержать всего один трек, а может и несколько тысяч. В последнем случае перемотку ленты можно и за целый день не заметить.
Есть скины, в которых лента перематывается просто за фиксированное время, но не синхронно с плейлистом, но без автореверса это смотрится нелогично, а автореверс присутствует далеко не вовсех аппаратах.
Поэтому вполне логично выглядит перемотка ленты за один трек, наглядно демонстрирует позицию воспроизведение в треке, своего рода прогрессбар.

Skin makers do not have information about the playback position in the playlist, so this is impossible to implement.
Think for a moment: a playlist can change dynamically (on the fly). The user can change the sort order, delete or add tracks to a playlist, switch to another playlist, or delete it altogether. Tracking all this is impossible, and it does not make sense. A playlist can contain just one track, or maybe several thousand. In the latter case, the rewinding of the tape may not be noticed for the whole day.
There are skins in which the tape is rewound simply for a fixed time, but not synchronously with the playlist, but without auto-reverse it looks illogical, and auto-reverse is not present on all devices.
Therefore, rewinding the tape for one track looks quite logical, it clearly demonstrates the playback position in the track, a kind of progress bar.
Title: Re: Tape progression animation question
Post by: flynnz on July 20, 2023, 14:07:50
The playlist dialog and media library box already have the "dynamic" time of the entire group of songs being played. The software also (of course) tracks what the current playback time of the track. As far as updating the playlist causing an issue, well the tape animation would simply reset itself to the proper position/speed to reflect the new adjusted playlist. For example if I add a song that makes the total playtime longer, the animation would grab the total playlist time along with the current playback time and with that information have the new animation switch postition and speed. It would still "jump" to that new animation everytime I add/remove/change the playlist, but that is not a big deal at all because the session once adjusted would playback as intended from then on. Again, the total time, current time and current track are all already being updated in real time, so adding or removing tracks would not matter at all.

As far as skinmakers not having the data needed, I can't speak to that, but I can say all the information IS in the app itself. The displays show track time and as stated above, total playlist time in the dialog box for both playlists and when playing back multibile files from the music library. So if you are saying it's not available to the people who are making the skin/creating the animation timing, it should be pretty simple to pass that info. Wheather or not it's worth doing is another question.

And while I agree with you that 1000 songs would be silly to use with accurate animation timing, you can easily have an option to switch back to the 1 song mode animation so it can function as it currently does. I am just saying it would be cool if you can SWITCH to a 'realistic' animation mode for when you have a playlist/group of songs that is smaller and indicitive to the length of a real tape/CD/record. (And since these are virtual tapes, it would be okay if they played a bit longer to accomadate the full album on one side :) )

And if you like to use the tape animation as a progress bar for each song, again, you simply shut off "realistic" mode. (or never use it all!)

Honestly, I just think it would add more realism to an already fantastically realistic experience. No big deal either way and for all I know no one else cares about it (though I am betting many others would like it too).

Thank you for the response.



Title: Re: Tape progression animation question
Post by: Black_AVP_Bim on July 20, 2023, 15:28:18
... Honestly, I just think it would add more realism to an already fantastically realistic experience.
Согласен с Вами, это выглядело бы реалистично для тех, кто слушает музыку альбомами, то есть для кого плейлист = альбом.
Подобные вопросы возникают уже давно и с приличной регулярностью, но в существующей реализации плеера мы можем оперировать только с играющим треком.
Оформите тему как предложение. Насколько технически сложно это будет реализовать сказать может только сам разработчик.

Но тогда возникает другая проблема и, скорее всего, непреодолимая, связанная с навигацией по треку, плейлисту. Рассчитать позицию в плейлисте, я думаю не сложно, зная его продолжительность и суммарное время треков до играющего, но если пользователь нажмёт на ускоренную перемотку вперёд или назад, то позиция в плейлисте может перейти на следующий / предыдущий трек и плеер будет вынужден загружать новый трек в память, рассчитывать его длину и активную позицию в нём, а это дело не быстрое... То есть должна быть обратная связь с плейлистом. Скорее всего это невозможно. Вряд ли кто-то захочет отказаться от ускоренной перемотки при реализации подобной фичи.