Кілька місяців тому Text-to-MOGRT був набором робочих гіпотез, скриптів і дуже конкретних монтажних проблем. Сьогодні це повноцінний UXP-плагін для Adobe Premiere Pro, який пройшов перевірку Adobe та доступний в Adobe Exchange.

Відкрити Text-to-MOGRT в Adobe Exchange

English version: read this post in English.

Це не історія про те, як я одного вечора написав невелику автоматизацію і наступного ранку натиснув Publish. Між першою ідеєю та релізом були різні архітектури, десятки тестових проєктів, ручні проходи в кількох версіях Premiere, Windows у віртуальній машині, окремі rollback-збірки, race condition у Premiere API, зламані припущення і кілька моментів, коли вже майже готовий кандидат доводилося відкладати.

Саме тому мені хочеться розповісти про цю роботу докладно. Найцікавіше в подібних продуктах відбувається не в момент, коли кнопка нарешті працює, а в усіх рішеннях, які роблять її безпечною для чужого проєкту.

З якої проблеми все почалося

У монтажі інтерв’ю, шортів, експлейнерів і рілсів часто є готовий текст, готовий стиль і вже змонтована структура. Залишається нібито просте завдання: перетворити текст на десятки або сотні графічних кліпів, розкласти їх за таймінгом, обрізати, відредагувати текст і не зламати оформлення.

Уручну це означає повторювати однакову операцію знову і знову:

  • дублювати Motion Graphics Template;
  • вставляти наступний фрагмент тексту;
  • підганяти тривалість;
  • стежити, щоб кліпи не перекривалися;
  • не переплутати репліки ведучого і цитати;
  • не втратити слово під час переносу;
  • перевірити, що все потрапило на правильну доріжку.

Одна така операція не страшна. П’ятдесят — уже рутина. Кількасот — окремий виробничий етап, у якому легко помилитися просто через втому.

Text-to-MOGRT мав забрати саме цю частину роботи: редактор готує текст і таймлайн, обирає MOGRT, переглядає план вставки, а плагін створює редаговані графічні кліпи на потрібній доріжці.

Не «автоматичні субтитри», а міст між текстом і монтажем

Важливе уточнення: Text-to-MOGRT не намагається вгадати мову з аудіо і не замінює транскрипцію. Його завдання починається там, де текст уже існує і має стати частиною монтажу.

Плагін підтримує два основні робочі режими.

Document / Text

У цьому режимі джерелом є TXT або DOCX. Таймінг задають вибрані доріжки активної sequence. Наприклад, V1 може позначати фрагменти ведучого, а V2 — цитати. Плагін читає ці часові вікна, розбиває текст на придатні для екрана блоки та розміщує їх у відповідних ділянках.

Для DOCX можна використовувати форматування ролей. Воно допомагає пов’язати абзаци ведучого і цитати з різними anchor-доріжками, зберігаючи порядок вихідного документа.

Timed Subtitles

Для SRT і WebVTT джерелом таймінгу є сам файл. Cue timecodes зберігаються, а довгі репліки можуть бути розбиті на кілька суміжних, вирівняних за кадровою сіткою MOGRT-кліпів.

В обох випадках результат — не закритий відеошар і не хмарний рендер, а звичайні редаговані MOGRT-кліпи в Premiere. Після вставки редактор залишається редактором: може змінити текст, тривалість, положення або дизайн у звичному таймлайні.

Детальний опис можливостей і встановлення доступний на сторінці Text-to-MOGRT в Adobe Exchange.

Чому я перейшов до UXP

Ранні версії цієї ідеї існували як Python-скрипти, інструменти для модифікації проєктів і CEP-прототип панелі. Усі вони були корисними: дали змогу перевірити правила розбиття тексту, структуру Premiere-проєктів, роботу з MOGRT і реальні потреби монтажу.

Але продуктовою версією став саме UXP-плагін.

Причини доволі практичні:

  • плагін працює всередині Premiere Pro;
  • він бачить активний проєкт і sequence;
  • редактор не має переносити роботу в термінал;
  • встановлення може відбуватися через екосистему Adobe;
  • немає окремого Python runtime, локального сервера або стороннього застосунку;
  • обробка залишається локальною.

У релізній версії немає облікового запису, телеметрії, активаційного сервера чи завантаження тексту в хмару. TXT, DOCX, SRT, VTT, MOGRT і дані проєкту залишаються на пристрої користувача. Інтернет потрібен Adobe для придбання та встановлення, але не для генерації кліпів.

Звучить як очевидний вибір. Насправді він просто переносить складність ближче до Premiere API.

Preview мав бути справжнім Preview

Однією з принципових вимог стала безпечна двофазна робота.

Спочатку Preview Batch будує план:

  • скільки кліпів буде створено;
  • на яких часових позиціях;
  • до якої ролі належить кожний блок;
  • як саме текст розбитий на рядки;
  • яка тривалість запланована.

Preview не повинен змінювати таймлайн. Це здається дрібницею, але саме тут проходить межа між корисною автоматизацією і кнопкою, яку страшно натискати.

Лише після перевірки плану редактор запускає Insert Batch. Перед вставкою плагін ще раз перевіряє output track. Якщо потрібний діапазон зайнятий, collision guard зупиняє всю операцію до першої зміни.

Без частково створених субтитрів. Без тихого перезапису. Без припущення, що «користувач потім розбереться».

MOGRT — це не просто файл

Плагін мав працювати з різними способами вибору стилю:

  • локальним .mogrt файлом;
  • MOGRT, встановленим у Premiere;
  • підготовленим template-кліпом на окремій доріжці таймлайна.

Останній варіант особливо важливий у реальному монтажі. Часто редактор уже поставив потрібну графіку на окрему лінійку з заготовкою, перевірив композицію, колір, opacity, motion та інші параметри. Логічно попросити плагін прочитати цей template і використати доступні налаштування для нових кліпів.

Тут виявилося важливе обмеження API: Premiere не віддає UXP-плагіну всі відредаговані параметри текстового стилю так, як хотілося б. Частину нетекстових контролів можна перенести, але шрифт і розмір з timeline template не завжди доступні для повного відтворення. Тому MOGRT-файл має вже містити правильні текстові defaults.

Замість того щоб маскувати це обмеження, плагін прямо повідомляє про нього в інтерфейсі. Прозоре обмеження краще за результат, який випадково виглядає не так.

Розбиття тексту виявилося окремим продуктом

Лічильник символів — недостатній алгоритм для субтитрів. Якщо просто різати рядок на 25-му знаку, легко отримати самотній прийменник, відірвану частку, некрасиву пряму мову або слово, якому не вистачило одного символу.

Правила поступово ставали точнішими:

  • короткі службові слова не повинні без потреби залишатися самі;
  • ручні переноси треба поважати;
  • довгі timed cues треба ділити без прогалин і накладань;
  • Unicode, кирилиця й різні типи тире не повинні псувати текст;
  • форми ‑,, –,, —,, −, мають залишатися з попередньою частиною;
  • тире на початку прямої мови після завершеного речення, навпаки, має переходити на новий рядок;
  • якщо одне слово лише трохи перевищує ліміт, краще тимчасово дозволити рядок до приблизно 1,5 ліміту, ніж ламати слово через один знак.

Ці правила виглядають маленькими, доки не побачиш їх на сотні реальних реплік. Саме з таких деталей складається відчуття, що інструмент розуміє монтажний текст, а не лише рахує символи.

Доріжка V5, якої не існувало для панелі

Один із пізніх багів був дуже наочним.

Проєкт відкривався з V1–V4, панель читала sequence і будувала списки доріжок. Потім я додавав V5 у Premiere — але вибрати її як timing, template або output track було неможливо. Панель продовжувала жити в структурі, яку побачила під час відкриття.

Проблема не була у V5. Проблема була в життєвому циклі каталогу доріжок.

Окремої надійної події «користувач додав track» у доступному UXP-контракті недостатньо для всіх версій Premiere, тому рішення стало гібридним:

  • слухати project і sequence events;
  • оновлювати каталог після повернення фокуса в панель;
  • додати явну кнопку Refresh Tracks як надійний fallback;
  • не запускати паралельне читання структури під час Preview або Insert;
  • не перемикати користувача мовчки на іншу доріжку.

Якщо вибрану доріжку видалили, вона залишається позначеною як missing, а залежна операція блокується з чітким повідомленням. Якщо структура змінилася, попередній Preview і знімок template стають недійсними, але вибрані файли та параметри тексту не скидаються.

У Premiere 26 автоматичне оновлення працює добре. У Premiere 25 ручний Refresh Tracks залишається важливим fallback через старішу версію UXP. Це компроміс, але контрольований і зрозумілий.

Найскладніший баг: кліп уже є, але його ще немає

Найбільше часу забрав race condition навколо Premiere TrackItem.

Початкова схема здавалася логічною:

  1. вставити MOGRT;
  2. отримати TrackItem;
  3. змінити його end time;
  4. перейти до наступного кліпу.

Проблема в тому, що факт завершення insert-виклику не означає, що новий TrackItem уже стабільно доступний через getTrackItems().

В одному машинному проході дев’ятий MOGRT був фізично вставлений, але свіже читання доріжки бачило лише п’ять нових items. В іншому, повністю ручному проході та сама помилка виникла вже на третьому кліпі. Позиція змінювалася, симптом залишався.

Спроба використати wrapper, повернутий безпосередньо операцією вставки, завершувалася помилкою A nullptr was dereferenced. Це був важливий доказ: wrapper існує на рівні JavaScript, але пов’язаний з ним внутрішній об’єкт Premiere уже не можна вважати стабільним.

Добра новина полягала в тому, що rollback обох проходів спрацював. Погана — реліз із таким race condition був неприйнятний.

Перша спроба виправлення теж виявила новий сценарій

Ми додали batch visibility barrier: вставити всі кліпи, дочекатися стабілізації колекції output track, зіставити items із planned rows, а потім змінити duration через свіжо отримані об’єкти.

Це прибрало використання небезпечних wrappers, але відкрило інший ефект Premiere.

До моменту скорочення duration довгі дефолтні MOGRT уже перекривалися між собою. У контрольному проході 19 фізичних вставок перетворилися на 37 items на доріжці: 19 очікуваних кліпів плюс 18 хвостових фрагментів.

Це був дуже корисний fail. Плагін не проковтнув зайві items і не оголосив операцію успішною. Exact-prefix verification побачив неправильну cardinality, зупинив batch і повернув output track до порожнього baseline.

Але стало зрозуміло, що batch-рівень усе ще надто широкий.

Фінальна модель: один кліп — одна завершена транзакція

У версії 1.1.6 цикл став серіалізованим:

  1. вставити один MOGRT;
  2. заново прочитати активну sequence і output track;
  3. знайти новий item за точним start frame;
  4. отримати дві однакові стабільні вибірки;
  5. створити duration Action всередині project.lockedAccess;
  6. виконати транзакцію;
  7. знову отримати свіжий TrackItem;
  8. перевірити фактичний end frame;
  9. перевірити весь уже вставлений prefix;
  10. лише тоді переходити до наступного MOGRT.

Premiere 26 більше ніколи не використовує insert-wrapper для duration або Effect Controls mutation. Якщо API повертає nullptr, wrapper відкидається, а item отримується з таймлайна наново. Кількість спроб і дедлайни обмежені, тому система не може зависнути в нескінченному очікуванні.

Цей підхід повільніший за оптимістичну масову вставку. Але він швидший за відновлення зіпсованого монтажного проєкту.

Rollback — це не кнопка Undo

Rollback у такому плагіні не може означати «видалити все з V4». Output track до початку операції може бути непорожнім, і ці кліпи належать користувачеві.

Тому перед Insert плагін знімає baseline-інвентар доріжки. Під час роботи він веде registry вставлених descriptors, start frames і свіжо отриманих TrackItems. Якщо будь-яка фаза завершується помилкою, rollback:

  • знаходить items саме поточного запуску;
  • не додає один фізичний кліп двічі;
  • видаляє лише створене цим batch;
  • перечитує доріжку;
  • порівнює її з exact baseline.

Для перевірки ми створили окрему non-release QA-збірку з одноразовою failure injection. Вона навмисно падала після першої фізичної вставки. На Windows Premiere 26.3.2 плагін вставив один item, згенерував очікувану помилку, видалив саме цей item і підтвердив baseline 0 → 0. Після використання конфіг ін’єкції сам видалився.

Таку QA-збірку не можна випадково відправити користувачам: вона має іншу artifact role, releaseEligible: false, окремий build ID і власний manifest. Після rollback-тесту release CCX був перевстановлений і перевірений через runtime identity.

Чому автоматизація не замінила ручну перевірку

Ми пробували автоматизувати UI-проходи максимально далеко. У Premiere 26 координатне керування панеллю працювало значно краще, ніж у Premiere 25, де частина accessibility-кліків завершувалася AXError.notImplemented.

Але навіть коли курсор можна рухати автоматично, це не означає, що так треба перевіряти все.

Машинний прохід іноді частіше падає через фокус, picker, затримку перемальовування або стан вікна, ніж через сам плагін. Він також витрачає багато часу на дії, які людина виконує за секунду і одразу візуально розуміє.

Тому фінальний QA став гібридним:

  • скрипти перевіряють hashes, manifests, identities, package structure і machine-readable reports;
  • automated tests перевіряють parser, wrapping, mapping, race recovery, rollback і packaging contracts;
  • ручний тестер натискає ключові кнопки, дивиться на таймлайн і підтверджує реальний результат у Premiere.

Для цього класу продукту це виявилося не компромісом, а найнадійнішою моделлю.

Чисті проєкти, immutable bundles і жодного «десь там лежав файл»

Ще одна частина роботи, яку не видно в інтерфейсі, — дисципліна тестових артефактів.

Початковий reviewer-проєкт після кількох сесій уже містив збережені QA-кліпи. Використовувати його як clean baseline було небезпечно. Відтоді кожний важливий прохід отримував нову timestamped-копію.

Release tooling почав створювати окремі каталоги з версією, commit і UTC-часом, а manifests зберігали SHA-256 для CCX, reviewer bundle та runtime payload. Старі кандидати не перезаписувалися. Dirty fixture більше не міг непомітно стати fallback.

Це інколи створює багато папок. Зате коли два незалежні тести падають у різних місцях, можна точно довести, що вони запускали ті самі байти, у тому самому host runtime, з тим самим MOGRT.

Для race condition це було вирішальним.

Mac, Windows і майбутній Premiere

Фінальна матриця не обмежилася одним ноутбуком і однією версією Premiere.

Плагін перевірявся на macOS у Premiere Pro 25.6 і 26.3. Окремий canary успішно пройшов у Premiere 27 Beta. Canary не замінює перевірку стабільних версій, але рано показує, чи не змінився критичний UXP-контракт у наступному поколінні host.

Windows-прохід відбувався у Windows 10 x64 через VMware Fusion на Intel MacBook Pro 2019. Там були встановлені Premiere 25 і 26, а CCX запускався у реальному Windows UXP runtime. Ми перевірили DOCX, VTT, offline SRT, TXT, persistence, Reset Saved Settings, collision і rollback.

Так, це не лабораторія з десятком фізичних Windows-комп’ютерів. Але це справжня Windows-система, справжній Premiere, справжня CCX-інсталяція і справжні runtime reports. Для незалежного продукту на старті це набагато цінніше за припущення «pure JavaScript, отже на Windows усе буде добре».

Окремо лишилося документоване обмеження: у Premiere 25 після динамічного додавання доріжки іноді треба натиснути Refresh Tracks. У Premiere 26 структура зазвичай оновлюється автоматично.

Що в результаті вміє Text-to-MOGRT

Поточна версія вміє:

  • працювати з TXT і DOCX через timing tracks;
  • розпізнавати host/quote ролі в структурованому DOCX;
  • імпортувати SRT і WebVTT зі збереженням cue timecodes;
  • розбивати довгі cues на суміжні frame-aligned кліпи;
  • використовувати локальний, встановлений або timeline-template MOGRT;
  • показувати повний Preview без зміни таймлайна;
  • вставляти лише на вибрану output track;
  • блокувати collision до першої мутації;
  • динамічно оновлювати каталог video й audio tracks;
  • зберігати вибраний MOGRT, source mode, layout і tracks;
  • ніколи не відновлювати автоматично попередній source-документ;
  • скидати remembered settings однією кнопкою;
  • працювати локально й offline;
  • відновлювати точний baseline після перерваного Insert.

Плагін доступний для Premiere Pro 25.6 або новішого на macOS і Windows x64. Придбати та встановити його можна безпосередньо через Adobe Exchange — Text-to-MOGRT.

Про ціну

Text-to-MOGRT продається як perpetual license за $19.99.

Я довго думав, чи не зробити його дешевшим «на старті». Але ціна має відображати не кількість кнопок, а обсяг ручної роботи, яку продукт забирає, і відповідальність за зміни в монтажному проєкті.

Це інструмент не для кожного користувача Premiere. Він для редактора, який регулярно має готовий текст, фірмовий MOGRT і багато повторюваних субтитрів. Якщо плагін економить хоча б одну довгу сесію дублювання та обрізання графіки, його вартість уже зрозуміла.

Водночас я свідомо залишив perpetual-модель: без підписки, без зовнішньої активації та без необхідності тримати ще один сервіс між текстом і Premiere.

Що дала перевірка Adobe

Adobe review — не магічний знак, що в програмі більше ніколи не буде багів. Premiere, UXP і сторонні MOGRT надто різноманітні для такої обіцянки.

Але review змушує довести базові речі до продуктового стану:

  • manifest і host compatibility мають бути коректними;
  • package повинен установлюватися через стандартний канал;
  • сторінка продукту не може обіцяти неіснуючі можливості;
  • privacy, terms, support і commercial model мають бути узгоджені;
  • reviewer повинен зрозуміти, як перевірити продукт;
  • version, screenshots, release notes і submitted bytes мають відповідати одне одному.

Коли повідомлення про схвалення нарешті прийшло, найбільше тішив не сам статус. Тішило те, що на цей момент release CCX уже був не «останнім файлом на робочому столі», а артефактом із відомим commit, SHA-256, runtime build ID і пройденою матрицею.

Що я виніс із цієї роботи

Людина в QA — не ознака слабкої автоматизації

На початку легко уявити ідеальну картину: агент відкриває Premiere, рухає курсор, натискає всі кнопки, порівнює скриншоти й самостійно оголошує реліз готовим. Частину цього справді вдалося реалізувати. У Premiere 26 автоматизація могла відкривати панель, працювати з picker і проходити основний сценарій. У Premiere 25 ті самі координатні кліки іноді завершувалися помилкою accessibility API, хоча сам плагін працював нормально.

Це важливе розрізнення. Падіння UI-автоматизації ще не означає падіння продукту. Машина може втратити фокус, не дочекатися перемальовування вікна, натиснути елемент у старій позиції або витратити багато кроків лише на те, щоб пересунути курсор. Якщо всі такі випадки записувати як дефекти плагіна, QA створює більше шуму, ніж інформації.

Людина бачить контекст інакше. Вона одразу помічає, що на V4 залишилося рівно 19 кліпів, що після rollback доріжка справді порожня, що в Program Monitor зник Sample text, але залишився Welcome, або що додана доріжка V5 фізично існує в Premiere, хоча її ще немає у списку панелі. Для автоматичного тесту кожне таке спостереження потребує окремого способу вимірювання. Для редактора це один погляд на екран.

Саме ручна перевірка дала другий незалежний TrackItem FAIL. Машинний прохід зупинився на дев’ятому кліпі, ручний — на третьому. Якби ми довіряли лише одному способу тестування, можна було б списати проблему на рух курсора, затримку або нестабільний сценарій. Два різні проходи з однаковою діагностикою довели, що race condition знаходиться в runtime, а не в тестовому інструменті.

Водночас людина не повинна вручну перевіряти SHA-256, структуру CCX, commit, build ID, точну кількість записів у JSON або відповідність package manifest. Тут скрипт незрівнянно надійніший. Він не втомлюється, не плутає два однаково названі файли й не вирішує, що «мабуть, це та збірка».

Тому найкращою стала не повна автоматизація, а чіткий розподіл відповідальності. Скрипти створювали immutable bundles, перевіряли identities, рахували timeline items, фіксували duration transactions і порівнювали baseline. Я вручну виконував короткі, зрозумілі кроки в реальному Premiere та підтверджував те, що бачу. Support Report поєднував ці два світи: людське спостереження отримувало точний технічний контекст.

Навіть інструкції «по одному кроку» виявилися частиною якості. Вони не дозволяли випадково натиснути Insert до Preview, змішати Premiere 25 і 26, запустити дві версії з одним plugin ID або перевстановити rollback-only CCX замість release-збірки. Хороший QA-сценарій має зменшувати когнітивне навантаження тестера, а не перетворювати його на ще один нестабільний automation script.

Для мене це головний висновок усієї роботи: присутність людини в QA не виправдовує нестачу тестів. Навпаки, вона дає автоматизованим тестам правильну роль. Машина перевіряє все, що можна однозначно виміряти. Людина оцінює стан, сенс і результат у реальному робочому середовищі. Надійність з’являється тоді, коли ці два типи доказів збігаються.

Далі

Після релізу робота не закінчується. Попереду — реальні проєкти, незнайомі MOGRT, інші структури sequence і сценарії, які неможливо повністю вигадати в тестовій матриці.

Найближчий план простий:

  • збирати реальні support reports без збору користувацького контенту;
  • розширювати сумісність із різними MOGRT;
  • стежити за змінами UXP у наступних версіях Premiere;
  • покращувати пояснення в панелі там, де API має обмеження;
  • не перетворювати локальний інструмент на хмарний сервіс без реальної потреби;
  • зберегти головний принцип: Preview спочатку, контрольована мутація потім.

Фінал

Мені подобаються продукти, які виростають із дуже конкретної незручності.

Text-to-MOGRT починався з питання: «Чому я маю вручну дублювати всі ці графічні кліпи, якщо текст, стиль і таймінг уже існують?» Відповідь виявилася набагато складнішою за один скрипт. Вона пройшла через парсинг документів, мовні правила, Premiere API, UXP lifecycle, TrackItem race conditions, rollback, Windows VM, Beta-canary, manifests, SHA-256 і Adobe review.

Тепер це інструмент, який можна встановити й використовувати у звичному Premiere workflow.

Text-to-MOGRT в Adobe Exchange

Якщо у вашій роботі є готові тексти, MOGRT-шаблони й таймлайни, на яких субтитри досі створюються вручну, буду радий почути, як цей підхід працює на реальному проєкті.

English version: Building Text-to-MOGRT: from editing-room friction to Adobe Marketplace.