[FAQ] Вопросы по работе в AIMP SkinEditor v3.50+

[Black_AVP_Bim]

А я ведь не просто так спросил, используются ли где-то костыли для реализации этого поведения...

Обратная перемотка с переходом на предыдущий трек нигде не реализована.
Перемотка в начало трека с переходом в PLAY - это стандартное поведение плеера, как всегда было. С переходом в STOP - это сделано скриптом подачей команды acPlayerStop при достижении позиции близкой к нулю.
"Костылями" это, вроде, не назовёшь.

[McClaud]

А я ведь не просто так спросил, используются ли где-то костыли для реализации этого поведения...

Непрерывная перемотка назад впервые применена в моих "ASC", но они пока не опубликованы. Реализация на двух скриптах. Первый осуществляет переход на предыдущий трек и, через делайер, запускает второй, позиционирующий в конец трека. Делайера необходим на время инициализации трека. При 50 мс ещё случаются несрабатывания, при 100 мс - вроде успевает.
Как отмечали выше, в Билле 2679 сквозная перемотка работает отлично, но сломалось поведение в старых скинах, где обратная перемотка упиралась в начало трека.

[McClaud]

Обратная перемотка с переходом на предыдущий трек нигде не реализована.

Мне не удалось реализовать отслеживание инициализации трека, после срабатывания первого скрипта. Пришлось просто подобрать задержку делайера. Вот это точно колхоз, хотя и работает.

[Artem]

С переходом в STOP - это сделано скриптом подачей команды acPlayerStop при достижении позиции близкой к нулю.

Как отмечали выше, в Билле 2679 сквозная перемотка работает отлично, но сломалось поведение в старых скинах, где обратная перемотка упиралась в начало трека.

Видимо, я не до конца понимаю, что именно сломалось?

[McClaud]

Видимо, я не до конца понимаю, что именно сломалось?

Обратная перемотка в старых скинах доматывала до начала трека и либо останавливалась, до отпускания клавиши, либо плеер переходил в состояние предшествующее началу перемотки, - Плей или Пауза. Останов перемотки осуществляется по биндингу, одним из условий является достижение НАЧАЛА трека. Но в билде 2679 происходит перескок на предыдущий трек, причём почти в его конец. Разумеется, что условия остановки перемотки не соблюдаются, плейер переходит в режим Плей или Пауза но не в начале трека, откуда была запущена обратная перемотка, а в конце предыдущего, на который осуществился перескок.
Подозреваю, что в новом билде плеера изменена логика обработки команд acPlayerSeekBackward и acPlayerSeekForward. А нельзя ли оставить им их стандартное поведение, дополнив "клонами" с обновлённой логикой? В таком случае все старые скины не потребуют "фиксинга", а уж свои три "ASC AS6002 " я доведу до ума в новом редакторе.

[MCW]

Хотелось давно узнать, есть ли возможность создать и использовать возможность масштабирования скинов аудио-аппаратуры.
О преимуществах такой функции думаю говорить не надо и догадываюсь о недостатках.

Пример работы с такой возможностью на древнем ноутбуке с минимумом памяти:

https://disk.yandex.ru/i/LgeT9jPDPN8xCA

[McClaud]

А я ведь не просто так спросил, используются ли где-то костыли для реализации этого поведения...

Терминологическое недопонимание. Ты спрашивал про обратную перемотку вообще, а мы имели ввиду сквозную, с переходом на предыдущий трек, которую до "ASC" и не пытались реализовать. А просто обратная, в границах трека, используется повсеместно.

[Black_AVP_Bim]

А нельзя ли оставить им их стандартное поведение, дополнив "клонами" с обновлённой логикой? В таком случае все старые скины не потребуют "фиксинга", а уж свои три "ASC AS6002 " я доведу до ума в новом редакторе.

Не надо делать "клоны", лучше добавить точку доступа в существующие провайдеры acPlayerSeekBackward и acPlayerSeekForward, тогда и совместимость не нарушится и в новых скинах всё можно проще исправить.

Кстати, сейчас стало сложно поймать скриптом начало трека в режиме обратной перемотки, приходится делать отступ более 1 с, и то не на всех треках срабатывает.

[Black_AVP_Bim]

Хотелось давно узнать, есть ли возможность создать и использовать возможность масштабирования скинов аудио-аппаратуры.

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

[MCW]

В бОльшую сторону некоторые скины и сейчас масштабируются за счёт подмены текстур.
Уменьшать чисто графически даже в целое число раз - это потеря детализации, некоторые элементы могут вообще исчезнуть, надписи станут нечитаемыми.
Сделайте скриншот с запущенного плеера и попробуйте уменьшить его в графическом редакторе, к примеру, в 2.5 раза и посмотрите что будет.

При грамотном подходе уменьшать масштаб в разы не потребуется, с потерей части детализации согласен, но тут уж ничего не сделать, зато появляется возможность использования на любом мониторе.

Данное изображение уменьшил в 2 раза, оригинал:
https://static.onlinetrade.ru/img/fullreviews/84832/3_big.png

Если в качестве Основного разрешения скина взять средние значения современных мониторов (1920х1200 - 2560х1440), то уменьшать в разы не придется.
Из за большого разнообразия мониторов понимаю, что не возможно создать универсальный скин, который бы полностью помещался при небольшом разрешении и не "терялся" на больших экранах.

Мне так кажется, но спорить с авторами скинов не собираюсь.

На вложенном видео детализация, если ней в данном примере можно вообще говорить, мягко говоря, хреновая.

С детализацией там всё нормально, если при просмотре выбрано максимальное качество видео, стандартное разрешение скина 1920х1080, а видеозахват и масштабирование производилось при 1366х768.

[McClaud]

Кстати, сейчас стало сложно поймать скриптом начало трека в режиме обратной перемотки, приходится делать отступ более 1 с, и то не на всех треках срабатывает.

Подозреваю, что Артём пошёл моим путём, переход осуществляется не при достижении нуля, а чуть раньше, чтоб наверняка. У меня принудительный переход вперёд (дабы обойти отключенный чекбокс автоперехода) вообще с позиции 95% 

[McClaud]

Позволю себе немного флуда…

Думается мне, что назначение команд acPlayerSeekBackward и acPlayerSeekForward – быстрое позиционировании внутри трека. Перемоткой они не являются, на чём неоднократно заострял внимание Артём. То, что acPlayerSeekForward позволяет сквозной переход («из коробки», как отметил Александр), обусловлено наличием опции «Автоматически переходить на следующий файл» и «попутным» воспроизведением. С acPlayerSeekBackward несколько сложнее. Если взять условную фразу «РррааазззДддввваааТттррриии», то при обратной перемотке получим «ТриДваРаз», а не «ИртАвдЗар». Для того, чтобы и здесь осуществлялся автопереход на следующий (в данном случае предыдущий) трек, необходимо реверсировать воспроизведение. При этом начало и конец трека меняются местами, позиции инвертируются, и перемотка, дойдя до конца трека (а по факту, до его начала), перейдёт к началу следующего (по факту – в конец предыдущего). Т.е. работа acPlayerSeekForward, но в режиме обратного воспроизведения. Сам эффект воспроизведения в обратном направлении может быть востребованным, а если снабдить его колесом/скроллом для быстрого позиционирования взад/вперёд – диджеи будут в восторге.

[Black_AVP_Bim]

С детализацией там всё нормально, стандартное разрешение скина 1920х1080, а видеозахват и масштабирование производилось при 1366х768.

Ну, вот они, плоды уменьшения. Разрешение оригинала 1920х1080 ещё не говори о том, что там высокая детализация. Не побоюсь сказать, что все скины аппаратуры для FullHD, что здесь представлены смотрятся довольно грубо. При рисовании в таком разрешении приходится порой мелкие элементы, шкалы стрелочников и т. п. рисовать сначала в увеличенном масштабе, затем уменьшать со сглаживанием, получается мыло, теряется текстура поверхностей. Плюс проблемы с надписями, в рамках FullHD они порой получаются меньше 5 пикселей, что невозможно реально отобразить, приходится увеличивать шрифт, искать шрифты которые сносно отображаются в мелком кегле, пусть даже немного другого стиля.
В 4К и выше все эти проблемы отпадают, а на мониторе с диагональю 27" и более тот же кассетник можно нарисовать в натуральную величину, а это уже эффект присутствия.
Сейчас не припомню, но где-то Артём объяснял, что есть и технические проблемы при уменьшении текстур, поэтому уменьшения скинов явно не предвидится.

[Black_AVP_Bim]

Позволю себе немного флуда…

И чЁ? Резюме то какое?
Я тут подумал, а что нам надо, так сказать, для полного счастья? То есть, чтоб полностью отказаться от колхоза и костылей, может, даже, и от скриптов. Пока две вещи пришли на ум.
1. Признак режима перемотки. Когда-то давным-давно я предлагал дополнить свойство/точку доступа prvPlayerState.State ещё двумя значениями (3, 4): перемотка вперёд и перемотка назад. Это позволило бы имитировать перемотку в подобных скинах и от горячих клавиш, и ещё более упростило схему.
2. Перемотка без лонгтапа, т. е. без задержки после нажатия кнопок (не убирая существующий вариант). Позиционирование стало бы намного удобней и оперативней.

[McClaud]

И чЁ? Резюме то какое?

Да это так, мысли вслух. Учитывая грядущий закат десктопной версии, не думаю, что стоит надеяться на столь глобальные нововведения. Я не в курсе, как устроен движок воспроизведения плеера, и реализуем ли там полный реверс. А было бы прикольно 

Я тут подумал, а что нам надо, так сказать, для полного счастья? То есть, чтоб полностью отказаться от колхоза и костылей, может, даже, и от скриптов. Пока две вещи пришли на ум.
1. Признак режима перемотки. Когда-то давным-давно я предлагал дополнить свойство/точку доступа prvPlayerState.State ещё двумя значениями (3, 4): перемотка вперёд и перемотка назад. Это позволило бы имитировать перемотку в подобных скинах и от горячих клавиш, и ещё более упростило схему.

prvPlayerState лишь визуализирует состояние плеера, т.е. запуск непосредственно перемотки всё равно будет осуществляться соответствующими командами, теми же acPlayerSeek? Но это не перемотка. Может вот тут и подошла бы перемотка реальная?

2. Перемотка без лонгтапа, т. е. без задержки после нажатия кнопок (не убирая существующий вариант). Позиционирование стало бы намного удобней и оперативней.

Ну, я лично следую "традиции" лишь из-за желания сохранить изначальное назначение клавишь PrevTrack - NextTrack, а свободных для перемотки без задержки как правило и нет. Можно сделать наоборот: нажал - перемотка; лонгтап - переход; ПКМ - ещё что0то там... Вот только боюсь, - не поймут.