GUI-elementer

GUI-elementer er for øjeblikket på det eksperimentelle stadium. Dette afsnit beskriver hvad det er meningen der skal ske med dem, så hvis du er udvikler, kan du forstå hvordan aRts vil håndtere grafiske grænseflader i fremtiden. Der er også allerede en del kode på plads.

GUI-elementer skal bruges til at lade syntesestrukturer vekselvirke med brugeren. I det enkleste tilfælde skal brugeren kunne ændre nogle parametre for en struktur direkte (som en forstærkningsfaktor som bruges inden det endelige afspilningsmodul).

I mere komplekse tilfælde, kan man tænke sig at brugeren ændrer parametre for grupper af strukturer og/eller strukturer som ikke kører endnu, såsom at ændre ADSR enveloppen for det aktive MIDI-instrument. Noget andet ville kunne være at angive filnavnet for et samplingsbaseret instrument.

På den anden side, kunne brugeren ville overvåge hvad syntheziseren gør. Der kunne være oscilloskoper, spektrumanalysatorer, lydstyrkemålere og “eksperimenter” som for eksempel regner frekvensoverførselskurven ud for et given filtermodul.

Til sidst, skal GUI-elementer kunne kontrollere hele strukturen af alt som kører inden i aRts, og på hvilken måde. Brugeren skal kunne tildele instrumenter til midi-kanaler, starte nye effektbehandlingsskridt, indstille sit hovedmikserpanel (som selv er opbygget af aRts-strukturer) for at få yderligere en kanal eller bruge en anden strategi for tonekontrol.

Som du ser, skal GUI-elementer give alle mulighederne i et virtuelt studie som aRts simulerer for brugeren. Naturligvis skal de også vekselvirke med midi-indgange (såsom skydere som også flyttes hvis de får MIDI-inddata som ændrer tilsvarende parametre), og formodentlig til og med oprette begivenheder selv, for at vekselvirkning med brugeren skal kunne indspilles via en sequencer.

Teknisk set er idéen at have en IDL-basisklasse for alle grafiske komponenter (Arts::Widget), og aflede et antal almindelige komponenter fra den (såsom Arts::Poti, Arts::Panel, Arts::Window, ...).

Derefter kan man implementere disse grafiske komponenter med en værktøjskasse, for eksempel Qt™ eller Gtk. Til slut, bør effekter bygge deres grafiske grænseflader fra eksisterende komponenter. En efterklangseffekt ville for eksempel kunne bygge sin grafiske grænseflade fra fem Arts::Poti-tingester og et Arts::Window. Så HVIS der findes en Qt™ implementering for disse grundkomponenter, kan effekten vises med Qt™. Hvis der findes en Gtk implementering, virker det også med Gtk (og ser mere eller mindre ud på samme måde).

Til sidst, eftersom vi bruger IDL her, kan aRts-builder (eller andre værktøjer) sætte grafiske grænseflader sammen visuelt, eller generere grafiske grænseflader automatisk, med tips for parameterværdier, kun baseret på grænsefladen. Det burde være ganske ligetil at skrive en klasse til at “oprette grafisk grænseflader fra en beskrivelse”, som tager en beskrivelse af en grafisk grænseflade (som indeholder de forskellige parametre og grafiske komponenter), og laver et levende objekt for en grafisk grænseflade ud fra den.

Baseret på IDL og aRts/MCOP-komponentmodellen, bør det være let at udvide de mulige objekter som kan bruges til den grafiske grænseflade præcis lige så let som det er at tilføje et plugin til aRts som for eksempel implementerer et nyt filter.