0 Members and 5 Guests are viewing this topic.
Теперь чекбокс "Автоматически переходить на следующий файл" стал неактуален. Т.е. его отключение ничего не меняет, переход на следующий/предыдущий трек происходит.
При воспроизведении работает, при перемотке нет.С другой стороны, может, это и логично.
Так, для пользователя практически ничего не изменится, кому надо быстро перейти в начало трека можно повторно нажать PLAY.
Попробовал на своём "ASC AS6002ST", выкинув переход на предыдущий трек и позиционирование в конец трека. Перемотка работает!!!Но! Теперь чекбокс "Автоматически переходить на следующий файл" стал неактуален. Т.е. его отключение ничего не меняет, переход на следующий/предыдущий трек происходит. Мне приходилось принудительно осуществлять переход, дабы обойти этот пункт настроек. Полагаю, что кому-то это не понравится.
Данная редакция перемотки меня устраивает, жду релиза, а пока займусь апдейтом "ASC...", доделаю "Три топора", ну и придётся фиксить все остальные, т.е. доводить до ума
... а пока займусь апдейтом "ASC...", доделаю "Три топора", ну и придётся фиксить все остальные, т.е. доводить до ума
... Так что, рулон с фиксированным временем для магнитофонов, логичнее.
Надо и дальше, если вопрос встанет ребром (и интерес к скинам не заржавеет), не "колхозить", а к Артёму с челобитной
А вот это правильно, +1
К обновлению сделаю скрытую опцию для отключения (мало ли, кому критично будет).
Может, как раз, наоборот, надо сделать эту опцию доступной из скина (в новых скинах), чтоб в прежних она была по умолчанию выключена, а в новых пользователь мог бы её переключить по своему усмотрению.Дело в том, что во всех скинах доселе созданных при перемотке в обратную сторону и достижении начала трека плеер переключался в режим PLAY, иногда в STOP (как в скрипте прописано), сейчас же в этих скинах плеер переходит в PLAY, но в конец предыдущего трека и почти тут же переключается на следующий трек, что выглядит некрасиво и в некоторых скинах нарушает логику работы.
... Но отдавать на откуп пользователя включение/отключение этой опции не стоит. Это должно определяться скиноделом, т.е. обновлённый режим перемотки должен включаться в редакторе. Я так думаю.
Пожалуй, ты прав. Это надо задавать в проекте скина, вот только к какому элементу это пристроить.Но, всё-таки, лучше иметь возможность переключения этой опции. В том же Revox'e в режиме "ТРЕК" хотелось бы сохранить прежнее поведение, а в режиме "ПЛЕЙЛИСТ" - сквозную перемотку.
А я ведь не просто так спросил, используются ли где-то костыли для реализации этого поведения...
Обратная перемотка с переходом на предыдущий трек нигде не реализована.
С переходом в STOP - это сделано скриптом подачей команды acPlayerStop при достижении позиции близкой к нулю.
Как отмечали выше, в Билле 2679 сквозная перемотка работает отлично, но сломалось поведение в старых скинах, где обратная перемотка упиралась в начало трека.
Видимо, я не до конца понимаю, что именно сломалось?
А нельзя ли оставить им их стандартное поведение, дополнив "клонами" с обновлённой логикой? В таком случае все старые скины не потребуют "фиксинга", а уж свои три "ASC AS6002 " я доведу до ума в новом редакторе.
Хотелось давно узнать, есть ли возможность создать и использовать возможность масштабирования скинов аудио-аппаратуры.
В бОльшую сторону некоторые скины и сейчас масштабируются за счёт подмены текстур.Уменьшать чисто графически даже в целое число раз - это потеря детализации, некоторые элементы могут вообще исчезнуть, надписи станут нечитаемыми.Сделайте скриншот с запущенного плеера и попробуйте уменьшить его в графическом редакторе, к примеру, в 2.5 раза и посмотрите что будет.
На вложенном видео детализация, если ней в данном примере можно вообще говорить, мягко говоря, хреновая.
Кстати, сейчас стало сложно поймать скриптом начало трека в режиме обратной перемотки, приходится делать отступ более 1 с, и то не на всех треках срабатывает.
С детализацией там всё нормально, стандартное разрешение скина 1920х1080, а видеозахват и масштабирование производилось при 1366х768.
Позволю себе немного флуда…
И чЁ? Резюме то какое?
Я тут подумал, а что нам надо, так сказать, для полного счастья? То есть, чтоб полностью отказаться от колхоза и костылей, может, даже, и от скриптов. Пока две вещи пришли на ум.1. Признак режима перемотки. Когда-то давным-давно я предлагал дополнить свойство/точку доступа prvPlayerState.State ещё двумя значениями (3, 4): перемотка вперёд и перемотка назад. Это позволило бы имитировать перемотку в подобных скинах и от горячих клавиш, и ещё более упростило схему.
2. Перемотка без лонгтапа, т. е. без задержки после нажатия кнопок (не убирая существующий вариант). Позиционирование стало бы намного удобней и оперативней.
prvPlayerState лишь визуализирует состояние плеера, т.е. запуск непосредственно перемотки всё равно будет осуществляться соответствующими командами, теми же acPlayerSeek?
Перемотку трека в этом случае осуществляет сам плеер, нам надо лишь вращать бобины и анимировать рулоны.
Не надо делать "клоны", лучше добавить точку доступа в существующие провайдеры acPlayerSeekBackward и acPlayerSeekForward, тогда и совместимость не нарушится и в новых скинах всё можно проще исправить.
Если будет два провайдера, выполняющих одну функцию, но в разных вариантах, то тебе придётся подключать их к одной кнопке - опять скрипты.
Или "этажерки". Функций много, кнопок мало. Либо обработчики условий, либо скрытие/видимость кнопок-клонов по условию. А в чём криминал? Я так постоянно поступаю...
одним из условий является достижение НАЧАЛА трека
Подозреваю, что в новом билде плеера изменена логика обработки команд acPlayerSeekBackward и acPlayerSeekForward. А нельзя ли оставить им их стандартное поведение, дополнив "клонами" с обновлённой логикой? В таком случае все старые скины не потребуют "фиксинга", а уж свои три "ASC AS6002 " я доведу до ума в новом редакторе.
Хотелось давно узнать, есть ли возможность создать и использовать возможность масштабирования скинов аудио-аппаратуры.О преимуществах такой функции думаю говорить не надо и догадываюсь о недостатках.
Подозреваю, что Артём пошёл моим путём, переход осуществляется не при достижении нуля, а чуть раньше, чтоб наверняка. У меня принудительный переход вперёд (дабы обойти отключенный чекбокс автоперехода) вообще с позиции 95%
и реализуем ли там полный реверс
Судя по тому, что Артём изменил реакцию на эти команды на уровне плеера, будет достаточно какого-то маркёра, указывающего обработчику осуществлять традиционную перемотку в границах трека, либо сквозную, с переходом. Где разместить этот маркёр, добавлением провайдера, или ещё как, тут Артёму виднее. Главное, чтобы оба варианта можно было использовать, в зависимости от задачи.
Перемотку трека в этом случае осуществляет сам плеер, нам надо лишь вращать бобины и анимировать рулоны.К тому же, и у этих провайдеров есть точка State, но она не работает.
Перемотка без лонгтапа, т. е. без задержки после нажатия кнопок (не убирая существующий вариант). Позиционирование стало бы намного удобней и оперативней
1. Признак режима перемотки. Когда-то давным-давно я предлагал дополнить свойство/точку доступа prvPlayerState.State ещё двумя значениями (3, 4): перемотка вперёд и перемотка назад. Это позволило бы имитировать перемотку в подобных скинах и от горячих клавиш, и ещё более упростило схему.
Проверка на 0? Без учета погрешности измерения?
Погрешности нет. На основе длительности трека рассчитывается номер кадра рулона с лентой, кадров в рулоне 200, и трек любой длительности приводится к этому числу. Эти же данные используются для остановки перемотки. И тут ноль в начале трека присутствует всегда.
Да тут простая математика: интервал перемотки задается в настройках, если при расчете новая позиция выходит за рамки трека (< 0 или > duration), то осуществляется переход на предыдущий/следующий трек, и уже от новый трек сдвигается на оставшийся интервал.В принципе, я могу сделать проход навигации через точный 0, чтобы скины могли этот момент поймать и "что-то" сделать.
Декодеры работают в поточном режиме, и декодируют они только вперед. Чтобы сделать нормальный реверс, нужно декодировать трек в память, и уже из памяти его играть. Это вполне реализуемо, но крайне требовательно к ресурсам ПК.
Такой вопрос, этот маркер нужен только для того, чтобы не сломать старые скины? Или вы хотите контролировать поведение и в новых?
Для старых скинов мне видится такой вариант: если сквозная навигация будет проходить через 0, то скрипт в старых скинах отработает и плеер перейдет в стоп (как и должно быть в старом поведении). Да, в этом плане получится, что сквозная навигация и вовсе работать не будет, но что поделать...
Есть еще такой вариант, делаю новое поведение только в AIMP6. Далее, если скин собирается в режиме совместимостью с 6-ой версией, он будет иметь новое поведение без вариантов. В этом случае, можно будет сразу реализовать и эти предложения:
а в новых - на усмотрение скинодела.
Так вот и вопрос, должно ли это быть опциональным на уровне скина? (новых скинов)
Если это делать на уровне скин-движка, то недостатка будет два:1) упадет производительность2) упадет качество картинки
Да, и в новых скинах должна быть возможность переключения/выбора этих поведений.
