Владимир, спасибо за отзывчивость. То, что на Си - это хорошо, а то, что на Линукс и не VST - это плохо. Но на всякий случай, ссылку для себя сохранил. Ну смысл мы с вами, чуть позже, поробуем либо через почту обсудить, либо в личке. Извиняюсь за занудство. Ответ на 99% знаю, но тем не менее хотел уточнить, чтоб уж наверняка. Если портировать, скажем, вокодер или синтезатор с Visual Basic в C/C++, да еще в VST-формат. Практически это же нужно будет переписать почти каждую строчку кода, что фактически будет равноценно написанию VST-синтезатора или вокодера с ноля. Я прав или не совсем?
Переписывать придется по любому, т.к. языки разные. А вот с алгоритмической частью ничего не поменяется, только внешний интерфейс.
Не прав, и корни этого заблуждения идут от малого налета программирования. Итоговая вещь строиться итеративно, путем многократных проб и переписывания. Поэтому к концу уже есть четкое представление в деталях, а "в нуле" нет. Поэтому переписывать придется 1 к 1, при готовой алгоритмической части, а без таковой написание это, условно, 10 к 1. Имеется ввиду 10 строк проб\ошибок к одной итоговой.
DSP-код - это всего-навсего где-то 20% от плагина. Ко всему ещё накручивается UI, работа с системными ресурсами, поддержка различных форматов плагинов. И в большинстве каждому приходится это делать по-своему либо заворачивать под какой-нибудь уже готовый фреймворк вроде JUCE.
q2e74, так получается, что вы у нас летчик-программист с большим налетом в программировании? Правда, вот здесь у вас было немного другое мнение о себе. Что-то здесь не сходится? Или я опять, как всегда, не прав?
Тут вы правы. Просто процессы "научения"(это термин в экспериментальной психологии) меня интересовали всегда. Вне зависимости от профессии, на старте люди имеют типичные "ошибочные" представления о предмете деятельности. Некоторые правда умудряются десятилетиями делать по факту одно, а говорить другое, но это частности. А в целом, люди избегают мысли, что перед хорошим результатом огромное количество ошибочных или менее успешных проб. Я увидел в тексте фразы, которые уже слышал от студентов. На деле, это объяснялось как низким скилом "умения читать" код, так и низким скилом "умения писать" код. Скил большой у тех кто упражняется в этом, т.е. читает и пишет. Но они как правило, такими вопросами (что быстрее?) не загоняются, просто берут и делают. sty, по другим темам, вы всякое обсуждение сводите на обсуждение личностных черт характера автора. Зачем? Так работать в коллективах не возможно, надо разделять человеческие качества от профессиональных. Да и подколок очень много в ваших текстах, что больше смахивает на дерганье девочек за косички в надежде познакомиться Что бы девушка была вашей, ведите себя так, словно она уже ваша. А "подколки" это детская суета у подъезда, движение есть, выхлопа нет. Я абсолютно не знаю кто вы, и мои посты скорее в воздух, пальцем в небо.
Петушки с кафедры это не программисты. Они десятилетиями преподают "программирование", однако разработчиками не являются. Когда я еще учился в вузе, я общался с таким преподом насчет поиска работы, и вот он сказал, как ходил по собеседованиям, и везде ему отказывали примерно со словами "У тебя нет опыта. Где же ты все это время был, дядя?" Насчет задачи - этот алгоритм можно ради производительности реализовать на FPGA, а не на C++. Но бесплатно делать это никто не будет, а деды с кафедры про FPGA даже не слышали.
сильно от алго зависит: 64 разряда и хороший запас озу + гпу возможно заюзать вряд ли пересилишь на фпга. а самым сильным решением тут мб лишь аналоговое устройство.
