На данный момент для получения удовольствия от помощи людям с их проблемами, связанными с MIDI :-) В целом, библиотека давно уже развивается благодаря обращениям пользователей. Изначально большинство нужных функций заложил я, впоследствие идеи приходили от других людей. Рассказывал подробно в статье Из Open Source с любовью.
Если будет нужна помощь с ней, обращайтесь. Наоборот, API построен так, чтобы позволять решать сложные задачи в пару строк. Не лишая при этом возможности залезть в дебри, разумеется.
Я так понимаю, ваша задача состоит в получении длительности ноты из midi-файла?
Преобразования любого произвольного отрезка времени из MIDI-формата в человеческий. Длительность нот, в частности. MIDI-файлом задача не ограничивается.
Длительности типа 133/400 обычно получаются не потому, что музыка авангардная, а потому, что длительности скорректированы для эффекта стаккато/легато/арпеджио/свинг/ и т.д. Стартовые позиции ноты тоже могут быть смещены в том числе и для эффекта "гуманизации", для создания иллюзии живой игры.
Это всё, разумеется, имеет место быть, сам много раз занимался гуманизацией программных дорожек. Я скорее про запись живой игры, да. И про специально сделанные "сложности" тоже, если всё-таки про авангард говорить. А ваша мысль дополняет мою, про эти моменты тоже стоило написать, согласен.
Если чуть подробнее, моя библиотека DryWetMIDI предоставляет API для преобразования времени в разные форматы. Например, в описанный в данной статье. У пользователя на руках может быть просто нота или аккорд или отдельное MIDI-событие, или произвольный отрезок в тиках, и он хочет знать, а сколько это в дробном выражении (или метрическом, или в тактах и долях и т.д.). Например, для ноты выглядеть будет так:
var tempoMap = midiFile.GetTempoMap(); // or TempoMap.Create(...) or ...
// ...
var musicalTime = note.TimeAs<MusicalTimeSpan>(tempoMap);
var musicalLength = note.LengthAs<MusicalTimeSpan>(tempoMap);
Тогда нормализация рационального числа это наименьшая из всех проблем.
А проблем, собственно, и нет, статья крохотной получилась. Этот формат самый простой для реализации. Разве что меня занесло с диофантовыми уравнениями в своё время :-)
Спасибо, что вышли и тут на связь :-) Хотел бы обозначить несколько моментов:
Мой экземпляр книги от 2020-го года. Я так понимаю, это доп. тираж. Есть ли у вас в издательстве ревью текста между тиражами?
Да, разумеется, если мы сосчитаем процент громких жалоб относительно общего числа ваших книг, число будет, вероятно, небольшое. Вопросы вызывает вообще наличие таких вопиющих ошибок. Такое попросту невозможно пропустить человеку, немного разбирающемуся в теме, а у вас для этого целый научный редактор должен быть.
Далее, про 2018-ый год. Я приведу несколько примеров.
Дала почитать хорошему другу. Он сказал что перевод плохой и много опечаток. Как могли доверить перевод такой важной книги не пойми кому? Бомбора (Эксмо) вроде уажаемое издательство, у меня в детстве были их энциклопедии и поэтому обидно что так.
Перевод оставляет желать лучшего. Без знания английского и предположений о том что было написано в оригинале смысл некоторых предложений может быть утерян.
Да, в этих комментариях нет конкретики, нет примеров. Но знаете, что огорчает больше всего? Что вы не отвечаете на эти отзывы. Продавец у всех трёх книг Торговый Дом «Эксмо». Это либо вы, либо ваше представительство. В ваших же интересах поинтересоваться у автора отзыва, что именно не так. Возможно, списаться лично для более подробного списка косяков. Нет даже банальной отписки о том, что вы сожалеете, что так вышло. У вас нет коннекта с вашими читателями, вы его и не ищете.
К слову, ваши конкуренты Альпина Паблишер/АНФ на все такие отзывы всегда отвечают, даже на положительные, иногда даже сами предлагают ещё книжки на схожие темы. И жалоб на их переводы я сходу найти не смог.
У вас внутри издательства, наверняка, много знакомых с разных сфер науки и техники. Ну дайте вы перед публикацией паре-тройке таких почитать текст. Если косяки есть, они их увидят, вы исправите, выпустите замечательную книгу, а той фокус-группе бесплатно вышлете напечатанные варианты. Если вы боитесь, что так текст может утечь, то в чём большие минусы? Ну даже если спиратят, оно вам на пользу будет, такой пиар тоже работает. Если материал интересный, люди захотят подержать его в руках потом.
Ещё хочу сказать, что, например, тут на Хабре регулярно выходят статьи от издательства Питер, и про новые их книги и про распродажи полезных образцов. Почему бы вам тоже не делиться со здешней аудиторией информацией? Будет стимул улучшить свои процессы и выглядеть достойно.
Я эту книжку читал не так давно в варианте от 2002-го года в электронном виде (Хакеры. Герои компьютерной революции). Переводчик: Лукин Алексей, 2001 год, г. Иркутск. Не знаю, как у Бомборы (но подозреваю), но тот древний перевод ни разу не заставил меня споткнуться нигде. Там даже есть раздел в самом начале Предисловие к русскому переводу.
А сама книга отличная. Очень интересно рассказано про зарождение компьютерных энтузиастов и в целом индустрии компьютеров. Будет весьма жаль, если Бомбора и этот текст испортила.
Добавил вводную информацию в начало статьи. Думаю, подробнее уже не стоит, все необходимые ссылки я привёл.
В принципе, это как с XML. Вряд ли "работа с XML-файлами" будет вызывать вопросы касательно применения такой библиотеки. MIDI – тоже формат данных с большим количеством сценариев использования.
Но в целом согласен, что какое-то краткое описание предметной области нужно было добавить. Спасибо!
Или же с давно существующим в C# синтаксисом через имена параметров:
var info1 = new Info(
email: "email@email.com",
phone: "79998888888");
С моей субъективной точки зрения для объектов, которые являются просто описателями некой небольшой сущности, билдер выглядит не особо нужным. Другое дело, если мы создаём сложный объект, где можно добавлять множество различных параметров. Кстати, тут неплохо бы сказать и о fluent API, обычно являющимся неотемлемой частью реализации билдера.
Ну и, разумеется, зависит от языка. Если где-то нельзя поименовать передаваемые значения, то билдер может оказаться полезным воркэраундом.
У меня есть ещё теория, почему в OSS есть описанные проблемы. Вскользь в статье было затронуто на примере F-Droid, что там могут быть приложения без скриншотов, разные иконки и т.д. На мой взгляд, в этом ещё одна проблема с OSS – отсутствие контроля качества (модерации). В коммерческом ПО зачастую есть QA, тесты, оценка руководством, экспертами и т.д. С OSS всё хуже в этом плане, всё выпускается, как есть, от разработчиков не требуют доработок. Да, кто-то может отвалиться с такими требованиями, но в целом, думается, о качестве заботились бы больше.
Функционал это хорошо, но ведь стоит стремиться к совершенству в разных аспектах программного обеспечения. UI/UX это немаловажная составляющая ПО. Для продвинутых пользователей всегда можно сделать рубильники в настройках и будет более продвинутый интерфейс.
Как по мне, для среднестатистического велосипедиста, который, тем не менее, хочет кататься активно, понты – это система с 3 звёздами (я про переднюю часть трансмиссии). Ну или не понты, а лишнее просто. Спортсменам, которые точно следят за каденсом, всё это нужно, дабы выбирать передачу, необходимую для сохранения об/мин + частоты пульса.
Я же в своё время решил, что мне 3 звезды спереди ничего не дают, кроме усложнения конструкции. Поэтому я поставил спереди одну звезду и сменил кассету сзади, дабы не просесть по минимальной и максимальной передаче на новой трансмиссии.
Но вот как жить без хотя бы 7 передач (стало быть, и кассеты), я не представляю. Горки, старт с места с низких передач и всё такое, ускорение на спуске. Можно обойтись и 3-мя, но зачем? Мне колени дороги :)
Есть втулки на заднее колесо под трещётки. Можете погуглить. Фишка там в том, где оказываются точки упора оси в колесе относительно дропаутов. С одной стороны точка упора будет находиться на значительном расстоянии от дропаута и при езде чуть агрессивнее, чем прогулка по парку, ось когда-то развалится из-за создающегося эффекта рычага. У меня ломалась, а явление это очень распространённое. А вот втулки с барабаном под кассету лишены этого недостатка, ибо расстояния до дропаутов от точек упора оси в колесе одинаковые и короткие.
Понятно, что ко всему можно приспособиться. Вопрос в другом, когда выбираешь тот или иной товар, не только велосипеды: если есть возможность пользоваться более комфортно и более безопасно, почему бы этот вариант и не выбрать? Почему не поставить каретку со шлицами вместо квадратной оси и забыть о подтяжке шатунов? Почему не поставить втулку с барабаном вместо трещётки и забыть про разлом оси в разгар поездки? Да, простота тоже неплохо, но если есть возможность сделать свою жизнь комфортнее, почему бы не воспользоваться? ;-)
В детстве был Forward с педальным тормозом. Обзаведясь в 2014 простым горником с тормозами на руле, я теперь не представляю, как ездить на ножном тормозе. Никто об этом не упомянул, но для меня главная проблема - безопасность. Случись что с цепью при спуске с горы, последствия могут быть крайне неприятными. У меня такое было на форварде, цепь слетала. К счастью, спуск был коротким.
А я верно понимаю, что все эти стикеры актуальны только если MirPay не поддерживает ваш банк или у телефона нет NFC (кто-то такими ещё пользуется?)? Учитывая, что большинство комментирует подобные новости в положительном или нейтральном ключе, думаю, что это я чего-то не понимаю. Ведь есть же MirPay.
Я там же пишу, что в самом начале люди, писавшие игры на Unity, именно исходники библиотеки клали к себе в проект. Соответственно, эти исходники должны были компилироваться. А Unity в те времена не поддерживал версию языка выше 6-ой.
В статье далее же пишу, что сейчас у меня есть поставки и в виде ассетов – максимально нативного способа интеграции 3d party продуктов в Unity. Но я всё равно оставляю возможность использовать библиотеку через исходники на древней версии Unity.
На данный момент для получения удовольствия от помощи людям с их проблемами, связанными с MIDI :-) В целом, библиотека давно уже развивается благодаря обращениям пользователей. Изначально большинство нужных функций заложил я, впоследствие идеи приходили от других людей. Рассказывал подробно в статье Из Open Source с любовью.
Если будет нужна помощь с ней, обращайтесь. Наоборот, API построен так, чтобы позволять решать сложные задачи в пару строк. Не лишая при этом возможности залезть в дебри, разумеется.
Преобразования любого произвольного отрезка времени из MIDI-формата в человеческий. Длительность нот, в частности. MIDI-файлом задача не ограничивается.
Это всё, разумеется, имеет место быть, сам много раз занимался гуманизацией программных дорожек. Я скорее про запись живой игры, да. И про специально сделанные "сложности" тоже, если всё-таки про авангард говорить. А ваша мысль дополняет мою, про эти моменты тоже стоило написать, согласен.
Если чуть подробнее, моя библиотека DryWetMIDI предоставляет API для преобразования времени в разные форматы. Например, в описанный в данной статье. У пользователя на руках может быть просто нота или аккорд или отдельное MIDI-событие, или произвольный отрезок в тиках, и он хочет знать, а сколько это в дробном выражении (или метрическом, или в тактах и долях и т.д.). Например, для ноты выглядеть будет так:
А проблем, собственно, и нет, статья крохотной получилась. Этот формат самый простой для реализации. Разве что меня занесло с диофантовыми уравнениями в своё время :-)
Есть и орфографические ошибки и перевод с английского в лоб, текст читается очень тяжело.
Здравствуйте!
Спасибо, что вышли и тут на связь :-) Хотел бы обозначить несколько моментов:
Мой экземпляр книги от 2020-го года. Я так понимаю, это доп. тираж. Есть ли у вас в издательстве ревью текста между тиражами?
Да, разумеется, если мы сосчитаем процент громких жалоб относительно общего числа ваших книг, число будет, вероятно, небольшое. Вопросы вызывает вообще наличие таких вопиющих ошибок. Такое попросту невозможно пропустить человеку, немного разбирающемуся в теме, а у вас для этого целый научный редактор должен быть.
Далее, про 2018-ый год. Я приведу несколько примеров.
📖 Друзья. 25 лет вместе. Как снимали главный сериал эпохи | Аустерлиц Сол
Год выпуска: 2023. Комментарий:
📖 Эволюция разума | Курцвейл Рэй
Год выпуска: 2021. Комментарий:
📖 Рождение машин. Неизвестная история кибернетики | Рид Томас
Год выпуска: 2019. Комментарий:
Да, в этих комментариях нет конкретики, нет примеров. Но знаете, что огорчает больше всего? Что вы не отвечаете на эти отзывы. Продавец у всех трёх книг Торговый Дом «Эксмо». Это либо вы, либо ваше представительство. В ваших же интересах поинтересоваться у автора отзыва, что именно не так. Возможно, списаться лично для более подробного списка косяков. Нет даже банальной отписки о том, что вы сожалеете, что так вышло. У вас нет коннекта с вашими читателями, вы его и не ищете.
К слову, ваши конкуренты Альпина Паблишер/АНФ на все такие отзывы всегда отвечают, даже на положительные, иногда даже сами предлагают ещё книжки на схожие темы. И жалоб на их переводы я сходу найти не смог.
У вас внутри издательства, наверняка, много знакомых с разных сфер науки и техники. Ну дайте вы перед публикацией паре-тройке таких почитать текст. Если косяки есть, они их увидят, вы исправите, выпустите замечательную книгу, а той фокус-группе бесплатно вышлете напечатанные варианты. Если вы боитесь, что так текст может утечь, то в чём большие минусы? Ну даже если спиратят, оно вам на пользу будет, такой пиар тоже работает. Если материал интересный, люди захотят подержать его в руках потом.
Ещё хочу сказать, что, например, тут на Хабре регулярно выходят статьи от издательства Питер, и про новые их книги и про распродажи полезных образцов. Почему бы вам тоже не делиться со здешней аудиторией информацией? Будет стимул улучшить свои процессы и выглядеть достойно.
Я эту книжку читал не так давно в варианте от 2002-го года в электронном виде (Хакеры. Герои компьютерной революции). Переводчик: Лукин Алексей, 2001 год, г. Иркутск. Не знаю, как у Бомборы (но подозреваю), но тот древний перевод ни разу не заставил меня споткнуться нигде. Там даже есть раздел в самом начале Предисловие к русскому переводу.
А сама книга отличная. Очень интересно рассказано про зарождение компьютерных энтузиастов и в целом индустрии компьютеров. Будет весьма жаль, если Бомбора и этот текст испортила.
Добавил вводную информацию в начало статьи. Думаю, подробнее уже не стоит, все необходимые ссылки я привёл.
В принципе, это как с XML. Вряд ли "работа с XML-файлами" будет вызывать вопросы касательно применения такой библиотеки. MIDI – тоже формат данных с большим количеством сценариев использования.
Но в целом согласен, что какое-то краткое описание предметной области нужно было добавить. Спасибо!
Точно ли вы читали? :-)
Это не приложение, а библиотека.
Если перейти по второй ссылке сразу же в началне статьи, то можно перейти на страницу проекта в GitHub, где всё подробно расписано.
Более того: первый же раздел в статье ("А почему бы..."), третий абзац:
Ну и далее по статье много информации, что библиотека умеет делать. Например, в подразделе "Ещё одна библиотека".
Или вы о том, чтобы продублировать README проекта? Если это будет полезно, то могу добавить.
С моей субъективной точки зрения для объектов, которые являются просто описателями некой небольшой сущности, билдер выглядит не особо нужным. Другое дело, если мы создаём сложный объект, где можно добавлять множество различных параметров. Кстати, тут неплохо бы сказать и о fluent API, обычно являющимся неотемлемой частью реализации билдера.
Ну и, разумеется, зависит от языка. Если где-то нельзя поименовать передаваемые значения, то билдер может оказаться полезным воркэраундом.
Функционал это хорошо, но ведь стоит стремиться к совершенству в разных аспектах программного обеспечения. UI/UX это немаловажная составляющая ПО. Для продвинутых пользователей всегда можно сделать рубильники в настройках и будет более продвинутый интерфейс.
Как по мне, для среднестатистического велосипедиста, который, тем не менее, хочет кататься активно, понты – это система с 3 звёздами (я про переднюю часть трансмиссии). Ну или не понты, а лишнее просто. Спортсменам, которые точно следят за каденсом, всё это нужно, дабы выбирать передачу, необходимую для сохранения об/мин + частоты пульса.
Я же в своё время решил, что мне 3 звезды спереди ничего не дают, кроме усложнения конструкции. Поэтому я поставил спереди одну звезду и сменил кассету сзади, дабы не просесть по минимальной и максимальной передаче на новой трансмиссии.
Но вот как жить без хотя бы 7 передач (стало быть, и кассеты), я не представляю. Горки, старт с места с низких передач и всё такое, ускорение на спуске. Можно обойтись и 3-мя, но зачем? Мне колени дороги :)
У меня есть такой. Только я им почему-то не пользуюсь :-)
Теперь-то я цепь каждый сезон меняю, как и тормозные колодки с тросами. Лучше перебдеть.
Есть втулки на заднее колесо под трещётки. Можете погуглить. Фишка там в том, где оказываются точки упора оси в колесе относительно дропаутов. С одной стороны точка упора будет находиться на значительном расстоянии от дропаута и при езде чуть агрессивнее, чем прогулка по парку, ось когда-то развалится из-за создающегося эффекта рычага. У меня ломалась, а явление это очень распространённое. А вот втулки с барабаном под кассету лишены этого недостатка, ибо расстояния до дропаутов от точек упора оси в колесе одинаковые и короткие.
Понятно, что ко всему можно приспособиться. Вопрос в другом, когда выбираешь тот или иной товар, не только велосипеды: если есть возможность пользоваться более комфортно и более безопасно, почему бы этот вариант и не выбрать? Почему не поставить каретку со шлицами вместо квадратной оси и забыть о подтяжке шатунов? Почему не поставить втулку с барабаном вместо трещётки и забыть про разлом оси в разгар поездки? Да, простота тоже неплохо, но если есть возможность сделать свою жизнь комфортнее, почему бы не воспользоваться? ;-)
В детстве был Forward с педальным тормозом. Обзаведясь в 2014 простым горником с тормозами на руле, я теперь не представляю, как ездить на ножном тормозе. Никто об этом не упомянул, но для меня главная проблема - безопасность. Случись что с цепью при спуске с горы, последствия могут быть крайне неприятными. У меня такое было на форварде, цепь слетала. К счастью, спуск был коротким.
А я верно понимаю, что все эти стикеры актуальны только если MirPay не поддерживает ваш банк или у телефона нет NFC (кто-то такими ещё пользуется?)? Учитывая, что большинство комментирует подобные новости в положительном или нейтральном ключе, думаю, что это я чего-то не понимаю. Ведь есть же MirPay.
Я там же пишу, что в самом начале люди, писавшие игры на Unity, именно исходники библиотеки клали к себе в проект. Соответственно, эти исходники должны были компилироваться. А Unity в те времена не поддерживал версию языка выше 6-ой.
В статье далее же пишу, что сейчас у меня есть поставки и в виде ассетов – максимально нативного способа интеграции 3d party продуктов в Unity. Но я всё равно оставляю возможность использовать библиотеку через исходники на древней версии Unity.
Спасибо! :)
Добавил информацию.