Синтезатор с чистым строем

[Toman]

Чередование меандров по 100 (50/50) тактов и по 101-му (50/51)
Разница на слух есть.

Я вот не слышу особо, кстати. Ну т.е. по спектру понимаю, что примерно "должен" слышать - некий темброво богатый звук на октаву ниже целевого. Но его громкость столь мала, видимо, что целевым звуком маскируется напрочь. По крайней мере, через мои домашние колонки, и при моём личном относительном восприятии силы звуков разной высоты. Может быть, для кого-то это и не так.

...Попробовал модифицировать второй вариант именно так, как описал выше. Если посмотреть на спектр результата - то спектра все лишние гармоники почти исчезли, однако, конечно, вылезают наверху. Но это чисто цифровой анализ, т.е. он не совсем отражает спектр того аналогового сигнала, который выходит. Вероятно, если соответствующим образом ещё чуть сгладить оставшиеся острые фронты, от этих гармоник останутся вовсе жалкие следы (правда, и "правильные" гармоники тоже уйдут в верху спектра - но выше 14-15 кГц я в общем-то вряд ли чего слышу, а если кому эта разница принципиальна - повышайте частоту дискретизации).

...Наконец, собрал и попробовал программу в действии. Во-первых, самое главное - у меня она тоже работает, и это хорошо, ура. Попробовал придумать какую-нибудь другую форму волны - но чтобы была симметричной относительно нуля (вообще говоря, меня интересует симметричность только в смысле того, чтоб постоянной составляющей не было, чётность/нечётность функции роли не играет, но я не делал её специально какой-то "художественно кривой", а просто собрал из трёх синусов, но не простых синусов, а в трёх разных степенях - 1-й, 3-й и 5-й, и, соответственно, взятых от соответствующей же степени координаты):

float a, s5, s3, s1, x;
//...
 x = (2.0*(float)phase/(float)period-1.0);
s5 = sin(M_PI*(x*x*x*x*x+1));
s3 = sin(M_PI*(x*x*x+1));
s1 = sin(M_PI*(x+1));
a = 2200*s5*s5*s5*s5*s5+2200*s3*s3*s3+600*s1;
sample += a;

Тембр, конечно, другой, но в принципе тоже возможный вариант. В каких-то регистрах кажется пожёстче звучащим, в каких-то других - наоборот, помягче. А постоянного смещения, надеюсь, теперь нет.

А вот про собственно строй позволю себе таки немножко поругаться. Попробовал сыграть небольшую простенькую фразу, которую когда-то сочинил ещё в школьные годы (на фоно). Тем более, что тембр (оба варианта) практически идеально подходит для того, как изначально задумывалась фраза (пианино было лишь неизбежной на то время заменой, за неимением даже синтезатора, не говоря уж об ансамбле из 3-5 духовых вроде практис-чантеров или крумхорнов). Фраза вся на белых клавишах, причём использует все 7 нот, т.е., вероятнее всего, тональность там "наша". Но тут же нарываюсь на кривущие терцию и квинту (звучащие там как гармонические интервалы) от ре. Потом обнаруживаю ещё по ощущениям довольно кривую при движении по мелодии секунду ля-си. Ну т.е. это достаточно серьёзная проблема. Так что при попытках использовать чистый строй или что-то близкое множество клавиш для разных случаев - неизбежны, имхо. Причём поставить эти клавиши на клавиатуре даже в принципе можно было бы - если отказаться от части "черноклавишных" нот, неактуалных для конкретного произведения.
Другая проблема (в случае данной фразы - даже бОльшая, чем кривые интервалы) - сыграть эту фразу в виде, похожем на то, как оно играется на фоно (или как это должен был бы играть ансамбль) - невозможно, потому что нужные аккорды с октавным удвоением попадают под запрет, приходится урезать практически до двухголосного, что звучит намного хуже...

[xjiss]

Toman, прежде всего, большое спасибо за критику.

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

Ещё нет - пока только читаю сорцы, чтобы понять, что там и как. И
офигеваю... То есть, с точки зрения чисто технической - всё вроде
нормально. Т.е. программа (по крайней мере у вас на компьютере)
работает, звук синтезирует и выводит на нужной частоте - это хорошо.

Реально она проверялась на 4-х различных компах
1) какой-то ноутбук, которого я не видел, с Ubuntu
(из-за этой Ubuntu, кстати, я и отказался от варианта
с функцией обратного вызова - он не работает с Pulse Audio,
который в той Убунте по умолчанию ставится; перешел на вариант
с 2-мя нитями)
2) относительно старый PC с Debian Lenny
3) относительно новый PC с Debian Squeeze
4) древняя кастрюля (P-какой-то 400 MHz) с Debian Squeeze

Звучки везде вроде как встроенные, Intel.

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

Ок, буду весьма признателен.
На остальное отвечу в следующем/следующих сообщениях.

[xjiss]

Ну, с вашей целочисленной арифметикой - конечно, разъедется. Вы же
фактически аппроксимируете любую ноту унтертонами частоты дискретизации.

Ну можно и так сказать, наверное.
Только не "аппроксимирую", а "использую".
Там ничего никуда не аппроксимируется, там все абсолютно точно.
Период самого низкого тона задан (720),
а дальше от него танцуем - например, 720*(4/5) = 576,
чистая б.терция (ми) и т.п. Некоторые тоны в верхних октавах
получаются нечистыми, но тут уж ничего не поделаешь.

И опять вопрос: зачем вам именно абсолютно точно?

1)
Мне это нужно ПО ОПРЕДЕЛЕНИЮ ЧИСТОГО СТРОЯ. ПО ОПРЕДЕЛЕНИЮ.
http://en.wikipedia.org/wiki/Just_intonation
Программа как называется?
Just Intonation Synthesizer.
Для этого и нужно абсолютно точно, чтобы контент соответствовал
названию.

2)
Для чистого строя это МОЖНО сделать.

Если бы мне взбрендило использовать 12TET, тогда
да - начихал бы я тогда на точное соблюдение интервалов.

А почему бы целочисленный период не поменять на нецелочисленный?
Разумеется, не просто так поменять тип переменной, а соответствующим
образом переделав всю схему синтеза звука.

Брр, какой еще тип переменной?
Индекс массива - он был, есть и будет целым.
Вы про тип, используемый для отсчетов?
Он тут вообще ни причем, мы ведем речи про периоды
и про частоты, то есть точность по времени, а не по уровню
сигнала.

Вот уж чего мне совершенно неинтересно делать - так это на такую тему
ругаться.

Фух... это хорошо! )

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

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

Ну, или такое вот дополнение к этому "аргументу".
Допустим, когда-нибудь я сделаю переключалку тембров
(какбы инструментов). Тогда мне надо будет для каждого тона
каждого тембра заранее нагенерить сигнальчиков.

Ну, вобщем, всё как обычно - компромисс
экономим процессорное время-жрём память. ))

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

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

Я объясню. Я дня два-три возился с подбором формы сигнала
(ну, чтобы от звука уши не рвало). В конце концов сделал
гауссиану, на первом полупериоде - "вверх", на втором полупериоде -
"вниз". Понравилось. Убрал второй полупериод - еще больше понравилось.
Так и оставил однополярный сигнал. Можно его, конечно, двинуть вниз,
но это же думать надо, насколько )))

А щелчков-то как раз при этом меньше,
так как все ноты и почти все аккорды
оканчиваются нулём.

Боитесь, вам точности типа double, например, не хватит, чтобы никто не
услышал биений, что обязательно нужно рациональную дробь из настоящих
целых чисел (в виде реальных физических отсчётов на звуковой карте)
сооружать? Я уверен, что такие опасения напрасны, причём с очень-очень
большим запасом.

Причем тут точность для значений отсчетов?
Не причом тут она вообще.

Я ещё раз повторю: звуковые карты создавались для работы с произвольным
звуком путём приближения, а не для асбстрактных меандров и т.п. И там
стоит выходной фильтр, который вам уже в аналоговой выходной линии
(намеренно!!! специально для этого и стоит!) переход от 16384 к -16384
размажет на время, соответствующее этак почти что паре отсчётов.

Разумеется, диффузор динамика переходит из одного положения в другое
не за нулевое время. И про фильтр всё правильно. Идеальный
меандр - ну да, это абстракция, в реальности всегда есть переходные
процессы конечной длительности.

Но! Соотношения периодов-то это же не исправит!
Или я чего-то где-то сильно не догоняю...

[xjiss]

Если мы изначально начнём полупериод выровненным по началу
первого отсчёта, то будем иметь 50 отсчётов значением +16384, потом
отсчёт, у которого 1/4 приходится на значение +16384, а 3/4 - на -16384.
....

Вроде понял. То есть Вы учитываете работу фильтра;
если слегка схитрить, введя как бы промежуточные
отсчеты, то на выходе поимеем сигнал с периодом
100.5 тактов дискретизации ну или что-то весьма
похожее.

Я-то изначально имел ввиду "идеальный" меандр
и при этом без учета того, что там делают ЦАП, фильтры,
усилители, колонки/наушники, воздух и уши;
иными словами, я смотрел на это дело просто как на вопрос
заполнения массива числами - есссна, в таком виде
решения просто нет и не может быть.

С "хитростями", учитывающими физические реалии - да.

скачки, а вовсе не для того, чтобы у кого-то волшебный период в 720
отсчётов в области инфразвуков не оказывался

Так с таким волшебным периодом мне не надо "хитрить"!
Там всё само собой как надо получается для любой формы
сигнала, все периоды (частоты) соотносятся так, как
положено по определению чистого строя.

[xjiss]

Наконец, собрал и попробовал программу в действии. Во-первых, самое
главное - у меня она тоже работает, и это хорошо, ура.

Это радует, но не удивляет - там только xlib и alsa используются,
чтоб как можно ближе к телу, так сказать, было.

Ну и posix threads, но с этим вроде как уж давно проблем нет.

[xjiss]

А вот про собственно строй позволю себе таки немножко поругаться.

А давайте!

Попробовал сыграть небольшую простенькую фразу.
Фраза вся на белых клавишах, причём
использует все 7 нот, т.е., вероятнее всего, тональность там "наша". Но
тут же нарываюсь на кривущие терцию и квинту (звучащие там как
гармонические интервалы) от ре.

Всё правильно.
Квинта ре-ля в диатонике чистого строя от до - кривая.
Равно как и малая терция ре-фа.
Но там же есть тон ре-минус (клавиши s, 2, 9).
С этой второй "ре" терция ре-фа и квинта ре-ля - акустически чистые.

Потом обнаруживаю ещё по ощущениям
довольно кривую при движении по мелодии секунду ля-си.

Куда хочется "си" двинуть - вверх?

Ну т.е. это
достаточно серьёзная проблема.

Ага, и ей уже лет этак 2 тыщи как минимум ,)

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

Как бы это сказать... Эти все так называемые "проблемы" чистого строя
на самом деле не являются проблемами именно строя как такового.
Он то сам по себе как раз, что надо.

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

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

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

Ох, с этим, я, к сожалению, ничего не могу поделать.
Так работает софтинка микроконтроллера клавиатурок.
Причем я вообще не понимаю логики, так сказать.

Например, 4-х звучный аккорд (n-y-i-p) "работает",
4-х звучный аккорд (b-t-u-o) тоже работает,
а вот фа (v-r-y-i) уже фигвам.

До мажор (i-p-]) - тоже не играет.

Какими соображениями руководствовались разработчики клавиатуры -
для меня это есть загадка великая.

[xjiss]

По поводу загрузки CPU при расчетах волны на лету
(имею ввиду эту свою гауссиану на первом полупериоде).

На уже упомянутой древней кастрюле с чипсетом i810
и процом Celeron (Mendocino), работающим на частоте 400 MHz,
наблюдается следующая картина.

Если "играть кулаком", то максимум, что занаблюдалось - 50%.
На некоторых аццких звукосочетаниях в 5-6-7 тонов - до 60%.

То есть даже для древнего железа еще есть запасик.

Я к тому, что, может и нет резону считать сигналы для всех нот
и для всех тембров (инструментов) заранее...
Как думаете?

[Toman]

Я к тому, что, может и нет резону считать сигналы для всех нот
и для всех тембров (инструментов) заранее...
Как думаете?

Немножко подумал, и решил, что считать заранее ...всё-таки в любом случае лучше, чем считать на лету. Причём, даже в обоих случаях - и для целочисленного периода колебаний (если это всё-таки имеет какое-то концептуальное значение), и для нецелочисленного (что для получения на практике сигнала, неотличимого на слух от нужного, вполне годится тоже, но даёт возможность получить сколько угодно нот в октаве, а значит, работать, в принципе, хоть в самом лучшем для каждого конкретного произведения "гибридном" строе (ну, то есть, мелодию ведём по тем интервалам, которые выгодны именно для ведения мелодии (а это - пифагоров тон, полуторатон, кварта, квинта и т.д.), в то время как гармонию для неё делаем терциями чистого строя, по возможности - по крайней мере, если речь идёт о простых мажорных или минорных трезвучиях) ). Т.е. то, чего жёстко заданный 12-ступенный строй, разумеется, не позволяет, из-за чего я на него и ругаюсь. Ну и, разумеется, возможность настраиваться в любые частоты.

Если по-прежнему делать только целочисленные периоды - то тогда имеет смысл рассчитать сразу (при запуске программы или при загрузке/смене тембра) ровно по одному периоду колебания для каждой ноты (каждого тембра). Поскольку нот у вас сейчас порядка 30, а средняя длина периода, наверное, порядка 300 отсчётов или менее, памяти на 1 тембр понадобится около 9 тыс. отсчётов, или 18 кб. Ну, допустим, можно предположить, что даже добавится ещё 12 нот (если перевести основу на октаву ниже, на 1440 отсчётов), ну, станет под 50 кб. Всё равно ни о каких страшных мегабайтах речи не идёт. Можно спокойно держать в таком виде хоть десяток-другой тембров одновременно. А вот во время игры, особенно если в хорошем темпе, да с одновременно включёнными несколькими регистрами, например, да тяжёлыми аккордами и т.д., процессорной мощности это сэкономит прилично. Да и загрузка процессора 50% - это, имхо, для такого синтезатора многовато. И вообще, почему бы не посчитать сэмплы заранее, если в данных тепличных условиях (целочисленный период) это не просто, а очень просто. До того, как я заглянул в код, я был вообще уверен, что всё заранее и считается, т.к. это было бы наиболее естественным объяснением для использования строго целочисленного периода.

Соответственно, что происходит дальше, как я это себе представляю... Дальше мы делаем буфер или "цепочку" из нескольких буферов (тут уж надо мне разобраться подробнее с тем, как происходит вывод звука при помощи данной библиотеки, как всё это синхронизируется и т.д., чтобы прикинуть, сколько именно нужно буферов и как им работать). Разумеется, память под буфер выделяется тоже заранее (а то, может, дажи и просто объявляется статически), и во время игры не меняется. Ибо такое постоянное выделение-освобождение динамической памяти под буферы со звуком во время игры, имхо, суть что-то чрезвычайно неправильное и нежелательное. При сравнительно лёгких условиях оно может работать нормально, но чуть что... В общем, работать с динамической памятью в цикле работы со звуком - это значит активно нарываться на проблемы. Так что делаем буфер/буферы некоторого фиксированного размера исходя из величины latency, которую мы хотим с точки зрения исполнителя /с которой вынуждены мириться из-за условий и ограничений, налагаемых ОС. Дальше, по ходу вывода звука в эти буферы, так же, как оно и сделано сейчас, у каждой из активных нот растёт, с регулярным возвратом на ноль, приписанная ей фаза, и из суммы взятых значений из предвычисленных сэмплов этих нот получается значение очередного отсчёта, ну и цикл идёт дальше. Таким образом, у нас нет никакой необходимости вычислять общий период для аккорда, а каждая нота может продолжать непрерывно звучать независимо от начала или конца звучания других нот. Для того, чтобы избежать щелчков, либо выключение (равно как и включение) нот допускается только при прохождении уровня сигнала близко от нуля (т.е. вместо нынешней единственной переменной по активным нотам делаем две - "запрос на включение/выключение" и реальную активность, или просто сэмплы делать такими, чтобы у них этот ноль был в самом начале/конце периода, и довыводить даже "неактивную" ноту до окончания её текущего периода). Либо сделать ещё более хитро, и включать/убирать звучание не моментально, а умножая сэмпл во время переходов на какой-то ряд величин (тоже предвычисленных, если хочется красивой кривой, или рассчитываемых на ходу по какой-то сравнительно лёгкой функции - напр. если это простая прямая линия), введя для этого дела ещё одну переменную для каждой ноты - "фазу" по кривой нарастания-спадания, с некоторой выделенной точкой, на которой коэффициент заведомо равен 1, и умножение не производится, равно как и начальной точкой, в которой он равен 0, и опять же умножение не производится, а нота просто игнорируется при сборке значения для записи в буфер, ну и соотв. переменная "активности" ноты в этом варианте будет просто управлять движением по этому "кругу" нарастания-спадания. Умножение, конечно, добавляет процессорного времени, но всё же это полегче, чем полномасштабное вычисление отсчёта. Если предполагается когда-нибудь использовать варьирование уровня звука (напр. если научить программу играть по MIDI управлению или что-то в этом роде), то умножение, видимо, всё равно неизбежно, уже для всего времени, пока ноты звучат.

Или же можно как бы скомбинировать идею выравнивания по началу-концу периодов, и идею делать профилированную атаку и спадание. И сделать практически "по-взрослому": предвычислить не только 1 период середины звучания, но и атаку и спадание звука. Так, разумеется, вычислять, чтобы сэмплы мягко стыковались по концам в порядке атака-середина-спадание (собственно, сэмпл может представлять собой единый массив, просто с указанием того участка, который представляет собой период продолжающегося звучания, и внутри которого программе надо будет крутиться, пока для ноты указано "активна"). Конечно, настоящие "взрослые" атака и спадание звука должны занимать как минимум несколько периодов колебаний (а "игрушечные" делать мало смысла, т.к. это не будет на слух лучше первого метода или того, что есть в программе уже сейчас), поэтому необходимая для хранения память возрастёт. Но поскольку, как мы видели, объём этой памяти для одного тембра и 30 нот, в общем-то, совсем не страшный, вполне можно себе позволить увеличить раз в 10-20, ради того, чтобы сделать красивую атаку и затухание (во время которых, в отличие от второго варианта, с умножением на число, можно не просто плавно менять громкость, а довольно сильно менять и тембровый состав, что делает более реалистичной в особенности атаку).

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

[Toman]

А теперь - о том, что и как меняется, если мы уходим от целочисленного периода к произвольным частотам. Вообще-то и здесь нет жёсткой необходимости вычислять на лету. Можно тоже предвычислить сигнал. Но только помня, что, поскольку теперь "фаза" будет с каждым отсчётом (выводимым, т.е. с "системной" частотой дискретизации) возрастать не на единицу, а на какую-то нецелую величину, повторения значений по отсчётам не будет. Поэтому предвычисляем мы период, разумеется, в виде целого числа отсчётов (нецелым количество отсчётов в массиве, разумеется, быть не может), но с частотой дискретизации, отличной от той, на которой будет происходить вывод звука. Соответственно, каждый отсчёт вывода будет попадать по фазе не точно на какой-то отсчёт нашего сэмпла, а между. И вот тут возможны варианты, и зависит это в первую очередь от избранного нами числа отсчётов на период (это может быть абсолютно любое целое число). Например, если это небольшое число (например, ради экономии памяти), то, чтобы избежать сильных искажений, необходима будет интерполяция - хотя бы линейная между соседними отсчётами - фактически, то самое, что я демонстрировал в качестве "хитрости" с меандром (хотя возможны теоретически и другие варианты интерполяции). А можно поступить и проще: предвычислить сигнал, подробив его очень мелко, т.е. на длинном массиве. Т.е. сделать что-то вроде оверсэмплинга. И тогда можно просто тупо брать отсчёт, ближайший к значению фазы (нецелому) для данного отсчёта вывода - интерполяция как бы уже сделана за нас, с какой-то, заведомо достаточной для практики, точностью.

Разумеется, необходимая для сэмпла память в разы возрастает при таком оверсэмплинге, равно как и время на вычисление. Но это на самом деле компенсируется (порой, с избытком даже) тем, что, в отличие от подхода со строгим совпадением частоты дискретизации для вычисления (с целым периодом, разумеется) и частоты дискретизации вывода, здесь нет необходимости предвычислять и хранить сэмплы для каждой ноты. В простейшем случае - т.е. для того, чтобы всего лишь воспроизвести ситуацию, имеющуюся в программе сейчас, с единственной функцией на все ноты - достаточно вообще посчитать единственный период. Например, тыщ на 8 отсчётов посчитать (а при желании - да хоть на 80 тыс., только это, пожалуй, вовсе уж избыточно) период, потом, при выборе частоты дискретизации вывода, на этапе общения с системой, посчитать для каждой ноты, скольким "внутренним" отсчётам будет равен отсчёт вывода (плавающее число), т.е. на сколько продвигать "фазу" ноты с каждым отсчётом. И т.о. для каждой ноты хранить фактически только "фазу", т.е. текущее положение на общем на все ноты сэмпле, да этот самый коэффициент, на сколько сдвигаться с каждым выводимым отсчётом. Здесь тоже возможен вариант с предвычисленными атакой и затуханием, конечно. Ну а если хочется делать более серьёзный тембр, "адаптирующийся" к частоте тона, то можно сделать несколько "образцовых" тембров - скажем, штучки по 1-3 на октаву. И простейшим, хоть линейным, образом интерполировать потом результирующий отсчёт из двух соседних образцовых тембров. (Конечно, чтобы это гладко сработало, эти образцовые тембры должны быть достаточно хорошо согласованы по фазам участвующих там гармоник или элементарных форм сигнала, из которых оно там синтезируется, чтобы они в промежутке между "опорными" нотам не глушили сами себя, оказавшись в противофазе, или под 90 градусов, или типа того).

Причем тут точность для значений отсчетов?

Как видите, это я не столько про значения отсчётов (хотя и их можно сделать плавающими, при желании, или просто увеличить число бит, т.е. перейти на 32-битные отсчёты хотя бы, для снижения накапливающихся при суммировании многих нот ошибок дискретизации - но это, во всяком случае, не первой важности вопрос на данном этапе), а про точность нецелого смещения каждой ноты ("генератора") по "фазе" при выводе каждого отсчёта. Разумеется, у плавающих типов есть своя точность, и из-за этого в итоге реальные частоты считаемых таким образом звуков будут, строго говоря, не совпадать точно с желаемыми, и от этого чистота строя будет, строго говоря, нарушена. Но, насколько я знаю, реальный счёт плавающих чисел на современных компах идёт как минимум в double, так что что-то ниже double для "фазы" использовать нет смысла. Исходно собственная точность этого типа близка к 16 десятичным знакам. К сожалению, правда, при прибавлении к фазе смещения из-за разности порядков самой фазы и смещения точность уменьшится на столько же порядков. Скажем, для частоты тона 12 Гц (беру как бы худший случай, с точки зрения относительной точности - самое большое количество смещений на период) на частоте дискретизации 48 кГц соотношение составит примерно 4000 - т.е. почти ровно 12 двоичных порядков (12 двоичных цифр долой из 53, имеющихся в типе double) или примерно 3,6 десятичных порядков. Т.е. оставшаяся точность (отдельной операции сложения) составит 41 двоичную цифру, или примерно 12,3 десятичных цифр. На самом деле, впрочем, ошибки округления будут падать в разные стороны, распределяясь достаточно равномерно, скорее всего, так что на самом деле суммарно по периоду точность будет несколько лучше, но, опять же, допустим, в качестве худшего случая, что все округления будут давать именно максимальную ошибку, и всякий раз в одну сторону. Т.е. точность соответствия частоты заданной будет в худшем случае 12,3 десятичных знаков, а в абсолютном значении порядка 10^-11 Гц.
Или, скажем, для частоты 400 Гц - теряем примерно 7 двоичных или 2,1 десятичных порядков, т.е. точность 46 двоичных или 13,8 десятичных знаков, а в абсолютном значении точность выдерживания частоты в худшем случае опять же порядка 10^-11 Гц. Т.е. возможный (и то, это в худшем случае, практически нереальном, имхо!) период биений из-за ошибок плавающей арифметики можно было бы ожидать порядка 5*10¹⁰ секунд, т.е. порядка 1500 лет. Имхо, такой точности соответствия частот друг другу всё же должно быть достаточно, чтобы считать строй в соответствующим заданному для любых практических целей

[Toman]

Всё правильно.
Квинта ре-ля в диатонике чистого строя от до - кривая.
Равно как и малая терция ре-фа.
Но там же есть тон ре-минус (клавиши s, 2, 9).
С этой второй "ре" терция ре-фа и квинта ре-ля - акустически чистые.

Хмм... Сам я как-то не догадался там искать другую ре, т.к. все остальные ноты в "верхних" рядах суть "черноклавишные", и я как-то просто не ждал там варианта ре. А про наличие в таблице в исходниках значения 10/9 честно забыл
Но тут тоже свои проблемы с его использованием. Во-первых, получающийся мелодический интервал 10/9 (который, в результате, имеет место и в басу, и в среднем голосе, и, естественно, в квинте, которая в верхнем голосе) воспринимается как довольно сильно несоответствующий ситуации. Во-вторых, кроме ре, фа и ля, которые по строю в таком аккорде соответствуют, во фразе участвует соль, которая теперь образует нам кривую кварту... Можно, конечно, на время звучания этой соль переходить на "основное" ре, а потом, когда пойдёт ля, вернуться на ре-минус. Но это не решает проблемы мелодически неприятно суженного интервала. Так что для адекватной игры второго "колена" фразы от ре больше бы подошёл повышенный вариант ля (ну и, по вкусу, также повышенный вариант фа - если хочется именно чистую терцию). Что происходит в третьем "колене" фразы, и какие ноты там были бы наиболее уместны - я пока не анализировал, т.к. там картина, пожалуй, сложнее (работают бас и середина ми, и в верхнем голосе и ля, си, до, ре). Но на слух, там как раз всё как надо. И даже мелодический ход на 10/9 секунду в этом случае воспринимается почему-то спокойнее.
Да, внезапно обнаружилось, что, кроме как в самой верхней октаве, "бьют" квинты ми-си и фа-до - хотя чисто с точки зрения строя, не должны. Т.е. это уже технические глюки какие-то, непонятно откуда берущиеся.

Куда хочется "си" двинуть - вверх?

Хм... Я вообще не уверен, что именно си. Дело в том, что "кривым" на самом деле мне показалось сочетание этой секунды с предыдущей соль-ля. Потому что они там разные, а в тот момент хотелось скорее одинаковых. А уж куда что двигать хотелось, и вовсе неопределённый вопрос. Может быть, двигать хотелось вообще соль. Но, во всяком случае, неравенство мелодических секунд как-то ощущается, и в некоторых случаях это ощущение неприятно. А в других случаях вроде и ничего - вот, как c ре на ми в этой моей фразе, который воспринимается нормально. М.б. потому что там что-то вроде минора перед этим, и зауженная секунда воспринимается как-то уместнее. А когда ноты в голом виде, или, допустим, с ля минора на си переходить... Нет, чёткого ответа всё равно не дам, это надо было бы попробовать посравнивать разные варианты, если бы они были - тогда бы можно было что-то понять. Я всё-таки не такой спец по настройкам, и не скрипач или какой ещё спец по интонированию, чтобы так сразу сказать "я бы сыграл вот так-то, настолько-то ниже/выше", не попробовав это сам в реальности.

Как бы это сказать... Эти все так называемые "проблемы" чистого строя
на самом деле не являются проблемами именно строя как такового.
Он то сам по себе как раз, что надо.

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

...Флейта, кстати, позволяет подстраивать интонацию в довольно широких пределах.

Ну так вот вы же делаете что? Инструмент как раз. И у него, в его нынешнем виде, эта проблема стоит просто в полный рост. Хотя на софтовом синтезаторе как раз наоборот можно было бы делать такие вещи как автоопределение терций и квинт в аккордах и автоматический выбор чистой интонации в этом случае относительно тоники. Для мелодии тут уже можно было бы разный строй брать, по вкусу - хоть пифагоров вообще как таковой (а для мелодий вроде пентатоники всякой и иже с ними он, вероятно, должен быть предпочтителен).

Ох, с этим, я, к сожалению, ничего не могу поделать.
Так работает софтинка микроконтроллера клавиатурок.
Причем я вообще не понимаю логики, так сказать.

Значит, надо искать какие-то другие варианты. Например, попробовать освоить подключение программы к MIDI интерфейсу - чтобы иметь возможность использовать нормальные MIDI клавиатуры.

До мажор (i-p-]) - тоже не играет.

Был на работе, там тоже скомпилировал прогу (бинарник из дома там не подошёл бы - дома-то 64-битная система, на работе 32-битная). Так на тамошней клавиатуре как раз до мажор этот верхний играет (дома у меня не играет). Зато там не играет, например, тот самый "кривой" ре минор (который с "основным" ре).