Алексей Акулович

На самом деле, лучше убрать без создания новой схемы:

Settings > Editor > Apperance > Show method separators

P.S. А выбор цвета для разделителя, совпадающий с фоном, я бы делать не советовал, а то вдруг захотите его все-таки включить и (вдруг!) не увидите изменений.

CakePHP уродливый внутри и давно устарел. Сейчас все юзают Yii. Kohana — не самостоятельный фреймворк, а улучшенная версия CI. Symphony — вроде тяжелый и оверинженеренный монстр, который включает в себя неуклюже скопированный из Java ORM.

Есть также мнение, что лучше всего было бы вообще перейти с PHP и недофреймворков на что-то серьезное, например Java (Гугл использует Java и С++ для своих сервисов, например) или хотя бы python, если яву не осилить.

Не знаю как правильно, но я размещаю так:
— логика приложения (она же системная): роутинг, логи, проверка параметров, прав, сохранение и получение данных (вызов всяких load и save), обработка форм, выбор способа отображения (html, xml, json, редиректы, ...), кэширование и т. п. — контроллеры (включая фронтконтроллер)
— логика модели (она же бизнес-логика): действия с данными без учёта их способа хранения (выставить или оплатить счёт, атаковать кого-то или построить здание) — как не странно, модели
— логика отображения: вывести сообщения системы (если они есть, формируются в контроллерах) раскрасить по разному чётные и не чётные строки таблицы, вывести дополнительные блоки (как правило для сайд-баров через вызов других контроллеров) — отображения (шаблоны)

То есть получается, что в модели сосредоточен код, который ничего не знает ни о http-запросах и ответах, ни о БД (или другом способе хранения). Контроллеры просто создают объекты модели, заполняют их, если нужно, данными из хранилища/запроса, вызывает, если требуется, методы модели, и если состояние объектов модели изменилось сохраняет их, после чего передаёт объекты в нужное отображение. Если приложение простое (только CRUD действия), то в модели вообще нет методов, кроме геттеров/сеттеров/делетеров (а иногда и их нет, только данные)

musicdsp.org и евонный форум, и e-mail рассылка.
На русском — любая книжка по цифровой обработке сигналов даст нормальную базу.

По вашей ситуации алгоритм такой:
микрофон(звук)=>АЦП(цифровой массив)=>оконное FFT(массив комплексных чисел)=>массив амплитуд(массив действительных чисел)=>относительная частота максимума=>частота максимума=>нота

Для вашей ситуации нужно знать api снятия звука с микрофона. Api будет выдавать порции звука кусками, допустим, по 1024 float'а. (При частоте дискретизации 44100 это будет 44100/1024 = 43 миллисекунды).
К этому куску нужно применить оконное быстрое преобразование Фурье (FFT), поищите где-нибудь нормальную статью, в котором оно объясняется (пригодится книжка по цифровой обработке сигналов). В интернете есть куча библиотечных функций.
Чтобы знать, что преобразование вообще делает, советую поставить Adobe^W Audition^W бесплатный аудиоредактор со спектроанализатором и посмотреть, что делается со звуком разных нот, на что влияет размер окна и т. п. Мозг сам по себе тоже работает со спектром, а не с самим сигналом, поэтому интуитивно все понимается на ура.

У FFT, чем больше данных, тем большее спектральное разрешение. Для нужного разрешения, может быть нужно FFT'ить 8192 байта, или около того. FFT выдаст массив из 8192 комплексных чисел, модуль каждого из этих чисел даст амплитуду спектра. При этом значения 4096-8191 будут зеркальной копией 0-4095, такова особенность алгоритма. У комплексных чисел можно получить амплитуду, фаза в данном случае не нужна, а амплитуда — sqrt(re^2+im^2). Ну а дальше поиском максимума в массиве.

Максимум будет относительной частотой (массив-то 0-4095, а частоты 0-44100/2). Чтобы перевести абсолютную в относительную, нужно по пропорции умножить на 44100/8192. Т.е. на частоту дискретизации деленную на размер окна FFT. И теперь перевести частоту в ноту. Там экспоненциальная зависимость (частота следующей ноты выше частоты предыдущей в корень двенадцатой степени из двух), с помощью таблички вида (A4 440; A#4 465.96] найти ближайшую не сложно.