Расширить возможности поля State провайдера prvPlayerState

[Black_AVP_Bim]

Предлагаю к имеющимся значениям добавить информацию о следующих состояниях плеера:
- ускоренная перемотка вперёд при длительном удержании кнопки Next;
- ускоренная перемотка назад при длительном удержании кнопки Prev. Было очень полезно в скинах-магнитофонах, и не только;
- запись (захват радио), чтоб не дублировать соответствующую кнопку.

Таким образом будем иметь на одном выходе полную информацию о состоянии плеера.

[Artem]

1-2 - не получится, т.к. быстрая перемотка ничем не отличается от простой навигации по треку.
3. Каким образом эта информация должна подмешиваться в состояние? в виде маски?

[Black_AVP_Bim]

1-2 - не получится, т.к. быстрая перемотка ничем не отличается от простой навигации по треку.

Но, ведь, кнопка при этом удерживается (состояние её меняется) и каким-то сообщением это можно передать провайдеру.

3. Каким образом эта информация должна подмешиваться в состояние? в виде маски?

Сейчас используются только 2 младших бита: 0,1,2. Предлагаемые состотяния можно навесить на старшую тетраду: $10, $20, $40.
Для старых скинов можно маскировать значение State AND 3.

[Soolo]

- запись (захват радио), чтоб не дублировать соответствующую кнопку.

Плохая идея. Во время записи плеер играет (State=1)

Но, ведь, кнопка при этом удерживается (состояние её меняется) и каким-то сообщением это можно передать провайдеру.

нужно привязываться не к нажатости кнопки, а к процессу перемотки

1-2 - не получится, т.к. быстрая перемотка ничем не отличается от простой навигации по треку.

кстати, процесс навигации было бы круто использовать: к примеру на 0,1...0,5 секунды передавать State=3(4). Можно было бы управлять скоростью кручения катушек магнитофонов и направлением (естественно, после реализации соответственной фичи).

[Black_AVP_Bim]

Плохая идея. Во время записи плеер играет (State=1)

Для того и предлягаю использовать старшую тетраду, чтоб не трогать эти биты.

[Soolo]

Для того и предлягаю использовать старшую тетраду, чтоб не трогать эти биты.

Что за старшая тетрада? Народ с простыми цифрами разбираться не особо желает, а тут тетрады какие-то

[Tarik]

Имхо, лучше делать отдельные провайдеры. Дополняя текущий провайдер, можно сломать существующие скины.

- запись (захват радио), чтоб не дублировать соответствующую кнопку.

По этому пункту вообще не понимаю, зачем это нужно для prvPlayerState. Разве состояние нельзя взять от acPlayerRadioCapure?

[Black_AVP_Bim]

Что за старшая тетрада? Народ с простыми цифрами разбираться не особо желает, а тут тетрады какие-то

   Это выражение применяется для двоичной системы. К примеру, в байте, как известно, 8 бит, 4 младших и образуют младшую тетраду, 4 старших - старшую.
В существующем положении State использует лишь 2 младших бита: 00, 01, 10 в двоичной системе.

[Black_AVP_Bim]

По этому пункту вообще не понимаю, зачем это нужно для prvPlayerState. Разве состояние нельзя взять от acPlayerRadioCapure?

Да лучше, чтоб всё это в одной куче было, так и логичнее, и проще обрабатыват значение.

[Soolo]

  Это выражение применяется для двоичной системы. К примеру, в байте, как известно, 8 бит, 4 младших и образуют младшую тетраду, 4 старших - старшую.
В существующем положении State использует лишь 2 младших бита: 00, 01, 10 в двоичной системе.

Я к тому, что далеко не все художники программисты =)

Да лучше, чтоб всё это в одной куче было, так и логичнее, и проще обрабатыват значение.

но не тогда, когда оператору нужно выводить сразу 2 значения ("плей" + "запись").
Запись, конечно, подразумевает плей, но это уже лишние условия для простых скинов.

[Artem]

Дело в том, что эмулировать быструю перемотку можно:
1. Плагином через API
2. Колесиком мыши
3. Быстрыми кликами мыши

Что есть из этого "быстрая перемотка", а что нет - сложный вопрос

[Black_AVP_Bim]

Я к тому, что далеко не все художники программисты =)

Нууу... Народ вон какие выражения загибает в строке преобразования, порой, не сразу и поймёшь.

но не тогда, когда оператору нужно выводить сразу 2 значения ("плей" + "запись").
Запись, конечно, подразумевает плей, но это уже лишние условия для простых скинов.

Так разобраться то несложно будет по значению State что идёт: чисnо Play или Record. В конце концов, есть тот же оператор AND.

[Soolo]

Что есть из этого "быстрая перемотка", а что нет - сложный вопрос

Любое изменение позиции трека пользователем - это перемотка. Даже просто клик в середине файла.
Поэтому и предложил передавать не мгновенное состояние, а немного удерживать его (на доли секунды), чтобы в скине что-то успевало произойти за это время.

[Black_AVP_Bim]

Что есть из этого "быстрая перемотка", а что нет - сложный вопрос

Я имел ввиду только то, что указано в первом посте, а именно, длительное удержание кнопок, остальные пункты нет смысла анимировать.

[Soolo]

Так разобраться то несложно будет по значению State что идёт: чисnо Play или Record. В конце концов, есть тот же оператор AND.

самое простое использование State: иконка передачи состояния: 3 кадра. При введении Record - придётся дорисовывать кадры, чтобы передать "Плей при Записи"

[Black_AVP_Bim]

самое простое использование State: иконка передачи состояния: 3 кадра. При введении Record - придётся дорисовывать кадры, чтобы передать "Плей при Записи"

Да, не придётся, эти биты и так будут передаваться как прежде, да маской в выражении их просто выделить.
Ну, если уж так не нравиться добавление сигнала о записи, можно и отказаться от него.

кстати, процесс навигации было бы круто использовать: к примеру на 0,1...0,5 секунды передавать State=3(4). Можно было бы управлять скоростью кручения катушек магнитофонов и направлением (естественно, после реализации соответственной фичи).

И не только, к примеру, в простых скинах можно изобразить анимацию в виде бегущих стрелочек в сторону перемотки, и Бог весть чего ещё - народ у нас талантлив.

[Artem]

Однако, чем нажатие на кнопочку в скине лучше аналогичного действия с клавиатуры?

[Black_AVP_Bim]

Однако, чем нажатие на кнопочку в скине лучше аналогичного действия с клавиатуры?

Так, наверное, и удержание кнопки, и автоповтор хоткея ведут на одну процедуру. Я то предполагал, что нажатое состояние (и удержание) кнопки можно передать провайдеру.

[Artem]

Зажатие кнопки по сути генерирует N событий перемотки на 1 секунду, тоже самое событие генерирует нажатие кнопки на клавиатуре, тоже самое может сделать плагин

[Black_AVP_Bim]

Зажатие кнопки по сути генерирует N событий перемотки на 1 секунду, тоже самое событие генерирует нажатие кнопки на клавиатуре, тоже самое может сделать плагин

Это я понимаю, но в той же собственной текстуре кнопки при нажатии включается 3-ий кадр и высвечивается, пока её не отпустят. Может как-то к этому событию ожно привязаться?

[Zhenya]

Имхо, лучше делать отдельные провайдеры. Дополняя текущий провайдер, можно сломать существующие скины.

+1

[Tarik]

Да лучше, чтоб всё это в одной куче было, так и логичнее, и проще обрабатыват значение.

Нет, это не так.

Что мешает создать свой провайдер-коммутатор? Объединяем по очереди в цепочку все нужные провайдеры, а затем у этого собственного провайдера берем значения.

[Black_AVP_Bim]

Нет, это не так.
Что мешает создать свой провайдер-коммутатор? Объединяем по очереди в цепочку все нужные провайдеры, а затем у этого собственного провайдера берем значения.

Т. е. городить такой огород лучше, чем распознать конкретное число на одном выходе Я бы не стал так утверждать, да ещё в столь категоричной форме. Только практика критерий истины.
Ну, хорошо, тогда в конце концов, можно было бы добавить ещё один выход к провайдеру acPlayerNextTrack (acPlayerPrevTrack), который ретранслировал бы событие ActionOnHold от соответствующей кнопки и его можно былобы использовать.
Вообще, странно, что встречаешь такое упорное сопротивление, когда предлагаешь, вроде, нужную вещь...

[Soolo]

Ну, хорошо, тогда в конце концов, можно было бы добавить ещё один выход к провайдеру acPlayerNextTrack (acPlayerPrevTrack), который ретранслировал бы событие ActionOnHold от соответствующей кнопки и его можно былобы использовать.

Артём уже раза 3 пытался сказать, что нельзя привязываться к нажатию кнопки: нужно привязываться к действию - к процессу перемотки. И в этом случае не совсем понятно как нужно реализовывать фичу.

Вообще, странно, что встречаешь такое упорное сопротивление, когда предлагаешь, вроде, нужную вещь...

Никто не сопротивляется, просто указываются подводные камни, на которые можно напороться, доставив потом неудобства авторам скинов.
Предложение висит. Артём возможностям скиндвижка уделяет много внимания, а значит и эту тему в каком-нибудь виде реализует однажды.