0 Members and 1 Guest are viewing this topic.
А у acPlayerSeek... можно State считать скриптом?
Напрямую, как видишь, нельзя, может через BindingsGetDataAsInteger. А зачем его считывать? Биндинг в этом случае намного проще.
У меня скрипт переключает вид бобины: чёткий/смазанный.
Я оба State подал на коммутатор, а с коммутатора на скрипт. счётчик для переодевания бобин.
... "аниматор" бобины един, сменяются лишь текстуры.
Так это ес-но, я не понял в чём проблема, зачем нужно считывать скриптом State?
Что перемотка продолжается, позиция в треке стоит близко к 0 (может, колышется), а у нас бобины при этом вертятся, поскольку State = 1.Пробовал вырубить State через acPlayerSeekBackward.Checked, но, похоже, это свойство не публично или read only.updА, ведь, точно время в этот момент "колышется", где-то в пределах до 0.3 сек, пока не отпустишь кнопку. Тогда переходит в PLAY.В перерывах между rewind плеер пытается воспроизвести трек с начала.
State это и есть признак перемотки, через коммутатор он передаётся на счетчик, тот в свою очереь по этому значению и переключает на разблюренную текстуру бобины.
Если ты хочешь, чтобы бобины в данном случае переставали вертеться - тогда нужно закладываться именно что на текущую позицию, а не факт перемотки.
Так у меня же там и смена просто бобин, в одном скрипте
Так вот и получается, что опять надо скриптом отлавливать начало трека,
Ну, зря ты так сделал. Тут нужна другая структура ресурсов. Для каждой бобины должен один пункт-ссылка, например "Bobina", тот в свою очередь должен ссылаться на ещё два пункта-ссылки: Bob и Bob_b (обычная и размытая).Сами же текстуры будут в списке ресурсов парами: Bob1, Bob1_b, .... BobN, BobN_b. Вот их и надо отдельным скриптом подставлять в Bob и Bob_b (переключать их будт пользователь).А Bob или Bob_b в Bobina при перемотке.
Т. е. скриптов два? У меня структура текстур именно, как ты и описал, но смена в одном скрипте.
procedure Execute(var State: Integer);var S: String; begin if State = 0 then S:= '' else S:= '_b'; BeginUpdateResources; FindResource('Bobina').Set('ID', 'Bob' + S); EndUpdateResources;end;
Для начала нужно определиться, к чему крепится анимация, к позиции трека или к состоянию перемотки.
Да, и оба с предельно простым кодом типа:Code: [Select]procedure Execute(var State: Integer);var S: String; begin if State = 0 then S:= '' else S:= '_b'; BeginUpdateResources; FindResource('Bobina').Set('ID', 'Bob' + S); EndUpdateResources;end;Во втором скрипте уже пользователь переключает сами текстуры бобин (парами). Такое построение позволяет переключать текстуры даже в режиме перемотки.
Со вторым скриптом помочь?
procedure Execute(var State: Integer);var S: String; begin S := 'Bob' + IntToStr(State + 1); // если имена нумеруются с 1 (Bob1, Bob1_b...) BeginUpdateResources; FindResource('Bob').Set('ID', S); // имя текстуры будет BobN FindResource('Bob_b').Set('ID', S + '_b'); // имя текстуры будет BobN_b EndUpdateResources;end;
Code: [Select]procedure Execute(var State: Integer);var S: String; begin S := 'Bob' + IntToStr(State + 1); // если имена нумеруются с 1 (Bob1, Bob1_b...) BeginUpdateResources; FindResource('Bob').Set('ID', S); // имя текстуры будет BobN FindResource('Bob_b').Set('ID', S + _b'); // имя текстуры будет BobN_b EndUpdateResources;end;
procedure Execute(var State: Integer);var S: String; begin S := 'Bob' + IntToStr(State + 1); // если имена нумеруются с 1 (Bob1, Bob1_b...) BeginUpdateResources; FindResource('Bob').Set('ID', S); // имя текстуры будет BobN FindResource('Bob_b').Set('ID', S + _b'); // имя текстуры будет BobN_b EndUpdateResources;end;
Так эти два скрипта никак друг от друга не зависят. Первым ты переключаешь текстуру для перемотки и без разницы, которая она там по счёту, вторым пользователь выбирает бобины кнопкой или ещё чем там...Структура ресурсов при этом должна быть такой:Первые три пункта - это ссылки, в них нет собственно текстур, иконка у них должна быть "цепочка". Bob и Bob_b должны указывать на текстуру первой бобины для синхронизации со счётчиком.P.S. Во втором скрипте пропущен апостроф в _b', в своём сообщении я исправил.
Это задается на уровне ОС:https://answers.microsoft.com/en-us/windows/forum/all/key-repeat-setting/89bc0de5-7506-4259-8eab-b48155ed39ff
Задержку поставил в минимум; скорость повтора в середину шкалы.
Если кнопка "удерживается" - значит перемотка идет. Без вариантов.
При перемотке в обратную сторону позиция упирается в начало трека и может оставаться так сколь угодно долго, пока пользователь не отпустит кнопку. При этом нет ни воспроизведения, ни перемотки как таковой. Кто-то, наверное, даже и не поймёт, что при этом происходит.
А как в других приложениях, такие параметры тебя устроят, при наборе текста, к примеру?
Кстати, в моих старых скинах при достижении начала при обратной перемотке, бобины останавливаются, по крайней мере в тех, которые успел проверить.
В STOP и сейчас несложно перевести, а вот в PLAY или PAUSE это будет огород, по сути возврат к прежней схеме перемотки и все эти новые доступные фичи остаются за бортом, а коммутация режимов ещё более усложнится. Мне больше нравится когда при обратной перемотке плеер переходит в воспроизведение.Применительно к нашим скинам логичнее всего было бы останавливать плеер как в начале, так и в конце трека, как это происходит в реальной кассете, но останов в конце трека, вроде, как и не нужен. К тому же поймать конец трека оказывается сложнее, чем начало, особенно на МР3. Может это связано с расхождением реального времени звучания с тем, что прописано в тегах, не знаю, но приходится закладываться аж на несколько секунд от конца трека.
... Stop в реальном магнитофоне тоже не произойдет, если я буду насильно давить кнопку перемотки.
Это только применительно к аппаратам с механическим управление и только, если клавиша перемотки не фиксируется. Автостоп был даже в наших носимых шарманках. А в аппаратах с электронным управление автоматика просто не позволит этого сделать.
Короче говоря, давай еще раз проговорим, что по твоему мнению должно происходить с перемоткой, при достижении начала (трека/плейлиста)?
Сквозная перемотка по плейлисту, что сейчас реализована, работает отлично. А вот прежнее поведение (перемотка внутри трека) на фоне её смотрится теперь, ИМХО, некрасиво.Речь даже не про наши "магнитофонные" скины, а вообще про навигацию по треку. При перемотке вперед происходит то же самое, что и при перемотке вперёд по плейлисту, т. е. переход на следующий трек и продолжение перемотки, если кнопка удерживается. При перемотке в обратную сторону позиция упирается в начало трека и может оставаться так сколь угодно долго, пока пользователь не отпустит кнопку. При этом нет ни воспроизведения, ни перемотки как таковой. Кто-то, наверное, даже и не поймёт, что при этом происходит.Мне кажется более логичным было бы следующее поведение. При перемотке назад и достижения начала трека переход в режим PLAY, независимо от удержания кнопки PREV. При перемотке вперёд и достижении конца трека переход на следующий трек (оставаться в конце текущего трека нет смысла) и тоже переход в режим воспроизведения.
Так я уж, вроде, сформулировал всё выше:
С перемоткой назад с упором в начало трека, согласись, ну, некрасивая ситуация получается.
А перемотка вперед получается сквозная, ничем не отличающаяся от перемотки по плейлисту. Вот, представь, запустил пользователь трек, послушал немного, захотельось промотать вперёд, потом ещё промотать, а плеер уже перескочил на следующий трек, начала трека уже не услышит, надо снова перезапускать трек.
Самое главное - при этом никакого вмешательства в логику работы плеера нет, мы только визуализируем его работу.
Не хотелось бы снова нагромождать скрипты, хендлеры и пр. чтоб отлавливать начало трека
Нотификация с prvPlayerState.OnTrackStarted/OnTrackFinished в этом режиме не работает.
По поводу традиционной сквозной перемотки вперёд. Не было её, я проверял. Теперь есть.
В AIMP5 уже была. Последняя версия, где не было перехода на следующий трек - 4.70, что ИМХО, ещё хуже.
Так просто настройки в разных версиях изменились, если переход на следующий трек разрешён, то и будет сквозная перемотка вперёд.
Теперь же при обратной - все "зависают" до отпускания клавиши ...
К слову о невозможности отследить переход через ноль. Берём кнопку, видимость её завязываем на prvPlayrState/State ...
И в этом случае можно обойтись без этажерок из кнопок, управляя ей по Accessibiliti, 0 в этой точке сделает её недоступной и действие прервётся.Есть ещё вариант. Скриптом рвать связь между кнопкой и провайдером, затем снова восстанавливать. Я ни разу не пробовал это делать, потому не знаю, как это будет работать.Жаль нет у нас такого коммутатора, который бы переключал связи в этом направлении на уровне биндинга.
А мультиплексор не подойдёт?
И в этом случае можно обойтись без этажерок из кнопок, управляя ей по Accessibiliti, 0 в этой точке сделает её недоступной и действие прервётся.
В данном случае кнопка станет недоступной лишь на мгновение и никто этого не заметит, а перемотка остановится.
А для меня все эти этажерки, слоёные пироги, пасхалки - это ГРЯЗЬ скинов. Так допустимо было делать лишь на заре появления биндинга.
Я для себя проблему перемотки решил и довольно просто, хоть в STOP, хоть в PLAY, можно ничего не менять в плеере.
