Svenska ElektronikForumet

Jag har för mig att det ingår i specifikationen att om man använder samma funktion används bara en status byte till flertalet efterföljande data bytes, precis som du har fått.

Ok, innebär att jag kommer designa min kod så att den stödjer detta från början.

Men kolla gärna MIDI-specifikationen, jag har laddat upp en gammal hemsida med det mesta om MIDI på TomasLs sida http://www.ebaman.com. Fast ser du att din sequencer skickat ut det borde det stämma tycker man.

Andax skrev:Senast jag fick lite tid över att titta på min midi-controller så såg jag lite konstigheter (som kanske inte är konstigheter) i mididata. Jag skickar vidare midi-infon till USB-uarten för debugging. Vad jag såg var att det kunde komma flera tangentnedtryckningar i samma meddelande, dvs det kom i stil med (i hex) "90 38 50 2E 40" istället som jag hade förväntat mig "90 38 22 90 2E 22". Är detta standard?

Stekern, om jag tolkat din midi-kod rätt hanterar den inte denna typ av kompakt mididata. Följer deb kompakta versionen standarden till 100%?

Såg även att "B0 xx xx xx xx xx xx" var längre och innehöll fler settings i följd än vad jag förväntat mig.

Jag har för mig att jag hade detta i åtanke när jag skrev koden för midi-delen, och nu när jag tittar på den så borde den fortsätta med den gamla statusbyten i minnet
och sedan bara parsa databyten/rna om det inte kommer en ny statusbyte. Denna del av koden är dock inte något som jag testat så det är möjligt att det inte fungerar så.

Men som psynoise säger så är det helt enligt specifikationen.

Även om detta projektet legat lite på is ett tag har jag nu haft lite tid att mellan omdränering av hus och andra elektronikprojekt att pilla på detta.

Håller på med att implementera ADSR-envelopen, vilket är mer komplicerat än jag först trodde.
Så långt som jag kommit med detta är att man kan med respektive insignaler på 0-127 kan styra Attack, Decay och Release till 0-16129 millisekunder (16129 kommer av att 127^2 är just 16129, insignalen är alltså upphöjd med 2 för att få fram tiden)
Problemet jag har är att jag måste sedan skala "outputen" (0-255) efter detta värde, dvs outputen för t.ex. attacken skall bli 255*<nuvarande timer för attack>/<attackvärdet>
Jag har inte hittat på nåt bättre sätt att lösa det på än att spara uppräkningsvärden för 0-127 i en lookup-table, så om nån har nån bra ide hur man smidigt kan lösa detta, varsågoda att tala ut

Nu börjar det hända lite saker med ADSR-envelopena.
Finns fortfarande lite småsaker som måste fixas innan det funkar tillfredställande men i det stora hela funkar det som det skall.

Ett lyssningsprov (ett C-minor spelas)
http://www.sk-electronics.com/sk-synth/ ... _test6.mp3

och så här ser det ut i cooledit:

Filade vidare lite på ADSR-envelopen idag.
Det som gör att den inte är helt perfekt är att uträknandet av releasen är lite bökig.
Först gjorde jag så att releasen skalades efter sustainen, dvs den räknar ner konstant oberoende av vad sustainen är.
Problemet med detta är bara att noten kan avbrytas innan vi nått sustain-läget.
Detta märks tydligt om man har en lång decay och låg sustain.
Då "skenar" releasen iväg och blir väldigt lång om man avbryter noten i början av decay-läget.
Nu är detta ändrat så att nedräkningstiden för ett steg av 255 är konstant, samma problem uppstår givetvis när man gör på detta sätt, men det märks inte lika tydligt.
Det helt korrekta sättet vore givetvis att för varje kanal spara undan det aktuella värdet när noten avbryts och räkna ut nedräkningsteget efter detta, men det innebär ett ganska drastiskt komplicerande av koden eftersom jag skulle behöva ha separata "phase-accumalators" för varje enskild kanals release.

Jag är inte ens säker på hur det fungerar på "riktiga" analog-synthar, är det så att release inställningen med järnhand styr releasetiden? Dvs är den alltid konstant för ett givet invärde oberoende vilken nivå envelopen ligger på när release-läget börjar?

aja, jag bjuder på lite mer lyssningsprov i form av min testtrudellut som jag använder mig av när jag "debugar"
http://www.sk-electronics.com/sk-synth/ ... _test8.mp3

Jag har nu ändrat koden så att release tiden räknas ut på det korrekta sättet som jag beskrev i förra inlägget, nu "känns" det rätt i alla fall när man spelar på synthen.
Nackdelen är såklart att envelope-modulen nu tar upp en hel del plats och jag kommer behöva initiera en till av den för att få till filter-envelopen (jag har bara implementerat amplitud-envelopet).
Men jag går vidare och när platsen tar slut så får jag börja revidera var nånstans man kan optimisera.
Målet är att få in alla funktioner med 8 noters polyfoni i den här fpgan.

stekern skrev:Här är ett blockschema så som den är uppbyggd för tillfället.

En fundering bara. Kommer synthen att vara en midi-modul till 100% (med inget mer än midi in och audio ut och i övrigt en svart fyrkantig låda utan reglage) eller kommer det att finnas rattar för filter, möjlighet att spara program, eller nån slags display där man ser vad man gör?
Den låter fint tycker jag, men lite av poängen med synthar är ju att de är lättanvända/snabbanvända. Och det där är ett skäl till att min Yamaha FB01 står i garderoben (kräver dator för att programmeras...).
Är bara lite nyfiken på tankegångarna, inte på något sätt menat som kritik på ett riktigt spännande projekt! Kommer att följa bygge och ljuddemo noga

Styrningen kommer nog alltid ske genom midi, men jag är helt inne på samma spår som dig, det ska finnas knappar som man kan vrida och meka med. Finns en ide i bakhuvudet att bygga en custom-hårdvarumidikontroller till den. Men som första steg blir nog att meka ihop en custom-softwaremidikontroller till den, har börjat lite smått att rita på en. Tills den är klar så använder jag tobybears midi control center.

Har petat lite i optimiseringen också, fått ner från 103% till 81%, problemet är bara att filterenvelopen inte får plats än...men skam den som ger sig.

Tjena, bara att säga grattis till projektet så här långt! Ser roligt ut men jäklar vilken åtgång av resurser du råkat få.. vad tar mycket? Filter?

Sorry om jag "kapar" tråden lite men det är bara att ignorera om det inte känns relevant.

Jag har själv varit "lite" aktiv kring FPGA-Synth: http://www.fpga.synth.net/ och följt vad folk gjort där och även hackat ihop nåt själv som åtminstone i nåt läge hade ljud. Hur mycket Slices tar din MIDI-controller I VHDL? Är du van assembler så kan jag rekommendera att lägga över den sysslan på en Picoblaze. Den tar väl c:a 100 slices och är nog rätt svårslagen på vilka finesser den klarar av att hantera via mjukvara då. FPGA-Synth forumet har ju moddat RS-232 controllern till Picoblaze för att kunna hantera MIDI har jag för mig, så det var det jag utgick ifrån. Steal-with-pride..

När jag byggde min egna enkla "synth" så satt jag faktiskt Picoblazen i mitten, så det var den som tolkade inkommande MIDI-signaler och sedan även indirekt styrde ljudet. Jag kopplade ett CoreGenerator-kopplat BRAM på en port till Picoblazen (typ som ett tillbehör) med lite extra intelligens där jag stoppat i en godtycklig vågform (provade både fyrkant, sågtand och sinus genererade av ett C# program). Fungerade rätt bra på 1 kanal som var det enda jag provade men hade ju inte samma finesser som din synth. Jag provade ADSR och fick även det att fungera skapligt, men hade problem med clipping när man tryckte ner tangenter utan att den förra tonen hade klingat ut.. kanske ska ta upp det igen och försöka få åtminstone 8 kanaler. Eftersom Picoblazen sköter allt så skulle det inte behövas nåt mer förutom möjligen flera kopior av BRAM-minnet som mappas på olika portar och sedan bara styra upp via mjukvara vilken som är "ledig" just nu alt. vilken som trycktes in först.

Lycka till framöver!

Jag håller med dig om att en mcu skulle kunna vara användbar och jag tittade faktiskt i nåt skede på just picoblaze.
Anledningen till att jag valde att inte använda den till slut var att den största meningen med det här projektet är att blåsa liv i vhdl kunskaper och ett av målen är att allt i den skall till 100% vara skrivet av mig själv. Så jag har inte använt coregenen nånstans heller.
Jag hade en tanke på att skriva en egen mini-mcu för att styra de olika delarna i synthen, men det kändes som lite för stort projekt i projektet.
Midi-delen tar ca 90-slicear så den är långt ifrån det som tar mest plats.
Det som tar plats är precis som du sa filtret och även ADSRen.
Dessa tar extra mycket plats i och med att de måste hålla reda på massa inviduella saker för varje kanal, så om jag drar ner antalet kanaler till 1 så tar hela synthen "bara" 1374 slicear (38%).
Jag har några ideer på hur jag ska kunna optimera filtret ytterligare.

En annan sak som bidrar till att storleken drar iväg är att jag har ett ganska stort antal olika statemaskiner som sköter olika delar av synthen. En möjlighet vore att kombinera dessa till en större statemaskin (och eventuellt dra upp klockfrekvensen om det behövs)

Nu har jag kopplat in filterenvelopet med, men jag har dragit ner antalet kanaler till 7 för att få den att få plats.
Jag ville dock ha den fungerande innan jag börjat rumstrera om för mycket i filtret för att optimisera det lite, så jag inte sabbar nåt för framtiden så att säga.

lyssningsprov: http://www.sk-electronics.com/sk-synth/ ... test10.mp3

Edit: är det nån som kan säga om truddeluten låter som nån annan låt och isåfall vilken? Jag har bara påtat ihop den från huvudet, men när jag lyssnar på den låter den misstänkt bekant.

Påminner lite om "Min hatt den har tre kanter,,,,"

Nu blev man ju lite sugen på att prova och bygga för mitt kort och extension-kort och plinka lite. Vilken ISE-verision kör du? Nåt man ska tänka på när man bygger? Är den versionen du pratar om Commitat i SVN? Är det enkelt att lägga till kanaler typ parametriserat? eller har du enkel Guide? Jag har ju Space Invaders DeltaSigma-Stero-ljud så jag byter ut output-steget på din koppling. Jag återkommer med ett ljud exempel.. I min 1600E torde det väl på plats en jäkla massa kanaler.. kanske..