0 Members and 1 Guest are viewing this topic.
Как ни странно, получилось поймать оба нуля вот таким образом, если, конечно, пользователь не переключит таймер на обратный отсчёт времени (но это победимо):
Мне кажется, тут можно повеситься на строгий 0 у точки доступа Progress
Тут другая бяка вылазит. Если включить перемотку назад в самом начале трека (менее 1% от его продолжительности, для длинных треков это может быть несколько секунд), то перемотка не останавливается, а в прямую стороны включается, но прерывается после достижения позиции > 1 с.Видимо, не хватает дискретности, там же Integer.
Не понятно, почему скриптом по Position ноль не ловится, какая-то асинхронность, что ли...
Скрипт у тебя по какому событию запускается?
По таймеру.Нашёл, в чём дело - мой косяк, неправильно был указан модуль счётчика. Блин, так можно было долго дурака валять!Работает сейчас.
По таймеру тоже не очень хорошо - обновление позиции тоже по таймеру происходит, и может случиться так, что позиция обновится до того, как отработает скрипт
Я понимаю, что это нехорошо, как, впрочем, и любой лишний таймер в скине. В принципе можно тактировать скрипт от prvPlayState.TrackPosition, но мне нужно, чтоб и режиме STOP отображались изменения в рулонах при изменении позиции в плейлисте, а так же при смене режимов перемотки.Интервал таймера 100 мс, но в скрипте нехитрые вычисления и, если изменений никаких нет, то и перерисовки не происходит. Так что, систему он не грузит.
Кстати, для AIMP6 у меня есть одна идея касательно текстур с большим набором кадров для аниматоров: я хочу попробовать сделать хранение кадров как в GIF-е ...
Так, у GIF-ов глубина цвета 8 бит, на градиентах даже в адаптивной палитре будут ступеньки.Надо ещё проверить, сможет ли ФШ собрать GIF-аниматор из сотен слоёв, да ещё большого размера.
Речь про то, что текстуры будут храниться в сжатом состоянии (по кадрово) и распаковываться на лету. Все это собирать и сжимать будет редактор при сборке скина. На данный момент я вижу лишь один минус такого подхода - понижение fps. На тестовом примере оно незначительное, а как будет на боевом - пока сложно оценить.
ЕМНИП, мы это уже проходили, из-за тормозов и отказались.
Я для сжатия текстур / графики пользуюсь утилитой Riot. В PNG для уменьшения размера файла можно выбрать Политру цвета / Количество цветов / Уровень сжатия и т.п. Визуально сравнивается полученный результат с оригиналом. При выборе оптимальной палитры размер файла может уменьшится в несколько раз.
В магнитофонных скинах используются текстуры с огромным количеством кадров. В распакованном виде такая текстура может занимать в памяти 100ти МБ. Моя идея заключается в том, чтобы распаковывать не картинку целиком, а конкретный кадр для отрисовки
Большие текстуры используются в основном в скинах бобинных магнитофонов, а такие скины даже в формате FullHD далеко не у все нормально работают
А память, что её особо экономить? Посмотрел на своём самом "тяжёлом" бобиннике - расход её порядка 1 ГБ, браузер больше потребляет.
Если всё оптимизировано, то и на слабом железе будет всё работать нормально.
Сколько тогда потребуется памяти если запустить "тяжёлый" бобинник с полноэкранной визуализацией (Milkdrop2, AVS и т.п.)?
Считаю не верным такой подход. Аудио-проигрыватели не должны потреблять гигабайты памяти ...
Посмотрел на своём самом "тяжёлом" бобиннике - расход её порядка 1 ГБ, браузер больше потребляет.
Заблуждаетесь, никогда не будут эти скины работать на слабом железе. И дело тут вовсе не в памяти, а в производительности процессора
Если будет полноэкранная визуализация, то тогда зачем сам бобинник? Подобные скины создаются не для того, чтоб визуалками любоваться.
Запустил на старом ноутбуке (10 - 12 лет, Celeron 877) Technics-RS-1700-4K, бабины, индикаторы и счётчик работают достаточно плавно.
А вы уверены, что бобины крутятся с той скоростью, которая задана? И ни одно ядро не перегружено? Чудеса ...
Что за "одинаковая плавность".
Сравнивал работу скина на новом и старом ноутбуке.
Если Вам ещё интересно попытать своё железо, могу предложить небольшой тест.
На видео с Technics-RS-1700-4K небольшие подёргивания связаны с работой программы видеозахвата и паралельной записи на HDD.
Это не подёргивания, это тормоза. Реально бобины вращаются в разы быстрее.
Вас ещё спасает, что система х32, на х64 бобины если бы и вращались, то индикаторы и счётчик вообще бы стояли или изредка подёргивались.
Сравнивал вращения бабин на новом / старом - одинаковые, при скорости 9.
Значит и на новом тормоза. Мы в скинах стараемся и скорость вращения бобин какая она есть в реальном аппарате. А как на видео - это разве на скорость 4 см/с потянет и то с натяжкой.
На новом при переключении с 9 на 19 / 38 изменяется в разы. Поэтому считаю так задано автором.
Артём, тут на фоне последних экспериментов, мысль возникла. Нельзя ли сделать тестовый компонент по виду как DigitsDisplay, который можно было вставить в скин, а в запущенном плеере он показывал бы реальный FPS. Это нужно только на стадии проектирования/отладки скина и, возможно, позволило бы что-то оптимизировать.
Реально в этом скине эти скорости в 2 раза ниже, поскольку скорость 38 при таком числе кадров в аниматоре реализовать невозможно, а уменьшать число кадров в ущерб плавности вращения я не стал.
Но у меня на мониторе бобины вращаются намного быстрее, чем на видео.
Я нашёл причину, буду фиксить. Начну с Пионеров. Скачать скины можно будет здесь.
Только не пойму тогда как такое возможноесли только выставлена скорость 38, тогда да...
Кстати говоря, текстуры с вертикальной раскладкой рисуются быстрее.
А насколько быстрее?
И ещё вопрос: будет ли релизная версия 5.40 с последними нововведениями или ждать 6-ку?
Я пробовал на аниматоре размером 1000х1000 с 90 кадрами, 10000 перерисовок выполняется за 4.7 секунд при горизонтальной раскладке, и за 4.2 при вертикальной
Это ж 2380 кадров/с ! 420 мкс интервал. Что за железо у тебя, если не секрет?У меня аниматоры 960х960 с интервалом меньше 10 мс хоть и вращаются, но остальная анимация уже лагает.
Сделал у плейлиста свойства PlaybackPosition, PlaybackDuration (доступны только из скриптов).
В плане использования этих данных для реализации рулона, длительностью в плейлист, в магнитофонных скинах. Есть два замечания.1. Данные считываются для Активного плейлиста. Т.е при прокрутке плелист-табов рулон и позиция будут синхронно перерисовываться. При окончании текущего плейлиста и автоматической его смене на другой (если так настроено), рулон останется привязан к отыгравшему плейлисту. Было бы правильнее, если бы PlaybackPosition и PlaybackDuration брались у Играющего плейлиста.2. Отключенные треки в плейлисте считаются проигранными, на общей продолжительности плейлиста это не сказывается. Начальная позиция сдвигается на продолжительность отключенных треков. ИМХО, было бы правильнее отключенные треки исключать из продолжительности плейлиста.
При окончании текущего плейлиста и автоматической его смене на другой (если так настроено), рулон останется привязан к отыгравшему плейлисту.
Только в случае, если курсор находится над плейлистов. Сейчас, вроде, есть на это опция.
Отключенные треки в плейлисте считаются проигранными, на общей продолжительности плейлиста это не сказывается
