Academiejaar 2011–2012
Geassocieerde faculteit Toegepaste Ingenieurswetenschappen Valentin Vaerwyckweg 1, 9000 Gent
Een gebruiksvriendelijke applicatie voor het aansturen van DMX512 apparatuur
Masterproef voorgedragen tot het behalen van het diploma van Master in de industriële wetenschappen: informatica
Gert VAN DER PAELT Promotor:
Wijnand SCHEPENS
Academiejaar 2011–2012
Geassocieerde faculteit Toegepaste Ingenieurswetenschappen Valentin Vaerwyckweg 1, 9000 Gent
Een gebruiksvriendelijke applicatie voor het aansturen van DMX512 apparatuur
Masterproef voorgedragen tot het behalen van het diploma van Master in de industriële wetenschappen: informatica
Gert VAN DER PAELT Promotor:
Wijnand SCHEPENS
Woord vooraf
In dit voorwoord dank ik iedereen die mij op elke mogelijke wijze gesteund heeft in het tot stand brengen van dit eindwerk. In het bijzonder wens ik mijn promotor dr. Wijnand Schepens en mijn interne begeleider dr. Marleen Denert te bedanken voor hun inspanningen. Gert Van Der Paelt September 2012
Abstract
English In the world of entertainment, lighting devices have become crucial to enhance the spectator’s experience. For smaller companies and hobbyists, the cost of the hardware necessary to control these devices are generally too high. This forces consumers to buy inexpensive, but less feature packed control devices. This master thesis describes the development of a budget- and user-friendly package consisting of an Arduino-based hardware device and a Java-based software application to control industry standard lighting devices by means of the DMX512 protocol.
Nederlands In de entertainmentwereld zijn lichttoestellen cruciaal geworden om de ervaring van de toeschouwer te verberen. Voor kleinere bedrijven en liefhebbers is de kost voor de nodige hardware om deze toestellen aan te kopen in de meeste gevallen te hoog. Hierdoor wordt deze groep gedwongen om goedkope, maar minder geavanceerde sturingen te kopen. Dit eindwerk beschrijft de ontwikkeling van een kostenefficiënt en gebruiksvriendelijk geheel van een hardwaretoestel gebaseerd op Arduino, en een op Java gebaseerde softwaretoepassing om gestandaardiseerde lichttoestellen te besturen met behulp van het DMX512 protocol .
5
Inhoudsopgave Hoofdstuk 1 Inleiding ...................................................................................................................... 10 1.1 De verschillende takken van de theatertechniek .................................................................. 10 1.1.1 Lichttechniek............................................................................................................... 10 1.2 Doelstellingen ...................................................................................................................... 11 1.2.1 Het hardware platform ................................................................................................ 11 Hoofdstuk 2 Toestellen in de Lichttechniek .................................................................................... 13 2.1 Fixtures ................................................................................................................................ 13 2.1.1 Conventioneel licht ..................................................................................................... 13 2.1.2 Intelligent of geautomatiseerd licht............................................................................. 14 2.2 DMX Profielen..................................................................................................................... 17 2.3 Enkele veel voorkomende attributen.................................................................................... 17 2.4 Sturingen .............................................................................................................................. 20 2.4.1 Het programmeren van lichtshows.............................................................................. 20 2.4.2 Het gebruik van shapes ............................................................................................... 20 2.5 Het gebruik van visualisatiesoftware ................................................................................... 21 Hoofdstuk 3 Gebruikte technologieën ............................................................................................. 23 3.1 Java Architecture For XML Binding ................................................................................... 23 3.1.1 Inleiding tot JAXB ...................................................................................................... 24 3.2 Protocollen ........................................................................................................................... 25 3.2.1 0/10V........................................................................................................................... 25 3.2.2 DMX ........................................................................................................................... 25 3.2.3 Art-Net ........................................................................................................................ 27 3.2.4 Proprietaire protocollen............................................................................................... 27 Hoofdstuk 4 Dongles ....................................................................................................................... 28 4.1 Commerciele dongles en software ....................................................................................... 28 4.2 Dongle op basis van de Arduino microcontroller ................................................................ 28 4.2.1 De Arduino microcontroller ........................................................................................ 29 4.2.2 De Arduino als DMX dongle ...................................................................................... 30 Hoofdstuk 5 De software architectuur ............................................................................................. 34 5.1 Besturing van de DMX512 apparatuur: de interface IDongle ............................................. 34 5.2 Modellering van een toestel ................................................................................................. 35 5.2.1 De klasse Fixture......................................................................................................... 35 5.2.2 De klasse Feature ........................................................................................................ 36 5.2.3 De klassen SimpleAspect en DiscreteAspect.............................................................. 36 5.2.4 Het instantiëren van Fixture objecten.......................................................................... 37 5.3 Modellering van shapes ....................................................................................................... 38 5.3.1 De klasse BasicShape.................................................................................................. 38 5.3.2 Een voorbeeldimplementatie van een shape: de SwingShape..................................... 39 5.3.3 De klasse ShapeConfiguration .................................................................................... 39 5.3.4 De klasse ShapeFactory .............................................................................................. 39 5.3.5 De klasse ShapeGroup ................................................................................................ 40 5.4 Hulpklassen.......................................................................................................................... 40 6
5.4.1 De klasse Pallette ........................................................................................................ 40 5.5 Modellering van de tijdsaspecten......................................................................................... 41 5.5.1 De EventGroup en Event............................................................................................. 42 5.5.2 Het concept generators ................................................................................................ 42 5.6 Opslag van de gegevens....................................................................................................... 43 5.6.1 Gebruik van JAXB voor de implementatie van de fixture bibliotheek en fixture profielen 43 5.6.2 Structuur van de showfile............................................................................................ 45 5.7 Het uitwendig tijdsmodel ..................................................................................................... 46 5.7.1 Inhoud van het tijdsbestand......................................................................................... 46 Hoofdstuk 6 De grafische interface.................................................................................................. 48 6.1 Overzicht van de grafische interface.................................................................................... 48 6.1.1 Het Workspace Window ............................................................................................. 48 6.2 Het Time Window................................................................................................................ 52 6.2.1 De tijdsboom ............................................................................................................... 53 6.2.2 De tijdlijn..................................................................................................................... 54 Hoofdstuk 7 Besluiten en toekomstperspectieven ........................................................................... 57 7.1 Evaluatie van de doelstellingen............................................................................................ 57 7.1.1 Een goedkope en toegankelijke oplossing................................................................... 57 7.1.2 Een bruikbare oplossing .............................................................................................. 57 7.1.3 Voorzien zowel in hardware als in software ............................................................... 58 7.1.4 Een open oplossing...................................................................................................... 58 7.2 Punten van verbetering......................................................................................................... 58 7.3 Mogelijkheden voor uitbreiding........................................................................................... 58
7
Lijst van figuren
FIGUUR 1 OVERZICHT VAN DE HARDWARE ............................................................................................................ 12 FIGUUR 2 VOORBEELD VAN EEN PARCAN: DE PAR64 (JK-LICHTENGELUID). .......................................................... 14 FIGUUR 3 EEN VOORBEELD VAN EEN DIMMER. (LICHT-GELUID)............................................................................. 14 FIGUUR 4 VOORBEELD VAN EEN KLASSIEKE SCANNER. (MADDEFFECTS) ............................................................... 15 FIGUUR 5 VOORBEELD VAN EEN SCANNER MET CYLINDRISCHE SPIEGEL. (DIRECTPROAUDIO) ............................... 16 FIGUUR 6 EEN WASHLIGHT. (MARTIN).................................................................................................................... 16 FIGUUR 7 EEN SPOTLIGHT. (MARTIN) ..................................................................................................................... 17 FIGUUR 8 VOORBEELD VAN EEN GOBOWIEL. (ASTUCES-PRATIQUES, 2011)............................................................. 19 FIGUUR 9 VOORBEELD VAN EEN SHAPE GENERATOR.............................................................................................. 21 FIGUUR 21 DE JAXB ARCHITECTUUR (ORACLE DOCS).......................................................................................... 24 FIGUUR 10 DE ARDUINO UNO MICROCONTROLLER. (ARDUINO) ............................................................................ 29 FIGUUR 11 AANSLUITSCHEMA VOOR DE MAX485/SN75176. (SENDING DMX WITH THE ARDUINO, T. NESS & D. CUARTIELLES, 2006)..................................................................................................................................... 30 FIGUUR 12 DE ARDUINO DONGLE OP EEN BREADBOARD. ....................................................................................... 31 FIGUUR 13 DE INTERFACE IDONGLE ...................................................................................................................... 34 FIGUUR 14 OVERZICHTSDIAGRAM VAN FIXTURES ................................................................................................. 35 FIGUUR 15 DE KLASSE FIXTUREBUILDER .............................................................................................................. 37 FIGUUR 16 DE KLASSE FIXTURECONFIGURATION .................................................................................................. 38 FIGUUR 17 DE KLASSE FIXTUREPERSONALITY ...................................................................................................... 38 FIGUUR 18 DE KLASSE BASICSHAPE ...................................................................................................................... 39 FIGUUR 19 DE KLASSE SHAPEGROUP .................................................................................................................... 40 FIGUUR 20 HET INWENDIG TIJDSMODEL ................................................................................................................ 42 FIGUUR 22 UML VOORSTELLING VAN HET XML SCHEMA VOOR DE OPSLAG VAN DE FIXTURE LIBRARY ............... 44 FIGUUR 23 DE WORKSPACES .................................................................................................................................. 49 FIGUUR 24 WEERGAVE VAN EEN CONTINUE FEATURE ........................................................................................... 51 FIGUUR 25 WEERGAVE VAN EEN DISCRETE FEATURE ............................................................................................ 51 FIGUUR 26 FRAGMENT VAN HET TIME WINDOW.................................................................................................... 53 FIGUUR 27 OVERZICHT VAN RELATIES VOOR DE TIMELINEDISPLAY ..................................................................... 54 FIGUUR 28 DE VERSCHILLENDE TOESTANDEN VAN EEN EVENTCOMPONENT (VLNR.: HIGHLIGHTED, NEUTRAAL EN GESELECTEERD) ............................................................................................................................................ 55
8
9
Hoofdstuk 1
Inleiding
Omdat de wereld van de theatertechniek bij velen onbekend is, wordt eerst een kleine toelichting gegeven. Er wordt ook een toelichting gegeven bij de doelstellingen van dit eindwerk.
1.1 De verschillende takken van de theatertechniek De omstandigheden in de hedendaagse wereld van de podiumkunsten hebben er toe geleid dat er een nieuwe technische tak ontstaan is: de theatertechniek. Theatertechniek is een verzamelnaam voor alle inspanningen ter ondersteuning van artiesten op het podium. Deze inspanningen zijn grofweg in te delen in een aantal gebieden. We onderscheiden hijstechniek, lichttechniek, geluidstechniek en video. Het is evenwel niet altijd even duidelijk waar nu precies de scheiding tussen de verschillende vakgebieden ligt. Veel hangt ook af van de schaal van de productie, en het aantal personen die erbij betrokken zijn. Is de productie eerder kleinschalig, dan is het best mogelijk dat alle aspecten worden gerealiseerd door eenzelfde persoon. Bij erg grote producties is het evenwel mogelijk dat een enkel gebied door meerdere personen wordt gerealiseerd. Dit project situeert zich uitsluitend in gebied van licht. Men gebruikt ook dikwijls de Engelse term light engineering.
1.1.1 Lichttechniek Specifiek voor de lichttechniek zijn er twee sleutelfuncties te identificeren: de designer en de operator. Het is de taak van de designer om een ontwerp te maken van het licht dat gedurende het evenement zal worden gebruikt. Hij kan beschouwd worden als de architect van het licht. Hierbij zal hij verschillende aspecten in rekeningen (waaronder budget, ruimtelijke beperkingen, structurele beperkingen, …) om een realistisch lichtplan op te stellen. De operator zal dan gedurende het evenement zelf het licht bedienen. Zijn mogelijkheden worden enerzijds bepaald door het lichtplan dat door de designer werd opgesteld. Anderzijds kan de operator zijn creativiteit pas volledig loslaten indien hij de juiste middelen heeft om het licht te besturen.
10
1.2 Doelstellingen De commercieel beschikbare oplossingen om de beschreven toestellen aan te sturen, zijn meestal zeer duur, en voor liefhebbers en kleine bedrijven ontoegankelijk. Er komt ook nog bij dat deze consoles moeten worden geprogrammeerd. De besturingssystemen van deze consoles hebben een vrij steile leercurve, wat maakt dat de opleiding van de het personeel eerder kostelijk is, en voor kleinere organisaties niet rendabel is. Goedkopere oplossingen zijn meestal zeer moeilijk te programmeren, en vereisen veel inspanningen. Het is essentieel om de nodige tijd voor het programmeren zo veel mogelijk te reduceren. In vele gevallen worden de mogelijkheden van het aanwezige materiaal niet ten volle benut, omdat de programmeertijd te kort is gebleken. Het doel van deze masterproef is tweeledig. De eerste stap bestaat erin om een open platform op te bouwen, waarbij alles zo goedkoop mogelijk moet kunnen worden gerealiseerd. Ontwikkelaars kunnen dan zelf hun applicaties bouwen op dit platform. Het platform beschrijft zowel de nodige hardware, als een beperkt softwareraamwerk. In het tweede luik, gebruikt de geproduceerde hardware om een clientapplicatie te maken, waarbij clients de aangesloten fixtures kunnen bedienen. Ook programmeren en ontwerpen van de effecten wordt verzorgd.
1.2.1 Het hardware platform Figuur 1 toont een overzicht van de hardwarearchitectuur zoals deze werd gerealiseerd, samen met de technologieën die zullen worden gebruikt. De client wordt verbonden via USB met de Dongle. De communicatie met de dongle verloopt niet rechtstreeks via USB: De microcontroller bevat een FTDI chip die ervoor zorgt dat er seriële RS323 communicatie kan gebeuren over USB. De dongle is dan via een DMX lijn verbonden met de ketting van fixtures.
11
Figuur 1 Overzicht van de hardware
De software zal worden ontwikkeld in Java. Door deze keuze kunnen we eenvoudiger in platformonafhankelijkheid voorzien.
12
Hoofdstuk 2 techniek
Toestellen in de Licht-
Functioneel gezien zijn de gebruikte toestellen op te delen in twee categorieën. In eerste instantie bekijken worden de zogeheten fixtures besproken. Zij staan in voor de creatie van visuele effecten op het podium. Op de tweede plaats komen de sturingen die worden gebruikt om de vorige soort apparatuur te besturen. Wanneer er dieper wordt ingaan op de gebruikte protocollen, zal het onderscheid tussen beide soorten ook duidelijk aan de hand van een aantal technische aspecten.
2.1 Fixtures Een fixture is eender welk toestel dat instaat voor de creatie van een effect op het podium. Fixtures bestaan in verschillende vormen, smaken en prijsklassen en worden door een breed spectrum aan fabrikanten geproduceerd. In de loop der jaren zijn fixtures steeds meer geavanceerd geworden. De toestellen zijn geëvolueerd van eenvoudige armaturen met slechts een enkele lamp, tot zeer dure en geavanceerde toestellen die de naam robot net niet waardig zijn. Merkwaardig is dat de eerste generatie van fixtures na vele jaren nog steeds wordt geproduceerd en gebruikt. Men spreekt in deze context van conventionele belichting. De nieuwere generatie wordt meestal benoemd met intelligent of geautomatiseerd licht. Het is deze laatste generatie die door de vele mogelijkheden ook een complexe besturing vraagt.
2.1.1 Conventioneel licht Wanneer men in het vakjargon over conventioneel licht spreekt, bedoelt men meestal statische projectoren die niet geautomatiseerd zijn. Zij voorzien enkel in de mogelijkheid om de intensiteit van de lichtbron te regelen, door de hoeveelheid stroom die het volledige toestel krijgt aan te passen. Het meest gekende voorbeeld van een conventionele armatuur is de parcan. Parcans zijn metalen behuizingen die een gloeilamp of halogeenlamp huisvesten.
13
Figuur 2 Voorbeeld van een parcan: de par64 (JK-Lichtengeluid).
Een conventioneel toestel wordt dikwijls aangesloten op een dimmer. Deze dimmer wordt dan via een welbepaald protocol bestuurd. Dit protocol voorziet de dimmer van instructies om de hoeveelheid stroom die de aangesloten toestellen krijgen aan te passen, om zo uiteindelijk de intensiteit de lamp te regelen.
Figuur 3 Een voorbeeld van een dimmer. (Licht-geluid)
Dit type van fixtures is, in tegenstelling tot intelligent licht, zeer goedkoop in aanschaf. Ze brengen echter ook een aantal nadelen met zich mee. Een eerste nadeel is de bekabeling die ze vereisen. Doordat ze passief worden bestuurd, moeten er veel kabels worden voorzien.. Ook het gewicht van deze kabels begint een rol te spelen. Een tweede nadeel is het gebrek aan flexibiliteit. De richting en kleur van een conventionele armatuur is steeds dezelfde. Conventionele toestellen worden steeds statisch opgehangen. De richting wijzigen van de toestellen gebeurt steeds manueel. Indien men meerdere posities wil belichten, met meerdere kleuren, moet men meerdere armaturen voorzien die van de gepaste toebehoren zijn voorzien, en gepast gepositioneerd zijn. Een belangrijk voordeel is echter wel dat ze in staat zijn om relatief grote lichtopbrengsten te realiseren, tegen een lage kostprijs. Dit maakt dat ze nog steeds inzetbaar zijn voor toepassingen waar de eerder genoemde nadelen geen beperking vormen.
2.1.2 Intelligent of geautomatiseerd licht Deze klasse van toestellen wordt gekenmerkt door een grote diversiteit aan toestellen. De diversiteit ligt vooral in de aanwezige features van de toestellen, en de kenmerken van deze features zelf. Waar conventioneel licht enkel in staat is tot het projecteren van een eenvoudige bundel, kunnen deze toestellen de lichtbundel op verschillende manieren manipuleren, om zo verschillende effecten te creëren. Men spreekt dikwijls van de verschillende attributen van een fixture. Deze attributen zijn in de meeste gevallen optische elementen die in de stralengang worden geplaatst, en bestuurbaar zijn door een of 14
meerdere parameters. We bespreken eerst een aantal verschillende soorten populaire fixtures. De eerste twee groepen, scanners en movingheads zijn gelijkaardig. Door hun constructie verschillen ze in hun mogelijkheden. De beweging wordt gerealiseerd door een rotatie, die rond twee assen kan gebeuren: de verticale en de horizontale as. De respectievelijke bewegingen worden pan en tilt genoemd.
2.1.2.1 Scanners Scanners zijn een eerste soort van bewegend licht. De beweging wordt bekomen door het licht te projecteren op een spiegel, en deze spiegel te laten bewegen door stappenmotoren. Door de constructie is de beweging beperkter in vrijheid dan de volgende soort. De exacte bereiken verschillen van model tot model, en van fabrikant tot fabrikant.
Figuur 4 Voorbeeld van een klassieke scanner. (Maddeffects)
Een speciale soort van scanners, heeft in plaats van een vlakke spiegel, een zogeheten barrel. Dit is een cilindrische spiegel, waarvan de mantel is opgebroken in verschillende vlakken, meestal facetten genoemd. De beweging rond de horizontale as, tilt, vervalt hierbij, en wordt gerealiseerd de rotatiesnelheid van de cilinder aan te passen. Wanneer een lichtbundel op deze spiegel invalt, wordt hij gebroken in meerdere individuele lichtbundels.
15
Figuur 5 Voorbeeld van een scanner met cylindrische spiegel. (Directproaudio)
2.1.2.2 Moving heads Movingheads verschillen van scanners doordat het volledige optisch systeem aangebracht is in een omhulsel dat kan bewegen rond twee assen. Door deze constructie is het bereik van de beweging veel groter. De groep van de movingheads zijn praktisch ook nog onder te verdelen in twee groepen: spots en washlights. Het verschil zit hem in de constructie van het optisch systeem. Een spot zal steeds een smalle, scherpe lichtbundel produceren, waar een washlight een brede onscherpe diffuse bundel maakt. Dit verschil valt onmiddellijk aan de buitenzijde van het toestel op te merken, door naar de lens te kijken. Ook de aspecten die aan te sturen zijn verschillen. Zo heeft een washlight bijvoorbeeld nooit een gobowiel (zie verder), maar dan wel specifieke controls om de lichtbundel vorm te geven.
Figuur 6 Een washlight. (Martin)
16
Figuur 7 Een spotlight. (Martin)
2.1.2.3 LED fixtures Deze groep behoort tot de meest recente ontwikkelingen. Scanners en moving heads bestaan ook in LED uitvoeringen. De lichtbron wordt hier vervangen door een matrix van LED’s. Dikwijls zijn er drie kleurgroepen voorzien: rood, groen en blauw. Door de intensiteiten van deze groepen aan te passen, kan de gebruiker een breed spectrum aan kleuren creëren.
2.1.2.4 Lasers Lasers zijn de laatste jaren erg populair geworden. Ze worden echter zelden op dezelfde manier aangestuurd als andere fixtures. Ze hebben hun eigen protocol: het ILDA protocol.
2.2 DMX Profielen Het profiel (eng. Personality) van een toestel is de beschrijving van de beschikbare attributen van een fixture, en de adressen die ze krijgen. Deze zijn steeds opgenomen in de handleiding van een fixture, en moeten uiteindelijk worden omgezet in een digitale structuur die toelaat om de fixture aan te sturen.
2.3 Enkele veel voorkomende attributen Zoals eerder aangehaald zijn de aanwezige aspecten niet gelijk voor elk type toestel. Welke aspecten aanwezig zijn, hangt grotendeels af van de prijs van de fixture. Zo zullen bijvoorbeeld enkel de duurdere fixtures beschikken over een iris (of diafragma). In wat volgt bekijken we de verschillende attributen die in de actuele apparatuur het meeste voorkomen. Dit is evenwel geen beperkende opsommingen. Sommige fabrikanten hebben veel fantasie in het bedenken van manieren om de lichtbundel te manipuleren. We merken hier ook nog op dat sommige attributen kunnen worden bestuurd door elke mogelijke waarde uit een bepaald bereik, terwijl andere attributen slechts toestanden uit een beperkte verzame17
ling kunnen aannemen. Men spreekt van continue en discrete attributen. Om wat volgt te kunnen begrijpen, wordt het principe van een kanaal besproken. Een kanaal kan het beste worden beschouwd als een variabele of een veld van het type 8 bit unsigned integer. De waarde van het attribuut komt dan overeen met de inhoud van de variabele. Elk van de volgende attributen wordt aangestuurd door een of meerdere kanalen van 8 bit breed. In deze context spreken we ook van de resolutie: sommige attributen worden, om een grotere precisie te behalen, door meerdere kanalen aangestuurd. Een voorbeeld hiervan zijn de bewegingsattributen. Stel dat bijvoorbeeld een toestel de mogelijkheid heeft om 540° te draaien. Indien er slechts een enkel kanaal zou worden gebruikt, beweegt het toestel in stappen van 2,1°. Dit resulteert in een schokkerige beweging. Wanneer er twee kanalen worden gebruikt, kan er in stappen van 0,008° worden bewogen. Voor het menselijk oog lijkt dit een vloeiende beweging. De dimmer regelt de intensiteit van de lamp. Elke fixture beschikt over minstens één dimmerkanaal. De verschillende waarden behoren meestal toe aan continu bereik van 0 tot 255, waar 0 overeenkomt met het laagst mogelijke intensiteitsniveau, en 255 met hoogst mogelijke intensiteit. De meeste fixtures regelen de intensiteit elektrisch door de spanning van de lamp aan te passen. Sommige fixtures gebruiken een mechanische dimmer met lamellen. Dit soort dimmer reageert trager dan elektronische dimmers. De shutter zorgt voor het al dan niet doorlaten van de lichtbundel. Hij kan er ook voor zorgen dat de lichtbundel met een hoge frequentie (waarden rond 14Hz) flitst, dit wordt ook wel stroben genoemd. Een aantal andere functies worden ook voorzien. Zo is er bijvoorbeeld ook de mogelijkheid om de shutter met een random frequentie te laten flitsen. Ook het pulseren met een opengaande of sluitende beweging is mogelijk. Voor het pulseren zijn meestal slechts een aantal discrete snelheidsinstellingen beschikbaar (bijvoorbeeld traag, middelsnel en snel). De meeste toestellen beschikken over een of meerdere kleurenwielen. Een kleurenwiel bevat in de meeste gevallen een aantal slots waarin kleurenfilters kunnen worden geplaatst. Het bereik van de DMX waarden wordt opgedeeld in een aantal intervallen. Elk van de intervallen stemt overeen met een bepaalde positie van het kleurenwiel. Om het kleurenwiel op de gewenste positie in te stellen, moet een waarde worden ingesteld die deel uitmaakt van het overeenkomstige interval. Sommige fixtures reserveren ook een aantal intervallen voor speciale functies. Bijvoorbeeld het kleurenwiel in wijzerzin roteren. Een andere mogelijkheid bestaat erin dat de fixture over een volledig systeem beschikt om kleuren te mengen. Dit wordt gerealiseerd door drie kleurenwielen achtereen te plaatsen, die meestal de hoofdkleuren cyaan, magenta en geel (CMY) zijn. Elk kleurenwiel wordt dan aangestuurd een DMX kanaal, dat dan meer of minder van de betreffende kleur in het mengsel brengt. Aanvullend kan er ook nog een vierde wiel toegevoegd zijn die de kleurtemperatuur van het witte licht aanpast. De laatste twee uitvoeringen komen voor bij de duurdere fixtures. Een washlight zal steeds over een CMY systeem beschikken. (De washlight uitvoering van een bepaalde fixture is dan typisch ook duurder dan de spot uitvoering.) Een laatste mogelijkheid voor het realiseren van een kleursysteem wordt gebruikt in moderne fixtures op basis van LED’s. Deze fixtures hebben grote aantallen LED’s die rood, groen of blauw zijn gekleurd. Een kleurenmengsel wordt dan bekomen door het rood, groen en blauw kanaal de gepaste intensiteit te geven. Een gobo is een metalen schijf waarin uitsparingen zijn geslepen die een figuur vormen. Wanneer deze schijfjes in de stralengang worden geplaatst, worden bepaalde delen van de lichtbundel geblokkeerd, zodat er een figuur wordt geprojecteerd. De duurdere toestellen hebben ook de mogelijkheid om deze gobo’s te laten roteren, of te indexeren. Het indexeren houdt in dat de rotatie wordt gecorrigeerd en vast blijft, terwijl rotatie de gobo continu laat ronddraaien. Indexering is bijvoorbeeld nuttig wan18
neer de gobo een bedrijfslogo is, waarvan een onderschrift zo gedraaid wordt dat het rechtop staat voor een toeschouwer. De keuze van de gobo, de rotatie en de indexering wordt meestal met twee kanalen gerealiseerd, waarbij rotatie en indexering hetzelfde kanaal delen. Bij functies kunnen immers niet samen voorkomen. Hierbij zou bijvoorbeeld het kanaal kunnen worden opgesplitst in 4 intervallen: een voor rotatie in wijzerzin (de waarde bepaalt dan de snelheid), een voor rotatie in tegenwijzerzin (idem), een voor positieve indexering (tegenwijzerzin), en een voor negatieve indexering (wijzerzin). Een derde kanaal wordt soms ook toegewezen aan de gobo shake, waarbij de gobo met een instelbare snelheid op een neer beweegt. Hoe al deze functies juist aan de kanalen worden toegewezen, verschilt sterk van fabrikant tot fabrikant.
Figuur 8 Voorbeeld van een gobowiel. (Astuces-pratiques, 2011)
De iris heeft een gelijkaardige functie als deze in het menselijk oog. Hij zal ervoor zorgen dat de lichtbundel smaller wordt. Hierbij kan het voorvallen dat er een stuk van een gobo wordt afgesneden. Hiervoor wordt meestal één kanaal gereserveerd. Het is nuttig om op te merken dat er een deel van de lichtintensiteit verloren gaat, doordat de lichtbundel afgesneden wordt. Het prisma zorgt ervoor dat de stralenbundel in meerdere bundels wordt opgesplitst. Typisch zijn dit drie bundels. Elk van de bundels die hierdoor ontstaan hebben dezelfde eigenschappen als de oorspronkelijke bundel, afgezien van de intensiteit die door het splitsen verminderd. Meestal kan deze prisma ook roteren. Dit heeft het effect dat de individuele projecties ontstaan door het splitsen van de bundel een revolutie uitvoeren rond een gemeenschappelijk punt. Pan is de rotatie rond de verticale as, tilt is de rotatie rond de horizontale as. De focus bepaalt de scherpte van de projectie. De zoom maakt de projectie groter of kleiner. In tegenstelling tot de iris, gaat er hierbij geen intensiteit verloren.
19
2.4 Sturingen De markt voor lichtsturingen is al even divers als de markt voor de eigenlijke fixtures. Sommige sturingen zijn heel goedkoop, maar zeer beperkt in mogelijkheden. Andere sturingen zijn zeer complex, maar flexibel en hebben veel mogelijkheden.
2.4.1 Het programmeren van lichtshows De basis van elke stuurtafel is dezelfde. De programmeur zal steeds een bepaalde look creëren door de verschillende attributen van de beschikbare fixtures in te stellen. Daarna worden alle waarden opgeslagen in wat men meestal een scene noemt. Deze scenes kunnen worden gecombineerd in een chase. Een chase is een getimede opeenvolging van scenes. Bij het afspelen van een chase zijn er twee timings van belang: de scene time en de fade time. De scene time bepaalt hoelang de scene wordt afgespeeld, terwijl de fade time bepaalt hoelang een geleidelijke overgang naar de volgende scene mag duren. Sommige begrippen worden door bepaalde fabrikanten anders benoemd. Zo wordt in de documentatie van de fabrikant Avolites een scene een cue genoemd, terwijl de fabrikant Martin een lijst van chases bedoelt met deze term. Er zijn nog wel meer verschillen. Dit maakt de communicatie tussen mensen die andere merken gewoon zijn soms wat onduidelijk.
2.4.2 Het gebruik van shapes Shapes zijn een manier om snel een dynamische look te maken, zonder dat er daarvoor individuele scenes moeten worden geprogrammeerd. Dit gebeurt door de waarde van bepaalde attributen te laten veranderen volgens een bepaalde wiskundige vergelijking.
20
Figuur 9 voorbeeld van een shape generator.
Figuur 9 toont een voorbeeld van een shape generator. Het voorbeeld werd specifiek ontworpen voor bewegingsshapes. Dit hoeft echter niet het geval zijn. In principe kan elk attribuut door een shape worden aangestuurd, alhoewel niet elk attribuut zich daartoe leent. In dit voorbeeld wordt de beweging rond de horizontale as (tilt) en de beweging rond de verticale as (pan) aangestuurd. We bekijken de belangrijkste componenten: •
De selectie van de shape (1). In dit voorbeeld zijn er een aantal vaste shapes beschikbaar. In het voorbeeld werd een ellips gekozen. Dit komt erop neer dat de waarden van de horizontale beweging en verticale beweging respectievelijk zullen evolueren volgens een cosinus en sinus functie.
•
De amplitude van het pan en tiltkanaal kan individueel worden ingesteld. (3)
•
De periode van de beweging kan ook worden ingesteld. (4)
•
De zin van de beweging (wijzerzin, tegenwijzerzin) kan worden gekozen. (5)
•
Op de grafische voorstelling van de shape (2) zijn een aantal verschillende punten te zien. Dit zijn de waarden van de attributen van de individuele fixtures. Dit effect wordt bekomen door een faseverschuiving toe te voegen die groter wordt bij stijgend fixturenummer. Dit heeft als gevolg dat de bewegingen van de individuele toestellen op elkaar zullen na-ijlen. Als n (in het voorbeel is n=4) het aantal fixtures voorstelt en i het fixturenummer. Dan is de faseverschuiving van elke fixture gelijk aan: i*(360°/n)
In het voorbeeld worden er twee kanalen aangestuurd door dezelfde shape. Sommige attributen beslaan slechts een enkel kanaal. Attributen die door twee kanalen worden aangestuurd om een grotere resolutie te bekomen zijn equivalent aan enkelvoudige kanalen.
2.5 Het gebruik van visualisatiesoftware Omdat het voor een designer of operator niet mogelijk is om over de volledige installatie te beschikken bij het voorbereiden van de show, werden er visualisatieprogramma’s ontwikkeld. Deze software geeft de gebruiker de mogelijkheid om in een virtuele driedimensionale omgeving de installatie weer te geven en aan te sturen. De console kan worden aangesloten op een PC die de software draait. De software ontvangt dan signalen van de console, en geeft deze weer in de virtuele omgeving.
21
Naast de functie van visualisatie, ondersteunt deze software meestal ook de mogelijkheid om een volledig lichtplan op te stellen, alsook het genereren van rapporten van de gebruikte materialen. In deze masterproef wordt voor testdoeleinden gebruik gemaakt van de visualisatiesoftware wysiwyg r22 van de fabrikant Cast Software.
22
Hoofdstuk 3 gieën
Gebruikte technolo-
3.1 Java Architecture For XML Binding Omdat de gebruiker zijn werk zou kunnen bewaren, is er nood aan gegevensopslag. In Java kan de ingebouwde serialisatie gebruikt worden. Dit heeft echter het nadeel dat de opgeslagen gegevens in een gesloten formaat worden opgeslagen. De opgeslagen bestanden kunnen dan niet met de hand worden bewerkt, en andere applicaties kunnen moeilijker met deze bestanden overweg. Een voordeel is dat het op deze manier weinig inspanning kost om de gegevens van de toepassing persistent te maken. Een alternatief bestaat in het gebruik van XML-bestanden, waarbij de data wordt voorgesteld in tekstformaat, en door een zelf opgestelde XML taal wordt gemarkeerd. Om met deze bestanden kunnen om te gaan bestaan er eveneens een aantal alternatieven: DOM1, SAX2 en JAXB3. De eerste twee zijn raamwerken voor het ontwikkelen van software die instaat voor het parsen van de XML-bestanden. Dit is zeer arbeidsintensief, en heeft bovendien het nadeel dat een wijziging in de structuur van de XML bestanden, ook een wijziging in de code impliceert. JAXB heeft de voordelen van ingebouwde serialisatie, zonder de nadelen van DOM en SAX. Deze architectuur gebruiken is eenvoudig en heeft het bijkomende voordeel dat wijzigingen in de structuur van de XML-bestanden niet volledig moeten worden opgevangen door de programmeur. Wanneer JAXB wordt gebruikt, moet men er wel rekening mee houden dat de klassenstructuur die ontstaat niet altijd even gebruiksvriendelijk is, en soms erg kunstmatig kan zijn. Verder zijn de mogelijkheden wat betreft polymorfisme en overerving vrij beperkt. Deze nadelen komen tot uiting wanneer de opslag van de tijdsgegevens worden besproken. Omdat JAXB een relatief onbekende technologie is, wordt deze kort bestproken.
1
Document Object Model
2
Simple API for XML
3
Java Architecture for XML Binding
23
3.1.1 Inleiding tot JAXB Zoals eerder vermeld biedt JAXB de mogelijkheid om data te serializeren naar XML formaat. Dit wordt gerealiseerd door Java objecten te binden aan dit XML bestand. In de context van JAXB spreekt men van marshalling en unmarshalling. Deze termen beduiden respectievelijk het opstellen van XML bestanden op basis van de inhoud van een Java-object, en het invullen van Java-objecten met data uit XML bestanden. Om een beter inzicht te krijgen in de werking van JAXB, wordt eerst de architectuur kort besproken.
3.1.1.1 De JAXB architectuur Figuur 10 toont een overzicht van de componenten van JAXB en hun onderlinge samenhang.
Figuur 10 De JAXB Architectuur (Oracle Docs)
De basis van de JAXB architectuur is het XML schema. In principe is dit de enige code die door de programmeur moet worden aangemaakt. Het XML schema bevat de beschrijving van alle klassen die worden gebruikt door het raamwerk. Dit is een groot voordeel ten opzichte van DOM en SAX. Indien men in beide technologieën wil afdwingen dat het XML-bestand conform een bepaald schema is, moet dit schema supplementair, naast de code van de parser, worden opgesteld. Indien een ongeldig XMLbestand niet wordt gevalideerd, zullen er fouten optreden tijdens het parsen van het document. Door het XML-bestand op voorhand te valideren, heeft men de zekerheid dat het parsen correct zal worden uitgevoerd. Het schema wordt samen met eventuele verfijningen verwerkt door de binding compiler. Deze compiler zet het XML schema om in javabronbestanden, die kunnen worden gebruikt in de applicatie. In deze bestanden komen de klassen die de objecten van het XML schema voorstellen. Deze klassen verschillen van gewone klassen, doordat met behulp van annotaties de relatie tussen de XMLbestanden en de klasse wordt gelegd. Het is dus ook mogelijk om van een bestaande javaklasse te vertrekken, en deze aan te vullen met annotaties, zodat deze door het JAXB framework kan worden gebruikt. Naast de eigenlijke klassen wordt ook een objectFactory gegenereerd. Het is de bedoeling dat deze fabriek wordt gebruikt om objecten van de gegenereerde klassen te instantiëren.
24
Om de compiler ertoe te bewegen om klassen te genereren met betekenisvolle eigenschappen, kan er gebruik gemaakt worden van annotaties in het XML schema. Zo kan de compiler er bijvoorbeeld toe bewogen worden om een door de gebruiker opgegeven klassenaam te gebruiken voor een bepaald XML-type, in plaats van de naam van het XML-type zelf. Als alternatief op deze werkwijze bestaat de mogelijkheid om van een bestaande klassenhiërarchie een schema op te stellen, en de klassen zelf manueel te annoteren. Eventueel kan de klassenhiërarchie opnieuw gegenereerd worden op basis van het gegenereerde schema. Deze werkwijze is evenwel minder voordelig: een kleine wijziging in de klassedefinitie heeft immers als gevolg dat er manueel in consistentie moet worden voorzien met het schema. Verder is er ook nog een groot inzicht nodig in de werking van JAXB. De package java.xml.bind bevat de klassen van de eigenlijke JAXB framework. Deze klassen staan in voor het omzetten van en naar XML. Ze maken gebruik van de annotaties in de gegenereerde bestanden om de binding met XML mogelijk correct uit te voeren.
3.2 Protocollen Doorheen de evolutie van de lichttechniek zijn er verschillende protocollen (of aansluitstandaarden) ontstaan. Elk van deze vertoont een aantal tekortkomingen, die worden opgelost in de opvolger.
3.2.1 0/10V Het 0/10V protocol is de oudste standaard. Het wordt nog zelden gebruikt. Sommige dimmers kunnen hier nog mee omgaan. De werking is zeer eenvoudig: voor elk kanaal dat moet worden aangestuurd, is er een signaal waarvan de spanning de waarde van het kanaal bepaalt. Dit wil meteen ook zeggen dat indien er veel kanalen moeten worden aangestuurd, er ook veel signaallijnen moeten worden voorzien. Dit zorgt ervoor dat de standaard minder schaalbaar is.
3.2.2 DMX DMX staat voor digitally multiplexed. Het is een digitaal serieel protocol waarin de waarden voor verschillende kanalen in de tijd worden gemultiplexed. Dit betekent dat er in theorie slechts een enkel draadpaar nodig om de waarden van een groot aantal kanalen te versturen. Op deze manier is de beperking van het 0/10V protocol meteen opgelost. Een nadeel is dan wel dat er complexere hardware nodig is om het signaal te interpreteren.
3.2.2.1 RS485 De elektrische basis voor DMX is het RS485 serieel protocol. In de fysische laag wordt een kabel met een karakteristieke impedantie van 120Ω gebruikt. De gebruikte connectoren zijn volgens de standaard de XLR 5-pin connector, terwijl in de werkelijkheid veelal de 3-pin variant wordt gebruikt. Dit is een groot voordeel, omdat dit net het type kabel is dat wordt gebruikt als signaallijnen voor audio. Productiefirma’s hebben reeds grote voorraden van dit type kabel, zodat er geen speciale bekabeling moet
25
worden aangeschaft. Het RS485 protocol is analoog aan het welbekende RS232 serieel protocol. Beide protocollen vertonen echter wel een aantal verschillen. We bespreken enkele typische eigenschappen van de standaard aan de hand van deze verschillen. Een communicatie-infrastructuur op basis van RS485 is steeds een bus. Dit wil zeggen dat er op een bepaald ogenblik steeds één toestel kan zenden, en meerdere toestellen kunnen ontvangen. Een tweede verschil is het gebruik van differentiële signalisatie. Dit houdt in dat er twee signaallijnen zijn: een lijn draagt het ongewijzigde signaal, een andere lijn draagt het geïnverteerde signaal. Wanneer nu een storing voorkomt, zal deze op beide lijnen voorkomen met een gelijke polariteit. Door de twee signalen van elkaar af te trekken bekomt men opnieuw het ongestoorde signaal. De derde lijn bevat dan de massa. Tot slot vermelden we ook nog dat RS485 in full duplex mode kan worden gebruikt, door 4 signaallijnen te voorzien. Een paar voor zenden en een paar voor ontvangen. Ook de afstanden waarover het protocol kan worden gebruik zijn een factor 4 groter.
3.2.2.2 DMX Het DMX protocol is simplex. Dit wil zeggen dat er steeds informatie wordt gezonden in een enkele richting. Hierdoor ontstaat ook een onderscheid in de aansluiting voor DMX. Een toestel zal steeds over een ingang en een uitgang beschikken. Om verwarring en aansluitfouten te vermijden, wordt voor een uitgang steeds een vrouwelijke variant van de XLR connector gebruikt. Voor een ingang wordt dan uiteraard de mannelijke variant gebruikt. Uit het vorige volgt dat de RS485 standaard enkel elektrische specificaties oplegt. Het eigenlijke communicatieprotocol dat wordt gebruikt op de bus wordt overgelaten aan de hogere lagen. De specificatie van het communicatieprotocol zit vervat in het DMX protocol, ontworpen door USITT. In wat volgt, worden deze specificatie beknopt besproken. Eerder werd aangehaald dat het onderliggende RS485 protocol een busconfiguratie is. Dit principe is ook zichtbaar in de verantwoordelijkheden van de toestellen. Zo zullen de fixtures steeds de rol van slaves op de bus vervullen, terwijl de console steeds de functie van master vervult. Indien er meerdere consoles op een bus worden aangesloten, moet er gebruik worden gemaakt van een multiplexer. Dit apparaat zorgt voor een elementaire vorm van arbitrage tussen de verschillende masters. Functioneel gezien vervult de multiplexer dan de rol van zowel master als slave. Hij zal slave zijn op elk van de bussen waarop een console is aangesloten, en master op de bus waarop de fixtures zijn aangesloten. Op een enkele bus kunnen tot 32 apparaten worden aangesloten. Het DMX protocol bepaalt de tijdstippen waarop er signaaltransities moeten gebeuren om de binaire waarden door te sturen. De detectie van de bits gebeurt op basis van het spanningsverschil tussen de twee signaalparen. Indien dit verschil gedurende 4µs lang positief is, wordt een 1 gedetecteerd. Wanneer het verschil gedurende 4µs lang negatief is, wordt een 0 gedetecteerd. Een byte data wordt steeds voorafgegaan door een nulbit, en wordt afgesloten door twee eenbits. Aan het begin van elke reeks data wordt een startbyte verzonden. In de huidige standaard is deze steeds nul, maar de startbyte is 26
aanwezig voor eventuele toekomstige uitbereidingen. Er worden maximaal 512 bytes na elkaar verstuurd. Elk van deze bytes stelt de waarde van een van de 512 digitale (gemultiplexte) kanalen voor. Een groep van 512 kanalen wordt een universe genoemd, en wordt meestal met een letter aangeduid. Er is vastgelegd dat over een enkele DMX lijn, maximaal 512 kanalen of een enkel universe wordt verstuurd. Indien deze adresruimte te klein is, moeten er meerdere parallelle universes worden gebruikt, verstuurd over verschillende fysieke lijnen.
3.2.3 Art-Net Protocollen zoals Art-Net zijn in staat om DMX data van meerdere universes over een enkel fysiek medium te versturen, zoals bijvoorbeeld een glasvezelkabel. Dit is zeer nuttig bij toepassingen zoals videoschermen, waarbij de benodigde adresruimte zeer groot is Het protocol is ontworpen om DMX data te transporteren over UDP. Als onderliggende protocollen worden IP en ethernet gebruikt. In de fysieke laag wordt meestal UTP of glasvezelkabel gebruikt. Het Art-Net protocol geeft ook richtlijnen op aan het toekennen van IPv4 adressen. Kort samengevat komt het er op neer dat er steeds klasse A adressen moeten worden gebruikt, in de subnetwerken 10/8 of 2/8. Elke adresruimte heeft een speciale betekenis, waarop we niet dieper ingaan. In de praktijk blijken deze beperkingen minder relevant te zijn. Het protocol kan werken met eender welk adres. Het is zowel mogelijk om berichten als unicast of als broadcast te versturen. Art-Net voorziet in verschillende berichttypes. Het protocol kan nog veel meer dan enkel het transporteren van DMX data. Het bericht met de naam ArtDmx is echter wel het belangrijkste. Dit bericht staat in voor de transport van DMX data. Er zijn weinig fixtures die rechtstreeks Art-Net kunnen interpreteren. Daarom wordt er gebruik gemaakt van network signal processors. Deze toestellen ontvangen Art-Net, en sturen de afzonderlijke universes terug uit over klassieke DMX bekabeling.
3.2.4 Proprietaire protocollen Sommige fabrikanten houden er de slechte gewoonte op na om een eigen protocol te ontwikkelen. Sommige van deze proprietaire protocollen zijn compatibel met DMX, de meesten echter niet. Dit maakt dat de betreffende toestellen niet kunnen worden opgenomen in het netwerk van andere toestellen, en bijgevolg ook apart moeten worden aangestuurd.
27
Hoofdstuk 4
Dongles
4.1 Commerciele dongles en software Een DMX dongle is een apparaat dat een PC in staat stelt om DMX te versturen. Tegenwoordig worden deze meestal via USB aangesloten. In de meeste gevallen levert de fabrikant samen met de dongle zijn eigen software, en kan de dongle ook enkel met de software van de fabrikant worden gebruikt. Meestal is de software gratis beschikbaar, en worden de kosten voor ontwikkeling van de software terugverdiend door de verkoop van de dongles. Prijzen van enkele honderden euro’s zijn hierbij geen uitzondering. Er bestaan ook een aantal universele dongles. Deze dongles worden zonder gebruikerssoftware gebruikt, maar beschikken wel over een API die door de programmeur kan worden gebruikt om zijn eigen software te ontwikkelen. Deze dongles zijn nog steeds relatief duur, en zijn bovendien niet steeds bruikbaar op elk besturingssysteem. Kostprijzen liggen tussen €70 en €150.
4.2 Dongle op basis van de Arduino microcontroller Om de prijs te drukken, zal in deze masterproef een Arduino microcontroller worden gebruikt als onderdeel van een DMX dongle, samen met enkele andere componenten. Deze methode heeft bovendien het voordeel dat ze compatibel is met een breed spectrum aan besturingsystemen. Van zodra een besturingssysteem RS232 ondersteunt is deze methode in principe bruikbaar. We geven een klein overzicht van de benodigde hardware, en de prijs.
28
Arduino UNO microcontroller
€24,95
MAX485 IC
€2,60
Weerstand 100Ω
€0,10
3-pin XLR female Connector
€3,50 €31,15
4.2.1 De Arduino microcontroller Arduino is een open hardware platform dat de samenstelling van een microcontroller op basis van een Atmell ATmega processor beschrijft. De gebruiker kan zelf zijn microcontroller assembleren, of een voorgeassembleerde microcontroller kopen.
Figuur 11 De arduino UNO microcontroller. (Arduino)
Er zijn verschillende uitvoeringen van dit platform in omloop. Dit project gebruikt de Arduino UNO uitvoering, gebaseerd op de atmega328P-PU, met een klokfrequentie van 16MHz. De microcontroller heeft 14 digitale IO-poorten, 6 analoge inputs en een RS232 transceiver. De Arduino wordt met een computer wordt verbonden, via USB. De Arduino doet zich dan voor als een virtuele COM poort. Deze virtuele poort kan in een Arduino programma worden gebruikt voor communicatie met externe apparaten. De microcontroller kan zowel worden gevoed door de USB-bus, 29
als door een externe voeding. Zoals veel andere microcontrollers, kan de Arduino worden geprogrammeerd in C++. Hiervoor wordt een IDE meegeleverd, waarin de gebruiker zijn programma’s kan ontwikkelen.
4.2.1.1 Een arduino programma Zoals alle microcontrollers voert de Arduino steeds een aantal instructies uit in een oneindige lus. Programma’s voor controllers, die meestal in assembleertaal worden geschreven, vallen typisch uiteen in twee delen: een setup deel, waarin de inwendige apparaten correct worden ingesteld en de nodige registers worden geïnitialiseerd en het hoofdprogramma. De eerste instructie van het hoofdprogramma wordt voorafgegaan door een label. Aan het einde van het hoofdprogramma wordt dan teruggesprongen naar dit label. Op het Arduino platform wordt deze werkmethode vertaald door het invullen van twee C++ routines: de setup() routine en de loop() routine. De setup() routine wordt bij het opstarten van de microcontroller eenmalig aangeroepen, de loop() routine wordt herhaaldelijk uitgevoerd tot de controller wordt gereset. Een voorbeeld van een dergelijk programma volgt in §4.2.2.2.
4.2.2 De Arduino als DMX dongle Om de Arduino als DMX dongle te gebruiken moeten er twee taken volbracht worden. In eerste instantie moet er een schakeling worden gebouwd om de RS485 signalen te versturen. Ten tweede moet er een programma worden ontwikkeld die de gegevens afkomstig van de PC vertaalt naar de gepaste output om de RS485 driver aan te sturen.
4.2.2.1 De schakeling Om de Arduino te gebruiken om via een PC DMX data te versturen, zijn er nog enkele andere componenten nodig. Deze componenten werden eerder opgelijst in paragraaf 4.2. Het basisidee bestaat erin om de Arduino aan te sluiten op een RS485 driver Block, en de outputs van deze driver te verbinden met een XLR connector.
Figuur 12 Aansluitschema voor de MAX485/SN75176. (Sending DMX with the arduino, T. Ness & D. Cuartielles, 2006)
30
Figuur 12 toont een schematisch overzicht van de aansluitingen die moeten worden gemaakt om de arduino microcontroller te verbinden met de MAX485 IC: In het linkerdeel (a) is een schematische weergave te zien van de MAX485 IC. Deze heeft in totaal acht pinnen, genummerd van 1 tot 8. De weerstand verbonden met pin 1 heeft een waarde van 100 ohm. Pin 4 van de IC wordt verbonden met één van de digitale poorten van de microcontroller. Op de figuur is deze aangeduid als input. De nummers aangeduid als “DMX Outputs” verwijzen naar de nummers van de vrouwelijke XLR connector (b). Pin 5 van de IC wordt verbonden met pin 1 (de massa) van de connector. Pinnen 6 en 7 worden respectievelijk verbonden met pinnen 3 en 2 van de XLR connector. Figuur 13 toont een prototype van het afgewerkte product.
Figuur 13 De arduino dongle op een breadboard.
4.2.2.2 Het programma voor de microcontroller De verantwoordelijkheid van de arduino in de schakeling valt uiteen in twee delen. In eerste instantie moet hij opdrachten van de PC ontvangen en interpreteren. De PC zal enkel wijzigingen in de waarden doorgeven naar de microcontroller. In tweede instantie moet hij periodiek de DMX waarden uitsturen via zijn digitale outputpoorten naar de MAX485 IC die de spanningen op het aderpaar van de DMX lijn zal onderhouden. Om de opdracht van de PC te ontvangen, zullen we de arduino zo programmeren dat hij telkens drie bytes achter elkaar uitleest van het serieel kanaal. De eerste twee bytes stellen het adres voor, het laatste byte stelt dan de eigenlijke waarde voor. De arduino wacht in een lus, zolang er geen data klaar staat in de invoerbuffer. Voor het verzenden van de DMX wordt de DMX simple bibliotheek gebruikt. Deze bibliotheek verzorgt in het onderhoud van het signaal op de gekozen digitale output. (standaard pin 3). Er moeten enkel wijzigingen worden doorgegeven, door de methode write() aan te roepen van deze klasse. #include
void setup(){ Serial.begin(9600); } void loop(){ while(!Serial.available());
31
int adressLSB = Serial.read(); while(adressLSB < 0) adressLSB = Serial.read(); int adressMSB = Serial.read(); while(adressMSB < 0) adressMSB = Serial.read(); int value = Serial.read(); while(value < 0) value = Serial.read(); DmxSimple.write(adressMSB * 256 + adressLSB, value); }
4.2.2.3 De dongle aansturen via een PC toestel Het onderstaand voorbeeld toont hoe de Arduino kan worden aangestuurd. Om gebruik te maken van de seriële poort van de computer, gebruiken we de GNU rxtx api. Deze wordt ook meegeleverd met de IDE die bij de Arduino hoort. public void testArduino() { CommPortIdentifier portIdentifier = null; Enumeration portEnum = commPortIdentifier.getPortIdentifiers();
In de volgende lus worden alle beschikbare seriële poorten overlopen. In dit geval heeft de virtuele seriële poort van de Arduino als naam “COM7”. while (portEnum.hasMoreElements()) { CommPortIdentifier currentPortIdentifier = (CommPortIdentifier) portEnum.nextElement(); if (currentPortIdentifier.getName().equals("COM7")) { portIdentifier = currentPortIdentifier; break; } } try { serialPort = (SerialPort) portIdentifier.open("JavaSerialTest", TIMEOUT);
De volgende aanroep stelt de parameters van seriële poort in: de baudrate, het aantal databits, het aantal stopbits en de pariteit. serialPort.setSerialPortParams( BAUDRATE, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); output = serialPort.getOutputStream();
In de buitenste lus worden elk van de 256 (0 tot 255) DMX waarden overlopen. Met een vertraging van 50ms. De binnenste lus schrijft de waarde weg naar de eerste 3 kanalen. Hiertoe stellen we een byte array op met lengte drie die achtereenvolgens het MSB en LSB van het adres bevat en de waarde.
32
for (int i = 0; i < 256; i++) { for (int channel = 1; channel <= 3; channel++) { byte[] v = new byte[3]; v[0] = (byte) (channel % 256); v[1] = (byte) (channel / 256); v[2] = (byte) i; output.write(v); } Thread.sleep(50); } serialPort.close(); } //excepties opvangen
Ook een andere microcontroller kan worden gebruikt voor deze toepassing. Er wordt wel nog op gewezen dat, indien er geen software bibliotheek beschikbaar is, de programmeur zelf moet voorzien in de code voor het uitsturen van het DMX protocol.
33
Hoofdstuk 5 tuur
De software architec-
De software die moet worden ontwikkeld valt uiteen in twee deelcomponenten. Enerzijds moet er code worden geschreven die voorziet in het aansturen van de DMX apparatuur. Anderzijds moeten er voorzieningen worden getroffen om de gebruiker toe te staan om shows te programmeren. Er wordt hierbij aandacht besteed aan de modellering van de tijdsaspecten.
5.1 Besturing van de DMX512 apparatuur: de interface IDongle Het sleutelobject in het versturen van DMX512 apparatuur, is het object die de hardware dongle zal aansturen. De interface van deze klasse van objecten is de volgende:
Figuur 14 De interface IDongle
De eerste twee methoden laten toe om de waarde van een bepaald kanaal te wijzigen. Het verschil tussen beiden is of de waarde enkel in de interne toestand van het object wordt gewijzigd, of ook meteen wordt doorgestuurd naar de dongle. De methode refresh zorgt ervoor dat de interne toestand via de dongle naar buiten wordt gebracht. De methode initZero initialiseert alle kanalen op nul. Klassen die dongles voorstellen moeten deze interface implementeren. Deze abstractie wordt gemaakt om de software implementatie los te koppelen van de eigenlijke sturing van de hardware. Zo is er bijvoorbeeld de mogelijkheid om gebruik te maken van een Arduino dongle, als van Art-Net op eenzelfde uniforme manier. De rest van de software hoeft niet op de hoogte te zijn van de onderliggende implementatie. Deze twee mogelijke implementaties zijn voorzien.
34
5.2 Modellering van een toestel Figuur 15 toont het overzicht van het model van een toestel. Hierbij wordt enkel de essentie weergegeven. De constructie van deze objecten verloopt op een speciale manier, en wordt op zich besproken.
Figuur 15 Overzichtsdiagram van fixtures
5.2.1 De klasse Fixture Objecten van de klasse Fixture stellen een toestel voor. Deze klasse is generiek, en hangt niet af van het concrete toestel dat wordt voorgesteld. De toestand van de klasse bestaat uit de naam van het toestel, en een DMX startadres. De klasse heeft een map die namen van features afbeeldt op de features zelf. In een later stadium wordt besproken hoe deze klassen dynamisch worden aangemaakt op basis van een configuratiebestand: de personality van een specifieke fixture. Dit is een bestand die alle specifieke attributen bepaalt, en de ligging in de adresruimte. In een ander configuratiebestand zal de gebruiker kunnen aangeven welke fixtures hij wenst te gebruiken voor zijn show. Op basis van dit configuratiebestand worden dan de juiste personalities opgehaald, en de fixture objecten correct ingevuld.
35
5.2.2 De klasse Feature De klasse Feature stelt een aan te sturen attribuut voor van een fixture. Voorbeelden zijn: dimmer, iris of positie. De waarde van een Feature wordt in procenten uitgedrukt. Deze keuze werd gemaakt, omdat er dan een uniforme benadering is voor alle features, ongeacht het aantal kanalen dat ze bestrijken. Features worden in twee soorten opgedeeld: continue features en discrete features. Continue features kunnen elke mogelijke waarde krijgen tussen 0 en 1. Discrete features kunnen slechts waarden toegekend krijgen uit een beperkte verzameling. Er zijn methoden voorzien om de inhoud van deze verzameling aan te passen. Het veld shapeValue bevat de waarde van een shape. De functie van deze waarde wordt in een later stadium toegelicht. De uiteindelijke waarde van de feature bestaat uit twee delen: een constante waarde bijgehouden door het veld value en een variabele waarde bijgehouden in het veld shapeValue. De uiteindelijke waarde bestaat uit de som van beiden. De methode applyValues wordt gebuikt om de wijzigingen door te voeren naar de onderliggende aspecten.
5.2.3 De klassen SimpleAspect en DiscreteAspect De klassen SimpleAspect en DiscreteAspect stellen elk een enkelvoudig DMX kanaal of een groep van kanalen voor, die elk verbonden zijn met een attribuut van de fixture. De klasse SimpleAspect stelt een kanaalgroep voor die wordt verbonden aan een continu attribuut (zoals bijvoorbeeld een dimmer). De tabel channelOffsets bevat de relatieve offsets ten opzicht van het fixture adres. Om de absolute adressen van de kanalen te bekomen, wordt de methode getAbsoluluteAdresses gebruikt. Deze methode vereist dat het veld containingFixture ingevuld is. Indien deze methode wordt aangeroepen zonder dat dit veld is gezet, wordt een ContainingFixtureNotSetException opgeworpen. Deze eigenschap moet worden ingevuld omdat een Aspect enkel zijn relatieve offset kent. Het fixture object waarvan het aspect deel uitmaakt bevat het startadres. Het absolute adres van de feature wordt dan bekomen door de som van relatieve offset en absoluut fixture adres te nemen. De methode getBytes geeft de waarde van het aspect uitgedrukt in bytes. Het mechanisme dat wordt gebruikt voor het updaten van de wijzigingen van de waarden van de aspecten is een implementatie van het observer patroon. Aan elk aspect wordt één of meerdere observers gekoppeld, die de interface IAspectObserver implementeren. Wanneer de waarde van het aspect wordt wijzigt, wordt de methode notifyObservers aangeroepen. Het is de verantwoordelijkheid van de observers om zelf de wijzigingen op te halen en te verwerken. Een voorbeeld van een IAspec36
tObserver kan bijvoorbeeld rechtstreeks een dongle-object zijn.
De klasse DiscreteAspect stelt een aspect van het toestel voor dat enkel waarden kan aannemen uit een beperkte verzameling. Ze is afgeleid van de klasse SimpleAspect en voegt een aantal methodes en beperkingen toe. De hashmap allowedValues beeldt namen van toegestane waarden af op de eigenlijke waarden. Wanneer een ongeldige naam wordt aangevraagd, wordt een InvalidValueRequestException opgeworpen.
5.2.4 Het instantiëren van Fixture objecten Omdat de eigenschappen van toestellen niet vastgelegd mogen worden in de software, werd er een mechanisme geïmplementeerd, dat instaat voor het opvullen van Fixture objecten op basis van de gegevens in een configuratiebestand. De sleutelklassen in dit mechanisme zijn de klassen FixtureBuilder, FixtureConfiguration en FixturePersonality. In de volgende paragrafen worden de eigenschappen van deze klassen besproken die relevant zijn voor het mechanisme.
5.2.4.1 De klasse FixtureBuilder Deze klasse wordt gebruikt om objecten van de klasse Fixture te instantiëren op basis van een gegeven FixturePersonality.
Figuur 16 De klasse FixtureBuilder
Het startadres van de aan te maken fixture wordt meegegeven, samen met een AspectObserver. Dit object zal luisteren naar de verandering van de waarden van de aspecten die deel uitmaken van de fixture.
5.2.4.2 De klasse FixtureConfiguration De klasse FixtureConfiguration bevat de globale configuratie van alle fixtures die aanwezig zijn in de show. Deze fixtures zijn opgenomen in containers van de klasse FixtureGroup, die een wrapper class is voor een arraylist.
37
Figuur 17 De klasse FixtureConfiguration
De FixtureGroupMap ten slotte, bevat een afbeelding van de groepsnamen op de groepen.
5.2.4.3 De klasse FixturePersonality Deze klasse stelt een verzameling van eigenschappen van een fixture voor, vertolkt door de eigenschap featureMap. Deze map beeldt de namen van de features af op de feature-objecten.
Figuur 18 De klasse FixturePersonality
Verder krijgt elke personality nog een naam, en is het mogelijk om het totaal aantal kanalen van het volledige profiel op te vragen.
5.3 Modellering van shapes Een shape is een snelle en eenvoudige manier om voor de eindgebruiker een beweging te programmeren.
5.3.1 De klasse BasicShape De basis is een eenvoudige shape, die een enkele waarde produceert, en voorts enkel afhangt van de tijd. Algemeen wordt een shape voorgesteld als een functie van de tijd en een constant faseverschil. Dit wordt vertolkt door het feit dat een shape-klasse die wordt afgeleid van de klasse BasicShape verplicht is om de methode func te overschrijven. Om dit af te dwingen is de klasse abstract. Deze methode wordt opgeroepen om, bij het verlopen van de timer, een nieuwe waarde te berekenen. Deze waarde wordt dan ook meteen ingesteld bij de subjectFeature van de shape.
38
Figuur 19 De klasse BasicShape
Om de timing bij te houden wordt een Java Swing Timer gebruikt. Het interval van deze timer wordt ingesteld op de constante waarde UPDATE_PERIOD. Bij het verlopen van de timer wordt de tijdswaarde t verhoogd met de waarde tickValue. De waarde t stelt de globale tijdsvariabele voor. De tickValue wordt gebruikt om de waarde van de shape te bepalen.
5.3.2 Een voorbeeldimplementatie van een shape: de SwingShape Om te verduidelijken hoe de software kan worden uitgebreid met bijkomende shapes wordt het belangrijkste deel van de implementatie van de klasse SwingShape als voorbeeld bekeken. public class SwingShape extends BasicShape{ private double size = 0.5d; private double speed = 2*Math.PI; @Override public double func(double t, double phi) { double frequency = 1 / speed; return size * Math.sin((2*Math.PI*frequency *t) + getDeltaPhi()); } }
De functie gebruikt een sinus, waarbij de hoek de som is van een tijdsafhankelijke term en de waarde van het veld deltaPhi uit de bovenklasse.
5.3.3 De klasse ShapeConfiguration De klasse ShapeConfiguration bevat een globale lijst van shapes die aan de gebruiker ter beschikking kunnen worden gesteld.
5.3.4 De klasse ShapeFactory Het is de verantwoordelijkheid van een de ShapeFactory om objecten van de klasse Shape te in39
stantiëren.
5.3.5 De klasse ShapeGroup De klasse ShapeGroup is een container die een of meerdere shapes kan bevatten. Deze klasse maakt het mogelijk om een aantal eigenschappen van een collectie shapes tegelijk in te stellen.
Figuur 20 De klasse ShapeGroup
De lijst members bevat alle leden van de groep. De methoden van de klasse maken het mogelijk om een aantal eigenschappen toe te passen op alle leden van de groep. Om een shape toe te voegen aan de groep, wordt de methode addMember gebruikt. Eender welke klasse die de interface IShape implementeert, kan deel uitmaken van een groep. De waarden van de eigenschappen worden ook lokaal bijgehouden. De methode setSpread kan worden gebruikt om de faseverschuiving van de shape in te stellen. Het onderlinge faseverschil wordt steeds ingesteld als 2 maal pi gedeeld door het aantal fxtures. De eerste shape in de groep krijgt dan nul als fase verschuiving, de volgende twee keer het faseverschil, de derde drie keer het faseverschil enz. De methode shuffle verandert de volgorde van de shapes in de leden. Hierdoor verandert ook de individuele faseverschuiving van de fixtures.
5.4 Hulpklassen 5.4.1 De klasse Pallette De klasse Pallette is een associatieklasse, die als enige functie het bijhouden van de relatie tussen een aantal Feature objecten en hun respectievelijke toe te kennen waarde. De toe te kennen waarde is in dit geval geen echt object, maar een gewone decimale waarde. De objecten van de klasse Pallette worden aangemaakt om de invoer van de gebruiker op te slaan en kunnen uiteindelijk worden ge40
transformeerd tot gebeurtenissen. Dit wordt verder verduidelijkt in §5.5.1.
5.5 Modellering van de tijdsaspecten Om de tijd te modelleren, wordt er een gebeurtenisgebaseerd model gebruikt. Een gebeurtenis is een atomaire handeling, waarbij een waarde wordt toegewezen aan een feature van een toestel. Deze gebeurtenissen worden gegroepeerd in gebeurtenisgroepen. Deze groepjes vormen de kleinste bewerkbare eenheid in de software. Het model is gebaseerd op het composite pattern, waarbij groepen van elementen op dezelfde manier worden behandeld als de atomaire elementen zelf. Concreet wil dit zeggen dat groepen van elementen aan dezelfde interface voldoen. Onderstaand UML-klassendiagram toont de statische structuur van het model. De toepassing van het composite pattern is hierin duidelijk zichtbaar.
«interface» TreeNode
«interface» IEventGroupGenerator +generate() : IEventGroupGenerator
Ouder Kind
AbstractEventGroupGenerator +transform(in : Event) : Event
SequentialGenerator
ScaleYGenerator
ParallelGenerator
EventGroup
-factor : double
ShiftTimeGenerator
ScaleTimeGenerator
-offset : int
-factor : double
1 * Event Feature 1
1
-value : double -time : int -duration : int
41
Figuur 21 Het inwendig tijdsmodel
Een eerste beslissing die moet worden gemaakt, is hoe de structuur van de gebeurtenisgroepen er zal uitzien. Het spreekt voor zich dat een gebeurtenis zich op een bepaald tijdstip zal voordoen. Heeft deze gebeurtenis dan ook een lengte? Met het achterliggende protocol in gedachten, lijkt het vanzelfsprekend dat dit niet het geval is. Immers, het DMX protocol is op zichzelf als gebeurtenisgebaseerd op te vatten, waarbij een gebeurtenis wordt voorgesteld door een wijziging in de waarde van een of meerdere kanalen. Tot zolang er geen zulke wijzigingen optreden, blijft de toestand van het protocol onveranderd. Deze beslissing brengt een volgend probleem: een bepaalde opeenvolging van gebeurtenissen heeft op zich zelf wel een bepaalde duur. Beschouw de situatie waarin twee gebeurtenisgroepen elkaar opvolgen. Bekijk de laatste gebeurtenis van de eerste groep. Deze zal slechts kortstondig actief zijn, omdat de eerste gebeurtenis van de tweede groep onmiddellijk hierna wordt afgevuurd. Dit probleem kan eenvoudig worden verholpen door op de gepaste plaats een lege eindgebeurtenis in te voegen. Deze werkwijze lijdt tot een vrij kunstmatig model. Het is natuurlijker om er voor te kiezen om tegen het onderliggende model in te gaan, en aan de gebeurtenissen toch een tijdsduur toe te kennen. Hierbij ontstaat de vraag wat er moet gebeuren na afloop van een bepaalde gebeurtenis. In principe moeten dan de wijzigingen die bij de aanvang van de gebeurtenis werden aangebracht terug ongedaan worden gemaakt. Echter omdat de volgende gebeurtenis onmiddellijk volgt, en ook onmiddellijk wijzigingen zal toebrengen, wordt ervoor gekozen om het einde te negeren, en de nieuwe toestand te laten bepalen door het begin van de volgende gebeurtenis. Uit Figuur 21 blijkt dat het volledige model een boomstructuur voorstelt. Dit zal ook voordelig blijken om de serialisatie naar XML te implementeren. De structuur van een XML bestand is immers de facto een boomstructuur.
5.5.1 De EventGroup en Event Gebeurtenissen van het DMX protocol worden voorgesteld door objecten van de klasse Event. De klasse bevat de nodige eigenschappen van de gebeurtenis, en een verwijzing naar de Feature waarop de gebeurtenis invloed heeft. De EventGroup is een verzameling van gebeurtenissen. Merk op dat een groep van gebeurtenissen zelf een generator is. Dit wordt duidelijker wanneer het concept van generatoren wordt uitgelegd. De EventGroup stelt een uitwendige knoop van de boom voor, en is zelf een lineaire structuur van events, die zonder meer kunnen worden afgespeeld.
5.5.2 Het concept generators Om de groepen van gebeurtenissen te rangschikken werd het concept generator geïntroduceerd. Een generator is niets meer dan een knoop van de boomstructuur. Er zijn 5 types generators die inwendige knopen voorstellen. Ze verschillen enkel in de manier waarop ze omgaan met hun kinderen. Elke generator zal de gebeurtenissen van zijn kinderen op een bepaalde manier rangschikken door hun tijdstip en/of lengte te wijzigen, of door hun waarde te beïnvloeden. Op deze manier kunnen de gebeurtenis42
groepen worden samengesteld tot nieuwe gebeurtenisgroepen. Er is steeds een enkele generator wortel van de boom. Door de methode generate() aan te roepen, wordt een nieuwe generator aangemaakt. In wezen is dit een object van de klasse EventGroup. Het brengt een aanzienlijke vereenvoudiging toe om deze klasse hier niet bloot te stellen. We kunnen immers EventGroup objecten gewoon zoals andere generators beschouwen. Het resultaat van een generator komt tot stand door de resultaten (die zelf worden bekomen door een recursieve oproep) van de kinderen te combineren volgens een welbepaalde operatie. De naam van de generator komt overeen met de operatie die hij uitvoert. In de grafische interface zal een gebruiker deze generators als knopen van een boom zien. Door combinaties van knopen te maken kan hij uiteindelijk herbruikbare groepen combineren tot een nieuwe sequentie, zodat dubbel werk wordt vermeden. Omdat een deel van de code gemeenschappelijk is in alle generators, werd de klasse AbstractEventGroupGenerator in de hiërarchie ingevoegd. Deze klasse bevat ook de code voor de implementatie van de java TreeNode interface, die werd geïmplementeerd om het gebruik van bepaalde interfacecomponenten te vereenvoudigen. Ook een deel van de code voor het genereren van het resultaat is voor de meeste generators gemeenschappelijk gebleken: indien de generator een gebeurtenis onafhankelijk van de vorige kan transformeren, volstaat het de methode transform() die als hook wordt opgeroepen in generate() te overschrijven. Dit is tevens verplicht (de methode tranform werd final gemaakt.) De rest van de huishouding wordt dan door de bovenklasse verzorgd. Indien individuele transformatie niet mogelijk is, moet eveneens de volledige methode generate worden overschreven.
5.6 Opslag van de gegevens 5.6.1 Gebruik van JAXB voor de implementatie van de fixture bibliotheek en fixture profielen Om ervoor te zorgen dat de eindgebruiker de mogelijkheid heeft om zelf toestellen toe te voegen aan de software, worden de eigenschappen van de toestellen niet hardgecodeerd, maar worden deze opgenomen in een configuratiebestand. Dit configuratiebestand heet de fixturebibliotheek. Het bevat een verzameling van beschrijvingen van toestellen die kunnen worden gebruikt.
5.6.1.1 Namenruimtes Alle elementen in de XML bestanden alsook de schema’s behoren tot de namenruimte http://openlighting.be we korten deze namenruimte af door de alias olg te gebruiken. De structuur van de schema’s die tot deze ruimte behoren stemmen overeen met de structuur van de globale applicatie, en wordt niet meer apart besproken. Er wordt verwezen naar §5.2. Het domein openlighting.be wordt tevens gebruikt als prefix voor de pakketnamen in het Javagedeelte
43
5.6.1.2 Statisch model van de fixturebibliotheek Onderstaand diagram geeft de eigenschappen en relaties weer van de diverse objecten die worden gebruikt om de fixturebibliotheek te realiseren. Dit diagram is een weerspiegeling van het XML schema. De gegevenstypes van de velden, zijn deze die behoren tot de XSD namenruimte.
Figuur 22 UML voorstelling van het XML schema voor de opslag van de fixture library
Ter verduidelijking wordt een beknopt voorbeeld gegeven van het profiel van een toestel in xml:
44
5.6.2 Structuur van de showfile 5.6.2.1 Globaal overzicht van de structuur De showfile bevat alle gegevens over tijdsstructuren, en de configuratie van een belichtingsproject. Ook hier wordt de namenruimte http://openlighting.be/, afgekort door olg gebruikt. Een beknopt overzicht:
Bovenstaand voorbeeld bevat de bovenste structuur en tevens de minimale inhoud van de showfile. Deze bestaat uit een lege toestellijst en groeplijst. Om de configuratie van toestellen te wijzigen, moet dit bestand worden bewerkt.
5.6.2.1.1 De configuratie van de toestellen Met behulp van het element fixturelist beschtijft de gebruiker een lijst van toestellen die hij wenst te gebruiken in zijn project. Voor elk gebruikt toestel wordt een kindelement van het type fixture opgegeven. De attributen id, type en address van dit kindelement duiden respectievelijk op de naam van het toestel, het DMX adres en het type, zoals vermeld in de configuratie van de fixturelibrary. Een eenvoudig voorbeeld: … …
Het element fixturelgrouplist wordt gebruikt om groepen van toestellen te configureren. Voor elke groep wordt een kindelement fixturegroup aangemaakt, het attribuut id. bevat de naam van de groep aan, zoals die in het programma kan worden gebruikt. De leden van een groep worden toegevoegd door aan het groepselement een kindelement van het type member toe te voegen. Dit groepselement heeft een attribuut id, dat refereert naar de naam van een toestel zoals die in het element fixturelist is opgegeven. De toestellen van bovenstaand voorbeeld kunnen in groepen worden ingedeeld:
45
…
5.7 Het uitwendig tijdsmodel Het is niet mogelijk gebleken om op eenvoudige wijze de JAXB binding compiler zodanig te sturen dat die een overervingshiërarchie produceert die bruikbaar is voor de interne structuur van de software. Om de eenvoud te bewaren, werd ervoor gekozen om twee structuren te behouden. Enerzijds is er het eerder besproken inwendig tijdsmodel, anderzijds is er het uitwendig tijdsmodel. Bij serialisatie en deserialisatie wordt er voor de vertaling tussen de twee modellen gezorgd. Het uitwendig model is het best op te vatten als een verzameling van klassen die toegang tot het gegevensbestand verzorgt. Verder werd er ook voor gekozen om de naamgeving van de compiler niet te beïnvloeden, om de overeenkomsten met de nomenclatuur in het XML bestand te behouden. Het uitwendige model wordt uitsluitend gebruikt door de klasse DataStorage die instaat voor de opslag van de gegevens. De vertalingen tussen inwendige en uitwendige structuur gebeuren hierin. Omdat de klassenstructuur die door JAXB worden gegenereerd erg log is en tevens volledig overeenkomt met de structuur van het XML-bestand, zal deze niet worden besproken. In de plaats wordt een korte toelichting gegeven bij de structuur van het laatste bestand: het tijdsbestand time.xml
5.7.1 Inhoud van het tijdsbestand De tijdsgegevens die door de gebruiker worden ingevoerd, worden bewaard in het tijdsbestand. Hieronder staat een voorbeeldafdruk van dergelijk bestand.
46
De gebruiker maakt in de software bepaalde groepen van effecten aan. In het showbestand worden deze groepen van effecten pallettes genoemd. Het element pallettelist bevat een oplijsting van deze gebeurtenisgroepen. Er werd bewust gekozen voor een andere naamgeving van de elementen, omdat deze beter overeenkomt de in de commerciële oplossing gangbare nomenclatuur. Deze naamgeving komt ook overeen met de termen die in de grafische interface worden gebruikt. Het attribuut name bevat de naam van de gebeurtenisgroep, zoals deze in het programma wordt weergegeven. Dit attribuut wordt in de hogere structuren ook gebruikt om Voor elke feature dat moet worden veranderd bij het afvuren van een gebeurtenis, wordt een kind van het type event opgenomen in de gebeurtenis groep. De attributen fixture, feature en value identificeren het aan te sturen effect van het toestel, en de in te stellen waarde. Deze waarde wordt uitgedrukt als een decimaal getal tussen nul en één. Ook tijdstip en tijdsduur kunnen worden toegekend. De gebeurtenisgroepen worden gebruikt in tijdsstructuren die uiteindelijk worden afgespeeld. Deze tijdstructuren worden in het element treelist bewaard. De boomstructuur wordt expliciet voorgesteld door de XML-elementen, waarbij de namen van de elementen overeenkomen met de generatoren.
47
Hoofdstuk 6
De grafische interface
In dit hoofdstuk worden kort de verschillende elementen van de grafische interface besproken, alsmede hun onderlinge interacties en hun interacties met de modellen. Zoals duidelijk zal worden is een van de grootste uitdagingen van dit project het dynamisch aanpassen van de inhoud van de interface als gevolg van de acties van de gebruiker. Ook de initiële toestand van de interface moet deels worden ingeladen op basis van de informatie die de gebruiker in de diverse configuratiebestanden heeft ingegeven.
6.1 Overzicht van de grafische interface De taken van de gemaakte toepassing zijn op te delen in twee categorieën: enerzijds zijn er de taken die verband houden met het aanmaken van de eigenlijke inhoud (de scenes), en anderzijds de taken die ervoor zorgen dat alles in de tijd wordt samengevoegd tot een bepaalde sequentie. We kunnen spreken van twee de domeinen: het featuredomein en het tijdsdomein. Er werd voor gekozen om de twee domeinen elk in hun eigen venster te behandelen. Het featuredomein wordt voorgesteld in het Workspace Window, terwijl het tijdsomein wordt weergegeven in het Time Window.
6.1.1 Het Workspace Window Dit venster ontleent zijn naam aan de opdeling in verschillende workspaces. Elk van deze workspaces heeft een eigen specifieke functie. De inhoud van sommige workspaces zijn dynamisch: ze worden aangepast op basis van een actie die de gebruiker heeft verricht in een andere workspace. In wat volgt wordt dieper ingegaan op de structuur van het venster en de functies van enkele workspaces en hoe deze werden gerealiseerd. Figuur 23 toont een fragment van het WorkspaceWindow met de workspaces.
48
Figuur 23 De workspaces
6.1.1.1 Structuur van het Workspace Window 6.1.1.1.1 Het Workspace Panel De klasse WorkspacePanel erft rechtstreeks van JPanel. Dit panel is in wezen een klassieke JPanel, waarop geforceerd een GridLayout wordt toegepast. In elk van de cellen van de GridLayout wordt een JPanel toegevoegd, dat zelf een BorderLayout gebruikt. Het uiteindelijke uitzicht van het paneel is een rooster, waarin de componenten worden uitgerokken zodat de volledige cel vullen. Om dit te bewerkstelligen, worden de componenten achter de schermen toegevoegd aan de CENTER van de BorderLayout van het overeenkomstige paneel. Het aantal rijen en kolommen wordt bij constructie meegegeven. De dimensies van het rooster zijn dus vast tijdens het verloop van de toepassing, maar kunnen wel eenvoudig worden vergroot, mocht in verder stadium de behoefte aan meer workspaces onstaan.
6.1.1.1.2 De ButtonGridWorkspace Tijdens het ontwerpen van de grafische interface is voor een aantal taken duidelijk geworden dat de beste weergave een rooster met knoppen is. Om duplicatie van code te vermijden, werd de ButtonGrid ontworpen die deze weergave realiseert. De code van de taken die worden ondernomen verschilt wel. Deze moet dus gescheiden worden van de weergave. Om dit te realiseren, wordt het Acti-
49
on gedeelte van Java Swing gebruikt. Deze acties worden toegewezen aan de besturingselementen.
De acties worden bewaard in een afzonderlijke container die de interface ButtonGridController. implementeert. De naam is enigszins misleidend, omdat het geen controller in traditionele zin is. Het verschil zit hem in het feit dat deze klassen een container zijn voor acties. Ze staan tevens in voor de constructie van de acties. De ButtonGrid vraagt bij constructie voor elke knop de overeenkomstige actie aan de controller. Indien dit nodig is, houdt de controller zelf eventuele andere huishouding bij. In de volgende paragrafen lichten we enkele controllers toe.
6.1.1.1.3 De FixtureSelectionGridController, het FixtureModel en de SelectFixtureAction De FixtureSelectionGridController is de eenvoudigste onder de controllers. Het grootste deel van de taken wordt met behulp van acties gedelegeerd naar het FixtureModel, dat instaat voor de huishouding van geselecteerde en actieve fixtures en hun features. In dit model wordt ook de afbeelding van het rij- en kolomnummer uit de workspace bijgehouden. De SelectFixtureAction staat dus in voor het doorgeven van de selectie van een toestel aan het model. Bij constructie worden zowel het model als het te selecteren toestel doorgegeven. Bij het uitvoeren van de actie wordt de fixture teruggeven aan het model, met de vraag om de selectie te togglen. Naast een gebruiker die op een knop van de workspace klikt, zijn er nog andere oorzaken dat selectietoestand van een fixture kan veranderen. Bijvoorbeeld als de gebruiker een groep van fixtures selecteert. Daarom is het nodig om ervoor te zorgen dat weergave van de fixtureSelection workspace wordt aangepast, zodat deze consistent met de selectie in het FixtureModel. Om dit gedrag eenvoudig te realiseren, werd het observer pattern geïmplementeerd, waarbij het FixtureModel de rol van observable vervult. De workspace vervult dan de rol van observer (of listener). Wanneer de selectie in het FixtureModel door een uitwendige invloed verandert, wordt de workspace hiervan op de hoogte gebracht via de ISelectedFixtureChanged interface. Het FixtureModel heeft nog andere functies. Deze zullen worden besproken in de respectievelijke paragrafen van de onderdelen die van deze functies gebruik van maken. De interacties tussen de GroupSelectionController, de SelectFixtureAction en het FixtureModel zijn analoog aan de interacties bij de enkelvoudige selectie, en worden niet apart besproken.
6.1.1.1.4 De SelectFeatureAction en de FeatureSelectionController Ook de selectie van features gebeurt via een ButtonGridWorkspace, en heeft dus een eigen controller nodig. De FeatureSelectionController staat in voor het bijhouden van de verzameling van geselecteerde features. De inhoud van deze verzameling is enkel van belang voor de weergave van de grafische interface. Dit is meteen de reden waarom ze wordt bijgehouden in de FeatureSelectionController, en niet in het FixtureModel, zoals dat met de selectie van fixtures gebeurt. Dit heeft tevens het voordeel dat er geen rekening hoeft gehouden te worden met problemen inzake concurrente wijziging. Wat belangrijker is voor het FixtureModel, is de verzameling van actieve features. Dit
50
zijn de features aan dewelke een waarde is toegekend. Hier wordt later op teruggekomen. Om de andere componenten op de hoogte te brengen van een verandering in de selectie van de features, wordt ook hier het observer pattern geïmplementeerd. De rol van observable wordt hier vervuld door de FeatureSelectionController. De observers (of listeners) worden via de ISelectedFeatureChanged interface op de hoogte gebracht van wijzigingen. Wanneer de verzameling van geselecteerde fixtures wijzigt, moeten ook de aan de gebruiker getoonde features veranderen. Daarom is de FeatureSelectionController ook zelf observer: hij implementeert de ISelectedFixtureChanged interface. Met de gedachte dat niet alle toestellen over dezelfde features beschikken in het achterhoofd, wordt aan het FixtureModel gevraagd om de doorsnede van alle verzamelingen van features te berekenen. Deze doorsnede wordt dan getoond aan de gebruiker.
6.1.1.1.5 De Feature Settings Workspace De klasse FeatureSettingsWorkspace wordt in tegenstelling tot de andere workspaces niet gerealiseerd door een ButtonGrid. De reden hiervoor is dat de componenten die moeten weergegeven afhangen van het soort feature dat geselecteerd wordt. Uit de inleiding weten we dat er in essentie twee soorten features bestaan: continu of discreet. Uit Figuur 24 en Figuur 25 blijkt het onderscheid.
Figuur 24 Weergave van een continue feature
Figuur 25 Weergave van een discrete feature
Wanneer een continue feature wordt geselecteerd, wordt een JSlider, enkele sneltoetsen (0%, 50% en 100%) en knoppen voor speciale waarden weergegeven. De speciale waarden zijn afkomstig uit het 51
profiel van het betreffende toestel, zoals het is opgenomen in de fixture bibliotheek. Wanneer een discrete feature wordt geselecteerd, worden de slider en sneltoetsen verwijderd. De slider wordt vooral verwijderd uit veiligheidsoverwegingen. Het is immers mogelijk dat een bepaalde waarde van een discrete feature een speciale functie heeft (denk bijvoorbeeld aan reset of lamp off). Omdat de waarde van de slider in realtime wordt weergegeven (de data wordt naar de fysieke toestellen gestuurd) terwijl hij versleept wordt, kan het zijn dat deze waarde ongewenst wordt doorgestuurd. De sneltoetsen worden verwijderd omdat ze bij een discrete feature toch geen betekenis hebben. Eerder werd aangehaald dat er onderscheid is tussen een geselecteerde fixture, en een actieve feature. Het activeren van een feature houdt in dat er een waarde wordt toegewezen, en dat de onthouden wordt dat de feature werd gewijzigd. Het is immers mogelijk dat een geheel van toewijzingen over meer dan een soort feature gaat, en dat bij het opslaan met al deze features moet rekening worden gehouden, en niet enkel met de laatst gewijzigde soort. De eigenlijk activering van de features gebeurt in het FixtureModel, maar wordt wel geïnitieerd vanuit de FeatureSettingsWorkspace.
6.1.1.1.6 De PalletteWorkspace Eerder werd vermeld dat een gebruiker groepen van gebeurtenis kan aanmaken. Dit gebeurt hier. Om een betere overeenstemming met de nomenclatuur in de commerciële oplossingen hebben werd ervoor gekozen om de gebruiker niet in contact te brengen met de naam EventGroup. In de plaats hiervan wordt het meer gangbare pallette behouden. Deze workspace is opnieuw een samenstelling van een ButtonGrid component en een controller: de PalletteController. De controller staat in voor het bijhouden van de pallettes die achter de respectievelijke zitten. In zekere zin is deze controller dus eigenlijk meer een model, dan een controller. Het aantal knoppen in de workspace is vast. De tekst op de knoppen is dit echter niet. De gebruiker kan de pallettes die maakt toewijzen aan een knop van de workspace. In dit geval wordt hem een gevraagd een naam op te geven. Wanneer de knop geen pallette voorstelt, toont deze geen naam. Dit is een indicatie voor de gebruiker of er al dan niet een pallette achter de knop schuilgaat. Dit gedrag wordt gerealiseerd door de PalletteAction: deze weet van zichzelf wat hij voorstelt.
6.2 Het Time Window A1le acties die zich in het tijdsdomein situeren gebeuren in het time window. Figuur 26 toont de globale structuur van het tijdsvenster. Het venster bestaat uit twee hoofdgedeelten: de tijdlijn (links) en de tijdsboom (rechts). Beiden zijn een weergave van hetzelfde model: de boomstructuur zoals deze werd besproken in §5.5. Om de beide componenten te rangschikken wordt gebruikt gemaakt van een JSplitPane, waaraan de componenten worden toegevoegd. Het splitpane wordt zelf toegevoegd in het middelste gebied van een BorderLayout. In de PAGE_START en PAGE_END gebieden worden respectievelijk de bovenste en de onderste werkbalken geplaatst.
52
Figuur 26 Fragment van het Time Window
6.2.1 De tijdsboom Ook hier wordt het concept van de tijdsboom doorgetrokken. De gebruiker kan rechtstreeks de knooppunten van het model manipuleren. Hiervoor gebruikt hij de knoppen die in de bovenste werkbalk zijn voorzien. De gebruiker kan een knoop in de tijdsboom selecteren, en hieraan knopen toevoegen, de deelboom die als wortel de geselecteerde knoop heeft knippen en elders in de boom terugplakken, of gewoon een knoop verwijderen. Indien de knoop parameters heeft (bijvoorbeeld in het geval van een shift knoop is de parameter de offset) kan hij deze wijzigen: de knop edit parameters roept een dialoog venster op waarin de waarden kunnen worden gewijzigd. Ook het opslaan van de gegevens gebeurt via dit venster. Wat betreft de implementatie van de tijdsboom valt er weinig te vertellen. Er werd voor gezorgd dat het model voldoet aan de Java Tree interfaces, zodat de component JTree kan worden gebruikt. De eigenlijke Tree interface wordt geïmplementeerd door de TreeModelWrapper klasse. Dit is een wrapper class rond de klasse IEventGroupGenerator, en geeft alle aanroepen gewoon door aan IEventGroupGenerator. Deze werkwijze heeft als doel om een aantal onhandigheden omtrent conflicterende naamgevingen weg te werken. (doordat alle paramters van de interface van het type Object zijn, ontstaan er dubbelzinnige situaties waarbij de correcte aanroep door de compiler niet eenduidig kan worden bepaald.) Er werd ook voor gezorgd dat de boom zichzelf hertekent wanneer er wijzigingen zijn toegebracht. De tijdsboom wordt voorgesteld door de klasse TreeDisplay, die erft van JPanel en de eigenlijk JTree bevat. De klasse implementeert verder nog de interface TreeModelListener, zodat deze op de hoogte kan worden gebracht wanneer de structuur van de tijdsboom wijzigt. Dit wordt gebruikt om ervoor te zorgen dat de uitgeklapte toestand van de boom terug wordt hersteld. (De JTree wordt volledig toegeklapt wanneer hij opnieuw wordt getekend.) De klasse zorgt er ook nog voor dat de TreeSelectionListeners zich kunnen registreren bij de JTree. Wat het nut is van deze luisteraars, komt aan het licht in de volgende paragraaf wanneer wordt besproken hoe, afhankelijk van de selectie in de tijdsboom, wordt bepaald wat er op te tijdslijn getekend wordt. Tot slot vermelden we nog dat ook de grafische code voor het wijzigen van de parameters is ondergebracht in het model zelf. Deze keuze werd gemaakt omdat er op die manier correct gebruik kan worden gemaakt van het polymorfisme van het model en zo een grote hoeveelheid if-else-instanceof code wordt vermeden.
53
6.2.2 De tijdlijn De tijdsboom is een praktische weergave voor het samenvoegen en hergebruiken van groepen van events, maar soms blijkt het echter nodig om wat meer overzicht over het resultaat te krijgen. Daarom werd ervoor gekozen om de voordelen van beide te combineren. De tijdlijn is een lineair weergave van de tijdsboom en is slechts in een enkel geval wijzigbaar: wanneer de geselecteerde knoop in de boom een EventGroup is. Ze geeft steeds weer wat het resultaat is van de evaluatie (het resultaat van de methode generate()) van de deelboom waarvan de geselecteerde knoop de wortel is. Telkens de selectie in de boom verandert, wordt ook de tijdlijn opnieuw getekend. Figuur 27 toont een overzicht van de klassen die verband houden met de tijdslijn en hun onderlinge relaties.
Figuur 27 Overzicht van relaties voor de TimeLineDisplay
6.2.2.1 Het TimeLineDisplay en de EventComponent Het TimeLineDisplay bevat de code die instaat voor het tekenen van de tijdlijn. De tijdlijn komt steeds overeen met de inhoud van de boom waarvan het wortelelement in de klasse wordt bijgehouden. Wanneer er een wijziging optreedt in de selectie van de boom, wordt het TimeLineDisplay hiervan op de hoogte gebracht via de methoden van de TreeSelectionListener interface. Op dit moment wordt de boom hertekend. Er zijn twee soorten oorzaken om de tijdlijn te hertekenen: een eerste waarbij het model werd gewijzigd, en de boom opnieuw moet worden geëvalueerd en een tweede waarbij dit niet nodig is. Deze laatste mogelijkheid doet zich bijvoorbeeld bij een muisbeweging voor. Alles wat zichtbaar is op de tijdlijn, wordt aangebracht door te tekenen met behulp van het Graphics object. Omdat er veel moet worden getekend, wordt het tekenen opgesplitst in een aantal stappen: eerst worden een aantal operaties gedaan zodat het assenstelsel overeenkomt met een klassiek assenstelsel. 54
Hierbij moet het font dat wordt gebruikt om karakters te tekenen worden aangepast, omdat het nu omgekeerd staat. Vervolgens wordt de eigenlijk tijdlijn en een raster getekend, waarvan de resolutie kan worden aangepast. Elke event op de tijdslijn wordt voorgesteld door een object van de klasse EventComponent. Er wordt aan deze objecten gevraagd om zichzelf te tekenen met behulp van het Graphics object dat zij krijgen van de TimeLineDisplay. Een EventComponent houdt voor zichzelf een relatieve locatie bij ten opzichte van een gegeven oorsprong. Wanneer deze uiteindelijk moet worden getekend, worden de relatieve coördinaten omgezet naar de absolute coordinaten, zodat deze overeenstemmen met het assenstelsel van het Graphics object, dat afkomstig is van het TimeLineDisplay paneel. De EventComponent zal zichzelf anders voorstellen afhankelijk van zijn toestand. De verzameling van mogelijke toestanden bestaat uit: highlighted, neutraal en geselecteerd. De TimeLineDisplay vangt de muisbewegingen van de gebruiker op, en stelt de toestand in van de EventComponents zodat deze zichzelf op gepaste wijze kunnen tekenen. In Figuur 28 worden deze verschillende wijzen weergegeven. De hoogte van het lijnstuk, en de plaats van de bullet wordt bepaald door de waarde van het event.
Figuur 28 De verschillende toestanden van een EventComponent (vlnr.: highlighted, neutraal en geselecteerd)
Als laatste wordt de muiscursor en de afspeelcursor getekend. Naast de muiscursor komt een aanduiding van het exacte tijdstip waarop de muiscursor zich bevindt. Via de implementatie van de interface MouseListener worden in het TimeLineDisplay de muiskliks van de gebruiker opgevangen. Een klik met de primaire muisknop dient om een event te selecteren, een klik met de secundaire wordt gebruikt om een EventGroup in te voegen op de aangeklikte plaats. Wanneer de gebruiker rechts klikt, verschijnt een dialoogvenster met namen van Pallettes die in het WorkspaceWindow werden aangemaakt. De gebruiker maakt een keuze, en het geselecteerde Pallette wordt omgevormd tot EventGroup, en wordt in de tijdsboom ingevoegd als kind van het geselecteerde knooppunt. Als tijdstip wordt de overeenkomstige tijd van de locatie waarop de gebruiker geklikt heeft meegegeven. Wanneer een EventComponent wordt geselecteerd of gedeselecteerd in de tijdlijn, wordt ook de onderste werkbalk (de EventManipulationToolBar) bijgewerkt. Deze bevat een aantal tekstvelden waarmee de eigenschappen van een event in de tijdlijn snel en nauwkeuriger kunnen worden ingesteld. Wanneer de selectie verandert, moet er uiteraard worden voor gezorgd dat de weergegeven waarden overeenstemmen met de eigenschappen van de geselecteerde gebeurtenis. Via de implementatie van de MouseMotionListener worden de muisgebaren van de gebruiker opgevangen. Deze worden gebruikt om de muiscursor op de juiste plaats te tekenen, en indien er zich een gebeurtenis onder de cursor bevindt, deze te highlighten. MouseWheelListener wordt geïmplemen55
teerd om de zoom functionaliteit te realiseren. Wanneer een gebruiker naar omhoog scrolt, verhoogt de schaal van de tijdlijn (in wezen het aantal pixels per miliseconde) en vice versa. Door deze functionaliteit moet er ook rekening worden gehouden met de schaal bij het tekenen van de componenten. De KeyListener implementatie tot slot wordt gebruikt om de toetsaanslagen van de gebruiker op te vangen. Wanneer een gebruiker op de delete toets drukt, wordt het geselecteerde event uit de EventGroup verwijderd.
56
Hoofdstuk 7 Besluiten en toekomstperspectieven
Ter conclusie van dit eindwerk wordt de realisatie van de vooropgestelde doelstellingen geëvalueerd en worden de punten van verbetering en uitbreidingsmogelijkheden besproken.
7.1 Evaluatie van de doelstellingen 7.1.1 Een goedkope en toegankelijke oplossing Dat de kostprijs van de ontwikkelde oplossing erg klein is ten opzichte van de commerciële oplossing werd in §4.2.2 aangetoond. Een mogelijk drempel voor instap in deze toepassing is de constructie van de dongle. Hoewel deze bijzonder eenvoudig is, vereist ze toch enkele elementaire vaardigheden op het gebied van elektronica. Ook het bekomen van de nodig componenten, hoewel ze gemakkelijk verkrijgbaar zijn, kan als een drempel worden ervaren. De gebruiker kan nog steeds terugvallen op het Art-Net protocol, maar de hardware nodig om dit protocol om te zetten naar DMX (de zogeheten NSP’s of network signal processors) is erg duur.
7.1.2 Een bruikbare oplossing Hoewel de werkwijze van de tijdsboom elegant is, moet nog blijken of deze oplossing in de praktijk ook erg praktisch is. Door de fixturebibliotheek op te nemen in een XML-bestand, kan de gebruiker eenvoudig nieuwe soorten toestellen toevoegen. Dit is een van de kernvereisten van dit soort toepassingen. Fabrikanten kunnen ook eenvoudig XML fragmenten uitgeven voor hun toestellen. Dit is een verbetering ten opzichte van de commerciële oplossingen, waar meestal de fabrikant van de sturing de profielen aanmaakt.
57
7.1.3 Voorzien zowel in hardware als in software Deze twee doelstellingen zijn gerealiseerd. Er werd een softwareapplicatie gemaakt, die wordt ondersteund door de nodige hardware. Er kan gesproken worden een realisatie van de volledige signaalketen.
7.1.4 Een open oplossing Dit is zeker en vast een sterktepunt van dit project. Doordat werd gekozen voor de serialisatie naar XML, hebben andere toepassingen onverminderd toegang tot de gegevens die door de gemaakte toepassing worden opgeslagen. Andere toepassingen kunnen brongegevens aanmaken voor de gemaakte toepassing, en vice versa. Verder werd bij het schrijven van de code aandacht besteed aan de openheid voor uitbereiding.
7.2 Punten van verbetering Omdat de grafische sterkte niet meteen een kerndoelstelling van dit project was, werd er weinig aandacht besteed aan de look and feel van de componenten van de grafische interface. Op dit gebied is er dus zeker nog een grote verbetering mogelijk om de toepassing aantrekkelijker te maken voor de eindgebruiker. De dubbele huishouding die wordt onderhouden in het inwendig en uitwendig model is ver van ideaal. Het is eerder een pragmatische doch effectieve oplossing om aan de nodige inspanningen voor het sturen van de JAXB binding compiler te ontkomen. In een verder stadium zou er toch moeten worden gestreefd naar een enkelvoudig model dat rechtsreeks naar XML kan worden geserialiseerd, zonder vertaling. In het tijdsmodel ontbreekt een functionaliteit die in de meeste commerciële oplossingen wel aanwezig is, hoewel ze slechts zelden wordt gebruikt: de ondersteuning voor fading, waarbij een waarde niet ogenblikkelijk wordt toegekend, maar de ze geleidelijk aan toeneemt van de oorspronkelijke waarde tot de gewenste waarde. Hierbij is ook de tijdsduur en het verloop van de stijgen instelbaar.
7.3 Mogelijkheden voor uitbreiding Hoe gebruiksvriendelijk een software toepassing ook kan zijn, er is niets dat aan de snelheid en handigheid kan tippen van hardwarebesturingselementen. Daarom zou het een goede uitbereiding zijn mochten de virtuele knoppen en faders van de applicatie ook kunnen worden bestuurd door fysieke hardware elementen. Hierbij lijkt de denkpiste om met behulp van de Arduino microcontroller de weerstanden van schuifpotentiometers uit te lezen en drukken van knoppen op te vangen vanzelfsprekend. Er zijn echter ook commercieel beschikbare oplossingen op basis van MIDI, die het bijkomend 58
voordeel hebben dat ze in twee richtingen kunnen werken: wanneer een fysiek besturingselement wordt aangepast wordt het besturingselement op het scherm overeenkomstig aangepast, maar ook als de gebruiker met de muis de component aanpast beweegt de fysieke knop of fader. Naast het afspelen van de inhoud van de tijdsboom, zou het ook interessant zijn om naast de besturing van lichtapparatuur, ook andere tijdlijnen kunnen toe te voegen die instaan voor het synchroon afspelen van bijvoorbeeld video en/of audio. In dit ontwikkelstadium werd enkel gebruik gemaakt van de Arduino dongle en Art-Net. Het zou de toepassing ten goede komen moesten ook andere dongles die een publieke API hebben kunnen worden gebruikt. Als laatste suggestie voor uitbereiding zou er kunnen worden voorzien in een applicatie voor een handheld toestel die de gebruiker in staat stelt om via een netwerk de toepassing op afstand te besturen.
59
Literatuurlijst
Arduino, 2011, geraadpleegd op 30/09/2011 via http://arduino.cc Astuces-pratiques, 2011, geraadpleegd op 10/11/2011 via http://www.astucespratiques.fr/electronique/jeu-de-lumiere-scan-scanner-principe-du-gobo. Maddeffects, geraadpleegd op 10/11/2011 via http://www.madeffects.com/ekmps/shops/madeffectsltd77/images/martin-mania-scx700-291-p.jpg Directproaudio, geraadpleegd op 10/11/2011 via http://www.directproaudio.com/product.cfm?directid=17157 Sending DMX with the arduino, T. Ness & D. Cuartielles, 2006. The Unofficial JAXB Guide (2009), geraadpleegd op 20/08/2012 via http://java.jaxb.net/guide. Oracle Docs, geraadpleegd op 14/01/2012 via http://docs.oracle.com/cd/E17802_01/webservices/webservices/docs/1.5/tutorial/doc/JAXBWorks2.ht ml RS-485, 2012, geraadpleegd op 22/08/2012 via http://en.wikipedia.org/wiki/RS-485 Deth-First Search, 2012, geraadpleegd op 22/08/2012 via http://en.wikipedia.org/wiki/Depthfirst_search. JK-Lichtengeluid, geraadpleegd op 1/09/2012 via http://jk-lichtengeluid.be Licht-geluid, geraadpleegd op 1/09/2012 via http://www.licht-geluid.nl/shop/p-3269-showtec-dimmerpack-shucko-6x10a.aspx Martin, geraadpleegd op 1/09/2012 via http://www.martin.dk
60
