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

[xjiss]

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

Хм. Может, это эффект восприятия, связанный с тембром?
С гауссианой звук как бы слегка булькающий, чтоли...
Если на чистом синусе попробовать?..

[xjiss]

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

Я в курсе:
http://zed.karelia.ru/go.to/for.all/music/whistle
(если не лазали по сайтику)

На остальное попозжа отвечу, подумать надо.

[xjiss]

Немножко подумал, и решил, что считать заранее ...всё-таки в любом
случае лучше, чем считать на лету.

В принципе, я тоже к такой мысли склоняюсь.
С мегабайтами - это да, это я не подумавши ляпнул.
Так и не вспомнил, с чего я решил рассчитывать "на лету".
Кстати, тонов не порядка 30, а ровно 46;
если из терминала запускать, оно пишет в него:

./xjiss 
NTONES = 46

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

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

Мне думается, что такие вот "маленькие хитрости" - это слишком мутно.
Для разных форм сигналов нужно будет мутить по-своему.
Не программа получится, а черт знает что...

Вообщем, затея двигать строй вверх-вниз мне кажется
не очень хорошей.

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

Тут я согласен.
Опять же не помню, какие тараканы заставили меня сделать именно так.
Щас есть мысль сделать буфер на 1-2-3-4-5 секунд звучания
и генерить в него. Мысль появилась тогда, когда я захотел
сделать реверберацию (надо просто добавлять ослабленные отсчеты
в "будущее"). Но силов и времени на implementation пока не хватило...

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

Пока не осознал, надо подумать. Чувствую, что тут рациональное зерно есть.

сделать красивую атаку и затухание

Я немного думал на эту тему; в принципе, сделать этот
envelope не особо сложно, надо просто считать периоды,
ну и множить/делить на соотв. коэффициент в зависимости от номера
периода. Опять же, не хватило запалу, чтоб реализовать.

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

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

По типу того, как это можно делать в FL Studio (для форточек)
и в линуксовом аналоге LMMS.

Я из-за этого даже примерно месяц гитару в руки не брал

И вот тут я просто обязан выразить искреннюю благодарность
за интерес к поделке и особенно за дельные замечания.
Если хотя бы один человек проявил интерес - это уже здорово!

Как будет время и желание, постараюсь хорошенько обдумать
всё, что Вы написали и перепилить программу так или иначе.

[xjiss]

Но, во всяком случае, неравенство мелодических секунд как-то ощущается, и в некоторых случаях это ощущение неприятно. А в других случаях вроде и ничего - вот, как c ре на ми в этой моей фразе, который воспринимается нормально

А можно фразу послушать?

[Toman]

Хм. Может, это эффект восприятия, связанный с тембром?
С гауссианой звук как бы слегка булькающий, чтоли...
Если на чистом синусе попробовать?..

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

[Toman]

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

Да нет, это совершенно общий и стандартный алгоритм для любых форм сигнала - в т.ч. записанных из реального мира звуков произвольного вида. При более-менее гладкой форме сигнала ошибки минимальны. Строгий меандр (наряду с пилой) - это один из тех самых худших случаев, при которой величина сопутствующих ошибок дискретизации в любом случае максимальна. Таких сигналов в цифре надо в любом случае избегать. Потому что даже если они выглядят в цифрах вроде бы аккуратненько и красиво, корректно выведены они быть не могут. В своё время, опять же, 10-12 лет назад, заинтересовавшись темой, я пошёл в книжный и купил книгу о работе со звуком с точки зрения программиста (автор Тим Кинтцель, издание в русском переводе 2000 года, НЯП). Значительную часть книги составляет, увы, не совсем относящаяся к делу словесная и кодовая шелуха, связанная с приверженностью автора к C++ и ООП. Но в части собственно работы с "цифрой" там он пишет дельные вещи. И, в частности, в самом начале он как раз приводит пример, что для того же прямоугольного сигнала, чтобы он реально звучал чище всего и содержал меньше искажений и мусора, он должен аппроксимироваться в цифровом виде вовсе не ровными полочками, а таким образом, чтобы были срезаны гармоники, слишком близкие к F/2. Т.е. с той ещё "колбаснёй" перед и после острого фронта. Т.е. сигналы, содержащие острые фронты, в принципе сложны для правильного синтеза в пригодном к выводу виде. Это вообще отдельная проблема, и она как минимум на порядок сложнее того довольно нехитрого алгоритма, что вы называете хитростями. Проще всего просто не нарываться на неё, избегая синтеза таких форм сигнала, по крайней мере, "непосредственным" образом. А с приличными сигналами без острых фронтов и (в меньшей степени, но всё же) острых "изломов" всё это работает общим образом без каких-то специфических мер.

Я немного думал на эту тему; в принципе, сделать этот
envelope не особо сложно, надо просто считать периоды,
ну и множить/делить на соотв. коэффициент в зависимости от номера
периода. Опять же, не хватило запалу, чтоб реализовать.

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

[xjiss]

Я у себя послушал, вроде как нет биений в квинтах ми-си и фа-до.
Кривая квинта ре-ля сразу слышна.

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

Чудяса...
А вы еще предлагаете похимичить с периодами тонов, некратными
периодам дискретизации. )))

Плюс, наверное, всё-таки что-то некорректное во взаимодействии с ALSA. Вот, например,
чего я не понял: вы получаете оттуда ( sound.c ) параметры "буфер" и
"период" (я пока не в курсе, что это именно означает, но, наверное,
всё-таки что-то важное, да?)

1) Что может быть некорректного в тупом write()?
(
Замечание - функция записи в девайс возвращается
не тогда, когда весь звук уже проигран, а раньше...
возврат из snd_pcm_writei() происходит тогда,
когда ALSA прожевала порцию и отправила в дело.
Сопсна, это и позволяет считать на лету...
Расчет длится меньше, чем проигрывание.
)

2) С параметрами "размер буфера" и "период" я и сам не особо разобрался.
Особенно с "период" - ваще не понимаю, чо это такое.
Я подобрал LATENCY таким образом, чтобы на моём древнем железе
ошибка "разорванная труба" не возникала слишком уж часто
(при включенной записи всё-таки иногда возникает, в итоге срыв звука).

Как я понял, broken pipe означает underrun, то есть приложение
не успело, извиняюсь, запихнуть очередную порцию данных.
Если заметили - прога пишет звук всегда; если кнопки не нажаты,
гонит нули (кстати, загрузка проца при этом - порядка 1-2%)

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

Да Вы просто из консольки запускайте, йошкин кодЪ ))
А не мышиными кликами с "раб. стола" )))
stdout, stderr - тут не принципиально.

[Toman]

А можно фразу послушать?

Вот (записано на данном синтезаторе, но с моим тембром (смесь из синусов 1, 3 и 5 степеней, с преобладанием 5-й степени, НЯП), с "кривым" ре минором (на "основной" ре) ):
http://ifolder.ru/29295247

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

[xjiss]

В продолжение темы про уложение 2-х периодов колебания в 201 отсчет.
Период в 100 отсчетов соответствует частоте звука 480 Hz.
Период в 101 отсчет соответствует частоте звука 475.248 Hz.
Разница - почти 5 Герц.

Допустим, что Ваш меандр с хитринкой действительно даст
период в 100.5 тактов дискретизации и, соответственно,
частоту звука 472.906 Hz.

А как Вы будете изображать, скажем, 478 Hz?
Период для этой частоты - 100.418.

У Вас опять получатся полочки по 49 или 50 отсчетов
и 3 промежуточных значения. Единственное, что Вы сможете
изменить, это значения этих промежуточных отсчетов.

И Вы хотите сказать, что от величины этих отсчётов
будет зависеть частота меандра на выходе звуковой карты?
Что-то терзают меня смутные сомнения....

[xjiss]

Фразу послушал. Красиво.
Кстати, почему то мой любимый mplayer играет только первую секунду.
Слушал в audacity.