En annan modell är att ge sig på JS script som du kan köra och kompilera direkt i Reaper.
Det har lånat en hel del från C i syntaxen dessutom.
Men allt beror på vad man vill uppnå och lära sig.
En annan modell är att ge sig på JS script som du kan köra och kompilera direkt i Reaper.
Det har lånat en hel del från C i syntaxen dessutom.
Men allt beror på vad man vill uppnå och lära sig.
Jag rekkomenderar fortfarande C.
Lär dig det och du kan kör på allt.
Bjarne Stroustrup: Why the Programming Language C Is ObsoleteUrsprungligen postat av janost
This quote is hidden because you are ignoring this member.
https://youtu.be/KlPC3O1DVcg
https://www.youtube.com/watch?v=KlPC3O1DVcg
C++Tutorial for Beginners 1 - Introduction
https://youtu.be/1MKhigIml3E
https://www.youtube.com/watch?v=1MKh...GHa4Kt&index=1
Att gå direkt på FPGA är nog inte bästa vägen framåt om du vill ha snabba resultat och troligtvis även overkill när det gäller prestanda (beroende på vad du vill åstadkomma förstås).
Om jag skulle ge mig på ett någorlunda seriöst projekt så skulle jag välja kretsar från XMOS. Dessa är i princip en blandning mellan en FPGA och en microcontroller (de har många beräkningskärnor och konfigurerbara I/O-banker). De är extremt kraftfulla, de programmeras i C, utvecklingsverktygen är gratis, utvecklingskorten är förhållandevis billiga (audio och midi I/O add-on-kort finns), kretsarna är billiga (om det blir en produkt) och de är perfekta för audioapplikationer.
http://www.xmos.com/
Dessutom behöver du inte vara hårdvarukonstruktör eller åtminstone ha en väldigt god förståelse för hårdvarudesign (som du behöver om du vill ta fram en fungerande och robust FPGA-design)
FPGA implementationer är ett annat tankesätt, och ska man lära sig nytt så är detta inte ett problem. Sedan vill jag okså mena att både SW- och RTL-implementation är svårt att göra riktigt bra.This quote is hidden because you are ignoring this member.Att gå direkt på FPGA är nog inte bästa vägen framåt om du vill ha snabba resultat och troligtvis även overkill när det gäller prestanda (beroende på vad du vill åstadkomma förstås).
Om jag skulle ge mig på ett någorlunda seriöst projekt så skulle jag välja kretsar från XMOS. Dessa är i princip en blandning mellan en FPGA och en microcontroller (de har många beräkningskärnor och konfigurerbara I/O-banker). De är extremt kraftfulla, de programmeras i C, utvecklingsverktygen är gratis, utvecklingskorten är förhållandevis billiga (audio och midi I/O add-on-kort finns), kretsarna är billiga (om det blir en produkt) och de är perfekta för audioapplikationer.
http://www.xmos.com/
Dessutom behöver du inte vara hårdvarukonstruktör eller åtminstone ha en väldigt god förståelse för hårdvarudesign (som du behöver om du vill ta fram en fungerande och robust FPGA-design)
Vidare tycker jag också att den mjukvaru-definierade synthens upplägg börjar bli väl mycket utforskat. Däremot så tycker jag nog att det finns mycket (som är svår implementerat i programkod) där man kan ta vid från där utvecklingen av digitalsynthen (i meningen byggd av logik) tog slut.
Givetvis så är de flesta såna synthar i någon form hybrider av SW och HW, men när stora delar av ljudgenereringen inte är implementerad i SW så är det i min mening inte fråga om någon mjukvaru definierad synth längre. (Exempel på såna icke mjukvarudefinierade synthar är definitivt DX7 (och derivat av den) PPG, och jag misstänker starkt (utan att veta) att Roland D50 och dess derivat också är en av dito.
Många hybrid-analoger med DCO är också denna typ av synthar (tex BITONE) har en logik implementerad oscillator.
FPGAer har öppnat för att utveckla denna typ av synthar på ett effektivt sätt (där man kan vara väldigt experimentell utan att dra på sig stora kostnader, och iterationsloopen med realiserade modeller går snabbt i utvecklingsprocessen.
Och för att referera till Bjarnes exempel med matriser, så smiskar möjligheterna till en prestanda optimerad implementation i en FPGA skiten ur mjukvara, hur fint objektorenterad den än må vara. En GPU är till stor del nämligen just detta.
Visst är det så. FPGA-implementationer öppnar för enorma möjligheter. Dock så är det nog tyvärr lite svårare att komma igång med. Det man hela tiden måste ha i bakhuvudet är att koden man skriver faktiskt beskriver en fysisk hårdvaruimplementation för att få en design som är realiserbar (timingmässigt och resursmässigt) i verkligheten och inte bara i en simulator.This quote is hidden because you are ignoring this member.
Det finns ett nytt utvecklingskort med en MAX10 FPGA-krets från Altera som är verkligen prisvärt($50), det är också fysiskt kompatibelt med Arduino. Generera ett processorsystem med en NIOS-II för att styra ljudgenereringsbiten samt gränssnittet mot en audio-shield sedan är det bara att börja köra (eller om man har någon annan form av I/O-kort vad det nu vara månde). Det man behöver utöver FPGA-kortet är en USB-blaster för att programmera via JTAG, dessa kostar en del om man köper original från Altera, men det finns tredjepartsalternativ som också borde fungera. Eller använd FPGA'n som en co-processor (oscillator etc etc) eller I/O-expander (exempelvis för att driva flera DACar, eller ta emot data från flera ADCer) till ett arduinokort.
Ett annat alternativ är gå på en SOC-lösning med t.ex. ett Zynq-chip från Xilinx. T.ex. detta: https://www.digilentinc.com/Products....cfm?Prod=ZYBO då får man det bästa av två världar men de är ganska bökiga att komma igång med.
Senast redigerat av knarr den 2015-04-19 klockan 10:51. Anledning: behöver ju inte vara processor i fpgan...
Kanske inte så konstigt att upphovsmannen bakom C++ tycker C är obsolet i och för sig ... C är ju ett väldigt levande språk fortfarande och används t ex i Linuxkärnan och i de flesta andra komponenter i ett Linuxsystem. Objektorienteringshypen för många år sedan satte ju dock C++ på kartan, och man ser en hel del små system (bl a mycket DSP-kod) skriven i C++, av för mig inte speciellt övertygande anledningar. Objektorientering som paradigm kan vara väldigt användbart, men min erfarenhet är att C++ är ett härke av bakåtkompatibilitet med C samtidigt som man introducerar ett objektorienterat synsätt som ofta mest tjänar till att göra det enkelt att skjuta sig i foten. Jag kan inte påstå att C++ är enklare att programmera i än C, vilket Stroustrup verkar antyda i videon. Det är ju en stor poäng att abstrahera bort detaljer, men jag tycker inte C++ lyckas göra det på ett speciellt tilltalande sätt.This quote is hidden because you are ignoring this member.
Men som sagt, det finns en hel del audioprocessingkod skriven i C++, så ska man hålla på med sånt så är det något man får försöka lära sig, även om det inte är helt optimalt (det är ju ofta så med standarder att det inte är den tekniskt bästa lösningen som vinner).
Debatten mellan C och C++ brukar verkligen kunna bli eldfängd, helt i onödan, även om jag inte tror att den blir det här.
C++ är såpass invecklat om man tillåter sig att använda alla finurligheter med multipla arv och templates etc att det nog blir lätt att skjuta sig i foten. Men man kan ju också andända det som en smidigare variant av ren C och då kan det vara enklare än C.
Oavsett är det naturligt att lära sig C först och sedan fylla på med C++.
Lär dig C först.
Fungerar på nästan alla plattformer.
När du känner dig varm i kläderna kan du krångla till det.
Precis. C++ ska betraktas som en samling med olika verktyg. Man börjar med att lära sig hantera dessa verktyg i ordning. De lätta först och de svåraste sist.This quote is hidden because you are ignoring this member.
Templates är det svåraste verktyget. Man kan lära sig några enkla saker med templates och sedan de svårare (template metaprogramming).
En nybörjare lär sig först C delen i C++ och kan använda en C++ kompilator istället för en C kompilator.
Det är det Bjarne Stroustrup menar med att programmerings språket C är föråldrat, för man kan använda C++ och enbart skriva programmet i C om man vill.
Ganska snart upptäcker man att det finns stöd i C++ för att göra koden enklare att förstå och hantera än om man begränsar sig till att endast använda C. Exempelvis: namespaces, bool, auto, constexpr, const, decltype, inline, range-based for loops, osv.
Några av de uppräknade "verktygen" (och enum, som även finns i C) gör att man inte behöver använda macros så mycket (förutom include guards och för att inkludera andra header filer, etc.)
Det är en bra rekommendation men en RPi är en jobbig maskin att börja med för någon som vill leka embedded?This quote is hidden because you are ignoring this member.
Linux och SD-kort vill du inte blanda in.
Arduinon är fortfarande det lättaste du kan börja med.
Efter det kommer en NXP LPC som bara behöver en USB-UART kabel för att programmer.
Tom STM är lika lätt.
Allt programmeras i C.
RPi är jobbig som nybörjare.
Och sen ska jag visa att RPi är en ganska cool och enkel bräda att leka med bara jag löst bekymmret med att den inte rullar på 700MHz utan söligare än alla mina embedded ARM.
Och jag orkar inte leva i blindo mera så jag kopplar in en 2.4" SPI touchskärm på alla mina projekt för debug.
Sparar massor med tid.
Utan SD kort blir det djävligt svårt att få igång nåt på RPi.This quote is hidden because you are ignoring this member.
RPi och baremetal kan man ju bara starkt avråda hårt från tills någon satt ihop en toolchain med typ newlib och en funkis cruntime.
Men jag kan nog tycka att RPi och Linux är en bra start. Sno ALSA-ljud-utmatning och MIDI implementation via dess UART från min OpenModular. Antingen låter man sitt bygge fortsätta använda Linux på RPi och lever med lite boottid, eller så flyttar man bara ljudgenereraring koden till någon annan plattform och kör utan Linux.
Steg ett är att installera en bra kompilator!
Mac OS X
Installera Xcode och använd kompilatorn clang.
Någon Linux distro (Ubuntu):
Installera först gcc och sen clang.
Om man kör Ubuntu 14.10: http://askubuntu.com/questions/46665...n-ubuntu-14-04
Installera en IDE: Code Blocks kanske är lämplig. Somliga gillar Eclipse.
Windows (men allt blir krångligare, så kanske bäst är att installera Linux och köra dual boot)
Installera Visual Studio (det ska finnas någon gratis variant, här kanske)
Annars MinGW med samma IDE alternativ som nämns för Linux.
Steg två är att lära sig programmera i C och C++ på datorn (PC).
Steg tre (antagligen några månader senare) är eventuellt att börja programmera mot ett inbäddat system, beroende på hur mycket C / C++ man förstår, annars blir allting bara svårare.
Jag har skaffat Xcode, tänkte köra textwrangler för jag har det och har pysslat lite (lite) i det tidigare så det känns bekant på något sätt. Learn C the Hard Way tipsade om den också. Steg 2 är väl att sätta igång...
Allt med Win/iOS/Linux är pest och pina om du vill lära dig embedded.
På en embedded platftorm äger du alla resurser själv och din kod rullar på max frekvens utan avbrott.
På en multitaskad/timeslice plattform måste du dels be om resurserna och kanske ändå inte få dom och du får inte 100% CPU ens om du ber om det.
Du måste ha ett OS laddat som ska starta innan din applikation gör det och det tar också resurser.
Och du måste lära dig en massa API:s som inte har med din applikation att göra.
Köp en Arduino, vilken spelar ingen roll.
Ladda ner Arduino IDE och installera.
Plugga in USB-kablen och dyk på C programmeringen.
Du behöver inte ens koppla på något på pinnarna på Arduinon för att kunna testa och lära dig
programmering.
Och du har miljoner exempel på Internet som andra har gjort som du kan lära av.
Det är absolut det enklaste sättet att lära sig C.
Jag har windows också, men kör C i mac till att börja med, tar windows när jag börjar med hårdvaran.
Jag trodde du också tyckte jag skulle börja med C utan hårdvara? Köper nog en Teensy 2.1 snart ändå...
Vad jag förstår så ville du lära dig embedded?
Alltså bygga med hårdvara?
Jag har aldrig sagt att du ska göra det utan hårdvara, det rimmar inte väl.
Om du vill lära dig utan hårdvara på iOS eller Windows så gör det, det går.
Men I slutändan vill du ha det fristående?
När du har fått det att fungera på datorn så måste du lära dig igen när du ska på hårdvaran?
Bättre att lära sig på hårdvaran och porta till dator om det behövs.
Senast redigerat av janost den 2015-04-24 klockan 21:15.
Jag håller inte med. oljud behöver först och främst lära sig grunderna i C programmering. Om man inte kan C alls och ska lära sig språket är man inte intresserad av optimering som du nämner (att koden exekveras utan OS på ett inbäddat system där man "äger" alla resurser). Om man ska lära sig vad en funktion är eller hur pekare fungerar så är det ointressant om programmet körs i 1 GHz eller 1 MHz, om det körs under ett OS med time-slicing eller utan OS och stöd för multitasking.This quote is hidden because you are ignoring this member.
Utvecklings cykeln (skriva kod, kompilera, länka, köra programmet, fel söka, rätta fel, kompilera, osv.) tar bara längre tid och blir svårare om man blandar in ett inbäddat system för då ska man distribuera filer till det inbäddade systemet och debugging blir mera komplicerat också.
Utvecklings cykeln går flera gånger snabbare att bara lära sig C programmering exempelvis på en Mac med Xcode.
När oljud har lärt sig grunderna i C eller C++ programmering så kan han börja experimentera med algoritmer för att generera ljud, etc. I det läget kan det eventuellt vara intressant att testa det hela på ett inbäddat system som kanske också är målplattformen.
Men vi är inte där än!
Den boken kommer ut 17 Juli 2015.This quote is hidden because you are ignoring this member.
http://www.bokus.com/cgi-bin/product...C+the+Hard+Way
Free MIT online C programming course
http://www.embedded.com/electrical-e...ramming-course
Kanske kan vara intressant.
Finns på internet också. http://c.learncodethehardway.org/book/
Aha bra, ska kolla igenom kursen! I första kapitlet Exercise 0: The Setup står det:This quote is hidden because you are ignoring this member.
WARNING: Do Not Use An IDE
An IDE, or "Integrated Development Environment" will turn you stupid. They are the worst tools if you want to be a good programmer because they hide what's going on from you, and your job is to know what's going on. They are useful if you're trying to get something done and the platform is designed around a particular IDE, but for learning to code C (and many other languages) they are pointless.
Det är sant om (exempel) koden inte mycket mer än 1000 rader i några filer. Så länge det är lite kod så kan man jobba med koden i en text editor som den du nämnde (textwrangler) och så kan man söka efter ord med grep eller sök funktion i text editorn. Du har terminal fönstret bredvid och växlar till det när man du ska kompilera. Helst med en makefile. Det funkar.
Men när projekten är större så behöver man en bra IDE för att snabbt kunna orientera sig i kodbasen, hitta saker, osv. En del IDE system är jobbiga att lära sig, så som Visual Studio, medan andra är relativt enkla, så som Code:.Blocks.
Här är The C Programming Language, Second Edition (PDF).
Det är den bästa referensen för programmerings språket C.
Har du skrivit ett "Hello World" program i C, kompilerat, länkat och kört programmet än?
I din hem katalog, gör en mapp "project" där du lägger alla dina programmerings projekt.
I mappen "project" gör en mapp "hello_world".
Öppna en text editor (Textredigeraren fungerar bra), namnge filen "hello.c" (inte hello.c.txt) och spara den i "hello_world" mappen.
hello.c ska se ut så här:
Öppna en Terminal. Varje rad nedan börjar med $ men man ska inte skriva in $ utan bara det som står efter $:Kod:// hello.c #include <stdio.h> int main() { printf("Hello World!\n"); return 0; }
$ cd project
$ cd hello_world
$ ls
Nu ska det stå:
hello.c
Kompilera programmet så här med GCC:
$ gcc hello.c -o hello
Eller kompilera med clang så här:
$ clang hello.c -o hello
Kolla nu om du har en exekverbar fil som heter "hello":
$ ls
hello hello.c
Kör programmet:
$ ./hello
Hello World!
För att testa motsvarande exempel i C++, öppna en text editor (Textredigeraren fungerar bra), namnge filen "hello.cpp" (inte hello.cpp.txt) och spara den i "hello_world" mappen.
hello.cpp ska se ut så här:
Öppna en Terminal.Kod:// hello.cpp #include <iostream> int main() { std::cout << "Hello World!\n"; }
$ cd project
$ cd hello_world
$ ls
Nu ska det stå:
hello.cpp
Kompilera programmet så här med GCC:
$ g++ hello.cpp -o hello
Eller kompilera med clang så här:
$ clang++ hello.cpp -o hello
Kolla nu om du har en exekverbar fil som heter "hello":
$ ls
hello
Kör programmet:
$ ./hello
Hello World!
För den som kan C eller C++ programmering och är intresserad av audio signal processing så är kanske FFTW intressant!
Dessutom har man bättre stöd för debugging i ett system med OS. Många gånger krävs det ytterligare hårdvara för att köra debugging direkt mot en MCU, typ en JTAG-dongel av något slag.This quote is hidden because you are ignoring this member.
Men jag håller med Jan och andra om att skall man väl implementera något som skall köra i full fart där man utnyttjar processorn till max så är det ren hårdvara som gäller. Men som läromedel tror jag en mjukare approach kan vara mer motiverande.
Uppenbarligen är detta i vissa fall så pass krångligt att även erfarna går bet - tänker på RPi där tex Jan inte fått upp farten på den när man kör baremetal... Jag själv har inte heller fått igång RPi baremetal.This quote is hidden because you are ignoring this member.
Eftersom det är något visst med att ha gjort en sw defined synth som inte bara är typ en VST plugin utan är en fysiks låda utan datorskärm, så valde jag att fortsätta köra OpenModularen på RPi'n under Linux även när den bor i sin tjusiga box. För i detta hobbyprojekt är jag mest road av ljudalgoritmerna, och inte att skapa sig en baremetal miljö och tokoptimera dito.
Senast redigerat av dannes den 2015-04-29 klockan 21:11.
Men det behöver inte vara svårt bara för att det är embedded, Arduino, som jag fastnat för, upplever jag som väldigt lättjobbat. Visst, debuggingen är inte så bra i Arduino, man får hanka sig fram med spårutskrifter. Anledningen att jag upplever Arduino som lättjobbat är bland annat att det finns en stor mängd bibliotek och drivrutiner för allehanda hårdvara man kan tänka sig koppla in. Man sparar mycket tid på det. Och jag tycker IDE:t är lättjobbat också.This quote is hidden because you are ignoring this member.
Absolut. Jag tittade på det en gång och kom fram till att mina kunskaper inte räckte till, så jag har använt två enklare bibliotek för FFT. Kiss fft kan rekommenderas om man vill ha något relativt enkelt i C.This quote is hidden because you are ignoring this member.
Nog är det väl så. RPi är dock ganska mycket mer kraftfull breräkningsmässigt - även om RPi inte är någon high end som embedded heller. Sen kan jag tycka att embedded är lite väl omfattande begrepp...This quote is hidden because you are ignoring this member.
Jag det håller jag självklart med om och det har jag skrivit tidigare också! Men första steget är att lära sig programmera i C eller C++ på en vanlig Mac eller PC dator (för det blir som sagt mycket enklare med allting), och därefter när man kan programmera i C eller C++ kan/bör man köra på hårdvara med ARM, DSP, FPGA, etc.This quote is hidden because you are ignoring this member.
Jag är själv intresserad av att köra på DSP och FPGA, och experimentera med audio signal behandling, men jag har inte börjat med det än.
Jo, det var ungefär så jag menade egentligen. (Och historiskt signifikant, tidig digital syntes, vi snackar 1970-tal och PDP-11 t ex, var också i icke-realtid).This quote is hidden because you are ignoring this member.
Man kan ju göra väldigt mycket i icke-realtid också, man kan ju generera en wav-fil och lyssna på den sedan. Ger inte den där omedelbara syntkänslan kanske, men det är ett ställe att börja på.Mm. Samma här faktiskt. Samtidigt så ser man hur mer och mer går att göra med icke-DSP:er. Vi har ju janosts dsp-G1 som kör på en liten ARM Cortex-M0 i 12 MHz, och lite mer high-end Audiothingies P6 som kör på en MCU med en ARM Cortex-M4 som kärna. (Har i dagarna beställt en P6 f ö för att testa och få en känsla på vad som går att göra på en plattform av det slaget).Jag är själv intresserad av att köra på DSP och FPGA, och experimentera med audio signal behandling, men jag har inte börjat med det än.
Den kör på 48MHz.
12MHz men 4x PLL.
Det är 60 DMIPS.
Clavia körde med Mototola 56K DSP för Nord Lead 1, 2 och 3, samt för Nord Modular G1 och G2.This quote is hidden because you are ignoring this member.
Waldorf för XT och Q använder också Motorola 56K DSP.
Men numera har Clavia bytt till Analog Devices SHARK DSP för Nord Lead 4 och A1.
Det är inte en religion.
Man väljer det som är enkelt, billigt och gör jobbet.
C funkar på allt.
Det gläder mig. Anade det men tycker inte det är självklart alls.This quote is hidden because you are ignoring this member.
Nej, det är absolut inte självklart.This quote is hidden because you are ignoring this member.
Man kan skriva DSP-kod i Basic eller Java om det funkar.
Men det är lätt att flytta din kod till vilken hårdvara som helst med små förändringar om den är skriven i C.
Vad härligt!
Peppad av det satte jag mig med LCTHW för att kika på exemplen, men när jag ska köra ex1.c (Hello World) får jag permission denied i terminalen. trööttsamt
Har du kompilerat? Du kan ju inte köra C-filen.
Ingen fara, alla är nybörjare nån gång. Du kanske gjort rätt. Hur gjorde du / vad skrev du för att köra programmet?
Det brukar vara nyttigt att leta reda på och följa nån "getting started"-instruktion som visar hur man skapar och kör sitt första program.
Hello world! Funkar det?
Det kan däremot hända om man skriver ett batch-skript att man får permission denied och måste ändra rättigheterna med chmod. Men det var väl inte det som var problemet här?
Jag körde inte programmet precis som du gissade. Sen körde jag det och det funkade. Sen blev jag distraherad...
- - - Updated - - -
Det funkar, fast jag får lite olika meddelanden än exemplet. Men inte så olika.
Nu kanske det här börjar likna en c-tråd, men i hans (learn c the ...) exempel på hur man ska kompilera skriver han såhär:
vilket jag tolkar som att man ska skriva det. Men jag kan inte göra radbrott i terminalen..? (körde bara översta raden och det funkade)Kod:$ make ex1 cc ex1.c -o ex1
betyder $ att det är ny rad?
$ ska föreställa prompten, men det kan nog vara andra tecken på olika konsoller. Skriv bara in det som står efter prompten, raden under borde vara (eller likna) det svar man får i konsollen.
Ja, $ skriver jag alltså inte. raden under innehåller ju -o vilket verkar vara någon sorts inställning för make? Utan den säger den "no rule for make" eller något i den stilen.
Ah. Ska kika på det där efter helgen. Körde på LCTHWs instruktioner och det var inte helt tydligt...This quote is hidden because you are ignoring this member.
Ok lycka till! Testa att kompilera dina projekt både med gcc och clang, men jag rekommenderar att du främst använder clang, för clang är en bättre kompilator än gcc. Apple använder clang för allting de bygger!This quote is hidden because you are ignoring this member.
Exempelvis är det särskilt bra för dig som nybörjare för clang har en mera tydlig fel rapportering (än gcc), så när du har något fel i C eller C++ koden som gör att det inte går att generera binär kod så blir det lättare att förstå var du ska söka efter felet utifrån fel rapporteringen som clang ger dig.
Om du kör fast med något så fråga här i tråden så ska jag/vi försöka hjälpa dig.
Någon kanske tycker det vore intressant att experimentera med ljud algorithmer och ljud generering under Mac OS X, Linux eller Windows i ett portabelt format. Kanske det här kan vara av intresse http://www.portaudio.com
Någon som har programmerat med portaudio?
Här är någon som kör portaudio med BeagleBoard
https://youtu.be/x_zIMIt2hco
Här är instruktioner hur man installerar portaudio under Mac OS X
https://youtu.be/PIswwa4UlRE
Senast redigerat av Andreas T den 2015-05-01 klockan 17:08.
Jag tänker att det är bäst att experimentera med ljud algorithmer i Mac OS X med CoreAudio.
Jag skulle aldrig palla med att göra det under nån Linux distro eller Windows, för de Operativ Systemen är inte designade från grunden med tanke på avancerad audio hantering och låg latency, vilket Mac OS X är!
När man är nöjd med sina algorithmer och synthesizer koncept så räknar man ut vilken hårdvara som krävs för att köra algorithmerna och ljudgenereringen, så kan man porta algorithmerna till hårdvaran sist av allt.
Jag tror det går snabbast/smidigast och är roligast att utveckla på det sättet. Det är lättare att debugga algorithmerna om man kör på en vanlig dator istället för mot hårdvara direkt.
Det är antagligen en fördel att börja med att skriva till ljudfiler. libsndfile är bra för sånt.
Behörigheter för att posta
Svara med citat