Pull to refresh
114
0

Desktop software developer

Send message

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

Покажите, пожалуйста, ваш код, как вы проверяли. Если вы говорите про приближение действительного числа рациональным, речь же про метод FromDouble? Если так, то там невозможно получить зависание, как я уже упомянул выше. Более того, вам не нужно ничего делать с количеством итераций, просто не указывайте и всё будет работать с настройками по умолчанию :-)

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

Видимо, дело вкуса.

Пусть будет дело вкуса.

Ваша реализация приближения действительного числа рациональным содержит ошибку, в результате чего итератор может входить в бесконечный цикл

var musicalTimeSpan = MusicalTimeSpan.FromDouble(
    0.77777777,
    new DoubleToMusicalTimeSpanSettings
    {
        FractionalPartEpsilon = 0.0000001
    });

За пару миллисекунд получил ответ 7/9. Никакого бесконечного цикла быть тут не может. Если вы посмотрите в настройки, там, помимо эпсилона на дробную часть и ограничения по точности приближения, есть ещё ограничение по количеству итераций. Это тот рубильник, который и призван спасти от каких-либо циклов и зависаний. Всё же лучше сперва проверять перед тем, как "находить ошибку" ;-)

А кроме того стоит уровень статьи Средний. Уровень это про текст статьи, но в статье (если это вообще статьёй можно назвать) нет ничего требующего навыков отличных от навыка чтения.

Также замечу, что существует сайт Code Review Stack Exchange, созданный специально с целью помогать ревьювить код и помогать с кодом в плане архитетуры, стиля и всего такого. Я подозреваю, что автору нужно было написать туда.

На данный момент для получения удовольствия от помощи людям с их проблемами, связанными с 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);

Тогда нормализация рационального числа это наименьшая из всех проблем.

А проблем, собственно, и нет, статья крохотной получилась. Этот формат самый простой для реализации. Разве что меня занесло с диофантовыми уравнениями в своё время :-)

Есть и орфографические ошибки и перевод с английского в лоб, текст читается очень тяжело.

Здравствуйте!

Спасибо, что вышли и тут на связь :-) Хотел бы обозначить несколько моментов:

  1. Мой экземпляр книги от 2020-го года. Я так понимаю, это доп. тираж. Есть ли у вас в издательстве ревью текста между тиражами?

  2. Да, разумеется, если мы сосчитаем процент громких жалоб относительно общего числа ваших книг, число будет, вероятно, небольшое. Вопросы вызывает вообще наличие таких вопиющих ошибок. Такое попросту невозможно пропустить человеку, немного разбирающемуся в теме, а у вас для этого целый научный редактор должен быть.

Далее, про 2018-ый год. Я приведу несколько примеров.

? Друзья. 25 лет вместе. Как снимали главный сериал эпохи | Аустерлиц Сол

Год выпуска: 2023. Комментарий:

ужасный дословный перевод, разрозненный текст, сомнительный шрифт

? Эволюция разума | Курцвейл Рэй

Год выпуска: 2021. Комментарий:

Дала почитать хорошему другу. Он сказал что перевод плохой и много опечаток. Как могли доверить перевод такой важной книги не пойми кому? Бомбора (Эксмо) вроде уажаемое издательство, у меня в детстве были их энциклопедии и поэтому обидно что так.

? Рождение машин. Неизвестная история кибернетики | Рид Томас

Год выпуска: 2019. Комментарий:

Перевод оставляет желать лучшего. Без знания английского и предположений о том что было написано в оригинале смысл некоторых предложений может быть утерян.

Да, в этих комментариях нет конкретики, нет примеров. Но знаете, что огорчает больше всего? Что вы не отвечаете на эти отзывы. Продавец у всех трёх книг Торговый Дом «Эксмо». Это либо вы, либо ваше представительство. В ваших же интересах поинтересоваться у автора отзыва, что именно не так. Возможно, списаться лично для более подробного списка косяков. Нет даже банальной отписки о том, что вы сожалеете, что так вышло. У вас нет коннекта с вашими читателями, вы его и не ищете.

К слову, ваши конкуренты Альпина Паблишер/АНФ на все такие отзывы всегда отвечают, даже на положительные, иногда даже сами предлагают ещё книжки на схожие темы. И жалоб на их переводы я сходу найти не смог.

У вас внутри издательства, наверняка, много знакомых с разных сфер науки и техники. Ну дайте вы перед публикацией паре-тройке таких почитать текст. Если косяки есть, они их увидят, вы исправите, выпустите замечательную книгу, а той фокус-группе бесплатно вышлете напечатанные варианты. Если вы боитесь, что так текст может утечь, то в чём большие минусы? Ну даже если спиратят, оно вам на пользу будет, такой пиар тоже работает. Если материал интересный, люди захотят подержать его в руках потом.

Ещё хочу сказать, что, например, тут на Хабре регулярно выходят статьи от издательства Питер, и про новые их книги и про распродажи полезных образцов. Почему бы вам тоже не делиться со здешней аудиторией информацией? Будет стимул улучшить свои процессы и выглядеть достойно.

Я эту книжку читал не так давно в варианте от 2002-го года в электронном виде (Хакеры. Герои компьютерной революции). Переводчик: Лукин Алексей, 2001 год, г. Иркутск. Не знаю, как у Бомборы (но подозреваю), но тот древний перевод ни разу не заставил меня споткнуться нигде. Там даже есть раздел в самом начале Предисловие к русскому переводу.

А сама книга отличная. Очень интересно рассказано про зарождение компьютерных энтузиастов и в целом индустрии компьютеров. Будет весьма жаль, если Бомбора и этот текст испортила.

Добавил вводную информацию в начало статьи. Думаю, подробнее уже не стоит, все необходимые ссылки я привёл.

В принципе, это как с XML. Вряд ли "работа с XML-файлами" будет вызывать вопросы касательно применения такой библиотеки. MIDI – тоже формат данных с большим количеством сценариев использования.

Но в целом согласен, что какое-то краткое описание предметной области нужно было добавить. Спасибо!

Точно ли вы читали? :-)

  1. Это не приложение, а библиотека.

  2. Если перейти по второй ссылке сразу же в началне статьи, то можно перейти на страницу проекта в GitHub, где всё подробно расписано.

  3. Более того: первый же раздел в статье ("А почему бы..."), третий абзац:

Вот и ответ – напишу библиотеку для работы с MIDI-файлами.

  1. Ну и далее по статье много информации, что библиотека умеет делать. Например, в подразделе "Ещё одна библиотека".

Или вы о том, чтобы продублировать README проекта? Если это будет полезно, то могу добавить.

Или же с давно существующим в 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 простым горником с тормозами на руле, я теперь не представляю, как ездить на ножном тормозе. Никто об этом не упомянул, но для меня главная проблема - безопасность. Случись что с цепью при спуске с горы, последствия могут быть крайне неприятными. У меня такое было на форварде, цепь слетала. К счастью, спуск был коротким.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity

Specialization

Software Developer, Test Automation Engineer
Lead
C#
.NET
Git
Selenium
Test Automation