Scripting bearbetning med MIDI (9 / 11 steg)

Steg 10: Gridly godhet

Denna inställning tillåter flera enheter att lägga roll rutnät. Vad som återstår är att lägga till några slutliga blomstrar.

Huvuddelen av grafiken händer på en delad skärm. En mer rendering struktur som täckte hela skärmen skulle vara trevligt. För detta ändamål skapas en ny RenderArgs ArrayList-instans.

Några mer tweaks bli presenterad också. Möjligheten att ställa en skalningsfaktor vid rendering en GIF. Detta gör att två intressanta funktioner: du kan centrera en stor GIF som annars inte skulle passa int ett enhetligt rutnät (eftersom du kan placera det övre vänstern och sedan skala det), och du kan växa/förminska GIF-bilder som de är Visa.

MIDI-standardmappning för arvet Launchpad ser ut som detta anmärkningsvärt sofistikerade diagram:

(104) (105) (106) (107) (108) (109) (110) (111)
[0] [1] [2] [3] [4] [5] [6] [7] (8)
[16] [17] [18] [19] [20] [21] [22] [23] (24)
[32] [33] [34] [35] [36] [37] [38] [39] (40)
[48] [49] [50] [51] [52] [53] [54] [55] (56)
[64] [65] [66] [67] [68] [69] [70] [71] (72)
[80] [81] [82] [83] [84] [85] [86] [87] (88)
[96] [97] [98] [99] [100] [101] [102] [103] (104)
[112] [113] [114] [115] [116] [117] [118] [119] (120)

Det finns runda knappar överst och längs till höger; den huvudsakliga layouten är en 8 x 8 rutnät. Siffrorna i diagrammet är MIDI notera värdena varje knapp skickar som standard.

Några saker att notera: det finns luckor i Obs spänner, och notera 104 upprepas två gånger, först på topp som den första knappen och igen på en knapp längst ner till höger.

Jag ville att relatera pad ställning till någon aspekt av en effekt att göra det mer intuitivt. Som du kanske har gissat av nu det i konstant flöde, men här är några exempel.

Renoise spåret inrättades att skicka några ganska strukturerade skiss utlösare. Exempelvis genererar en grid-fyllning sekvens.

Jag ville onGridNoteNN meddelanden för att kunna placera och skala GIFs över fönstret full skiss.

Som innan, det finns en lista att hålla data för utsläppande GIF-bilder på skärmen och metoder lägga till objekt och rensa listan.

Fokus ligger på avsnitt av startfönstret: de första fem kolumnerna (från vänster) och de tre översta raderna.

Flytta över kuddar i rad placerar en GIF relativa skärmen läge (längst till vänster, kinda vänster, center, etc.). Flyttar från första raden till tredje anger olika GIF gradering; lägre är större.

Slå pad för not 32 platser en GIF som fyller hela vänster sida; not 36 fyller till höger.

Kontrollera den skiss använda startfönstret

Allt detta verk av ett rutnät 8 rader av 16 kolumner. Skillnaden är i skalningsfaktor används. Att lägga till en GIF remderC RenderArgs listan omfattar anropar den här metoden:

void placeGif8x16 (heltal index, flyta skalning) {
gridCRows = 8;
gridCCols = 16.
gridCPointer = index.
centerScaling = gradering;
addToGridC();
}

där addToGridC är ungefär som addToGridL4x4.

Och mycket som äldre kod, det finns användning av diverse globala variabler kontrollera rutnät indexering och skalning.

Varning: Kan orsaka biverkningar

En hel del bearbetning koden jag ser gör rikliga användande av globala variabler. Det vill säga variabler som kan nås och eventuellt ändras för någon plats i skissen.

Allmänhet gör sådana saker mig krypa. Men varför? Och om det är så krypa-inducerande varför gör jag det här?

Det är är något god täckning av farorna med globala variabler här och här.

I ett nötskal, globala variabler är just det: globalt variabel. När en metod, som placeGifAt använder har en global variabel (t.ex. centerScaling) det finns inga garantier vilket värde den variabeln.

Värdet kan har fastställt en metod, men senare ändrade då av en annan, innan placeGifAt kommer att använda den. Denna höga grad av föränderlighet gör det mycket svårt att förstå vad som kommer att hända när placeGifAt anropas. Det är faktiskt mycket möjligt att centerScaling kan sluta med ett helt oanvändbar värde. När något inte beter sig korrekt, där ser du för att förstå varför? Om ett värde som används i en metod kan ändras från var som helst i din kod, hur du styr det?

Många bearbetning skisser är ganska små. De passar in i en fil, och är för det mesta lätt att titta igenom. Om en skiss inte är fruktansvärt komplicerat är då spåra udda beteende kanske inte ett stort problem.

Det började ett litet program med hjälp av globala variabler är inte en stor synd och kan göra det lättare att hoppa i, prova grejer och bedöma resultaten. Denna typ av utforskning bör uppmuntras.

När koden växer, men avsett nackdelen med biverkningar som följd av globala variabler förändras på ett sätt som strider mot beteende kan växa. Det kan vara meningsfullt att starta encapsulating dessa variabler, och hur de kan nås, i klasser.

För förberedande kod, och kanske creative coding i allmänhet, kan dessa biverkningar vara en oavsiktlig välsignelse.

Som jag skrev i handtagen för att reagera på Launchpad meddelanden jag lagt till metoder som befolkat en lista över GIF-placering. Faktiska utsläppande av dessa GIF-filer använder gemensamma globala värdet av centerScaling.

Utan att inse konsekvenserna hade jag mina metoder ändra värdet för centerScaling. Oavsiktliga resultatet blev att alla befintliga GIFs i renderC ändra storlek när en metod ändras värdet för centerScaling.

Inte vad jag tänkte, men jag gillar effekten. Om och när jag corral koden in i en mindre slumpartat strukturera detta slags beteende kan vara något jag vill hålla.