Владимир Серёгин

После БПФ получаете комплексный массив, где каждый элемент - амплитуда определенной частоты.
Частота по сути - это индекс массива.
Но в элементе может быть не одна частота - количество частот в элементе массива зависит от частоты дискретизации сигнала и от длины БПФ: freq_length = sampling_rate / fft_length;
Если sampling_rate == fft_length, то в элементе массива единственная частота.
freq_length - разрешение элемента массива по частоте.
Анализировать можно только половину массива (см. про частоту Найквиста), остальные отсчеты - это сопряжение первой половины. Соответственно реально получить частоты до sampling_rate / 2 - 1.
В вашем случае, видимо, нужно найти энергетический спектр: сложить квадраты действительной и мнимой частей всех частот. Найти максимумы - это и будут ваши частоты аккорда - лучше построить график и посмотреть визуально, что получится.

Описанная тобой схема, при которой приложение разбито на две части: клиентское на JS и серверное, которые обмениваются данными через открытое API по HTTP - называется Rich Internet Application или Single Page Application. Реализуется на любом стеке. PHP/Python/NodeJS/Ruby/Go/C#/Java и др. с одной стороны и Vue/Angular/Meteor/React и др. (тыщи их) с другой стороны.

(Упомянуя схема "микросервисная архитектура" по сути декомпозиция серверной части на незаввисимые модули с открытым API, совсем не обязательно реализовано через HTTP. Частный случай SPA/RIA.)

Проблему назову одну. Только она не даёт покоя. Она выматывает душу, нервы и кошелёк.

Интернет магазин должен быть открыт для индексации поисковым ботам, а HTML генерится в runtime на JavsScript. Только Google умеет выполнять JS, и то весьма посредственно. Остальные вообще JS не трогают. Есть два решения:
для индексации сразу рисовать HTML на стороне сервера
или снимать "отпечатки" HTML c приложения через виртуальный браузер, что сбоит

Отрисовка HTML на стороне сервера (server side render) может быть реализована тремя способами:
* подменять выдачу через серверный язык программирования, то есть вместо шаблонизации в Vue рисовать в Falcon - блин, две шаблонизации, две логики работы с данными (через AJAX и напрямую из базы)
* имитировать исполнение JS на сервере (хм, это возможно опять же несколькими способами) - тут вообще танцы с бубном
* отказаться от PHP/Python/Ruby и др. в пользу NodeJS и изоморфного фрейморка, например MeteorJS или VueJS (Nuxt)

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

P.S. Про Google: проверено, глючит в тех местах, где клиентский JS начинает подкачку данных через HTTP - гугль обрывает рендеринг и в поисковом индексе лежат пустые HTML страницы. Толку от них никакого.
P.P.S Снятие "отпечатков" HTML для SPA можно через специальные сервисы (prerender.io или brombone.com) или сделать самостоятельно, например через PhantomJS или Electron. В любом случае для проекта с десятком тысяч страниц это расходы на оплату сервиса, либо на мощный сервер. И электрон и фантом виснут, а HTML довольно большие и со временем забивают диск/базу. Опят же надо не забывать про то, что страницы требуют подгрузки данных через AJAX, надо чуть подождать.
Пример: web-mastery-gauge.ru сделан на Angular, для поисковиков HTML отрисовывается через prerender.io - для проекта с 15 страницами это вообще никакой сложности не вызывает.
P.P.P.S. SPA просто идеально для реализации той части пользовательского интерфейса, которая не индексируется поисковыми ботами. Например, то доступно только авторизованным пользователям. В этом случае не требуется server side render и 75% проблем отпадают. В том же интернет-магазине может быть админка - её можно сделать на VueJS.

Создать класс, наследующийся от library.Api. Либо реализовать нужную логику в виде отдельной функции, а не метода:

#...
api = library.Api(API_URL, LOGIN, PASSWORD)
get_something_specific(api)

• Deployment checklist
  
• Nginx + Gunicorn
  

в data завести переменную:
isD3JS: true
На чекбокс повесить v-model
<input type="checkbox" v-model="isD3JS">
и в методе использовать

svg: function (){
  if(this.isD3JS){
    this.d3()
  }else{
    this.svgSnap()
  }
}

Можно брать элемент по id, как дали ответ выше, но используя Vue это бдует неправильно.

const routes = [
...
  { 
		path: '/404', 
		name: '404', 
		component: NotFound, 
	}, { 
		path: '*', 
		redirect: '/404' 
	}
]

При нажатии на удалить не нужно присваивать класс, нужно удалить из коллекции. Или, если есть подзадача отображать еще и удаленные, то менять свойство, а выводить отфильтрованные элементы. Это вам не jquery.

Ну и в документации есть хороший пример

1) Мой основной язык Python, на JS больших программ почти не писал. Когда писал на нём больше, то ощущал дискомфорт из-за:
- отсутствия нормального наследования (хотя сейчас, вероятно, это уже исправлено)
- трудностей с типами данных и неявными преобразованиями (вот вчера буквально был холивар на Тостере о == и ===)
- списков, реализованных как переодетые объекты
- отсутствия из коробки структур данных вроде deque.

Но это были студенческие поделки.

2) Python предоставляет больше средств борьбы со сложностью. Наследование, система метаклассов, синтаксический сахар. Хотя бы даже такая штука как property. Он даёт больше возможности инкапсулировать сложность внутри. Ну и на нём действительно очень много разнообразных библиотек. Возьмите хотя бы Django: она умеет автоматически генерировать миграции базы данных. Насколько я знаю, это мало кто умеет делать.

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

4) Ничто не помешает вам изучить платформу А, затем Б, потом В и так далее; от этого только польза. Может быть, вы через десять лет будете на Quipper - диалекте Haskell для квантовых компьютеров - писать. Но начинать посоветую всё же с Python - чтоб меньше заниматься мазохизмом и больше писать кода.)

The Tangled Web

Вот тут ошибки

a1[xxx].append(x)
a2[xxx].append(y)
a3[xxx].append(z)

Вы обращаетесь к элементам списков a1, a2 и a3, но изначально списки пустые и скорее всего у вас возникает исключение IndexError.

Если хотите добавить элемент в список, то нужно писать так

a1.append(x)
a2.append(y)
a3.append(z)