Суть вопроса будет иметь примерно такой ответ:
- в Reason масштаб любого элемента управления (кноб, фейдер) исчисляется во внутреннем масштабировании заданного значения 0-1.000.000, и к данному масштабу для разных значений (hz, midi 0-127, beats, и тд) устанавливается пропорциональное значение.
Существую как линейные пропорции элементов управления условно 0-100 (где 50 это середина), так и не линейные шкалы кнобов 0-600 (где 30 середина к примеру).
В случае с hz эквалайзера MClass - числа внутренние не левые 30-600 hz (low) и прочие значения для иных контроллеров.
Вот в случае 30-600 для кноба - значение не линейное (экспотенциаольное), на дорожке же для уравнивания баланса к контроллеру - применяется линейная пропорция.
Именно линейное отображение в автоматизации 0-1000 есть конвертация из hz в линейную шкалу.
Выше я говорил что нативно контроллеры имеют в структуре ризона шкалу 0-1.000.000, так вот стандартная конывертация имеет коэффициент понижающий - *1000, отсюда 1.000.000 / 1000 = 1000
Среднее значение 134.2 Hz = 500 (середина примененного линейного диапазона 0-1000)
Вот так и ориентируйтесь для понимания.
А вот пытаться предугадать в конкретном случае какое число будет соответствовать заданной частоте в Hz - не получится как сами видите из за нелинейности в кнобе самих Герц.
Самый древний вопрос и желание пользователей - внедрить в Ризоне ввод цифрами значений кнобов, что упростило бы ситуацию. Но этого нет и не ожидается пока что.
Назхад к проблеме - MClass это зародышевые наработки будущей структуры Rack Extensions, и свойства примененные ТОГДА - изменились, они позднее прикрутили конвертацию от заданной размерности кноба с его переходом значений в дорожку автоматизации.
И проблема тут всего одна - МКласс нужно обновлять, сохраняя поддержку заданных кнобов скрытыми вне интерфейса свойтсвами засунув под капот для поддержки, и создание новых свойств с назначением на существующие кнобы с использованием уже самих значений в нужной размерности
Звучит путано. На деле - все крайне просто. Это недочет, во времена созданий MClass просто не было унификации конвертаций для создаваемой структуры RE на будущее. Так и осталось устройство там.
Ну а расчет вручную данных точек автоматизации задача оч сложная для пользователя ввиду применении экспотенциальности по заданным правилам, я к примеру знаю строчку кода которую нужно применить для данных свойств, и пропы знают, но это вопрос чисто технический в плане апдейта самих устройств уже. Сложного в этом ничего - но абсолютно точно прийдется добавлять дубликаты масштаба как новые свойства прикрепляемые к существующим кнобам в интерфейсе.
Конкретный совет один - используйте ориентир выбираемой шкалы - как проценты. 0-100% c серединой самого кноба на 50% (500 на шкале).
Теоретически можно воссоздать экспотенциальность конечно чтоб конвертировать самому - в том же MatLab, хотя может можно и в Экселе задался целью. Но убьете больше времени, потому что в игру нелинейности Hz - включается еще и конвертация Hz->kHz так же являющейся прогрессией для задаваемого масштаба линейного кноба...
Вобщем я отпишу пропам письмо наверное на сей счет, реально не оч удобно пользователи это вникать и пользоваться условным масштабированием в процентах.
Если бы пропы прикрутили к данным цифрам % думаю для пользователей стало бы несколько очевиднее применение процентов как несоответствие нелинейности к линейности
Это на других девайсах такого больше нет, а вот Класс разрабатывался до того, и с одной стороны попов можно и нужно понять, вешать новые свойства в устройство - как дублирующие ради масштаба - это костыль. Тут скорее пропам бы обновить сам МКласс до 2.0
Можете и сами написать их с просьбой сделать в апгрейде замену линейных 0-1000 в MClass EQ - LOW к примеру на конкретные значения Гц кноба, без этой условной линейной шкалы. Больше писем - больше шансов быть услышанным.
Я если честно этому нюансу как пользователь не придавал значения никогда.
пс: консольный EQ тоже имеет значения в 0-1000, многое РН надо в таком случае перерабатывать...
С другой стороны - они уже объявили что сильно переписывают сейчас 10ку и хотят успеть к НГ ввиду оптимизации под ВСТ и хз чего там еще, но может это тот момент когда РН стоит просить о подобном массово?
С другой стороны взять сторонний РЕ и ориентироваться по нему без этих проблем, которые проблемой не являются а являются просто соотношением ниленейности к линейности (что конечно нужно бы исправить со временем)