Rikta in dig på ett projekt med ett definierat mål.
Programmeringen kommer du att lära dig på vägen för att nå målet.
Rikta in dig på ett projekt med ett definierat mål.
Programmeringen kommer du att lära dig på vägen för att nå målet.
Om du samplar ett akustiskt instrument i hög upplösning är 64k toklite. Samplar du däremot endast en vågform räcker 64k till massor av instrument. Oavsett vilket så ligger datat i minnet. Du behöver veta tre saker. 1) Startadressen, dvs var i minnet samplingen börjar, 2) datatypen, dvs hur många byte varje "sample" är och vad dess data representerar, och 3) hur lång din sampling är, dvs storleken på arrayen.Ursprungligen postat av oljud
This quote is hidden because you are ignoring this member.
Du kan förstås också tänka dig arrayer av arrayer. Om du exempelvis har ett antal samplingar på olika minnesadresser så kan du ha en annan array där varje element håller reda på de tre ovannämnda sakerna om varje sampling.
Jag kan inte förklara mer specifikt utan att känna till mer om ditt problem.
Då väntar framgången på dig runt hörnet. Underbara dagar framför oss.This quote is hidden because you are ignoring this member.
Dessutom verkar det finnas mycket hjälp att få här på forumet om du kör fast.
Senast redigerat av gumse den 2017-04-17 klockan 12:16.
Hög upplösning är inget krav. Jag är villig att hålla mig inom begränsningarna, jag försöker tänka lite så att jag anpassar mig till begränsningarna istället för att göra något komplicerat som är "proffsigt". I slutändan blir det ju ändå bara oljud :-)This quote is hidden because you are ignoring this member.
Men, om jag gör en array med typ några värden, behöver jag väl inte säga var i minnet den är? En sampling är ju inget mer än en rad siffror, bara lite längre. I arduino-referensen ser det i alla fall ut som att man inte behöver göra något komplicerat, bara tuta och kör. Att storleken behöver definieras inser jag såklart (såg däremot att man kan läsa "efter" att arrayen tar slut, a'la Buchla 259e, och få in andra grejer ur minnet. Känns lovande).
Ja, det låter ju fiffigt med arrayer med arrayer. Så kan man också skriva i dem i något sorts 2d-mönster.
Okej. Jag ska försöka formulea problemet lite mer specifikt. Får fundera lite.
Det känns faktiskt så. Jag har inga problem med att förstå tänkandet bakom programmering, men jag har liksom fastnat i att använda MaxMSP (grafiskt) och nord modular (jag har gjort "menyer" och andra "program" i nord modular, inte bara syntes) men då är man fast i datorn. När jag väl kommer igång med Arduino känns det som att jag kommer kunna göra allt möjligt. Det känns så himla kul (så har jag inte känt tidigare i tråden, då har det mest känts hopplöst)This quote is hidden because you are ignoring this member.
(Jag har stora problem med att begripa elektronik, ärligt talat, även om helgens youtubetittande har börjat lossa lite på det. Programmering är rationellt och begripligt, elektronik känns som svartkonst. Men detsamma gäller ju t.ex. matlagning i viss mån och det klarar jag ju av. Man måste inte förstå allt, och med en microprocessor behöver man inte göra så mycket i den analoga världen, tänker jag).
Vilken Teensy använder du och var köpte du den/beställde den ifrån?
Här är Teensy 3.6 som jag tror är senaste som tillverkats.
Jag vill göra något liknade som du gör ojud. Tänker mig en plattform med en snabb Teensy med tillräckligt mycket RAM för mera avancerade projekt. En OLED display...kanske grafisk, A/D och D/A, ett antal knappar och rattar.
PS. Den kod du nu har jobbat med mot Teensy är ju C eller C++ kod, som detta:
analogRead() är en funktion som anropas här. Den tar emot en parameter A0.Kod:int accelX = analogRead(A0);
Vad den gör är att läsa av värdet för någon signal ingång "A0" i Teensy microprocessorn, och när funktionen returnerar gör den det med det avlästa värdet som är av typen int.
Det returnerade värdet tilldelas här en variabel accelX som är deklarerad som typen int.
oljud: Du behöver inte hålla reda på minnesadresser själv nej, för det gör variabeln åt dig. Variabeln kan man säga är en etikett på en specifik minnesadress. Om du exempelvis deklarerar en array såhär:
char myarray[100] = "min lilla char-array";
så blir egentligen myarray en pekare till första minnesadressen. Om du tittar i en debugger (jag vet inte vad du har tillgång till i din utvecklingsmiljö) så ligger myarray på en adress som du nog ser som ett hexadecimalt värde. Tittar du på innehållet i den adressen kommer det ha värdet 0x6d, dvs ascii-koden för bokstaven m (första tecknet i din array).
Därmed har du minnesadressen till första elementet i din array. Hur lång är arrayen då? I deklarationen bestämde du att den ska vara 100 char lång. I C, och sannolikt även i arduino, är char 1 byte lång, så din array är 100 byte. I detta exempel fyller du inte hela arrayen med data, men du har fortfarande allokerat minne för 100 byte.
Där har vi således alla tre sakerna på plats, 1) startadress, 2) datatyp och 3) arrayens längd.
Det är en Teensy 3.1. Köpte på Electrokit för rätt länge sedan. Accelerometern är en från tinkerkit, men den skickar analoga värden så det hade ju kunnat vara vilken signal som helst.This quote is hidden because you are ignoring this member.
Yes, det fattar jag :-)
Jahaa, då är jag med. Då var det ungefär som jag trodde dessutom. Skönt. Tack för hjälpen :-)This quote is hidden because you are ignoring this member.
Det jag har kört är Arduino IDE (tror jag det heter, deras vanliga program) och Teensy Loader. Och så en Teensy 3.1.
Det finns C kod listad i Korg Wavestation Reference Guide, under 5 Data Structure Tables (sid 115), som visar hur den interna strukturen är uppbyggd.
Väldigt lärorikt och intressant om man vill skapa en synthesizer. Man kan koda det ännu tydligare i C++ men principen de använt i C är mycket bra och korrekt. Skolexempel.
Strängt taget är det där bara en spec på hur midi-sysexen är uppbyggd, även om man göra en god gissning att synthen använder samma structar för att lagra ljud internt. Men det är ju ändå bara några datatyper och säger väldigt lite om den interna arkitekturen i synthen och ingenting om hur ljudprocessingen är uppbyggd.This quote is hidden because you are ignoring this member.
Vill man kolla på några exempel på mjuksynthar så finns till exempel källkoden till alla MDA-pluggarna i som open source. Kolla tex på JX10 för en analogsynth i ganska C-lik implementation.
https://sourceforge.net/projects/mda-vst/
OBXD är ett större projekt, inget man kör på en Teensy, men väldigt välskriven C++ med bra objektorienterad arkitektur, och låter bra gör den också.
https://github.com/2DaT/Obxd
Även janost här på 99an har lagt upp kod till en komplett stråksynth i en arduio om du vill titta på nåt riktigt lättviktigt.
https://janostman.wordpress.com/how-...-string-synth/
Senast redigerat av makari den 2017-04-19 klockan 13:14.
Och så finns den här sidan, vet inte om den har postats här förr.
http://blog.demofox.org/diy-synthesizer/
Har bara skummat igenom delar av den, men ser lovande ut.
Såg definitivt intressant ut. Men den gick väldigt snabbt från basic till sjukt hardcore när han blandade in SafeNumerics och sånt som visserligen är bra, men kanske lite overkill för tutorial riktad till nybörjareThis quote is hidden because you are ignoring this member.
Jag kan kolla hur jag gjort i min cv-sampler. Där sparas värden i en 256 lång array.
Funkar väl lika i alla programmeringsspråk.
Du definierar en array (eller allokerar minne) och en variabel som pekare eller räknare.
Alla läs och skriv operationer görs i arrayen på det index/adress som variabeln pekar ut och du ändrar bara pekaren, arrayen modifierar du inte direkt.
Funkar för lookup, fasmodulation, sampling, wavetable m.m
Jag har visst använt någon smart funktion "map" för att spara värden i array:This quote is hidden because you are ignoring this member.
int pot0 = 0;
int pot1 = 0;
byte recValue[256];
byte i = 0;
boolean buttonState;
void setup() {
pinMode(2, INPUT);
}
void loop() {
buttonState = digitalRead(2);
pot0 = analogRead(0);
pot1 = analogRead(1);
if (buttonState == HIGH) {
recValue[i]=map(pot0, 0, 1023, 0, 255);
};
analogWrite(9, recValue[i]);
i=i+1;
delay((pot1/10)+1);
}
Vad du har gjort är att mappa 0-1023 till 0-255.This quote is hidden because you are ignoring this member.
Samma sak som värde högershiftat 2 steg, eller pot0 >> 2
Har inget med arrays att göra.
recvalue[] är din array.
ah, såklart, nu minns jag. Iom att PWM-utgångarna endast är 8-bit men ADC-erna är 10-bit var jag tvungen att göra det.This quote is hidden because you are ignoring this member.
Ja recValue[i] är min array, så enkelt är det att spara värden iaf...
Tack! Ogillar att läsa kod på random för att lära mig, men det där kan nog komma väl till pass. Ska ha tid att sitta bara...This quote is hidden because you are ignoring this member.
map-funktionen var visst inte viktig ändå. skulle lika gärna kunna funka med:This quote is hidden because you are ignoring this member.
recValue[i] = pot0;
Nej.This quote is hidden because you are ignoring this member.
Pot0 är 10 bitar och din array är 8 bitar så det var helt rätt.
Lite bloatad men rätt
C exemplen du ser här funkar på vilken MCU som helst.This quote is hidden because you are ignoring this member.
Det är det som är fördelen med ett språk.
Titta på min Tiny-TS eller Stringsynt kod.
Allt funkar på Arduino Uno/Nano/AVR/Due, Teensy eller esp8266 utan modifikation annat än GPIO.
Senast redigerat av janost den 2017-04-19 klockan 22:57.
Nej, vad map gör visste jag redan, den verkar bra :-)This quote is hidden because you are ignoring this member.
Det är inte det det handlar om. Det är bara att det finns alltför mycket okommenterad (eller dåligt kommenterad) kod som man sförväntas lära något sig av att läsa innan man vet vad det betyder. Programmeringsvärlden har konstiga pedagogiska glapp tycker jag. Men men.This quote is hidden because you are ignoring this member.
Förstår dilemmat på ett sätt. Produktionskod brukar inte ha så mycket kommentarer, man förväntas förstå grundläggande strukturer och funktioner och vad de gör. Sen tycker jag också att kommentarer ofta är lite överskattade. Kod kan vara fruktansvärt snårig ändå och det hänger oftast inte på om den är väl kommenterad eller ej. Också kommentarer somThis quote is hidden because you are ignoring this member.
// Increase counter
counter++;
Gör ingenting för förståelsen direkt. Jag lägger ganska lite kommentarer löpande i koden när jag skriver. Målet är att genom struktur, namn på variabler, funktioner och enums, etc, göra koden i sig så pass tydlig att kommentarer är överflödiga. Jag brukar snarare skriva en kommentar när jag använder en funktion på ett ovanligt sätt eller när jag tycker att koden i sig inte är tydlig nog. Eller så gör jag en övergripande kommentar på ett block, alternativt bryter ut det blocket till en egen funktion som får ett vettigt och förklarande namn. På så sätt kan man skumma koden och få ett hum om vad de olika blocken gör.
Senast redigerat av makari den 2017-04-20 klockan 12:06.
Senast redigerat av Andreas T den 2017-04-20 klockan 13:07.
Nej då, vanliga kommentarer är rätt onödiga med. Och det är väl inte superviktigt för en själv. Jag sydtar mer på kod som är gjord för att lära ut, det känns som att de inte anar hur lite man fattar. När de bara förklarar en tiondel av kodens funktion men låter resten stå kvar så fattar man ju inte. Inte jag i alla fall. :-)This quote is hidden because you are ignoring this member.
Exakt, vettiga namn på variabler är viktigare.
Så länge syftet med koden är känt "Den här metoden implementerar ett resonant lågpassfilter enligt modell XYZ" så är det bra. Tänk kommentarerna som krav egentligen, mer fokuserat på VAD än HUR så blir det lättare att ta sig till.
När det gäller vilken plattform som skall väljas så skulle jag ta någon existerande euromodul med färdig kod för att ha något att utgå ifrån.
Håller helt med och försöker jobba efter samma princip. För de som är intresserade kan jag rekommendera boken Clean code som hade mycket bra tänk kring bra kod.This quote is hidden because you are ignoring this member.
Jo, men jag har ju inget åjro :-)This quote is hidden because you are ignoring this member.
Jag hoppas ni inte använder memcpy i era algoritmer:
https://www.audioasylum.com/messages...udio-renderingfound that a function called memcpy was the culprit, most memory players use memcpy and this is one of the reasons why memory play sounds worse ie digital sounding. Fortunately there is an optimised version of memcpy from http://www.agner.org/optimize/, using this version removes the hard edge produced by memcpy. the other thing I did was to close the file after reading into the buffer.
also most players use malloc to get memory while new is the c++ method and sounds better.
updated exe below, sounds fantastic I use it all the time now, doesn't have the processed sound of JPlay and is the best player I have heard on my system.
(Helt OT, men jag tänker att de som läser tråden här kan finna sånt här underhållande.)
Skaffa +/- 12V och kör på!This quote is hidden because you are ignoring this member.
This quote is hidden because you are ignoring this member.
Fast just det jag pysslar med nu ska typ sitta fast med kardborrband ändå, så det är inte så smidigt att bygga ett euro för att prototypa... accelerometer och elektretmick in, batteridrift, mono ut (fastlödd sladd gissar jag).This quote is hidden because you are ignoring this member.Skaffa +/- 12V och kör på!
Har inte Mutable Instruments öppen källkod? I så fall skulle man kanske kunna snappa upp några idéer från koden utan att behöva modulerna. Men kanske inte så användbart för just det här projektet?
Japp, MI kör open source på både hårdvara och mjukvara!
Tror att det kan vara för djupt och avancerat för min nivå. Fast visst, oscillatorer... skulle vilja ha lite uppslag på oscillatorer och dylikt.This quote is hidden because you are ignoring this member.
Om du vill börja experimentera med oscillatorer och programmerar på en dator så kan du ju ta dig friheter att koda enkelt och ineffektivt. Generera sampel med funktionen sin() från <math.h> och skriv dem till en ljudfil. Kolla upp formeln för FM så kan du fort komma igång med det också. Eller synk, fastän det kommer att ge aliasering om du gör det på det enklaste sättet.
Nästa steg är att göra det effektivare. Ersätt funktionsanropet till sin() med en vågformstabell. Då kan du skapa egna vågformer genom att skriva dem till tabellen.
Så här, för en sinuston på 440 Hz i 2 sekunder:
Kod:#include <math.h> int main() { const int samplerate = 48000; const int N = 2*samplerate; double x; for(int i=0; i<N; i++) { x = sin(2*M_PI*440*i/samplerate); // skriv x till ljudfil etc } }
Och om du modulerar fasen i sinusfunktionen med en annan sinus så har du PM, aka FM.This quote is hidden because you are ignoring this member.
Och gör det utan math och double.
Du bränner MCU cykler fortare än du hinner säga ordet synt.
Det finns mängder av intressanta Arduino projekt man kan följa via Twitter:
https://twitter.com/ArduinoOrg
Nu har jag ett mycket enkelt program igång, som verkar rulla på fint. Har bara kört inbyggda leden, ska testa med Attiny25 och högtalare på måndag.
Attiny är ju asgrymt. Vill göra massa kul nu.
(Det tidigare peojektet lade jag ner/i vila eftersom festivalen/koferensen jag skulle föra det på inte skulle betala något, hade kostat massor. Trist)
Försöker förgäves hitta max input till attiny85 på internet (/24/45). Visst kan man väl skicka 5v??
...ok. Bättre att leta i datorn, och när jag är vaken. Verkar bero på vad man kör på (och just nu rullar den på USB-ström, får se om det blir fem eller tre framöver. Verkar inte spela så stor rol för mitt ändamål, så kanske batteriet håller lite längre om jag kör på 3 v...)
Insåg också att jag inte behöver köra in spänningen kontinuerligt, borde kunna plocka en kort digitalWrite-puls från en annan pin. Borde spara lite ström tänker jag.
edit: fast den drar nog inte mkt på ingångarna, såklart. Kanske bara bökigt :-)
Resan fortsätter... Finns det någonstans där man kan läsa vad det är som tar upp program memory? Jag fattar noll. Tog just bort "halva" programmet, inkl. if-delen som bytte funktion, samt en analogRead. Det sparade mig 192 bytes (av cirka 20k).
Hur faan ska man få plats i en attiny? Vad är det som tar upp allt flash?
Man kan se lite i meddellanderutan, typ:
Sketch uses 33,420 bytes (13%) of program storage space. Maximum is 253,952 bytes.
Global variables use 2,787 bytes (34%) of dynamic memory, leaving 5,405 bytes for local variables. Maximum is 8,192 bytes.
Ja, men vad betyder det? :-)
- - - Updated - - -
Alltså, kan man läsa någonstans vad en analogRead tar upp? Om det funkar så?
Det är nog en hel del bibliotek som länkas in och tar upp plats (för IO och annat). Men kul att det går framåt.
Jag har inga bibliotek med. Det är liksom ett svinekelt program, inbillar jag mig.
Är det någon som Har länk till en guide som förklarar vad som avgör storleken?
Finns det bibliotek man kan plocka bort? Det är ingen kommunikation med något, bara en analog+digitalRead lite delays, random och digitalWrite. En metronom typ...
Du får nog visa koden om man skall kunna avgöra vad som tar upp flash.This quote is hidden because you are ignoring this member.
Och hur får du in 20k i en ATtiny85 som bara har 8k flash?
Jag är dålig på Arduino, men alla #include som inte är dina egna filer är antagligen arduinobibliotek. Sen tänker jag att det finns lite saker i botten som inte går att komma bort från som bootloader och sånt.This quote is hidden because you are ignoring this member.
Det gör jag inte. Kör på teensy som prototyp bara för att den var ikopplad i däcket...This quote is hidden because you are ignoring this member.
Jag har inga include. Tror jag har skalat ner det till en variabel nu. Jaja, får återkomma med min säkert pinsamt dåliga kod när jag har gått upp :-|This quote is hidden because you are ignoring this member.
Here goes...
senaste (trodde det skulle bli mindre, tar 22332 bytes
gårdagens:Kod:void setup() { pinMode(12, OUTPUT); } void loop() { byte mode = 0; digitalWrite(12, HIGH); // click delayMicroseconds(100); digitalWrite(12, LOW); mode = analogRead(A1); if (mode > 128) { delay((pow(analogRead(A0),1.19))+40); } delay(random (analogRead(A0)*2+1,(analogRead(A0)+23)*5)); }
:-|Kod:void setup() { const byte out = 12; pinMode(out, OUTPUT); } void loop() { int trimmer = 0; const byte out = 12; trimmer = analogRead(A0); if (analogRead(A1) > 512) { digitalWrite(out, HIGH); // click delayMicroseconds(100); digitalWrite(out, LOW); delay((pow(trimmer,1.19))+40); //set rate of clicks } digitalWrite(out, HIGH); // click delayMicroseconds(100); digitalWrite(out, LOW); delay(random (trimmer*2+1,(trimmer+23)*5)); }
- - - Updated - - -
(inser att kommentarerna inte tar plats, bara tog bort dem pga de var för någon annans skull, i ett mail, men de var till viss del inaktuella och störde mig)
Vad ska du göra? En oscillator?
F.ö. försök att undvika delay funktionen.
Använd millis istället. Finns exempel på arduino.cc
Arduino.h för Teensy är ganska stor för ARM och Teensy.
Den inkluderas alltid och innehåller grundfunktionera.
På en ATtiny är den ca 1k.
Sedan när du använder pow så inkluderas också math.h eftersom det inte är en grundfunktion.
Men den största orsaken är att arduino.h är stor på Teensy.
Din kod går nog utan problem in i en ATtiny.
Ok. Anade att delay() var en bov... Får kika på millis.This quote is hidden because you are ignoring this member.
När jag kompilerar (verify, inte upload) för en ATtiny får jag felmeddelande om att det är för stort. Kanske är någon inställning i programmet?This quote is hidden because you are ignoring this member.
Nu har du väckt mitt hopp!! (har planerat att bygga typ tio små klickgeneratorer till en spelning på lördag, i London, så har lite småbråttom :-)
Behörigheter för att posta
Svara med citat
