Одно пространство имён для всего или же отдельные под каждую папку? Быть может, есть варианты интереснее? Рискнём и ступим на землю жестоких программистских баталий, в которых льётся цифровая кровь и рождается “истина”: какая из организаций пространств имён есть свет, а какая от лукавого.

Ах, если бы пользователи всегда разбирались в предметной области и передавали в наши замечательные алгоритмы только допустимые данные… Но реальность беспощадна, и проверки аргументов — необходимость. В статье посмотрим, как определение своего значимого типа может с этим помочь.

В статье завершим цикл материалов по преобразованию MIDI-времени в другие форматы. Попутно столкнёмся с неожиданным приступом оверинжиниринга, напишем микроскопическое количество кода и откроем для себя неправильную музыку.

Статья поведёт нас через границу, где сходятся MIDI и метрическое время. В этом путешествии мы откроем брошюру по Международной системе единиц СИ, повстречаем файлы с более чем 6000 изменений темпа, столкнёмся с ошибками округления и напишем немного кода. Звучит заманчиво? Тогда добро пожаловать!

Вы покупаете книгу в бумажном исполнении, вдыхаете аромат её страниц, начинаете читать это чудо человеческой мысли и печатного станка, как вдруг… #%^#@&*#^~$%? Чуть выдохнув, вы пытаетесь понять, а что, собственно, за ахинею вы только что загрузили к себе в мозг? В этой статье поделюсь своим опытом, полученным от попытки прочитать переводную книгу от издательства Бомбора. Только сразу предупреждаю: от показанных примеров «перевода» могут случиться истерические припадки.

На написание данной статьи меня вдохновила другая – Как делается OpenSource: личный опыт. Мой проект DryWetMIDI менее масштабный, но тем не менее весьма популярен в своей нише. В статье я вспомню, как он создавался, развивался, что дал (и продолжает давать) и какие были любопытные моменты по пути. Надеюсь, сии мемуары будут вам интересны и полезны в ваших собственных начинаниях.

Представьте: вы создаёте новый шедевр в любимой DAW, вставляете в проект MIDI-файл, редактор показывает, что ноты в нём имеют восьмую длительность. Не обращая на это внимания, вы продолжаете творить. Но, постойте. А как DAW, собственно, понимает, что ноты в файле восьмые?

В статье попробуем разобраться, как времена в MIDI-файле соотносятся с главным форматом времени при работе с музыкой – тактами и долями. Результатом наших исследований будет законченный алгоритм на C#.

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

Надеюсь, данная статья поможет ответить на эти и другие вопросы. На примере своей библиотеки с открытым исходным кодом – DryWetMIDI – рассмотрим различные аспекты создания подобных проектов. И хотя речь будет идти про .NET/C#, уверен, многое применимо и к другим популярным платформам и языкам программирования.

Ранее мы уже посмотрели, чем нам может помочь .NET в реализации задачи, обозначенной в теме статьи, в Windows. Сейчас рассмотрим её решение в macOS.

Вы пишите код на платформе .NET под Windows и вам нужно выполнять некоторые действия каждую миллисекунду. Возможно ли это? Какие есть варианты и насколько они надёжны? Разберёмся, что можно использовать, и какие есть гарантии по точности срабатывания. Статья сконцентрирована на поиске такого решения, которое работало бы и под .NET Framework, и под .NET Core / .NET, и в разных версиях ОС, и являлось бы механизмом общего назначения (а не только для программ с GUI, например).

Возможности по работе с MIDI-устройствами в macOS очень богатые (по сравнению с Windows, например), однако, официальная документация не может похвастаться подробным изложением. Приходится подглядывать в другие проекты, а также много экспериментировать, что не всегда удобно, если компьютер не сильно мощный, а единственной возможностью отлаживать код под macOS является использование виртуальной машины. В этой статье я покажу базовые сценарии работы с CoreMIDI и постараюсь восполнить пробелы в документации.

When creating a .NET library with a partially platform-specific API, we should think about how to pack it into a NuGet package so that the installed library will work in various scenarios (.NET Framework, .NET Core, self-contained application and so on). Unfortunately, it is difficult to find a step-by-step instruction on the web that describes how to perform this task. This article is intended to be such an instruction.

Когда речь заходит о создании .NET библиотеки, части API которой являются платформозависимыми, приходится думать, как всё это оформить в NuGet пакет, да так, чтобы установленная из пакета библиотека работала в разных сценариях (.NET Framework, .NET Core, self-contained app и т.д.). К сожалению, в сети сложно найти инструкцию, которая бы шаг за шагом показывала, как выполнить эту задачу. Данная статья призвана быть такой инструкцией.