предлагаемого вами подхода — каждый класс класть в отдельное пространство имён
Я не кладу каждый класс в отдельное пространство имён конечно же, приводил полное имя класса. Привычка такая сформировалась после работы с рефлексией.
Вы путаете MIDI и Audio.
Не путаю. 99.99% задач связанных с MIDI - это воспроизведение MIDI. Когда-то давно этим занималась звуковая карта, а типичный процессор тех лет синтез звука в реальном времени никак не тянул. Для этого и нужен был вывод в миди-устройство. Но сейчас ситуация изменилась и мощности обычного домашнего компьютера более чем хватает для роли студии звукозаписи, синтезом звука занимаются VSTi и прочие программные продукты, а аудио-карты занимаются только вводом/выводом звука.
Ну вот подключил я недавно синтезатор к компьютеру и захотел с него получить квадро-звук с реверберацией из органного зала. Но стандартный миди-девайс Microsoft GS Wavetable Synth не даёт такой возможности, поэтому никак тут без низкоуровневого звука не обойтись.
Мой опыт - собрать статистику, а не полагаться на ощущения. Повторить и экстраполировать на флэшки с USB type A вполне возможно. А вот мне - уже нет, потому что я давно знаю, а где у разъёма верх, а где низ, и смотрю на флешку, перед тем как вставить. Вставлять флешки с первого раза правильно - не так уж и сложно.
Когда сотовые телефоны только появились, у многих были ощущения "предсказания звонка" за пару секунд до. Что заодно нагнеталось и истерией о вреде сотового излучения от товарищей в шапочках из фольги. Не избежал этого и я, но решил поставить эксперимент - записывать эти ощущения и реальные звонки с привязкой ко времени. 0 (ноль) совпадений по итогу оказалось, а ощущения "предсказания звонка" благополучно прошли.
Так я и есть тот самый "благодарный пользователь" Sanford и MidiSharp. Там конечно тоже не всё идеально и есть что улучшить, но зато вполне ложится на мою логику.
Да и большое число пользователей, вопросов и обращений подтверждают, что API библиотеки сделан более или менее правильно
Конечно, ведь те, кто считает иначе - просто проходят мимо. Если бы не ваши статьи на хабре и мой интерес в этой теме - вы бы так и не узнали, что ненулевое количество людей считают вашу библиотеку излишне переусложнённой, не воспримите за критику пожалуйста. Своё видение высокоуровневой абстракции я вам ещё в прошлой статье показывал, если помните. Заодно и ошибку в низкоуровневых алгоритмах нашёл, которую вы не захотели принимать, что тоже мне не совсем понятно.
Мне кажется, вы полагаете, что библиотека предоставляет только абстракции высокого уровня.
Конечно я ознакомился с кодом вашей библиотеки, причём не раз. Не нашёл, например, никакого упоминания про VSTi и устройства вывода звука, ни на каком уровне абстракции. Что заодно решило бы проблему с таймером в 1мс. Значит, это нужно делать самому, и вникать в низкоуровневую реализацию тоже самому, а тогда зачем вот это вот всё.
странно, что у функций нет имени возвращаемого значения
Исторически сложилось, т.к. программирование выросло из математики, в математике у элементарных функций возвращаемое значение одномерно. Но в графически-ориентированных языках это давно реализовано, в ООП-языках это можно сделать на уровне SDK, в вижуал студии можно написать плагин для сворачивания кода по тегам, всплывающие подсказки по специальной логике и вообще всё что угодно (делал всё из перечисленного). Претензии к отсутствию вектор.resize_to_range() вообще не понятны - ну напишите свой класс, заточенный под конкретно вашу логику.
Давно не покупаю бумажные книги, а печатаю сам, выборочные главы, статьи, справочники, обработанные напильником под свой вкус. Современный лазерный принтер - это не древний матричный, вполне справляется. И читать приятно, и выкинуть не жалко, а при желании что-то и переплести можно.
В автоматах ещё интереснее. Их настраивают так, чтобы иногда они проигрывали чаще, чем выигрывали. Наивные детишки на пике эмоций начинают верить в свою везучую богоизбранность и тащить в автоматы все свои сбережения - но увы, хитрый дядя ночью уже подкрутил пружинку обратно.
Да, потому что в стандарте MIDI есть понятие "событие". Поэтому правильные (и логичные) нэймспейсы будут Midi.Event.NoteOn, Midi.Event.NoteOff, Midi.Event.AllNoteOff и т.д. И сам MIDI - это прежде всего протокол передачи данных, поэтому строить над ним высокоуровневые абстракции возможно не самая лучшая идея. Возможно, более лучшей идеей будет строить высокоуровневые абстракции над более понятными музыканту вещами, такими как классическая нотная запись, пиано-ролл, гитарные табы/аккорды и пр., а MIDI оставить как вариант импорта/экспорта.
Пока никак не применяю, поскольку он появился совсем недавно и существует пока что только в виде черновой спецификации. Всё началось со статьи @shiru8bitпро его проект 1tracker, где он обобщает редакторы трекерной музыки и придумывает свой (текстовый) формат для описания и хранения трекерной музыки. Ну а цитата " трекер — это неудобный интерфейс с высоким порогом вхождения" вызвала желание подумать о том, а можно ли попроще и пониже, а не просто наследовать сложившиеся традиции. Помимо этого, у меня уже достаточно давно в разработке SDK для визуального программирования DSP, который я делаю поочёредно на двух языках (c++ и c#), наследуя идеи NI Reaktor, но с намного более высоким уровнем ООП-абстракции, включая возможность описывать граф обработки чисто текстом и ничем не ограниченную модульность. Первым делом реализовал спектр-анализатор с произвольной длиной (а не только 2 в степени), и быструю свёртку с нулевой задержкой. Затем появилась поддержка VST, там и VSTi, играть соло с клавиатуры быстро наскучило и захотелось иметь возможность быстро накидать басовую партию и какой-нибудь пэд на фоне. Писать полноценный нотный редактор я не готов, а вот распарсить текст вполне реально, поскольку опыт парсинга мат. выражений и гитарных табов уже есть.
Музыкальное образование у меня классическое (хоть и не долгое), учился по нотам с русскими названиями. Это было основной причиной, по который lilpond и прочие меня не впечатлили. Ну а дальше исходил из "максимально удобно" и "максимально читаемо" (куда MusicXML очевидно не подходит). Отдельным интересом было продумать запись цифрами в табулатурном стиле (типа 0 4 0 7 0 5 0 8 на первой струне гитары) и так, чтобы это не противоречило общей концепции. Похожим образом хотелось реализовать и партии ударных - визуально понятный паттерн, который можно запустить в цикле без необходимости копирования во все такты партитуры, как в типичном нотном редакторе. Да и так в целом сейчас мало кто пишет в стиле Баха и современная музыка состоит из коротких повторяющихся отрывков, которые незачем прописывать много раз в явном виде.
Я не приступил к реализации сразу, чтобы язык немного "отлежался" и его можно было бы критически осмыслить и доработать без необходимости переписывать кодовую базу. Также осталась парочка спорных моментов, с которыми я еще не смог определиться - например, в одном случае для паузы удобно использовать символ "_", а в другом - ".". Но точка уже присутствует в классической нотной записи для увеличения длительности ноты, и например Guido Music Notation её так и использует. Другой момент - я хочу избавиться от явного задания октавы в ноте (потому что это замусоривает текст и вообще хотелось бы иметь возможность транспонирования, в том числе и по диатонической, а не только хроматической гамме), а для этого нужно задавать перескоки через октавы, в чём тоже есть несколько вариантов (в частности, ми и +ми отличаются сильнее, чем 0 и +0, поскольку мы привыкли к тому, что плюс перед числом ничего не меняет, а ++ вообще инкремент). Ну и с нестандартными темперациями тоже не всё понятно (типа 22EDO), и особенно неравномерных. Возможно, что не стоит упираться в ASCII и использовать уже наконец расширенный набор символов из юникода. Тогда ↑ вместо + будет трактоваться более однозначно.
А пример кода - как-то так в минимальной комплектации:
Поначалу, наверное, буду делать экспорт в MIDI, чтобы результат можно было открыть в нотном редакторе в привычном графическом виде и быстро проверить. А вот наоборот, из MIDI в текст будет сильно сложнее, особенно с многоголосными дорожками и арпеджированными аккордами. Но желание сделать это тоже сильное.
Когда-то очень давно между Фендером и Гибсоном я выбрал Ibanez с комбоусилителем Vox, про который раньше не слышал, но его звучание показалось более интересным, чем у Marshall. С тех пор желания ни модифицировать, ни менять её на более дорогие (и модные) модели не появлялось.
Про эликсир слышал противоречивые отзывы, но главный вопрос - как полимерное покрытие улучшает звучание, если в электрогитаре звук получается через изменение магнитного поля? Особенно если ещё и с перегрузом играть. Как-то раз у меня струны вообще заржавели, и даже тогда разницы в звуке не услышал. А вот на акустиках - там да, разница в звучании хорошо прослушивается в зависимости от содержания бронзы.
Полином Лагранжа - это математическая функция, позволяющая записать полином минимальной степени, проходящей через заданное количество. Минимальной здесь ключевой момент, и осцилляции здесь появляются из-за знакочередующих производных. Существуют методы построения полиномов более высоких порядков с явным заданием производных.
Многочлены Чебышева достойны отдельной статьи, ну или хотя бы можно было пояснить, откуда там косинус взялся.
Ну и современное решение задачи интерполяции - это барицентрическая интерполяция рациональными полиномами, там проблемы с феноменом Рунге нету. Статью в википедию, правда, до сих пор не подвезли (а а школьную программу и подавно), но вот неплохая обзорная статья.
Так ЯП - это же не обязательно самодостаточный компилятор, а в первую очередь синтаксис и грамматика. Я читал Страуструпа и знаю, что си с классами компилировался в си, и пошёл тем же путём, только в c#, в котором описывается вся необходимая инфраструктура. Когда-нибудь потом и c++ подключу.
Статьи на эту темы вряд ли будут в обозримом будущем, но в комментариях неоднократно упоминал. Для музыки - нужен для моего ДСП-процессора и хочется попробовать неравномерные темперации (это когда в частности до-диез не равен ре-бемолю). Для математики - стало не хватать Вольфрама и хочется свести количество скобочек к минимуму, что достигается вводом дополнительных операторов умножения и деления с другими приоритетами. Например sin x pi + cos x pi. Или a+b//c+d вместо (a+b)/(c+d). Параллельное присваивание a,b=a+b,a-b. Определение (и приведение) типа справа, как в паскале x=1:quaternion.
По работе - надстройка над SQL для описания логики обмена данными (в обе стороны) между контроллерами Simatic и СУБД.
Я придумал уже 3 ЯП, один из которых применяется в металлургическом производстве. Второй - для описания музыки текстом. Третий ориентирован на математические вычисления с расширенным набором операторов. И ни один из них не кажется мне ужасным)
Проблема Room EQ Wizard и подобных в отсутствии у них хорошо проработанного мат.аппарата для коррекции АЧХ. Недостаточно просто взять и сделать 1/x над амплитудами, интерференционные провалы таким образом не компенсируются. Адекватного сглаживания АЧХ/ФЧХ я тоже нигде не встречал, везде какие-то мутные алгоритмы и сомнительные результаты. Корректное сглаживание достигается аппроксимацией методом наименьших квадратов, ФЧХ лучше вообще не корректировать, а посчитать как минимально-фазовую от АЧХ (через кепстр). Применительно к IIR-фильтрам эти вопросы хорошо рассмотрены в работах Balázs Bank-а.
Ещё одно хитрое решение существует - это использовать 2 излучателя, играющих с задержкой пропорционально расстоянию между ними. В более сложном случае можно рассчитать сдвиг фаз на каждой частоте таким образом, чтобы заодно ещё и АЧХ корректировать.
Судя по тексту, претензии к звучанию вполне понятны - автор весьма слабо разбирается в вопросе и по сути в статье не сказано вообще ничего. Ну в частности, "Virtual Bass" на самом деле называется "Missing fundamental". Про биквадратные фильтры автор слышал, а вот как ими аппроксимировать произвольную АЧХ для её коррекции - вероятно нет, потому что в статье об этом тоже ни слова. Выровнять АЧХ у автора тоже не получилось, перепады в 15 дБ на средних частотах - совсем не то, чем можно гордиться. Да и для подобных девайсов это и не важно, а важно разборчивость речи и громкое ненапряжное звучание. Для которого нужно не ровнять АЧХ, а давить определённые частоты.
Я не кладу каждый класс в отдельное пространство имён конечно же, приводил полное имя класса. Привычка такая сформировалась после работы с рефлексией.
Не путаю. 99.99% задач связанных с MIDI - это воспроизведение MIDI. Когда-то давно этим занималась звуковая карта, а типичный процессор тех лет синтез звука в реальном времени никак не тянул. Для этого и нужен был вывод в миди-устройство. Но сейчас ситуация изменилась и мощности обычного домашнего компьютера более чем хватает для роли студии звукозаписи, синтезом звука занимаются VSTi и прочие программные продукты, а аудио-карты занимаются только вводом/выводом звука.
Ну вот подключил я недавно синтезатор к компьютеру и захотел с него получить квадро-звук с реверберацией из органного зала. Но стандартный миди-девайс Microsoft GS Wavetable Synth не даёт такой возможности, поэтому никак тут без низкоуровневого звука не обойтись.
Ну вот. Если вставлять флешку всегда одним концом и поднабрать статистики, то получится 3 варианта:
1) 50/50;
2) значительно больше снизу;
3) значительно больше сверху;
Для увеличения вероятности попадания с первого раза надо просто изменить положение флешки по-умолчанию опираясь на два последних пункта.
Мой опыт - собрать статистику, а не полагаться на ощущения. Повторить и экстраполировать на флэшки с USB type A вполне возможно. А вот мне - уже нет, потому что я давно знаю, а где у разъёма верх, а где низ, и смотрю на флешку, перед тем как вставить. Вставлять флешки с первого раза правильно - не так уж и сложно.
Когда сотовые телефоны только появились, у многих были ощущения "предсказания звонка" за пару секунд до. Что заодно нагнеталось и истерией о вреде сотового излучения от товарищей в шапочках из фольги. Не избежал этого и я, но решил поставить эксперимент - записывать эти ощущения и реальные звонки с привязкой ко времени. 0 (ноль) совпадений по итогу оказалось, а ощущения "предсказания звонка" благополучно прошли.
Так я и есть тот самый "благодарный пользователь" Sanford и MidiSharp. Там конечно тоже не всё идеально и есть что улучшить, но зато вполне ложится на мою логику.
Конечно, ведь те, кто считает иначе - просто проходят мимо. Если бы не ваши статьи на хабре и мой интерес в этой теме - вы бы так и не узнали, что ненулевое количество людей считают вашу библиотеку излишне переусложнённой, не воспримите за критику пожалуйста. Своё видение высокоуровневой абстракции я вам ещё в прошлой статье показывал, если помните. Заодно и ошибку в низкоуровневых алгоритмах нашёл, которую вы не захотели принимать, что тоже мне не совсем понятно.
Конечно я ознакомился с кодом вашей библиотеки, причём не раз. Не нашёл, например, никакого упоминания про VSTi и устройства вывода звука, ни на каком уровне абстракции. Что заодно решило бы проблему с таймером в 1мс. Значит, это нужно делать самому, и вникать в низкоуровневую реализацию тоже самому, а тогда зачем вот это вот всё.
Исторически сложилось, т.к. программирование выросло из математики, в математике у элементарных функций возвращаемое значение одномерно. Но в графически-ориентированных языках это давно реализовано, в ООП-языках это можно сделать на уровне SDK, в вижуал студии можно написать плагин для сворачивания кода по тегам, всплывающие подсказки по специальной логике и вообще всё что угодно (делал всё из перечисленного). Претензии к отсутствию вектор.resize_to_range() вообще не понятны - ну напишите свой класс, заточенный под конкретно вашу логику.
Давно не покупаю бумажные книги, а печатаю сам, выборочные главы, статьи, справочники, обработанные напильником под свой вкус. Современный лазерный принтер - это не древний матричный, вполне справляется. И читать приятно, и выкинуть не жалко, а при желании что-то и переплести можно.
В автоматах ещё интереснее. Их настраивают так, чтобы иногда они проигрывали чаще, чем выигрывали. Наивные детишки на пике эмоций начинают верить в свою везучую богоизбранность и тащить в автоматы все свои сбережения - но увы, хитрый дядя ночью уже подкрутил пружинку обратно.
Да, потому что в стандарте MIDI есть понятие "событие". Поэтому правильные (и логичные) нэймспейсы будут Midi.Event.NoteOn, Midi.Event.NoteOff, Midi.Event.AllNoteOff и т.д. И сам MIDI - это прежде всего протокол передачи данных, поэтому строить над ним высокоуровневые абстракции возможно не самая лучшая идея. Возможно, более лучшей идеей будет строить высокоуровневые абстракции над более понятными музыканту вещами, такими как классическая нотная запись, пиано-ролл, гитарные табы/аккорды и пр., а MIDI оставить как вариант импорта/экспорта.
Пока никак не применяю, поскольку он появился совсем недавно и существует пока что только в виде черновой спецификации. Всё началось со статьи @shiru8bitпро его проект 1tracker, где он обобщает редакторы трекерной музыки и придумывает свой (текстовый) формат для описания и хранения трекерной музыки. Ну а цитата " трекер — это неудобный интерфейс с высоким порогом вхождения" вызвала желание подумать о том, а можно ли попроще и пониже, а не просто наследовать сложившиеся традиции. Помимо этого, у меня уже достаточно давно в разработке SDK для визуального программирования DSP, который я делаю поочёредно на двух языках (c++ и c#), наследуя идеи NI Reaktor, но с намного более высоким уровнем ООП-абстракции, включая возможность описывать граф обработки чисто текстом и ничем не ограниченную модульность. Первым делом реализовал спектр-анализатор с произвольной длиной (а не только 2 в степени), и быструю свёртку с нулевой задержкой. Затем появилась поддержка VST, там и VSTi, играть соло с клавиатуры быстро наскучило и захотелось иметь возможность быстро накидать басовую партию и какой-нибудь пэд на фоне. Писать полноценный нотный редактор я не готов, а вот распарсить текст вполне реально, поскольку опыт парсинга мат. выражений и гитарных табов уже есть.
Музыкальное образование у меня классическое (хоть и не долгое), учился по нотам с русскими названиями. Это было основной причиной, по который lilpond и прочие меня не впечатлили. Ну а дальше исходил из "максимально удобно" и "максимально читаемо" (куда MusicXML очевидно не подходит). Отдельным интересом было продумать запись цифрами в табулатурном стиле (типа 0 4 0 7 0 5 0 8 на первой струне гитары) и так, чтобы это не противоречило общей концепции. Похожим образом хотелось реализовать и партии ударных - визуально понятный паттерн, который можно запустить в цикле без необходимости копирования во все такты партитуры, как в типичном нотном редакторе. Да и так в целом сейчас мало кто пишет в стиле Баха и современная музыка состоит из коротких повторяющихся отрывков, которые незачем прописывать много раз в явном виде.
Я не приступил к реализации сразу, чтобы язык немного "отлежался" и его можно было бы критически осмыслить и доработать без необходимости переписывать кодовую базу. Также осталась парочка спорных моментов, с которыми я еще не смог определиться - например, в одном случае для паузы удобно использовать символ "_", а в другом - ".". Но точка уже присутствует в классической нотной записи для увеличения длительности ноты, и например Guido Music Notation её так и использует. Другой момент - я хочу избавиться от явного задания октавы в ноте (потому что это замусоривает текст и вообще хотелось бы иметь возможность транспонирования, в том числе и по диатонической, а не только хроматической гамме), а для этого нужно задавать перескоки через октавы, в чём тоже есть несколько вариантов (в частности, ми и +ми отличаются сильнее, чем 0 и +0, поскольку мы привыкли к тому, что плюс перед числом ничего не меняет, а ++ вообще инкремент). Ну и с нестандартными темперациями тоже не всё понятно (типа 22EDO), и особенно неравномерных. Возможно, что не стоит упираться в ASCII и использовать уже наконец расширенный набор символов из юникода. Тогда ↑ вместо + будет трактоваться более однозначно.
А пример кода - как-то так в минимальной комплектации:
Собачий вальс
Поначалу, наверное, буду делать экспорт в MIDI, чтобы результат можно было открыть в нотном редакторе в привычном графическом виде и быстро проверить. А вот наоборот, из MIDI в текст будет сильно сложнее, особенно с многоголосными дорожками и арпеджированными аккордами. Но желание сделать это тоже сильное.
Когда-то очень давно между Фендером и Гибсоном я выбрал Ibanez с комбоусилителем Vox, про который раньше не слышал, но его звучание показалось более интересным, чем у Marshall. С тех пор желания ни модифицировать, ни менять её на более дорогие (и модные) модели не появлялось.
Про эликсир слышал противоречивые отзывы, но главный вопрос - как полимерное покрытие улучшает звучание, если в электрогитаре звук получается через изменение магнитного поля? Особенно если ещё и с перегрузом играть. Как-то раз у меня струны вообще заржавели, и даже тогда разницы в звуке не услышал. А вот на акустиках - там да, разница в звучании хорошо прослушивается в зависимости от содержания бронзы.
Полином Лагранжа - это математическая функция, позволяющая записать полином минимальной степени, проходящей через заданное количество. Минимальной здесь ключевой момент, и осцилляции здесь появляются из-за знакочередующих производных. Существуют методы построения полиномов более высоких порядков с явным заданием производных.
Многочлены Чебышева достойны отдельной статьи, ну или хотя бы можно было пояснить, откуда там косинус взялся.
Ну и современное решение задачи интерполяции - это барицентрическая интерполяция рациональными полиномами, там проблемы с феноменом Рунге нету. Статью в википедию, правда, до сих пор не подвезли (а а школьную программу и подавно), но вот неплохая обзорная статья.
Я пока что единственный их пользователь, сам с собой как-нибудь найду компромисс.
Да, я помню ваши статьи, они классные.
Так ЯП - это же не обязательно самодостаточный компилятор, а в первую очередь синтаксис и грамматика. Я читал Страуструпа и знаю, что си с классами компилировался в си, и пошёл тем же путём, только в c#, в котором описывается вся необходимая инфраструктура. Когда-нибудь потом и c++ подключу.
Статьи на эту темы вряд ли будут в обозримом будущем, но в комментариях неоднократно упоминал. Для музыки - нужен для моего ДСП-процессора и хочется попробовать неравномерные темперации (это когда в частности до-диез не равен ре-бемолю). Для математики - стало не хватать Вольфрама и хочется свести количество скобочек к минимуму, что достигается вводом дополнительных операторов умножения и деления с другими приоритетами. Например
sin x pi + cos x pi. Илиa+b//c+dвместо(a+b)/(c+d). Параллельное присваиваниеa,b=a+b,a-b. Определение (и приведение) типа справа, как в паскалеx=1:quaternion.По работе - надстройка над SQL для описания логики обмена данными (в обе стороны) между контроллерами Simatic и СУБД.
Я придумал уже 3 ЯП, один из которых применяется в металлургическом производстве. Второй - для описания музыки текстом. Третий ориентирован на математические вычисления с расширенным набором операторов. И ни один из них не кажется мне ужасным)
Проблема Room EQ Wizard и подобных в отсутствии у них хорошо проработанного мат.аппарата для коррекции АЧХ. Недостаточно просто взять и сделать 1/x над амплитудами, интерференционные провалы таким образом не компенсируются. Адекватного сглаживания АЧХ/ФЧХ я тоже нигде не встречал, везде какие-то мутные алгоритмы и сомнительные результаты. Корректное сглаживание достигается аппроксимацией методом наименьших квадратов, ФЧХ лучше вообще не корректировать, а посчитать как минимально-фазовую от АЧХ (через кепстр). Применительно к IIR-фильтрам эти вопросы хорошо рассмотрены в работах Balázs Bank-а.
Ещё одно хитрое решение существует - это использовать 2 излучателя, играющих с задержкой пропорционально расстоянию между ними. В более сложном случае можно рассчитать сдвиг фаз на каждой частоте таким образом, чтобы заодно ещё и АЧХ корректировать.
Судя по тексту, претензии к звучанию вполне понятны - автор весьма слабо разбирается в вопросе и по сути в статье не сказано вообще ничего. Ну в частности, "Virtual Bass" на самом деле называется "Missing fundamental". Про биквадратные фильтры автор слышал, а вот как ими аппроксимировать произвольную АЧХ для её коррекции - вероятно нет, потому что в статье об этом тоже ни слова. Выровнять АЧХ у автора тоже не получилось, перепады в 15 дБ на средних частотах - совсем не то, чем можно гордиться. Да и для подобных девайсов это и не важно, а важно разборчивость речи и громкое ненапряжное звучание. Для которого нужно не ровнять АЧХ, а давить определённые частоты.
Ну что поделать, не я это всё придумал. А так конечно, на психологию много завязано.