2 soorten van gebaren:
directe gebaren (direct gestures): gebaren die objecten direct kunnen manipuleren:
* scaleren (--> pinching): 2 vingers van elkaar weg of naar elkaar toe bewegen om in te zoomen of uit te zoomen
* roteren: 2 vingers in roteren rond eenzelfde middelpunt
* transleren: drag-and-drop met 1 vinger ipv muis
Deze categorie van gebaren is eerder beperkt, want ze hangen sterk af van het object dat gemanipuleerd wordt. Meestal kan een object, dat in dit geval eigenlijk een 2D-beeld is, slechts op een eindig aantal manieren gemanipuleerd worden, zoals hierboven beschreven.
symbolische gebaren (symbolic gestures): patronen die gebaseerd zijn op de locatie en traject van het gebaar. Zo kan er aan een bepaalde bewegingssequentie van 1 of meerdere vingers een actie gekoppeld worden. Een recognition engine is typisch in staat voorgedefinieerde patronen te herkennen en hierbij een opdracht te geven om de actie uit te voeren gekoppeld aan dit patroon.
Deze categorie laat toe eigenlijk een oneindig aantal patronen te definiëren. Zo zou er een bepaalde functie opgeroepen kunnen worden als er een bepaald nummer getekend wordt.
Hoe gebaren herkennen?
De meest gangbare modellen om patronen te herkennen zijn de volgende 3: neural netwerken, modellen gebaseerd op regio en modellen gebaseerd op richting.
Neural netwerken worden vaak gebruikt voor patroonherkenning. Men gebruikt dan feedforward neural networks die 3 lagen hebben: input, hidden en output layer. Een groot nadeel van dit model is dat initieel de knopen van de hidden layer gevuld worden met random gewichten zodanig dat dit model eerst getraind moet worden om een accurate herkenning te kunnen doen.
Een regiogebaseerd herkenningsmodel houdt initieel een 3x3 grid bij die kan scaleren naargelang het afgelegde pad van het gebaar. Voor elke cel in het grid slaat het model op of een gebaar langs die cel gepasseerd is of niet. De nummers van de cellen waar een gebaar gepasseerd is worden opgeslagen in een string die dan vergeleken kan worden met de gebaren in de database.
Een richtingsgebaseerd herkenningsmodel beschrijft een pad van een gebaar als een opeenvolging van richtingen. Als men bv. 8 richtingen (zoals de 8 windrichtingen) definieert met het oosten als richting 0 en zo in wijzerszin tot en met 7, dan zou de letter 'N' geschreven kunnen worden als '616'. Twee keer naar boven (6) en 1 keer schuin naar beneden (1). De bekomen string van richtingen gaat men dan vergelijken met de patronen uit de database met behulp van de Levenshtein-afstand. Het patroon waarvoor de laagste kost berekend werd, wordt dan geselecteerd. Om valse positieven te vermijden kan er een waarde voor maximale kost ingesteld worden. Dit laatste model heeft als voordeel dat het relatief gemakkelijk te implementeren is.
woensdag 28 oktober 2009
maandag 26 oktober 2009
Finger tracking
* paper: reacTIVision: A Computer-Vision Framework for Table-Based Tangible Interaction
Een zeer algemene paper die een overzicht geeft van de onderdelen van een multi-touch systeem, wat de rol van reacTIVision hierin is, hoe zo'n opstelling fysiek gebouwd wordt en in welke projecten het framework gebruikt wordt. Bij de beknopte bespreking van reacTIVision worden kort de verschillende tracker engines (Amoeba (zie vorige blogbericht), d-touch, ...) besproken en zegt men het volgende over het detecteren van vingers:
Aangezien reacTIVision in de eerste plaats ontworpen was om fiducials te traceren, werd aanvankelijk het probleem van vingerdetectie herleid tot een fiducialprobleem. Hierbij moest een eenvoudige fiducial (met een boomstructuur van 1 enkele tak) aangebracht worden op de vinger om gedetecteerd te kunnen worden. Een groot nadeel van deze methode is de topologie van de fiducial die al snel vals gedetecteerd kan worden vanwege zijn eenvoudigheid. Deze fout kan wel geminimaliseerd worden door rekening te houden met detecties uit voorgaande frames.
In volgende versies van het framework is men overgeschakeld naar een alternatief optisch vingerdetectiesysteem dat niet meer gebruik maakt van fiducials, maar hierover wordt verder niks gezegd in deze paper.
* De meeste trackers gebruiken de openCV (Open Source Computer Vision) bibliotheek om blobs te detecteren. Deze bibliotheek zet elk frame via image thresholding (grijswaarden beneden een bepaalde drempel worden omgezet naar wit, de rest wordt zwart) om naar een binair beeld. In dit beeld gaat men via contour tracing de witte punten (i.e. 'blobs', vingertoppen in dit geval) localiseren. Om het precieze raakpunt met het oppervlak te bepalen gaat men dan het middelpunt van het witte punt berekenen. Oriëntatie berekenen heeft geen zin, maar is eventueel wel mogelijk als men rekening houdt met de positie van de volledige hand die op een ruw frame dikwijls nog wel zichtbaar is. Dit wordt (nog) niet ondersteund door openCV.
Om ervoor te zorgen dat dezelfde blobs over de verschillende frames heen (tot ze verdwijnen) hetzelfde unieke ID hebben, worden in een eerste frame de ID's van alle blobs in een vector opgeslagen. Bij een volgend frame wordt dan het ID van een blob bepaald met het kNN-algoritme (k nearest neighbour).
Enkele bedenkingen bij de aanpak van openCV:
1) Als 2 vingers dicht bij elkaar het scherm raken, kan het zijn dat de 2 witte punten met elkaar versmelten en worden geïdentificeerd als 1 raakpunt. OpenCV houdt hier voorlopig geen rekening mee en dit kan problemen geven bij bv. inzoomen (pinching)
2) Het precieze raakpunt met het scherm is enkel het middelpunt van het witte punt als de vinger het scherm loodrecht raakt, wat niet altijd het geval is.
Een zeer algemene paper die een overzicht geeft van de onderdelen van een multi-touch systeem, wat de rol van reacTIVision hierin is, hoe zo'n opstelling fysiek gebouwd wordt en in welke projecten het framework gebruikt wordt. Bij de beknopte bespreking van reacTIVision worden kort de verschillende tracker engines (Amoeba (zie vorige blogbericht), d-touch, ...) besproken en zegt men het volgende over het detecteren van vingers:
Aangezien reacTIVision in de eerste plaats ontworpen was om fiducials te traceren, werd aanvankelijk het probleem van vingerdetectie herleid tot een fiducialprobleem. Hierbij moest een eenvoudige fiducial (met een boomstructuur van 1 enkele tak) aangebracht worden op de vinger om gedetecteerd te kunnen worden. Een groot nadeel van deze methode is de topologie van de fiducial die al snel vals gedetecteerd kan worden vanwege zijn eenvoudigheid. Deze fout kan wel geminimaliseerd worden door rekening te houden met detecties uit voorgaande frames.
In volgende versies van het framework is men overgeschakeld naar een alternatief optisch vingerdetectiesysteem dat niet meer gebruik maakt van fiducials, maar hierover wordt verder niks gezegd in deze paper.
* De meeste trackers gebruiken de openCV (Open Source Computer Vision) bibliotheek om blobs te detecteren. Deze bibliotheek zet elk frame via image thresholding (grijswaarden beneden een bepaalde drempel worden omgezet naar wit, de rest wordt zwart) om naar een binair beeld. In dit beeld gaat men via contour tracing de witte punten (i.e. 'blobs', vingertoppen in dit geval) localiseren. Om het precieze raakpunt met het oppervlak te bepalen gaat men dan het middelpunt van het witte punt berekenen. Oriëntatie berekenen heeft geen zin, maar is eventueel wel mogelijk als men rekening houdt met de positie van de volledige hand die op een ruw frame dikwijls nog wel zichtbaar is. Dit wordt (nog) niet ondersteund door openCV.
Om ervoor te zorgen dat dezelfde blobs over de verschillende frames heen (tot ze verdwijnen) hetzelfde unieke ID hebben, worden in een eerste frame de ID's van alle blobs in een vector opgeslagen. Bij een volgend frame wordt dan het ID van een blob bepaald met het kNN-algoritme (k nearest neighbour).
Enkele bedenkingen bij de aanpak van openCV:
1) Als 2 vingers dicht bij elkaar het scherm raken, kan het zijn dat de 2 witte punten met elkaar versmelten en worden geïdentificeerd als 1 raakpunt. OpenCV houdt hier voorlopig geen rekening mee en dit kan problemen geven bij bv. inzoomen (pinching)
2) Het precieze raakpunt met het scherm is enkel het middelpunt van het witte punt als de vinger het scherm loodrecht raakt, wat niet altijd het geval is.
woensdag 21 oktober 2009
Verslag meeting 21/10
aanwezigen: Bram Vandeputte, Jef Hermans
onderwerpen:
* richtlijnen voor de eerste rapportering: De volgende punten moeten zeker in het document aan bod komen: probleemstelling, de planning gecombineerd met de aanpak van het probleem en de resultaten op dat moment van de literatuurstudie. Een eerste versie van de outline moet asap opgesteld en gepost worden op de blog. De deadline voor de eerste rapportering is 30 oktober.
* planning: De wijzigingen van de planning tov de eerste versie werden besproken. Er is nog een fase vergeten op de planning, nl. de verwerking van de evaluatie van de paper mockup.
* presentatie: Het is de bedoeling om een presentatie te geven over de stand van zaken op dat moment in de periode na de eerste rapportering alsook de plannen voor de komende periode.
* literatuur: Er is nog niets opgezocht geweest over mogelijke handelingen op een tabletop. Hierover nog papers en info zoeken.
* tabletop zelf: De hardware opstelling wordt binnenkort naar cw gebracht, waardoor het eventueel mogelijk zou worden om aan de opstelling te sleutelen en al enkele testen te doen.
* volgende meeting: Er is nog geen moment vastgelegd, misschien volgende week als er nog punten ivm de outline besproken moeten worden.
onderwerpen:
* richtlijnen voor de eerste rapportering: De volgende punten moeten zeker in het document aan bod komen: probleemstelling, de planning gecombineerd met de aanpak van het probleem en de resultaten op dat moment van de literatuurstudie. Een eerste versie van de outline moet asap opgesteld en gepost worden op de blog. De deadline voor de eerste rapportering is 30 oktober.
* planning: De wijzigingen van de planning tov de eerste versie werden besproken. Er is nog een fase vergeten op de planning, nl. de verwerking van de evaluatie van de paper mockup.
* presentatie: Het is de bedoeling om een presentatie te geven over de stand van zaken op dat moment in de periode na de eerste rapportering alsook de plannen voor de komende periode.
* literatuur: Er is nog niets opgezocht geweest over mogelijke handelingen op een tabletop. Hierover nog papers en info zoeken.
* tabletop zelf: De hardware opstelling wordt binnenkort naar cw gebracht, waardoor het eventueel mogelijk zou worden om aan de opstelling te sleutelen en al enkele testen te doen.
* volgende meeting: Er is nog geen moment vastgelegd, misschien volgende week als er nog punten ivm de outline besproken moeten worden.
maandag 19 oktober 2009
Paper: Improved Topological Fiducial Tracking in the reacTIVision System
(eerste versie van deze paper staat hier)
Amoeba engine
Deze paper beschrijft hoe fiducials (grafisch symbool dat gekend is door het computer vision systeem en daarom gemakkelijk herkend kan worden wanneer het op de tabletop ligt) gebruikt kunnen worden door een trackingsysteem en hoe ze gevormd werden.
Elke fiducial is feitelijk een binair beeld (zwart/wit) dat via segmentatie (pixels die tot eenzelfde object/gebied behoren worden gegroepeerd) herleid kan worden tot een "region adjacency graph" waarbij zwarte en witte gebieden elkaar opvolgen in de boom als er telkens van vader naar zoon gegaan wordt. De bladeren van de boom zijn dus gebieden die geen andere gebieden meer bevatten. Een fiducial wordt herkend op basis van zijn topologie, m.a.w. op basis van zijn graaf. 2 fiducials zijn verschillend van mekaar als ze een verschillende graaf hebben, ongeacht de geometrie.
Locatie & oriëntatie
Het bepalen van locatie en oriëntatie werd sterk beïnvloed door de implementatie van het segmentatiealgoritme. Dit onthoudt van de verschillende gebieden slechts hun omhullende rechthoek waarvan de zijden evenwijdig lopen met de assen. Het bleek dat het middelpunt van een gebied goed benaderd werd door het middelpunt van zijn omhullende rechthoek te nemen, met de kleinste fout bij de kleinste gebieden. Vandaar kiest men ervoor om de locatie van een fiducial als volgt te bepalen: een gewogen gemiddelde wordt genomen van alle middelpunten van de bladeren in de boom.
De oriëntatie wordt bepaald aan de hand van ofwel de witte ofwel de zwarte bladeren. Er wordt opnieuw een gewogen gemiddelde genomen van 1 van beide groepen, waarbij het gewicht afhangt van het blad in de boom. Dit is een manier om de grootte van het gebied mee in rekening te brengen.
Hoe fiducials genereren?
Eerst worden er bomen gegenereerd die aan bepaalde beperkingen moeten voldoen (aantal witte en zwarte bladeren, bepaalde diepte, totaal aantal knopen). Eens er topologieën (bomen) gevonden zijn gaat men op zoek naar geometrieën (fiducials). Ook hier zijn er weer beperkingen:
1. het middelpunt van alle bladeren moet het middelpunt van de fiducial goed genoeg benaderen
2. de vector die nodig is om de oriëntatie te bepalen moet voldoende lang zijn om dit nauwkeurig te kunnen doen.
In de volgende stap gebruikt men een genetisch algoritme om alle parameters te optimaliseren. Van elke boom wordt dan de beste geometrie gekozen, met als criteria grootte en de lengte van de oriëntatievector.
Hoe fiducial herkennen in een videoframe?
Om een fiducial (een subgraaf van het gehele frame) te herkennen in een frame gebruikt men een voorstellingswijze adhv de diepte van de knopen: 'left heavy depth sequences'. Elke knoop van een boom krijgt een getal mee adhv zijn diepte en die van zijn kinderen, waarbij de meest zware kinderen, die op hun beurt het meeste kinderen hebben, eerst vermeld worden. Het trackingsysteem bezit een database met de 'left heavy depth sequences' van de gebruikte fiducials en gaat na of er in de graaf van het globale beeld een subgraaf is met een sequentie van een fiducial. Als zo'n fiducial succesvol geïdentificeerd wordt, kan de locatie en oriëntatie berekend worden.
enkele alternatieve trackingalgoritmen voor fiducials:
ARToolKit
ARTag
D-touch (voorloper van dit algoritme)
zaterdag 17 oktober 2009
TUIO-alternatieven
* LusidOSC: Een waardig alternatief voor TUIO dat ook als laag bovenop OSC geïmplementeerd werd. LusidOSC breidt de ideeën van TUIO uit, op een manier dat het protocol voor een breder gamma aan systemen gebruikt kan worden (dus niet specifiek gericht op multi-touch touchscreens). Vandaar de belangrijke verschillen in het protocoldesign. Een eerste groot verschil zit bij het profielgebruik. TUIO bezit een aantal voorgedefinieerde profielen (2D, 3D, ...) die gebruikt worden naargelang de noden van de trackingsysteem. Bij LusidOSC is er slechts 1 profiel dat gebruikt zal worden voor alle situaties. Op die manier is het niet langer mogelijk dat een client-applicatie slechts een implementatie biedt voor 1 bepaald profiel, m.a.w. maar 1 type van berichten (bv. van het 2D-profiel) kan parsen. Bovendien blijft het protocol zo onafhankelijk van de bestaande trackingsystemen. Andere verschillen zitten in de parameters die meegezonden worden bij LusidOSC-berichten. De set-berichten bevatten volgende parameters (9 in totaal): uniek ID (u), positie (x, y, z), rotatie (a, b, c) en parameters voor extra data (e, d). fseq (geeft aan tot welk frame een pakket hoort) heeft 3 parameters: frame-nummer (f) en de tijd (s.m), maar 1 parameter (frame-nummer) bij TUIO. Daarnaast worden bij TUIO ook nog vectoren meegezonden met info over snelheid en richting. Die informatie wordt bij TUIO typisch aan de low-level zijde, dus bij de tracker, berekend. LusidOSC daarentegen zendt de tijd mee in de fseq-berichten en schuift die berekeningen door naar de clientzijde, wat het berekenen toch wel minder efficiënt maakt. Anderzijds nemen de vectoren (64 bit per seq-bericht voor een object, 32 bit voor een cursor) wel veel plaats in in een UDP-pakket, want ze zitten vervat in elk seq-bericht. De tijd (64 bit) zit enkel in een fseq-bericht, dat per pakket 1 keer wordt gestuurd.
Een concrete vergelijking brengt aan het licht dat LusidOSC duidelijk efficiënter en performanter is als het gaat om traceren van objecten in een 3D-omgeving, nu net hetgeen waar de LusidOSC-berichten zich op focussen. Bij het traceren van 2D-cursors (lees: vingers, dus het belangrijkste voor deze thesis) is TUIO dan weer op alle vlakken beter dan LusidOSC omdat LusidOSC maar 1 type van set-berichten kent die eigenlijk speciaal gericht zijn op een 3D-omgeving. Hierbij komt nog eens het nadeel dat bij het ontvangen van een LusidOSC-bericht informatie omtrent snelheid en acceleratie nog moet berekend worden.
Dit protocol wordt gebruikt door 1 belangrijk trackingsysteem, nl. Trackmate, maar dat is vooral gericht op objecten die voorzien zijn van unieke tags, wat ook bij reacTable toegepast wordt.
LusidOSC biedt momenteel libraries aan voor volgende programmeertalen: Processing, Max/MSP en Java.
Gezien de populariteit en ondersteuning van een brede waaier aan programmeertalen is TUIO nog steeds het standaardprotocol, maar LusidOSC is aan een opmars bezig. Libraries voor Flash, Python en C++ worden momenteel ontwikkeld. Aan de trackerzijde zijn er nog maar weinig mogelijkheden, voorlopig enkel Trackmate.
* MIDI: ReacTIVision kan naast TUIO ook via MIDI communiceren, hoewel TUIO nog steeds de primaire manier van communicatie blijft. Er wordt dan een XML-file opgesteld die de mapping van positie en rotatie naar MIDI bepaalt. Zo worden x- en y-positie voorgesteld door de positie van faders, een hoek door een draaiknop en note-on/note-off geeft de aanwezigheid van een object aan. Een groot nadeel van de MIDI-berichten is de beperkte bandbreedte (31,25 kbit/s, i.e. 4 bytes per millisec). 1 MIDI-bericht van 3 bytes neemt dus 0.75 millisec in beslag, dus 3 berichten (voor xpos, ypos en hoek) versturen zou 2.25 millisec duren, wat beduidend veel trager gaat dan het verzenden van UDP-pakketten.
Een concrete vergelijking brengt aan het licht dat LusidOSC duidelijk efficiënter en performanter is als het gaat om traceren van objecten in een 3D-omgeving, nu net hetgeen waar de LusidOSC-berichten zich op focussen. Bij het traceren van 2D-cursors (lees: vingers, dus het belangrijkste voor deze thesis) is TUIO dan weer op alle vlakken beter dan LusidOSC omdat LusidOSC maar 1 type van set-berichten kent die eigenlijk speciaal gericht zijn op een 3D-omgeving. Hierbij komt nog eens het nadeel dat bij het ontvangen van een LusidOSC-bericht informatie omtrent snelheid en acceleratie nog moet berekend worden.
Dit protocol wordt gebruikt door 1 belangrijk trackingsysteem, nl. Trackmate, maar dat is vooral gericht op objecten die voorzien zijn van unieke tags, wat ook bij reacTable toegepast wordt.
LusidOSC biedt momenteel libraries aan voor volgende programmeertalen: Processing, Max/MSP en Java.
Gezien de populariteit en ondersteuning van een brede waaier aan programmeertalen is TUIO nog steeds het standaardprotocol, maar LusidOSC is aan een opmars bezig. Libraries voor Flash, Python en C++ worden momenteel ontwikkeld. Aan de trackerzijde zijn er nog maar weinig mogelijkheden, voorlopig enkel Trackmate.
* MIDI: ReacTIVision kan naast TUIO ook via MIDI communiceren, hoewel TUIO nog steeds de primaire manier van communicatie blijft. Er wordt dan een XML-file opgesteld die de mapping van positie en rotatie naar MIDI bepaalt. Zo worden x- en y-positie voorgesteld door de positie van faders, een hoek door een draaiknop en note-on/note-off geeft de aanwezigheid van een object aan. Een groot nadeel van de MIDI-berichten is de beperkte bandbreedte (31,25 kbit/s, i.e. 4 bytes per millisec). 1 MIDI-bericht van 3 bytes neemt dus 0.75 millisec in beslag, dus 3 berichten (voor xpos, ypos en hoek) versturen zou 2.25 millisec duren, wat beduidend veel trager gaat dan het verzenden van UDP-pakketten.
woensdag 14 oktober 2009
Verslag meeting 14/10
aanwezigen: Bram Vandeputte, Jef Hermans
onderwerpen:
* planning: Deze zou aangepast en verder uitgewerkt moeten worden. Verschillende fasen op de planning zouden in elkaar over moeten lopen en lange fasen in het ontwerpproces worden best opgesplitst met telkens een evaluatiestap ertussen. De startdatum voor het schrijven van de thesistekst moet vervroegd worden.
* literatuurstudie: Papers zoeken over de achterliggende ideeën en algoritmes van de verschillende trackers. Een vergelijkende studie maken van hun mechanismen zou later kunnen helpen bij het selecteren van een bepaalde tracker op basis van de noden van de applicatie. Daarnaast ook opzoeken en nadenken over welke handelingen (pinching, ...) er mogelijk zijn op een tabletop.
* Tijdens de literatuurstudie en het vergelijken van de verschillende libraries zouden deze eventueel al praktisch getest kunnen worden om te kijken welke handig zijn in gebruik, welke problemen er mee optreden, enz.
* TUIO: Tot nu toe werden er enkel libraries gebaseerd op TUIO besproken. Best ook eens nagaan of er alternatieven voor TUIO bestaan en voor- en nadelen tov TUIO bespreken.
* nadenken over applicatie: Voorstellen tot applicaties formuleren en interessante ideeën opschrijven als mogelijk startpunt voor de ontwerpfase.
* volgende meeting: 21/10 10u30
onderwerpen:
* planning: Deze zou aangepast en verder uitgewerkt moeten worden. Verschillende fasen op de planning zouden in elkaar over moeten lopen en lange fasen in het ontwerpproces worden best opgesplitst met telkens een evaluatiestap ertussen. De startdatum voor het schrijven van de thesistekst moet vervroegd worden.
* literatuurstudie: Papers zoeken over de achterliggende ideeën en algoritmes van de verschillende trackers. Een vergelijkende studie maken van hun mechanismen zou later kunnen helpen bij het selecteren van een bepaalde tracker op basis van de noden van de applicatie. Daarnaast ook opzoeken en nadenken over welke handelingen (pinching, ...) er mogelijk zijn op een tabletop.
* Tijdens de literatuurstudie en het vergelijken van de verschillende libraries zouden deze eventueel al praktisch getest kunnen worden om te kijken welke handig zijn in gebruik, welke problemen er mee optreden, enz.
* TUIO: Tot nu toe werden er enkel libraries gebaseerd op TUIO besproken. Best ook eens nagaan of er alternatieven voor TUIO bestaan en voor- en nadelen tov TUIO bespreken.
* nadenken over applicatie: Voorstellen tot applicaties formuleren en interessante ideeën opschrijven als mogelijk startpunt voor de ontwerpfase.
* volgende meeting: 21/10 10u30
dinsdag 13 oktober 2009
Quartz Composer
Quartz Composer is opnieuw een visuele programmeertaal gebaseerd op een soort van knopennetwerk en hoort daarom thuis in het rijtje van Pure Data en Max/MSP. Het wordt ontwikkeld door Apple en is enkel geschikt voor MacOS, een minpunt ivm de alternatieven. Volledig analoog aan de eerdergenoemde talen gebeurt programmeren ook via patches. Patches kunnen gegroepeerd worden tot macros, die op hun beurt genest kunnen voorkomen. Met de komst van Leopard werd er meer aandacht besteed aan de netwerkfunctionaliteit en werd er ook ondersteuning voorzien voor het zenden en ontvangen van OSC-berichten. Eigenlijk biedt deze taal niet direct een meerwaarde tov Max/MSP in de zin dat er niet direct een link wordt gelegd met audio-mogelijkheden (zoals Max for Live).
Voordelen:
* veel online documentatie te vinden, tutorials, ...
Nadelen:
* enkel voor MacOS
* opnieuw grafisch programmeren adhv dataflow
Voordelen:
* veel online documentatie te vinden, tutorials, ...
Nadelen:
* enkel voor MacOS
* opnieuw grafisch programmeren adhv dataflow
maandag 12 oktober 2009
Reeds bestaande hardware
lemur
Akai APC40
Monome
Novation Launchpad
ReacTable:
Een groot rond multitouch display (76 cm diameter) gebaseerd op een camera-projector systeem. Muziek wordt gemaakt door de plaatsing van objecten op het scherm. Er zijn 4 categorieën van objecten: sound generators, sound filters/effects, controllers en global objects.
Een generator is te herkennen aan z'n vierkante vorm. Draaien verandert de frequentie, met een vinger een bolletje op de omgevende cirkel bewegen past de amplitude van het signaal aan.
Filters kunnen herkend worden aan een vierkant object met afgeronde hoeken. Ze hebben slechts invloed op geluidsbronnen wanneer ze in hun nabijheid gebracht worden.
Ronde objecten zijn de controllers, die controledata zenden naar het dichtsbijzijnde object.
Met globale objecten kunnen parameters van de tafel aangepast worden, zoals bv. BPM.
De geluidsgolven die veroorzaakt worden worden visueel voorgesteld als de verbindingen tussen de objecten.
Aanpassingen aan bepaalde componenten, zoals een verandering van golfvorm, kunnen ook met de vinger gedaan worden door in dit geval de nieuwe golfvorm op het scherm te tekenen.
AudioTouch OS
AudioTouch OS is een systeem dat 4 muziekapplicaties aanbiedt op een tabletop. Een eerste applicatie geeft 2 keyboards (ééntje van 1 octaaf en een ander van 2 octaven). Een volgende applicatie is MusicalSquares: een aantal vierkanten worden losgelaten in een rechthoek. Telkens wanneer vierkanten met elkaar botsen, wordt er een muzieknoot afgespeeld. Hierbij kan het traject van die vierkanten ook gewijzigd worden door ze vast te nemen en in een zelfgekozen richting te 'gooien'.
De derde applicatie is Audioshape sequencer. Een sequencer wordt gevormd door een lus te maken van vierkanten.
De laatste applicatie is Musical Wong, dat muziek genereert op basis van het spel pong. Wanneer het object de muren raakt, wordt er telkens een verschillend geluid afgespeeld.
demonstratie
Akai APC40
Monome
Novation Launchpad
ReacTable:
Een groot rond multitouch display (76 cm diameter) gebaseerd op een camera-projector systeem. Muziek wordt gemaakt door de plaatsing van objecten op het scherm. Er zijn 4 categorieën van objecten: sound generators, sound filters/effects, controllers en global objects.
Een generator is te herkennen aan z'n vierkante vorm. Draaien verandert de frequentie, met een vinger een bolletje op de omgevende cirkel bewegen past de amplitude van het signaal aan.
Filters kunnen herkend worden aan een vierkant object met afgeronde hoeken. Ze hebben slechts invloed op geluidsbronnen wanneer ze in hun nabijheid gebracht worden.
Ronde objecten zijn de controllers, die controledata zenden naar het dichtsbijzijnde object.
Met globale objecten kunnen parameters van de tafel aangepast worden, zoals bv. BPM.
De geluidsgolven die veroorzaakt worden worden visueel voorgesteld als de verbindingen tussen de objecten.
Aanpassingen aan bepaalde componenten, zoals een verandering van golfvorm, kunnen ook met de vinger gedaan worden door in dit geval de nieuwe golfvorm op het scherm te tekenen.
AudioTouch OS
AudioTouch OS is een systeem dat 4 muziekapplicaties aanbiedt op een tabletop. Een eerste applicatie geeft 2 keyboards (ééntje van 1 octaaf en een ander van 2 octaven). Een volgende applicatie is MusicalSquares: een aantal vierkanten worden losgelaten in een rechthoek. Telkens wanneer vierkanten met elkaar botsen, wordt er een muzieknoot afgespeeld. Hierbij kan het traject van die vierkanten ook gewijzigd worden door ze vast te nemen en in een zelfgekozen richting te 'gooien'.
De derde applicatie is Audioshape sequencer. Een sequencer wordt gevormd door een lus te maken van vierkanten.
De laatste applicatie is Musical Wong, dat muziek genereert op basis van het spel pong. Wanneer het object de muren raakt, wordt er telkens een verschillend geluid afgespeeld.
demonstratie
zondag 11 oktober 2009
Max/MSP
Max/MSP is een grafische ontwerpomgeving voor muziek & video, ontworpen door de man achter Pure Data en daardoor ook heel verwant hieraan. Het programmeren gaat op dezelfde manier als bij Pure Data, hoewel de bibliotheek van Max ook grafische componenten bevat zoals sliders, knoppen, menu's om de patch te kunnen besturen. Een andere interessante meerwaarde van Max/MSP t.o.v. Pure Data is Max for Live, dat eigenlijk de integratie is van Max in Ableton Live. Hierdoor is het dus mogelijk geworden om eigen synths en effecten te ontwerpen als zijnde een Live-plugin. Daarnaast kunnen bestaande Abletonmodules ook aangepast worden. In het kader van deze thesis zou dit de mogelijk bieden om op basis van touch events bepaalde modules te bedienen. De Live API bevat 4 objecten (live.path, live.observer, live.object en live.remote) waarmee alle UI componenten binnen Ableton Live bestuurd kunnen worden.
Voordelen:
* Max for Live!
Nadelen:
* dataflow-programmatie, geen OOP
Voordelen:
* Max for Live!
Nadelen:
* dataflow-programmatie, geen OOP
zaterdag 10 oktober 2009
Pure Data (Pd)
Pure Data is een opensource grafische programmeertaal waarmee interactieve computermuziek kan worden gemaakt. Het is een dataflow-taal (zoals Max/MSP). De bedoeling is dat de programmeur aan de hand van 4 basiscomponenten (messages, objects, atoms, and comments) een soort van petrinet opstelt dat doorlopen wordt door controleberichten en audiosignalen van boven naar beneden. Pd is in staat harmonische golven te genereren, de frequentie hiervan aan te passen, amplitudes te veranderen, ... en hieruit muziek te produceren. Dit lijkt fel op het principe dat bij reacTable gebruikt wordt: de karakteristieken van de muziek kunnen gewijzigd worden door een object van plaats te veranderen, te draaien of weg te nemen. Programma's in elkaar steken die niet op muziek gericht zijn, lijkt me vrij moeilijk met deze taal.
Voordelen:
* Pd kan direct muziek produceren uitgaande van touch events
Nadelen:
* dataflow, totaal andere manier van programmeren ivm OOP
Voordelen:
* Pd kan direct muziek produceren uitgaande van touch events
Nadelen:
* dataflow, totaal andere manier van programmeren ivm OOP
Processing
Processing is een open-source programmeertaal, die als library kan gebruikt worden in een Java-omgeving en zo gebruik maakt van de grafische capaciteiten van Java. Processing kan bijgevolg op elk platform gebruikt worden. Verder zijn er veel boeken en tutorials met voorbeelden beschikbaar en wordt de taal online heel uitgebreid gedocumenteerd. Leren werken met deze taal lijkt me vrij gemakkelijk mits de grondige kennis van Java.
Processing heeft ook een 'sketchbook', een soort van minimale IDE om kleine applicaties te ontwikkelen. Voor geavanceerd gebruik raadt men uiteraard Eclipse aan.
Op de TUIO-site wordt een java-klasse aangeboden die de interface TuioListener implementeert en bovenop de Processing-applicatie luistert naar inkomende TUIO-data. Naast deze interface biedt de TUIO Java API nog 5 andere klassen aan. TuioClient is de centrale component en luistert op poort 3333 naar inkomende UDP-pakketten met TUIO-berichten. Deze info wordt dan als TUIO events doorgestuurd naar de klassen die zich bij TuioClient geregistreerd hebben. De info wordt doorgestuurd met object van TuioPoint (met als subklassen TuioCursor en TuioObject) die o.a. coördinaten, hoeken en snelheden opslaat. Tenslotte is er TuioTime die de duur van de sessie aangeeft.
Voordelen:
* gebaseerd op Java
* goed gedocumenteerd, veel tutorials voorhanden
Nadelen:
?
Processing heeft ook een 'sketchbook', een soort van minimale IDE om kleine applicaties te ontwikkelen. Voor geavanceerd gebruik raadt men uiteraard Eclipse aan.
Op de TUIO-site wordt een java-klasse aangeboden die de interface TuioListener implementeert en bovenop de Processing-applicatie luistert naar inkomende TUIO-data. Naast deze interface biedt de TUIO Java API nog 5 andere klassen aan. TuioClient is de centrale component en luistert op poort 3333 naar inkomende UDP-pakketten met TUIO-berichten. Deze info wordt dan als TUIO events doorgestuurd naar de klassen die zich bij TuioClient geregistreerd hebben. De info wordt doorgestuurd met object van TuioPoint (met als subklassen TuioCursor en TuioObject) die o.a. coördinaten, hoeken en snelheden opslaat. Tenslotte is er TuioTime die de duur van de sessie aangeeft.
Voordelen:
* gebaseerd op Java
* goed gedocumenteerd, veel tutorials voorhanden
Nadelen:
?
vrijdag 9 oktober 2009
TUIO client implementaties
overzicht van de belangrijkste programmeeromgevingen waarvoor er TUIO-libraries zijn:
* C++
* Java (libTUIO.jar)
* C#
* Flash ActionScript3
* Python
* Processing
* Pure Data
* Max/MSP
* Quartz Composer
C++, Java, C# en Python hebben het voordeel dat het relatief snel gaat om tot een textueel programma te komen, maar het nadeel dat het veel omslachtiger is en dus meer tijd in beslag neemt dan Flash en Processing op het gebied van GUI's. In het rijtje van Pure Data, Max/MSP en Quartz Composer blijkt Max/MSP dan weer zeer geschikt om touch events te verwerken en zo eventueel Ableton Live te bedienen, maar Pd en Max/MSP blijken in het algemeen niet of minder geschikt voor het ontwerp van een GUI.
* C++
* Java (libTUIO.jar)
* C#
* Flash ActionScript3
* Python
* Processing
* Pure Data
* Max/MSP
* Quartz Composer
C++, Java, C# en Python hebben het voordeel dat het relatief snel gaat om tot een textueel programma te komen, maar het nadeel dat het veel omslachtiger is en dus meer tijd in beslag neemt dan Flash en Processing op het gebied van GUI's. In het rijtje van Pure Data, Max/MSP en Quartz Composer blijkt Max/MSP dan weer zeer geschikt om touch events te verwerken en zo eventueel Ableton Live te bedienen, maar Pd en Max/MSP blijken in het algemeen niet of minder geschikt voor het ontwerp van een GUI.
maandag 5 oktober 2009
Paper: A Multitouch Software Architecture
Paper geschreven door Echtler & Klinker (TU München, 2008).
Zij stellen een algemene softwarearchitectuur voor voor multitouch systemen met als hoofddoel de draagbaarheid van bestaande software over verschillende hardwaresystemen (FTIR/lasers/DI/... met bijhorende camera's) te vergroten door een minimale verandering. Ook willen ze door deze architectuur een high-level API aanbieden.
Hoe ziet de architectuur eruit?
1. hardware abstractie laag: krijgt van de camera's onbewerkte data binnen en probeert vinger- en handposities te detecteren
2. transformatielaag: voert allerhande berekeningen uit: o.a. conversie van cameracoördinaten naar schermcoördinaten, calibratie,...
3. interpretatielaag: gaat op zoek naar bewegingen door opeenvolgende beelden te analyseren
4. widgetlaag: krijgt de handelingen door van de interpretatielaag en genereert hiermee zichtbare output naar de gebruiker toe
Laag 1 is typisch de tracker applicatie (touchLib/touché/CCV/...) die via het TUIO protocol z'n gegevens doorgeeft naar de client applicatie die output gaat genereren. Meestal zitten laag 2, 3 en 4 vervat in het framework aan de applicatiezijde.
De softwarelibraries die ontwikkeld werden vooraleer deze architectuur bestond zijn duidelijk gericht op het TUIO protocol: een tracker applicatie verzamelt gegevens en die worden verstuurd via TUIO naar een client applicatie. Echtler & Klinker proberen met hun nieuwe architectuur te gaan naar een 4-delig schema waarbij deze onderdelen gedistribueerd kunnen samenwerken. Berichten worden hierbij via UDP-pakketten verstuurd, wat volgens hen slechts een relatief kleine latency oplevert. TISCH is een implementatie van deze architectuur, maar zit nog in een beginfase en wordt voorlopig online weinig of niet gedocumenteerd. De implementatie is gebaseerd op C++ in combinatie met OpenGL wegens de hoge performantie, de draagbaarheid over verschillende platformen en de hoge grafische prestaties.
Zij stellen een algemene softwarearchitectuur voor voor multitouch systemen met als hoofddoel de draagbaarheid van bestaande software over verschillende hardwaresystemen (FTIR/lasers/DI/... met bijhorende camera's) te vergroten door een minimale verandering. Ook willen ze door deze architectuur een high-level API aanbieden.
Hoe ziet de architectuur eruit?
1. hardware abstractie laag: krijgt van de camera's onbewerkte data binnen en probeert vinger- en handposities te detecteren
2. transformatielaag: voert allerhande berekeningen uit: o.a. conversie van cameracoördinaten naar schermcoördinaten, calibratie,...
3. interpretatielaag: gaat op zoek naar bewegingen door opeenvolgende beelden te analyseren
4. widgetlaag: krijgt de handelingen door van de interpretatielaag en genereert hiermee zichtbare output naar de gebruiker toe
Laag 1 is typisch de tracker applicatie (touchLib/touché/CCV/...) die via het TUIO protocol z'n gegevens doorgeeft naar de client applicatie die output gaat genereren. Meestal zitten laag 2, 3 en 4 vervat in het framework aan de applicatiezijde.
De softwarelibraries die ontwikkeld werden vooraleer deze architectuur bestond zijn duidelijk gericht op het TUIO protocol: een tracker applicatie verzamelt gegevens en die worden verstuurd via TUIO naar een client applicatie. Echtler & Klinker proberen met hun nieuwe architectuur te gaan naar een 4-delig schema waarbij deze onderdelen gedistribueerd kunnen samenwerken. Berichten worden hierbij via UDP-pakketten verstuurd, wat volgens hen slechts een relatief kleine latency oplevert. TISCH is een implementatie van deze architectuur, maar zit nog in een beginfase en wordt voorlopig online weinig of niet gedocumenteerd. De implementatie is gebaseerd op C++ in combinatie met OpenGL wegens de hoge performantie, de draagbaarheid over verschillende platformen en de hoge grafische prestaties.
Flash ActionScript 3.0
Flash is een multimedia-omgeving waarbij Actionscript 3 wordt gebruikt om cross-platform desktopapplicaties te creëren. Een eerste probleem is dat Flash niet rechtstreeks blob-data kan ontvangen van trackers. Waarom niet? TUIO is gebaseerd op UDP en Actionscript kan niet overweg met UDP sockets, enkel XML sockets (TCP) en binaire sockets. Daarom moet de TUIO-data langs de FLOSC gateway passeren, die OSC omzet in XML. De meeste trackers doen het op deze manier, maar Community Core Vision (CCV) kan het sinds de laatste versie (v1.2.0 (2009-04-28)) ook rechtstreeks (zie quote uit de changelog.txt). Ook touché kan het ondertussen rechtstreeks.
Communication
* TUIO direct to Flash sending through TCP - Can now send TUIO to flash without FLOSC (currently doesn't work on Windows Vista for unknown reason)
Voordelen:
* Veel uitgewerkte voorbeelden beschikbaar
* Actionscript kan ook gebruikt worden voor Adobe Flex
* Objectgeöriënteerd programmeren
Nadelen:
* passeren langs FLOSC gateway (niet bij CCV of touché)
zaterdag 3 oktober 2009
Designing the user interface (Shneiderman)
enkele richtlijnen bij het ontwerp van user interfaces:
* opstellen van gebruikersprofielen (p. 67): "wie zijn de gebruikers?" De gebruikers kunnen ingedeeld worden in verschillende categorieën (novice/intermittent/frequent users) op basis van ervaring, maar verschillen ook op gebied van leeftijd, fysieke mogelijkheden, culturele achtergrond, opleiding, ...
Vroeg in het ontwerpproces is het dus belangrijk de gebruikers zo goed mogelijk te kennen.
* omschrijving van de uit te voeren taken ('task profile', p. 70): "wat wil de gebruiker doen?" Bepalen van een verzameling van atomische acties die samen een taak kunnen vormen --> niet eenvoudig! --> atomische acties mogen niet te groot zijn (om perfect te kunnen doen wat de gebruiker van het systeem vraagt) en ook niet te klein (om hoog aantal acties voor 1 taak te vermijden)
* 8 gouden regels voor interface-ontwerp (p. 74): 1. consistentie 2. gebruik van shortcuts voor frequente gebruikers 3. informatieve feedback aanbieden 4. ontwerp van dialogen 5. eenvoudig afhandelen van errors 6. toestaan om acties eenvoudig ongedaan te maken 7. gebruiker moet controle hebben over de acties, niet omgekeerd: verrassende systeemacties en het niet in staat zijn bepaalde informatie op te vragen bv. leiden tot ongenoegen 8. vermijd belasting van het kortetermijngeheugen
* opstellen van een richtlijnendocument ('guidelines document', p. 100): document dat heel praktisch richtlijnen beschrijft voor woorden en iconen (terminologie, lettertype, kleurengebruik,...), layout, I/O apparaten, opeenvolging van acties (syntax, voorgeprogrammeerde functies, afhandelen van errors,...) en training (ivm tutorials en handleidingen).
belangrijke aandachtspunten bij de evaluatie van user interfaces:
* 5 meetbare criteria (p. 15): 1. leertijd 2. tijd nodig om taak uit te voeren 3. aantal en soort errors 4. tijd dat de gebruikers onthouden hoe ze een taak moeten uitvoeren 5. subjectieve voldoening: vindt de gebruiker het tof om met deze interface te werken?
* aantal manieren van evaluatie mogelijk: evaluatie door experten (verschillende methodes mogelijk), usability testing, surveys, evaluatie door actief gebruik (bv logging van performantie)
* opstellen van gebruikersprofielen (p. 67): "wie zijn de gebruikers?" De gebruikers kunnen ingedeeld worden in verschillende categorieën (novice/intermittent/frequent users) op basis van ervaring, maar verschillen ook op gebied van leeftijd, fysieke mogelijkheden, culturele achtergrond, opleiding, ...
Vroeg in het ontwerpproces is het dus belangrijk de gebruikers zo goed mogelijk te kennen.
* omschrijving van de uit te voeren taken ('task profile', p. 70): "wat wil de gebruiker doen?" Bepalen van een verzameling van atomische acties die samen een taak kunnen vormen --> niet eenvoudig! --> atomische acties mogen niet te groot zijn (om perfect te kunnen doen wat de gebruiker van het systeem vraagt) en ook niet te klein (om hoog aantal acties voor 1 taak te vermijden)
* 8 gouden regels voor interface-ontwerp (p. 74): 1. consistentie 2. gebruik van shortcuts voor frequente gebruikers 3. informatieve feedback aanbieden 4. ontwerp van dialogen 5. eenvoudig afhandelen van errors 6. toestaan om acties eenvoudig ongedaan te maken 7. gebruiker moet controle hebben over de acties, niet omgekeerd: verrassende systeemacties en het niet in staat zijn bepaalde informatie op te vragen bv. leiden tot ongenoegen 8. vermijd belasting van het kortetermijngeheugen
* opstellen van een richtlijnendocument ('guidelines document', p. 100): document dat heel praktisch richtlijnen beschrijft voor woorden en iconen (terminologie, lettertype, kleurengebruik,...), layout, I/O apparaten, opeenvolging van acties (syntax, voorgeprogrammeerde functies, afhandelen van errors,...) en training (ivm tutorials en handleidingen).
belangrijke aandachtspunten bij de evaluatie van user interfaces:
* 5 meetbare criteria (p. 15): 1. leertijd 2. tijd nodig om taak uit te voeren 3. aantal en soort errors 4. tijd dat de gebruikers onthouden hoe ze een taak moeten uitvoeren 5. subjectieve voldoening: vindt de gebruiker het tof om met deze interface te werken?
* aantal manieren van evaluatie mogelijk: evaluatie door experten (verschillende methodes mogelijk), usability testing, surveys, evaluatie door actief gebruik (bv logging van performantie)
Abonneren op:
Posts (Atom)