Svenska ElektronikForumet

ISE 10.1 kör jag
lägga till och ta bort kanaler är lätt, bara ändra:
constant NUM_VOICES : integer := 8;
till det önskade antalet i SK-Synth_Pack.vhdl

Optimiseringen går för övrigt framåt bra, jag lyckades spara in nåra procent här och där så jag fick in allt med 8 kanaler med 97% utnyttjat
Sen började jag kolla över NCOerna och upptäckte att det fanns ganska mycket att fixa där, så just nu håller jag på och skriver om de ganska rejält, ser ut att landa på 77% (2778 slicear) när det är klart.
Detta finns inte i SVNen än dock

Eftersom de inte låg någon projektfil så provade jag min 11.2 först och det funkade bra! Snyggt jobbat med koden när allt bara funkar rakt av!
Blev ju lite sugen på att se hur mycket som fick plats. I dom understående exemplen nu kör jag I2C-ljudet men min lilla Delta-Sigma blir ju bra mycket mindre sen (och med sämre ljud säkert)

72Mhz verkar vara det som denna konstruktion landar på utan några Constraints. Vad behöver den egentligen? Den blir ju potentiellt mindre om du sätter upp ett gäng sådana.. eller åtminstone 1.

6 röster:
Total Number of 4 input LUTs 5,253/ 29,504 17%

8 röster:
Total Number of 4 input LUTs 6,117/29,504 20%

16 röster:
Total Number of 4 input LUTs 10,341/29,504 35%

24 röster:
Total Number of 4 input LUTs 34895/29504 118% (öhh där blev det lite stort)

Än så länge har jag bara provbyggt på datorn (inget kort kopplat till) men jag ska försöka hinna bygga riktigt till mitt kort och sätta mig och spela lite ikväll! Blir skitkul!
Jag rapporterar eftersom.

Nu är den optimiserade koden commitad i SVN, 2736 slicear (76%) är den nu.
Finns säkert fortfarande några procent kvar att hämta här och där.

Overclocked: Kul att du tar dig tid att leka med den!
Angående klockningen så kör jag den på 16MHz (det är vad oscillator på av-net kortet är på)
Jag tror att all kod förutom i2s koden (detta på grund av att jag kör den direkt på 16Mhz klockan för att få så bra samplingsfrekvens som möjligt) skall anpassa sig efter nedanstående,men det är ingenting som jag testat. Det som finns på TODO listan nu är:
* Göra så att LFOn kan styra amplitud och filterfrekvensen och inte bara pitchen som det är nu.
* Eventuellt lägga till en till LFO
* Göra det möjligt att stämma oscillatorerna individuellt med en cents precision

Andra saker som skulle vara kul att lägga till/implementera:
* Brusgenerator
* Portamento och legato
* Delayeffekt
* Disteffekt
* Ge förslag!

Snyggt jobbat med optimeringen!

Jag har valt att labba vidare med den här konfigurationen (gamla bygget just nu), dock bara byggt och inte lyssnat/provat än:

16 röster:
Total Number of 4 input LUTs 10,341/29,504 34%

En constraint på 16Mhz på clk gjorde inte så nån skillnad eftersom konstruktionen är ganska satt som den är med BRAM och MUL's. Landade ändå på 60Mhz.. och knappt mindre.

Eftersom jag tagit bort I2C-delen och ersatt den med 2st. DeltaSigmas och ett enkelt RC-nät på Line-out så löser sig klockproblemet. Dock blev den knappt mindre av detta utan ungefär samma storlek.. Då ska jag börja köra hela konstruktionen på 50Mhz som sitter på mitt kort istället för att kasta in en DCM för nerdelning som jag hade tänkt.

DeltaSigmas på 24-bit och 50Mhz blir nog inte så pjåkigt ljud ändå.. Då skulle man kanske nästan ha haft en CORDIC-core som genererar SIN-kurvorna med hög upplösning. Nån som provat eller kan nåt om dem? Ligger en på OpenCores och skräpar vet jag..

Att konstruktionen sticker iväg fort över 16 röster beror säkert på att antingen HW-BRAM eller HW-MUL's tar slut och börjar implementeras i logik antar jag..

Lite förslag på resursspar är:

- SIN-kurvan kunde ju delas i 4 delar och inverteras/vändas och på så sätt få ner BRAM-användningen till 1/4, men då passar den iofs inte på samma sätt som idag i lämpliga BRAM-block... alternativt kan man använda det till att öka upplösningen på SIN-kurvan 4ggr om man är i behov av det. Kräver ju lite mer look-up logik så kanske är dumt om du jobbar mot mindre logikanvändning.

- Tidsmultiplexning av BRAM's/MUL's kanske vore ett alternativ. Rätt byggd gör säkert ett BRAM c:a 180-200Mhz oavsett Spartan-3-krets och då hinner ju den delas åtminstone c:a 8-10ggr så 8st. kanaler borde kunna använda samma BRAM-minne. Kanske blir lite krångligt i kod eftersom man då skapat ett beroende mellan antalet kanaler/8 eller är sånt lätt att lösa i VHDL och generate satser?

Självklart måste du ju ha en phaser och en flanger. Det enda som krävs är ju ett litet delay eller ett allpassfilter och sen mixa ihop signalen med orginalsignalen. Sen vill man ju såklart modulera med ett LFO. Jag minns inte vilken som var vilken, för det är nämligen tvärtom i digitala världen än i analoga.

Overclocked:
Jo jag är medveten om att SIN-kurvan skulle kunna delas upp i 4delar men undvikit detta just pga av de anledningar som du tar upp.
Tidsmultiplexningen av BRAMen är jag inte riktigt med på hur du menar? om jag behöver hålla ett värde i minne så får jag ju inte den minnesplatsen ledig till nåt annat hur fort jag än försöker använda BRAMet?

Att det finns utrymme för att utnyttja BRAMen bättre är dock helt klart, som det är nu (som jag förstått) så går det åt ett BRAM-block åt även om det inte är helt utfyllt, så jag skulle kunna initiera ett stort BRAM som fyller upp hela utrymmet och sedan tidsmultiplexa åtkomsten till det där det är möjligt. Men det var kanske så du menade.

chille:
Bra ide, verkar ju inte alltför komplicerat och man kanske kan kombinera det med koden för en delayeffect på nåt sätt.

Yo, sorry för att jag inte förklarar bättre, men du listade ut det ändå! Jag menar alltså att access till dessa "BROM" tidsdelas. Enligt det du byggt så borde man kunna åtminstone dela ROM mellan de 2 NCO du har i samma Voice kanske? Då räcker det ju med dubbla frekvensen för att spara hälften av BRAM-resurserna vilket blir bra.

Jag har forskat lite mer kring varför resursutgången sticker iväg och kommit fram till att det är BRAM-instanserna som brakar i taket. De tar egentligen inte slut utan problemet uppstår när man passerar hälften av antalet som finns i kretsen. Min gissning (och du får nog kolla mer själv) är att beror på att du valt att använda 10-bitar (9 downto 0) istället för 9 bitar (8 downto 0) till SINROM vilket gör att Synth/Routern inte kan matcha de 18-bit BRAM i FPGA:n på ett bra sätt. Så det slutar med att den bra använder hälften.. Om du kunde tänka dig att gå ned i precision så KANSKE detta skulle försvinna och bättre mappa den HW som finns tillgänglig. Alternativt kan du nog gå upp till 18-bitars precision utan att saker och ting sticker iväg alltför mycket.

En annan mindre buggrapport är att det inte går att bygga en Synth med <3 röster p.g.a. av nåt syntaxproblem.. då ger iallafall ISE 11.2 upp! Well du får lyssna på det du vill av detta. Jag bara delar med mig att infon jag hittar!

Jag är imponerad av koden du skrivit och mycket tacksam att du delar med dig!! Skitkul att kolla och lära sig nya sätt att lösa problem på.

Det är precis det jag gjort i NCO optimiseringarna jag talade om, så att 2 NCO delar samma SINROM (samt logiken för att generera de övriga vågformerna bara initieras en gång).
Men det var ännu värre, för som jag hade innan så initierades dessa gånger antalet kanaler.
Detta beror på att NCOen var nåt av det första jag implementerade och iden om att öka i polyfoni har kommit efterhand, men att jag inte kommit på den missen förrens nu
är ju litet klantigt.

Själva hastigheten är inte något problem i sig, i teorin så är det samplingsfrekvensen till filtret som sätter gränsen och den är 96kHz.

Innan har jag i alla fall kunnat bygga med <3 röster, men det kan ju vara nån ändring som jag gjort nu som ställer till det, ska kolla på det.

För mig är det skitbra att någon har tid och ork att meka med koden, så man får lite feedback och ideer om förbättringar. Så det är jag som är tacksam!

Sorry lägg ingen tid på <3 rösters problemet! Det var buggar i ISE 11.2 som skapade problemet. Ibland klickar bygger helt enkelt så det blir byggfel trots att man inte ändrat koden.. hamnar i nån typ av felsynk.. Just nu bygger den allt mellan 1-18 röster så det är lugnt! Jag har laddat hem 11.3 updaten (typ 3Gbyte till!!) men inte vågat lagt in den än.. men jag ska nog göra det nu!

Ex:
1 röst:
Number of Slices 1262/14752 8%

OK nu har jag byggt 16-rösters version till mitt kort och fått igång den! MIDI-delen funkar skitbra.. av någon anledning distar ljudet fett men va sjutton då spelar man ju grejor som funkar... eller som jag tycker funkar! Stekern, har du en aning om varför den distar? Måste man justera för många stämmor? Har du hört något liknande på din I2C-output tidigare? Kan ju vara min extrema DeltaSigma som inte fungerar som tänkt, jag har fått rent ljud tidigare i mina egna demos med liknande upplägg men jag har ju inte kört mer än rena sinus/sågtand/fyrkant/triangel och när man bara spelar ett ljud så låter det ju bra även här.. jaja jag ska forska vidare när man får tid!

Kan man komma åt några parametrar på Synthen genom MIDI? Hur gör man detta? Skulle vara roligt med lite ADSR, rätt platt här under i jammet.. Jag har möjlighet att köra Cubase Lite som jag faktiskt använde till denna inspelning men spelade bara in ljudet live, måste ha en sladd till för att kunna få in MIDI i datorn också.. skulle vara roligt i så fall att ha en MIDI-kontroll-panel. Med en spec så kanske jag kunde knacka ihop en... dock aldrig provat förr.

Första demo-filen och första gången jag försöker använda den här online-driven så slå mig om det inte funkar, håll till godo:
http://cid-bcb1a8d90aae3cba.skydrive.li ... thJam1.mp3

Jag ska prova att ladda ner den sista versionen av projektet och överföra mina ändringar dit så man få lyssna lite igen! Skitkul att det funkade på första försöket!! ljud direkt!

Nu när du säger det så minns jag att mixningen av rösterna inte är ultimat, detta är något som jag måste fixa.
Som det är nu så är de bara nerskalade och sedan adderas de ihop.
Och nerskalningen är nog tyvärr anpassad för just 8 kanaler (är en sån där "det där fixar jag sen" som blivit liggande)

Just nu håller jag på och kollar på BRAMen i filtret, som det ser ut borde jag kunna kombinera 6st 24xNUM_VOICES BRAM till ett 24x(NUM_VOICES*4) BRAM där.
eftersom 24 bitar genererar ett 32x512 BRAM så skulle det innebära att upp till 128 röster skulle kunna få plats i detta.

midi control change parametrarna finns att hitta i SVNen: http://www.sk-electronics.com/svn/repos ... i_ctrl.txt

Förresten ligger mittpunkten på ljud_ut_vänster/höger på 0 eller mitt i spannet för de 24-bitarna (typ 80'0000)? Kan ju kolla men det är ju roligare med lite kommunikation. Det beror ju på hur din I2C-enhet vill ha datat. Min DeltaSigma kräver ju att den ligger på mitten och aldrig får underflow/overflow då blir det oljud.. Om den ligger på 0 så får jag addera till just 80'0000 i så fall..

Jag ska prova att bygga en 8-kanalers version istället framöver och återkommer med resultat.

Tack för infon kring CC-styr värderna! Pefekt med en sån spec! Nu skulle man ju alldeles ha haft en sån där fin MIDI-kontroller-box (som det pratades om tidigare) med en massa roliga rattar.. som jag aldrig förstått nyttan med till nu Jag ska läsa på hur man bygger styrpaneler i Cubase och knacka ihop en sån.

I2Sen vill ha datat i 2-komplementsform, så det är vad som kommer ut ur synthen. Så ja, för att få det mitt i så får du addera med (2^24)/2.

Fick just möjlighet att lyssna på jam'et, den oönskade disteffekten passade ju ganska bra in där iaf

En fråga Stekern, för att ADSR-kurvan skall upplevas linjär för örat borde den inte ändras logaritmiskt? Jag talar inte av kunskap utan bara en öppen tanke? Ditt demo lät liksom inte riktigt linjärt trots att det tydligt syntes på bilden att så var fallet med signalen.