0 Members and 1 Guest are viewing this topic.
Тут и старые скины будут работать, и в новых, реализация хоть старого, хоть нового поведения не вызовет сложностей.
Догадывался, поэтому, если есть такая возможность, ещё пара вопросов:1. Сделать отключаемую масштабируемость в настройках интерфейса проигрывателя.2. При включеном режиме масштабируемости будет ли разница в снижении производительности / качества, между ручным (произвольным) изменением масштаба и фиксированным / автоматическим под разрешение монитора.
Если текстур нет, и на стороне скина разрешено менять масштаб на произвольный, движок плеера будет сам растягивать текстуры до нужного размера. В этом случае будет "мыльцо" и просадка производительности
Это работает только с увеличением размера, а если необходима небольшая коррекция в сторону уменьшения (с соблюдением пропорции сторон), чтобы вписать скин в меньшее разрешение экрана?
В данный момент да, только в сторону увеличения, но технически можно попробовать сделать и в другую сторону.
Поэтому я и указывал на отключаемую масштабируемость в настройках проигрывателя, чтобы пользователь сам выбирал между производительностью и желанием вписать понравившийся скрин в своё разрешение монитора, с частичной потерей качества.
Тут есть другая проблема. У магнитофонных скинов как правило лишь главное окно огромное, а все остальные - обычные. Чтобы вписать скин в маленький монитор, нужно делать настройки масштабирования для конкретного окна, а не как сейчас - для программы целиком
А в сторону увеличения как работает?
Да, и в новых скинах должна быть возможность переключения/выбора этих поведений.
Тогда получается, пользователь не сможет это поведение никак контролировать.
1) Делаю отдельные acPlayerSeekForwardContinuous/acPlayerSeekBackwardContinuous.
Почему не сможет? Я уже попытался в последнем скине Revox B 77 v2 это реализовать, но получилось только переключить режим счётчика времени на плейлист, а старое поведение (навигация внутри текущего трека) при этом сломалось, на этом скине я это и заметил. Выбор и здесь хотелось оставить за пользователем, управление режимами - на счётчике по контекстному меню.
Переход через ноль при перемотке по плейлисту, конечно, тоже желательно бы иметь, наверное, можно для этого использовать нотификацию prnPlayerState.onTrackFinished.
Я по-прежнему считаю, что это неудачное решение. Придётся к одной кнопке подключать два провайдера, а это опять, в лучшем случае, скрипты или "этажерки".
Если бы была возможность переключить и провайдер acPlayerSeek... на прежнее поведение, то было бы замечательно
Я имел в виду через настройки плеера, а не скин.
Можно, конечно, и опцию на стороне имеющихся провайдеров сделать, но ее все равно нужно будет как-то переключать... через биндинг или скрипты.
В любом случае, старые скины новую возможность не подцепят. Вот о чем речь
Если будет дополнительная точка доступа Continuous в провайдере acPlayerSeekBackward и к ней ничего не будет подключено, старые скины никак не пострадают и будут работать с прежним поведением
Со стопом в начале - да, получится. А вот реализовать поведение как сейчас - уже не получится.
Переход точно через Стоп исключает сквозную перемотку? А в чём причина?
Я имел в виду текущее поведение - переход в 0 с сохранением статуса плеера.
Не понял Сейчас плеер ноль перескакивает, и плеер, как был в режиме воспроизведения, либо на паузе, так и остаётся. А если через ноль, то что?
я про актуальный релиз
Актуальный - это 2675? Я про него и забыл, жду 2680
А смысл? Если мы решили, что это все должно быть опциональным на уровне скина, а не плеера?
Однако, незадача - чем переключать режимы перемотки по точке доступа?Счётчики при таком подключении только принимают информацию, а не передают:
И ещё один неприятный момент при нынешней реализации перемотки по плейлисту.При перемотке в обратную сторону в момент перехода на предыдущих трек на счётчике времени (глобального по плейлисту) сначала отображается время начала трека, а потом уже реальная позиция в плейлисте. Соответственно и рулоны ленты в такт этому прыгают.
Заглянул в Планы и Планы, и что-то мне стало грустно. Казалось, вот оно, решение практически есть, а до шестёрки, как до морковкиного заговенья...
Мне в реализации очень сильно мешает опциональность поведения, что должна реализовываться на уровне скинов.
Вообще говоря, если порассуждать, это опциональным вообще быть не должно: перемотка вперед у нас же работает всегда в сквозном режиме, без каких либо настроек. С обратной перемоткой должно быть так же.
Опциональность в данном случае нужна в основном, чтоб не потревожить старые скины. Я про опциональность на уровне скина.У меня, честно говря, нет никакого желания править скины 10-летней давности, от некоторых уже и проектов нет.
Проверил на 2675, дефотный скин, "перемотка" горячими клавишами Ctrl+стрелки. Если отключить чекбокс "Автоматически переходить на следующий файл" то никакой сквозной перемотки вперёд нет, не только на Паузе, но даже и при Воспроизведении!
2) поправил косяк с TASEPlaylist.PlaybackPosition при сквозной перемотке
Но иногда случаются перескоки через трек, иногда через два, а пару раз вообще за раз перескочило через три или даже четыре. Повторный запуск в той же зоне прошёл без перескоков , так что причина неясна. А было и наоборот, когда дважды перематывался один и тот же трек
Артём, низкий поклон тебе, за то что столько внимания уделяешь скин-движку!
Но иногда случаются перескоки через трек, иногда через два, а пару раз вообще за раз перескочило через три или даже четыре. Повторный запуск в той же зоне прошёл без перескоков , так что причина неясна. А было и наоборот, когда дважды перематывался один и тот же трек.
3) у TASEButton.ActionOnHold больше нет задержки, если на Action и ActionOnHold висит одно и тоже действие.
Шафл, часом, не включен? Сегодня с утра гонял по разным плейлистам (flac, ogg, mp3), проскоков ни одного не было, что вперёд, что назад.
Свойство State у провайдеров acPlayerSeekХХХ теперь работает, но отключается с заметной задержкой (с 1 на 0).
Первые впечатления: старые скины работают как обычно.На тестовом скине включил Continuos в OnLoaded. Сквозная перемотка работает. Но иногда случаются перескоки через трек, иногда через два, а пару раз вообще за раз перескочило через три или даже четыре. Повторный запуск в той же зоне прошёл без перескоков , так что причина неясна. А было и наоборот, когда дважды перематывался один и тот же трек.
Точка State у провайдеров acPlayerSeekХХХ теперь работает, но отключается с заметной задержкой (с 1 на 0).
Вот сборка, попробуй: https://disk.yandex.ru/d/-Om0zR4gi_AZiw
Прокрутил полторы сотни треков - ни единого сбоя! Спасибо!Хотелось бы ещё 64-х битную версию поюзать.
Среди ночных есть: https://disk.yandex.ru/d/VHE42X-nX_PMuA
Полёт нормальный, сбоев нет!
Так сбои были только на архивах?
Единственное, что при длительном удержании комбинации Ctrl+стрелки, виснет вся анимация: бобины крутятся рывками, замирают индикаторы уровня и счётчик, ну и т.д...
Я уж всё проверил, сделал себе стенд для экспериментов на основе Bliss Lite, добавил туда бобинки, рулоны, свой счётчик с переключением режимов перемотки.Перемотка от горячих клавиш работает что-то уж очень быстро, в разы быстрее, чем от кнопок в скине. Небольшие рывки бобин есть при смене трека, но они одиночные, особо и не заметно при вращении разблюренных бобин. Индикаторы в режиме перемотки и не должны почти ничего показывать, если в настройках отмечено "Затухание звука при навигации", счетчик времени нормально работает.
Ну, так она и от кнопок понизится, и всё равно от клавиш в разы выше остаётся.
Это задается на уровне ОС:
плеер пытается воспроизвести трек с начала, а перемотка его "давит".
Что ты под этим подразумеваешь?
