zaterdag 26 december 2009
woensdag 16 december 2009
Resultaten usability tests
Gebruiker 1
heeft brede IT-kennis en heeft al met Ableton gewerkt
testscenario's:
1) De gebruiker grijpt meteen naar de Settings-knop en past daar de slider van muzikant 4 aan. Test wordt helemaal tot een goed einde gebracht.
2) De gebruiker legt onmiddellijk de link tussen de startknop en de sequencer die rond het middenpanel gebouwd is. De plaatsing van deze knoppen op de huidige positie lijkt dus eerder logisch voor deze persoon.
3) Hij probeert de hihats te verwijderen door ze aan te raken. Dit was niet de voorziene actie om instrumenten te verwijderen (bij aanraken zou het effectenvenster verschijnen). Zijn argument was vooral de snelheid van handelen: het is belangrijk, zeker bij een live performance, om snel instrumenten te kunnen verwijderen en toevoegen.
Daarop heb ik dan nog de vraag gesteld of het gemakkelijk zou werken wanneer een instrument telkens naar een vuilbakicoon gesleept moet worden om het te verwijderen. Het antwoord was negatief: het duurt te lang en er zou telkens naar 1 bepaald punten gesleept moeten worden, wat niet altijd vlot gaat wanneer er meerdere mensen op dezelfde plaats moeten samenwerken.
4) Dit probleem werd door de gebruiker als volgt aangepakt. Hij koos eerst voor het instrumentenvenster en raakte dan het instrument aan dat hij wou plaatsen op de sequencer. Daarna koos hij de posities op de sequencer door die aan te raken. Na het plaatsen tikt hij opnieuw het instrument aan om aan te geven dat het plaatsen voorbij is. Dit is een totaal andere manier van werken dan de beoogde wijze, maar is wel efficiënter. Het probleem bij deze aanpak zijn de andere muzikanten. Als 2 muzikanten tegelijkertijd een instrument kiezen om op de sequencer te plaatsen, dan is het bijna onmogelijk om te weten welk instrument er geplaatst moet worden in de sequencer wanneer 1 muzikant een positie kiest.
5) Bij dit scenario is de werkwijze volledig duidelijk. Het effectenvenster wordt onmiddellijk gevonden door een instrument aan te raken. De bediening van de elementen is ook intuïtief.
vragen achteraf:
Een eerste opmerking van deze testgebruiker gaat over de taken van elke muzikant. Volgens hem is het misschien beter om vooraf onderling rollen af te spreken (bv. muzikant die zich bezig houdt met de drums, andere dan weer met melodie, ...)
Een tweede opmerking gaat over de scheiding drums-melodie. Het zou beter zijn volgens hem om deze twee gescheiden te houden en elke gebruiker eventueel een synth te geven gekoppeld aan een sequencer om de melodielijn te bepalen. Volgens mij is het uit elkaar halen van drums-melodie slechts gedeeltelijk mogelijk, omdat het eigenlijk niet de bedoeling is de sequencer meerdere keren te kopiëren. Dit zou teveel overhead geven en de beschikbare ruimte om andere dingen te doen beperken. Een mogelijk compromis is het tonen van een uitgebreide synth wanneer de effecten opgevraagd worden van bv. een synth bass op de sequencer.
Gebruiker 2
brede IT-kennis en enige ervaring met Fruity Loops
testscenario's:
1) De Settings-knop wordt na enige aarzeling gevonden en de testgebruiker past daarna zonder moeite het volume aan via de slider. Test geslaagd.
2) Dit scenario wordt heel snel uitgevoerd. De gebruiker verwachtte zelfs dat het middenstuk gedraaid kon worden in zijn richting, wat ook volledig de bedoeling is.
3) De gebruiker verwacht een instrument te kunnen wegslepen van de sequencer en dat deze dan buiten de cirkel ergens blijven 'zweven' zodat ze later nog opnieuw gebruikt kunnen worden als ze opnieuw nodig zijn. Dit is niet zoals de applicatie zich op dit moment gedraagt. Test gefaald in principe, maar deze manier van werken lijkt nog wel een te overwegen alternatief. Hoewel in dit geval er wel een andere manier moet voorzien worden om instrumenten effectief van de tabletop te verwijderen.
4) De gebruiker kiest voor het instrumentenmenu en probeert elke kick apart naar de sequencer te slepen. Dit is een mogelijke manier om het aan te pakken, maar dan wordt er voor elke kick een aparte effectenmodule gemaakt en dat maakt het toepassen van effecten omslachtiger. In een volledig functionele en werkelijke opstelling zou dit apart toevoegen van elke kick ook niet efficiënt genoeg werken.
5) Het oproepen van het effectenvenster wordt gedaan door tweemaal snel het gewenste instrument aan te raken ('dubbelklikken'). Het gebruik van de verschillende elementen van de effectenmodule verloopt volledig volgens het geplande scenario.
heeft brede IT-kennis en heeft al met Ableton gewerkt
testscenario's:
1) De gebruiker grijpt meteen naar de Settings-knop en past daar de slider van muzikant 4 aan. Test wordt helemaal tot een goed einde gebracht.
2) De gebruiker legt onmiddellijk de link tussen de startknop en de sequencer die rond het middenpanel gebouwd is. De plaatsing van deze knoppen op de huidige positie lijkt dus eerder logisch voor deze persoon.
3) Hij probeert de hihats te verwijderen door ze aan te raken. Dit was niet de voorziene actie om instrumenten te verwijderen (bij aanraken zou het effectenvenster verschijnen). Zijn argument was vooral de snelheid van handelen: het is belangrijk, zeker bij een live performance, om snel instrumenten te kunnen verwijderen en toevoegen.
Daarop heb ik dan nog de vraag gesteld of het gemakkelijk zou werken wanneer een instrument telkens naar een vuilbakicoon gesleept moet worden om het te verwijderen. Het antwoord was negatief: het duurt te lang en er zou telkens naar 1 bepaald punten gesleept moeten worden, wat niet altijd vlot gaat wanneer er meerdere mensen op dezelfde plaats moeten samenwerken.
4) Dit probleem werd door de gebruiker als volgt aangepakt. Hij koos eerst voor het instrumentenvenster en raakte dan het instrument aan dat hij wou plaatsen op de sequencer. Daarna koos hij de posities op de sequencer door die aan te raken. Na het plaatsen tikt hij opnieuw het instrument aan om aan te geven dat het plaatsen voorbij is. Dit is een totaal andere manier van werken dan de beoogde wijze, maar is wel efficiënter. Het probleem bij deze aanpak zijn de andere muzikanten. Als 2 muzikanten tegelijkertijd een instrument kiezen om op de sequencer te plaatsen, dan is het bijna onmogelijk om te weten welk instrument er geplaatst moet worden in de sequencer wanneer 1 muzikant een positie kiest.
5) Bij dit scenario is de werkwijze volledig duidelijk. Het effectenvenster wordt onmiddellijk gevonden door een instrument aan te raken. De bediening van de elementen is ook intuïtief.
vragen achteraf:
Een eerste opmerking van deze testgebruiker gaat over de taken van elke muzikant. Volgens hem is het misschien beter om vooraf onderling rollen af te spreken (bv. muzikant die zich bezig houdt met de drums, andere dan weer met melodie, ...)
Een tweede opmerking gaat over de scheiding drums-melodie. Het zou beter zijn volgens hem om deze twee gescheiden te houden en elke gebruiker eventueel een synth te geven gekoppeld aan een sequencer om de melodielijn te bepalen. Volgens mij is het uit elkaar halen van drums-melodie slechts gedeeltelijk mogelijk, omdat het eigenlijk niet de bedoeling is de sequencer meerdere keren te kopiëren. Dit zou teveel overhead geven en de beschikbare ruimte om andere dingen te doen beperken. Een mogelijk compromis is het tonen van een uitgebreide synth wanneer de effecten opgevraagd worden van bv. een synth bass op de sequencer.
Gebruiker 2
brede IT-kennis en enige ervaring met Fruity Loops
testscenario's:
1) De Settings-knop wordt na enige aarzeling gevonden en de testgebruiker past daarna zonder moeite het volume aan via de slider. Test geslaagd.
2) Dit scenario wordt heel snel uitgevoerd. De gebruiker verwachtte zelfs dat het middenstuk gedraaid kon worden in zijn richting, wat ook volledig de bedoeling is.
3) De gebruiker verwacht een instrument te kunnen wegslepen van de sequencer en dat deze dan buiten de cirkel ergens blijven 'zweven' zodat ze later nog opnieuw gebruikt kunnen worden als ze opnieuw nodig zijn. Dit is niet zoals de applicatie zich op dit moment gedraagt. Test gefaald in principe, maar deze manier van werken lijkt nog wel een te overwegen alternatief. Hoewel in dit geval er wel een andere manier moet voorzien worden om instrumenten effectief van de tabletop te verwijderen.
4) De gebruiker kiest voor het instrumentenmenu en probeert elke kick apart naar de sequencer te slepen. Dit is een mogelijke manier om het aan te pakken, maar dan wordt er voor elke kick een aparte effectenmodule gemaakt en dat maakt het toepassen van effecten omslachtiger. In een volledig functionele en werkelijke opstelling zou dit apart toevoegen van elke kick ook niet efficiënt genoeg werken.
5) Het oproepen van het effectenvenster wordt gedaan door tweemaal snel het gewenste instrument aan te raken ('dubbelklikken'). Het gebruik van de verschillende elementen van de effectenmodule verloopt volledig volgens het geplande scenario.
zondag 13 december 2009
Usability tests
mogelijke kritieke problemen van een interface (deze problemen moeten adhv tests blootgelegd worden):
* ontbreken van functionaliteiten om een bepaalde taak te kunnen uitvoeren
* uitvoeren van een taak faalt ("Kan een testgebruiker een opgelegde taak tot een goed einde brengen?") bij meerdere gebruikers
* interface wordt niet geapprecieerd door meerdere gebruikers (subjectieve voldoening)
manier van testen:
* enkel observeren: de testgebruiker probeert een taak uit te voeren en de designer van de interface observeert enkel wat de tester doet. Deze aanpak werkt enkel goed bij een volledig functioneel prototype, maar is wel handig om de tijd, nodig om de taak uit te voeren, te meten
* think-aloud test: een testgebruiker laten interageren met een paper mock-up terwijl hij hardop nadenkt en zegt wat hij verwacht hoe de applicatie gaat reageren.
* cooperation: 2 testgebruikers werken samen aan eenzelfde taak en worden gevraagd om in discussie te gaan tijdens het uitvoeren van de taak
Opstellen van testscenario's
Aan welke criteria moet een testscenario voldoen?
* het moet een realistische taak zijn die typisch vaak uitgevoerd wordt met het systeem
* een gesloten taak: een taak waarmee de gebruiker op het einde echt iets bereikt (bv het toevoegen van een nieuw instrument aan de sequencer)
* geen hints over hoe een taak uitgevoerd moet worden
Testscenario's voor de tabletop
eerst enkele gemakkelijke taken:
1) De compositie van de vierde muzikant is momenteel niet hoorbaar. Pas dit aan zodanig dat de compositie van deze persoon maximaal hoorbaar wordt. (Deze test moet duidelijk maken of de plaatsing van de volumes onder de 'Settings'-knop logisch is en hoe snel de gebruiker de link settings-volume legt. Bij deze test is de eerste reactie heel belangrijk: waar verwacht de tester deze aanpassing te kunnen doen?)
2) U als muzikant hebt zojuist een bepaalde compositie gemaakt en zou deze graag eens laten lopen om te horen wat u er van gemaakt hebt. (Hier wordt gekeken of de gebruiker onmiddellijk naar de startknop in het midden van het scherm gaat grijpen of ergens anders gaat zoeken)
3) Er is een bepaalde compositie gemaakt met verschillende instrumenten, maar alle hihats zouden verwijderd moeten worden uit deze compositie. Probeer dit uit te voeren. (Testen hoe de testgebruiker verwacht de instrumenten te kunnen verwijderen. Gaat hij expliciet op zoek naar een verwijderknop, verwacht hij de instrumenten ergens naar toe te kunnen slepen of ziet hij het nog anders?)
meer geavanceerd:
4) U bent van plan om een compositie te maken van 4 kicks, dus 1 kick op elke tel. Probeer dit uit te voeren op de tabletop en start de gemaakte compositie. (Nagaan of het logisch is om instrumenten vanuit de instrumentenlijst te slepen naar de sequencer en hoe de gebruiker de instrumenten op meerdere plaatsen op de sequencer gaat zetten. Kiest hij om elke kopie van het instrument vanuit het instrumentenpanel in de sequencer te slepen of gaat hij eerder proberen om het vanaf de sequencer te kopiëren? Dit laatste is de beoogde manier van werken, maar tests zullen uitwijzen of dit wel de beste manier is.)
5) Er is een bepaalde compositie gemaakt met shakers en kicks. De geluidseigenschappen van de shakers zouden aangepast moeten worden (toon aan hoe deze eigenschappen volgens u gemanipuleerd kunnen worden) en het volume van de shakers zou gehalveerd moeten worden. Probeer dit uit te voeren op de tabletop. (Waar gaat de gebruiker het effectenvenster zoeken? Is het logisch dat het venster verschijnt als er op een instrument geduwd wordt? Verder wordt er gecontroleerd dat het voorstellen van de envelope intuïtief genoeg is. Normaal is het de bedoeling de envelope te manipuleren door de curve te verslepen.)
enkele vragen achteraf:
Welk gevoel geeft het werken met deze applicatie? Zit het systeem van werken vreemd in mekaar of is het eerder logisch?
Op welke punten kan de interface nog verbeterd worden? Is het uitvoeren van bepaalde taken soms te omslachtig?
Er moet nog een manier gevonden worden om de BPM aan te passen. Welke manier lijkt volgens u het meest aangeraden? 1) via een slider 2) een draaiknop 3) door nummers te tekenen op het scherm die dan herkend worden door de applicatie
Welke instructies krijgen de testgebruikers op voorhand?
Belangrijk is te weten tot welke categorie de testgebruikers behoren (veel of weinig/geen voorkennis van het producen van muziek). Mensen met echt helemaal geen voorkennis (worst case) krijgen eerst een introductie over de concepten 'sequencer', virtuele instrumenten, effecten en filters zonder hierbij al de link te leggen naar de applicatie op de tabletop. Personen met enige voorkennis krijgen een minimale opfrissing van deze concepten.
Hoeveel testgebruikers?
Sommige CHI-experts zeggen ten minste 10 testgebruikers om statistische significantie te hebben, maar dit vraagt veel tijd. Anderen zeggen dan weer dat 3 testgebruikers ook al volstaan om usability problemen te ontdekken.
* ontbreken van functionaliteiten om een bepaalde taak te kunnen uitvoeren
* uitvoeren van een taak faalt ("Kan een testgebruiker een opgelegde taak tot een goed einde brengen?") bij meerdere gebruikers
* interface wordt niet geapprecieerd door meerdere gebruikers (subjectieve voldoening)
manier van testen:
* enkel observeren: de testgebruiker probeert een taak uit te voeren en de designer van de interface observeert enkel wat de tester doet. Deze aanpak werkt enkel goed bij een volledig functioneel prototype, maar is wel handig om de tijd, nodig om de taak uit te voeren, te meten
* think-aloud test: een testgebruiker laten interageren met een paper mock-up terwijl hij hardop nadenkt en zegt wat hij verwacht hoe de applicatie gaat reageren.
* cooperation: 2 testgebruikers werken samen aan eenzelfde taak en worden gevraagd om in discussie te gaan tijdens het uitvoeren van de taak
Opstellen van testscenario's
Aan welke criteria moet een testscenario voldoen?
* het moet een realistische taak zijn die typisch vaak uitgevoerd wordt met het systeem
* een gesloten taak: een taak waarmee de gebruiker op het einde echt iets bereikt (bv het toevoegen van een nieuw instrument aan de sequencer)
* geen hints over hoe een taak uitgevoerd moet worden
Testscenario's voor de tabletop
eerst enkele gemakkelijke taken:
1) De compositie van de vierde muzikant is momenteel niet hoorbaar. Pas dit aan zodanig dat de compositie van deze persoon maximaal hoorbaar wordt. (Deze test moet duidelijk maken of de plaatsing van de volumes onder de 'Settings'-knop logisch is en hoe snel de gebruiker de link settings-volume legt. Bij deze test is de eerste reactie heel belangrijk: waar verwacht de tester deze aanpassing te kunnen doen?)
2) U als muzikant hebt zojuist een bepaalde compositie gemaakt en zou deze graag eens laten lopen om te horen wat u er van gemaakt hebt. (Hier wordt gekeken of de gebruiker onmiddellijk naar de startknop in het midden van het scherm gaat grijpen of ergens anders gaat zoeken)
3) Er is een bepaalde compositie gemaakt met verschillende instrumenten, maar alle hihats zouden verwijderd moeten worden uit deze compositie. Probeer dit uit te voeren. (Testen hoe de testgebruiker verwacht de instrumenten te kunnen verwijderen. Gaat hij expliciet op zoek naar een verwijderknop, verwacht hij de instrumenten ergens naar toe te kunnen slepen of ziet hij het nog anders?)
meer geavanceerd:
4) U bent van plan om een compositie te maken van 4 kicks, dus 1 kick op elke tel. Probeer dit uit te voeren op de tabletop en start de gemaakte compositie. (Nagaan of het logisch is om instrumenten vanuit de instrumentenlijst te slepen naar de sequencer en hoe de gebruiker de instrumenten op meerdere plaatsen op de sequencer gaat zetten. Kiest hij om elke kopie van het instrument vanuit het instrumentenpanel in de sequencer te slepen of gaat hij eerder proberen om het vanaf de sequencer te kopiëren? Dit laatste is de beoogde manier van werken, maar tests zullen uitwijzen of dit wel de beste manier is.)
5) Er is een bepaalde compositie gemaakt met shakers en kicks. De geluidseigenschappen van de shakers zouden aangepast moeten worden (toon aan hoe deze eigenschappen volgens u gemanipuleerd kunnen worden) en het volume van de shakers zou gehalveerd moeten worden. Probeer dit uit te voeren op de tabletop. (Waar gaat de gebruiker het effectenvenster zoeken? Is het logisch dat het venster verschijnt als er op een instrument geduwd wordt? Verder wordt er gecontroleerd dat het voorstellen van de envelope intuïtief genoeg is. Normaal is het de bedoeling de envelope te manipuleren door de curve te verslepen.)
enkele vragen achteraf:
Welk gevoel geeft het werken met deze applicatie? Zit het systeem van werken vreemd in mekaar of is het eerder logisch?
Op welke punten kan de interface nog verbeterd worden? Is het uitvoeren van bepaalde taken soms te omslachtig?
Er moet nog een manier gevonden worden om de BPM aan te passen. Welke manier lijkt volgens u het meest aangeraden? 1) via een slider 2) een draaiknop 3) door nummers te tekenen op het scherm die dan herkend worden door de applicatie
Welke instructies krijgen de testgebruikers op voorhand?
Belangrijk is te weten tot welke categorie de testgebruikers behoren (veel of weinig/geen voorkennis van het producen van muziek). Mensen met echt helemaal geen voorkennis (worst case) krijgen eerst een introductie over de concepten 'sequencer', virtuele instrumenten, effecten en filters zonder hierbij al de link te leggen naar de applicatie op de tabletop. Personen met enige voorkennis krijgen een minimale opfrissing van deze concepten.
Hoeveel testgebruikers?
Sommige CHI-experts zeggen ten minste 10 testgebruikers om statistische significantie te hebben, maar dit vraagt veel tijd. Anderen zeggen dan weer dat 3 testgebruikers ook al volstaan om usability problemen te ontdekken.
zaterdag 5 december 2009
Gebruikers- en takenprofiel
Gebruikers:
De gebruikers zijn typisch DJ's of personen met enige kennis van het producen van muziek (= personen met domein- en IT-kennis). Anderzijds zijn er ook gebruikers met weinig of geen voorkennis van het produceren van muziek (= personen met enkel IT-kennis), die bv. willen werken met de tabletop omwille van het multitouch-aspect. Het ontwerp van de interface moet dus uitgaan van deze laatste groep als worst case scenario. De interface moet ofwel eenvoudig blijven ofwel uitgebreid gedocumenteerd worden op niet-triviale punten (bv. het venster waarin de effecten gekozen worden kan voor een leek ingewikkeld lijken, terwijl dit voor een doorwinterde Ableton-gebruiker eerder vertrouwd en eenvoudig oogt). Met IT-kennis wordt een zeer beperkte ervaring met GUIs bedoeld.
Taken:
* algemene instellingen:
-- veranderen van globaal volume: de gebruiker moet in staat zijn om het globale muziekvolume aan te passen
-- veranderen van eigen volume relatief tov de anderen: de gebruiker kan er voor kiezen om het volume van zijn instrumenten te dempen of om de compositie van andere gebruikers zachter te laten doorklinken
-- instellen van het tempo: op een centrale plaats moet de gebruiker het tempo van het muziekstuk kunnen instellen
* sequencer
-- starten van de sequencer: de sequencer kan gestart worden op 1 centrale plaats op de tabletop waardoor de sequencer begint te lopen op de aangegeven plaats
-- stoppen van de sequencer: de sequencer kan gestopt worden op 1 centrale plaats op de tabletop
-- toevoegen van een muziekinstrument aan de sequencer: de gebruiker moet in staat zijn om een bepaald muziekinstrument te kiezen en dit op een bepaalde plaats in de sequencer in te voegen
-- kopiëren van instrumenten naar meerdere plaatsen in de sequencer: het moet mogelijk zijn om snel instrumenten te kopiëren in de sequencer zonder ze te selecteren in een bepaalde instrumentenlijst
-- verwijderen van een muziekinstrument: bezette plaatsen in de sequencer moeten snel leeggemaakt kunnen worden
* effecten
-- filter toepassen op een muziekbron: er kunnen 3 soorten filters toegepast worden op een virtuele muziekbron (high, low of bandpass filter) waarbij frequentie en resonantie ingesteld kunnen worden
-- envelope en oscillator aanpassen van de muziekbron
-- frequentie aanpassen van een muziekbron
-- instrumentvolume instellen: elk muziekinstrument afzonderlijk heeft een bepaald volume dat ingesteld kan worden ten opzichte van het volume van andere instrumenten
De gebruikers zijn typisch DJ's of personen met enige kennis van het producen van muziek (= personen met domein- en IT-kennis). Anderzijds zijn er ook gebruikers met weinig of geen voorkennis van het produceren van muziek (= personen met enkel IT-kennis), die bv. willen werken met de tabletop omwille van het multitouch-aspect. Het ontwerp van de interface moet dus uitgaan van deze laatste groep als worst case scenario. De interface moet ofwel eenvoudig blijven ofwel uitgebreid gedocumenteerd worden op niet-triviale punten (bv. het venster waarin de effecten gekozen worden kan voor een leek ingewikkeld lijken, terwijl dit voor een doorwinterde Ableton-gebruiker eerder vertrouwd en eenvoudig oogt). Met IT-kennis wordt een zeer beperkte ervaring met GUIs bedoeld.
Taken:
* algemene instellingen:
-- veranderen van globaal volume: de gebruiker moet in staat zijn om het globale muziekvolume aan te passen
-- veranderen van eigen volume relatief tov de anderen: de gebruiker kan er voor kiezen om het volume van zijn instrumenten te dempen of om de compositie van andere gebruikers zachter te laten doorklinken
-- instellen van het tempo: op een centrale plaats moet de gebruiker het tempo van het muziekstuk kunnen instellen
* sequencer
-- starten van de sequencer: de sequencer kan gestart worden op 1 centrale plaats op de tabletop waardoor de sequencer begint te lopen op de aangegeven plaats
-- stoppen van de sequencer: de sequencer kan gestopt worden op 1 centrale plaats op de tabletop
-- toevoegen van een muziekinstrument aan de sequencer: de gebruiker moet in staat zijn om een bepaald muziekinstrument te kiezen en dit op een bepaalde plaats in de sequencer in te voegen
-- kopiëren van instrumenten naar meerdere plaatsen in de sequencer: het moet mogelijk zijn om snel instrumenten te kopiëren in de sequencer zonder ze te selecteren in een bepaalde instrumentenlijst
-- verwijderen van een muziekinstrument: bezette plaatsen in de sequencer moeten snel leeggemaakt kunnen worden
* effecten
-- filter toepassen op een muziekbron: er kunnen 3 soorten filters toegepast worden op een virtuele muziekbron (high, low of bandpass filter) waarbij frequentie en resonantie ingesteld kunnen worden
-- envelope en oscillator aanpassen van de muziekbron
-- frequentie aanpassen van een muziekbron
-- instrumentvolume instellen: elk muziekinstrument afzonderlijk heeft een bepaald volume dat ingesteld kan worden ten opzichte van het volume van andere instrumenten
Ontwerpbeslissingen schets & paper mock-up
Eerste schets
De eerste schets werd gemaakt aan de hand van de functionele vereisten van de applicatie. De gebruiker moet in staat zijn instrumenten te kiezen waarmee hij wil werken. Verder moet er ergens een mogelijkheid zijn om een tijdsaspect te koppelen aan een instrument (op welk punt in de compositie moet het instrument hoorbaar zijn?) Hiervoor werd er initieel gedacht aan een tijdslijn. Daarnaast moet het mogelijk zijn om een globaal volume in te stellen en moet er een optie zijn om relatief gezien volumes in te stellen. Deze 3 aspecten worden gegroepeerd onder 3 verschillende knoppen op de tabletop die altijd zichtbaar blijven. Groot genoeg zodanig dat ze goed zichtbaar zijn (het zijn namelijk de hoofdknoppen) en dat ze gemakkelijk met een vinger geselecteerd kunnen worden.
De eerst knop groepeert de algemene instellingen (namen van de artiesten, BPM,...) en toont bijgevolg een venster waarin deze dingen veranderd kunnen worden.
De tweede button zorgt ervoor dat de tijdslijn verschijnt. Deze tijdslijn is er voor elke artiest en is eigenlijk een window dat een lijn bevat die begint bij seconde 0 en tot 60 seconden gaat. Het is hierbij de bedoeling dat de artiest een instrument kiest en deze koppelt aan de tijdslijn door ze vanuit het instrumentenvenster naar de tijdslijn te slepen. Waarom slepen? Het lijkt zeer logisch en intuïtief zeer gemakkelijk in te zien om op een tabletop de objecten zelf te slepen naar de locatie waar ze nodig zijn, eerder dan zoals in een muisgebaseerde omgeving alles met klikken te doen. Het verwijderen kan dan gebeuren door een instrument vast te nemen en het buiten het venster te slepen. Tests zullen moeten uitwijzen of dit logisch lijkt in de ogen van de gebruikers.
De derde button staat in voor de instrumenten. Bij het aanraken verschijnt er een scherm waarin de gebruiker kan scrollen om het gewenste instrument te zien. Dat instrument kan dan op de tijdslijn gesleept worden. Wanneer er een instrument op de tijdslijn gezet wordt, wordt het bijhorende icoon ook automatisch onderaan in de buttonlijst met de 3 buttons gezet.
Het effectenvenster kan opgeroepen worden door een instrument aan te raken in de buttonlijst onderaan. Dit venster bevat 4 onderdelen: een plaats waar de envelope en oscillatie aangepast kan worden, een draaiknop voor de frequentie van het instrument, een sectie waar de filter ingesteld kan worden aan de hand van draaiknoppen en een slider om het volume van het instrument in te stellen. Het manipuleren is in de eerste plaats gewoon gebaseerd op hoe dit in Ableton gebeurd, bv om de envelope in Ableton te veranderen volstaat het om een curve met de muis te verslepen. In het eerste ontwerp wordt hier dus gekozen om een curve met de vinger te verslepen. Voor Abletongebruikers komt dit zeer vertrouwd over en vermindert deze gelijkaardige aanpak de tijd om de applicatie te leren. Ook voor de sliders en draaiknoppen wordt in eerste instantie gekozen om deze op plaatsen te gebruiken waar dat ook bij Ableton het geval was. Usability tests moeten ook hier weer aantonen voor elk element of het gebruik ervan wel geschikt is op een tabletop.
Paper mock-up
De bedoeling van de paper mock-up is een papieren versie op ware grootte te maken van de applicatie waardoor de verhoudingen tussen vensters en widgets meteen duidelijk worden en er in zekere mate al geëxperimenteerd en getest kan worden. Na het bekijken van de eerste schets werden er al meteen enkele dingen aangepast:
1) de tijdslijn: wanneer er gewerkt wordt met de tijdslijn moet die zeer snel en efficiënt gaan. Dit kan niet wanneer de tijdslijn 1 minuut lang is en er voortdurend gescrolled en gezoomed moet worden. Na het zoomen moet dan weer op zoek gegaan worden naar de juiste positie om een instrument te kunnen plaatsen of verwijderen. Dit neemt allemaal te veel tijd in. Een mogelijke oplossing hiervoor: de tijdslijn korter maken en niet meer spreken over een minuut, maar slechts een maat. Een ander probleem met de tijdslijn is de redundantie op het scherm. Elke gebruiker heeft dezelfde tijdslijn nodig aangezien ze aan dezelfde compositie werken. Logischer zou zijn dat er maar 1 tijdslijn is die gebruikt kan worden door alle muzikanten tegelijkertijd. Bij deze oplossing is de oriëntatie nog een probleem. Hoe kan een venster getoond worden dat gemakkelijk werkt en leesbaar is voor alle gebruikers? De ideale oplossing hiervoor is een cirkel. Al deze ideeën samenbrengen leidt tot het totaal nieuwe ontwerp voor de tijdslijn dat nu eigenlijk een sequencer is geworden met 16 posities (maat van 1/16). Waarom 16 posities? 4 of 8 posities is te weinig, dit zou te veel lege ruimte laten in de cirkel ofwel ruimte verspillen door de iconen te groot te maken. De keuze ligt dan tussen 16 en 32 (enkel machten van 2) waarbij 16 de voorkeur krijgt omdat de sequencer dan nog altijd overzichtelijk blijft. Bij 32 posities zou het zoeken naar een instrument bv. niet meer efficiënt genoeg zijn, waardoor een muzikant zich snel gaat frustreren. Als we voor elke positie de mogelijkheid voorzien om 4 instrumenten te plaatsen, krijgen we 64 posities die opgevuld kunnen worden, maar dit zal zelfs in het worst case scenario niet het geval zijn. Rekening houdend met de 4 instrumenten per positie, de breedte van de tabletop en de grootte van de iconen op de sequencer lijkt de keuze voor 16 posities het meest aangewezen. Een mogelijk probleem hierbij is het fysieke aspect: wanneer meerdere gebruikers op dezelfde ruimte moeten samenwerken kan dit problemen geven doordat personen in de weg staan of bepaalde posities op de sequencer niet bereikt kunnen worden, maar dit kan enkel aangetoond worden door realistische tests.
2) instrumentenmenu: vanaf nu wordt er niet meer gekozen om een lijst van instrumenten te tonen waarin gescrolled kan worden. Opnieuw zou dit tijdverlies opleveren en aangezien er maar een beperkt aantal instrumenten gebruikt gaat worden, is het beter om direct de volledige lijst te tonen. Het scherm is hiervoor groot genoeg.
3) buttonslijst onderaan: de knop voor de tijdslijn verdwijnt aangezien de tijdslijn altijd zichtbaar blijft voor iedereen en het concept van 'lijst van buttons' verdwijnt ook. Wanneer er een instrument wordt toegevoegd aan de sequencer wordt dit niet langer expliciet vermeld onderaan. Een lijst van instrumenten zou opnieuw impliceren dat er gescrolled moeten worden om een bepaald instrument te tonen. Het effectenvenster kan vanaf nu opgeroepen worden door gewoon een instrument in de sequencer aan te raken.
4) algemene instellingen: dit venster wordt niet langer in het midden van het scherm getoond, aangezien daar de sequencer nu staat. Het venster kan maar op 1 plaats opgeroepen worden aangezien het globale instellingen bevat die voor iedereen hetzelfde zijn. De ronde vorm blijft behouden en het venster kan ook gedraaid worden zodanig dat iedereen de oriëntatie kan aanpassen naar eigen wens.
5) starten en stoppen vd sequencer: Dit gebeurt voortaan in het midden van de sequencer omdat dit eerder bij de sequencer hoort dan bij de algemene instellingen. Ook wordt hier het aantal BPM aangegeven.
Aangezien de paper mock-up op ware grootte wordt getekend, kan de grootte van de vensters al vastgelegd worden en kan er nagegaan worden of die grootte wel optimaal is als er effectief 4 gebruikers tegelijkertijd bezig zijn. Het voorlopige ontwerp is getest geweest met een worst case scenario van vensters. De tabletop werd volledig vol gelegd met vensters om te kijken wat er in dat geval allemaal mogelijk is van combinaties. Zo is het bv mogelijk dat ze tegelijkertijd een instrument kiezen of effecten van verschillende instrumenten op dezelfde moment instellen. Elk venster op zich lijkt voldoende ruimte te geven om de taken binnen dat venster uit te voeren, maar om zekerheid te hebben zou dit effectief softwarematig getest moeten worden. Ook de grootte van de te verslepen iconen in het instrumentenvenster is normaal groot genoeg om geen last te hebben van het fat finger probleem, maar ook hier weer zal een test uitsluitsel moeten brengen. In het geval dat dit toch problemen zou geven volstaat het om de grootte een beetje aan te passen. Dit mag geen onoverkomelijke problemen opleveren.
Voorlopig is er nog geen rekening gehouden met het draaien van vensters; enkel de ronde vensters kunnen gedraaid worden. De rechthoekige vensters kunnen versleept worden waarbij de oriëntatie dezelfde blijft.
De eerste schets werd gemaakt aan de hand van de functionele vereisten van de applicatie. De gebruiker moet in staat zijn instrumenten te kiezen waarmee hij wil werken. Verder moet er ergens een mogelijkheid zijn om een tijdsaspect te koppelen aan een instrument (op welk punt in de compositie moet het instrument hoorbaar zijn?) Hiervoor werd er initieel gedacht aan een tijdslijn. Daarnaast moet het mogelijk zijn om een globaal volume in te stellen en moet er een optie zijn om relatief gezien volumes in te stellen. Deze 3 aspecten worden gegroepeerd onder 3 verschillende knoppen op de tabletop die altijd zichtbaar blijven. Groot genoeg zodanig dat ze goed zichtbaar zijn (het zijn namelijk de hoofdknoppen) en dat ze gemakkelijk met een vinger geselecteerd kunnen worden.
De eerst knop groepeert de algemene instellingen (namen van de artiesten, BPM,...) en toont bijgevolg een venster waarin deze dingen veranderd kunnen worden.
De tweede button zorgt ervoor dat de tijdslijn verschijnt. Deze tijdslijn is er voor elke artiest en is eigenlijk een window dat een lijn bevat die begint bij seconde 0 en tot 60 seconden gaat. Het is hierbij de bedoeling dat de artiest een instrument kiest en deze koppelt aan de tijdslijn door ze vanuit het instrumentenvenster naar de tijdslijn te slepen. Waarom slepen? Het lijkt zeer logisch en intuïtief zeer gemakkelijk in te zien om op een tabletop de objecten zelf te slepen naar de locatie waar ze nodig zijn, eerder dan zoals in een muisgebaseerde omgeving alles met klikken te doen. Het verwijderen kan dan gebeuren door een instrument vast te nemen en het buiten het venster te slepen. Tests zullen moeten uitwijzen of dit logisch lijkt in de ogen van de gebruikers.
De derde button staat in voor de instrumenten. Bij het aanraken verschijnt er een scherm waarin de gebruiker kan scrollen om het gewenste instrument te zien. Dat instrument kan dan op de tijdslijn gesleept worden. Wanneer er een instrument op de tijdslijn gezet wordt, wordt het bijhorende icoon ook automatisch onderaan in de buttonlijst met de 3 buttons gezet.
Het effectenvenster kan opgeroepen worden door een instrument aan te raken in de buttonlijst onderaan. Dit venster bevat 4 onderdelen: een plaats waar de envelope en oscillatie aangepast kan worden, een draaiknop voor de frequentie van het instrument, een sectie waar de filter ingesteld kan worden aan de hand van draaiknoppen en een slider om het volume van het instrument in te stellen. Het manipuleren is in de eerste plaats gewoon gebaseerd op hoe dit in Ableton gebeurd, bv om de envelope in Ableton te veranderen volstaat het om een curve met de muis te verslepen. In het eerste ontwerp wordt hier dus gekozen om een curve met de vinger te verslepen. Voor Abletongebruikers komt dit zeer vertrouwd over en vermindert deze gelijkaardige aanpak de tijd om de applicatie te leren. Ook voor de sliders en draaiknoppen wordt in eerste instantie gekozen om deze op plaatsen te gebruiken waar dat ook bij Ableton het geval was. Usability tests moeten ook hier weer aantonen voor elk element of het gebruik ervan wel geschikt is op een tabletop.
Paper mock-up
De bedoeling van de paper mock-up is een papieren versie op ware grootte te maken van de applicatie waardoor de verhoudingen tussen vensters en widgets meteen duidelijk worden en er in zekere mate al geëxperimenteerd en getest kan worden. Na het bekijken van de eerste schets werden er al meteen enkele dingen aangepast:
1) de tijdslijn: wanneer er gewerkt wordt met de tijdslijn moet die zeer snel en efficiënt gaan. Dit kan niet wanneer de tijdslijn 1 minuut lang is en er voortdurend gescrolled en gezoomed moet worden. Na het zoomen moet dan weer op zoek gegaan worden naar de juiste positie om een instrument te kunnen plaatsen of verwijderen. Dit neemt allemaal te veel tijd in. Een mogelijke oplossing hiervoor: de tijdslijn korter maken en niet meer spreken over een minuut, maar slechts een maat. Een ander probleem met de tijdslijn is de redundantie op het scherm. Elke gebruiker heeft dezelfde tijdslijn nodig aangezien ze aan dezelfde compositie werken. Logischer zou zijn dat er maar 1 tijdslijn is die gebruikt kan worden door alle muzikanten tegelijkertijd. Bij deze oplossing is de oriëntatie nog een probleem. Hoe kan een venster getoond worden dat gemakkelijk werkt en leesbaar is voor alle gebruikers? De ideale oplossing hiervoor is een cirkel. Al deze ideeën samenbrengen leidt tot het totaal nieuwe ontwerp voor de tijdslijn dat nu eigenlijk een sequencer is geworden met 16 posities (maat van 1/16). Waarom 16 posities? 4 of 8 posities is te weinig, dit zou te veel lege ruimte laten in de cirkel ofwel ruimte verspillen door de iconen te groot te maken. De keuze ligt dan tussen 16 en 32 (enkel machten van 2) waarbij 16 de voorkeur krijgt omdat de sequencer dan nog altijd overzichtelijk blijft. Bij 32 posities zou het zoeken naar een instrument bv. niet meer efficiënt genoeg zijn, waardoor een muzikant zich snel gaat frustreren. Als we voor elke positie de mogelijkheid voorzien om 4 instrumenten te plaatsen, krijgen we 64 posities die opgevuld kunnen worden, maar dit zal zelfs in het worst case scenario niet het geval zijn. Rekening houdend met de 4 instrumenten per positie, de breedte van de tabletop en de grootte van de iconen op de sequencer lijkt de keuze voor 16 posities het meest aangewezen. Een mogelijk probleem hierbij is het fysieke aspect: wanneer meerdere gebruikers op dezelfde ruimte moeten samenwerken kan dit problemen geven doordat personen in de weg staan of bepaalde posities op de sequencer niet bereikt kunnen worden, maar dit kan enkel aangetoond worden door realistische tests.
2) instrumentenmenu: vanaf nu wordt er niet meer gekozen om een lijst van instrumenten te tonen waarin gescrolled kan worden. Opnieuw zou dit tijdverlies opleveren en aangezien er maar een beperkt aantal instrumenten gebruikt gaat worden, is het beter om direct de volledige lijst te tonen. Het scherm is hiervoor groot genoeg.
3) buttonslijst onderaan: de knop voor de tijdslijn verdwijnt aangezien de tijdslijn altijd zichtbaar blijft voor iedereen en het concept van 'lijst van buttons' verdwijnt ook. Wanneer er een instrument wordt toegevoegd aan de sequencer wordt dit niet langer expliciet vermeld onderaan. Een lijst van instrumenten zou opnieuw impliceren dat er gescrolled moeten worden om een bepaald instrument te tonen. Het effectenvenster kan vanaf nu opgeroepen worden door gewoon een instrument in de sequencer aan te raken.
4) algemene instellingen: dit venster wordt niet langer in het midden van het scherm getoond, aangezien daar de sequencer nu staat. Het venster kan maar op 1 plaats opgeroepen worden aangezien het globale instellingen bevat die voor iedereen hetzelfde zijn. De ronde vorm blijft behouden en het venster kan ook gedraaid worden zodanig dat iedereen de oriëntatie kan aanpassen naar eigen wens.
5) starten en stoppen vd sequencer: Dit gebeurt voortaan in het midden van de sequencer omdat dit eerder bij de sequencer hoort dan bij de algemene instellingen. Ook wordt hier het aantal BPM aangegeven.
Aangezien de paper mock-up op ware grootte wordt getekend, kan de grootte van de vensters al vastgelegd worden en kan er nagegaan worden of die grootte wel optimaal is als er effectief 4 gebruikers tegelijkertijd bezig zijn. Het voorlopige ontwerp is getest geweest met een worst case scenario van vensters. De tabletop werd volledig vol gelegd met vensters om te kijken wat er in dat geval allemaal mogelijk is van combinaties. Zo is het bv mogelijk dat ze tegelijkertijd een instrument kiezen of effecten van verschillende instrumenten op dezelfde moment instellen. Elk venster op zich lijkt voldoende ruimte te geven om de taken binnen dat venster uit te voeren, maar om zekerheid te hebben zou dit effectief softwarematig getest moeten worden. Ook de grootte van de te verslepen iconen in het instrumentenvenster is normaal groot genoeg om geen last te hebben van het fat finger probleem, maar ook hier weer zal een test uitsluitsel moeten brengen. In het geval dat dit toch problemen zou geven volstaat het om de grootte een beetje aan te passen. Dit mag geen onoverkomelijke problemen opleveren.
Voorlopig is er nog geen rekening gehouden met het draaien van vensters; enkel de ronde vensters kunnen gedraaid worden. De rechthoekige vensters kunnen versleept worden waarbij de oriëntatie dezelfde blijft.
vrijdag 4 december 2009
Verslag meeting 3/12
aanwezigen: Bram Vandeputte, Nik Corthaut, Jef Hermans
onderwerpen:
* voorstelling paper mockup: uitleg over de werking van de applicatie aan de hand van een papieren prototype, volledig op schaal getekend. Deze uitleg gebeurde aan de hand van een analoog voorbeeld in Ableton Live. De applicatie werd op een aantal punten veranderd ten opzichte van de eerste schets. De ontwerpbeslissingen die genomen werden, worden nog gepost op deze blog.
Belangrijk is nu scenario's op te stellen en voor te leggen aan enkele testgebruikers. Op basis van de ondervindingen kan de paper mockup aangepast worden waar nodig.
* planning: Er zou een gedetailleerde en concrete planning, voorzien van milestones, opgesteld moeten worden voor de komende weken. Op 16 en 17 december zijn er opnieuw thesispresentaties voorzien met aandacht voor planning en de stand van zaken, aangevuld met een demo.
* tabletop: De tabletop staat bijna volledig op punt. Een eerste korte test van de tabletop werd door Bram voorgesteld aan de hand van een filmpje. Er zijn nog een paar kleine onvolmaaktheden (o.a. gebruik van een te kleine spiegel), maar deze kunnen snel opgelost worden. Ondertussen kunnen al wel de eerste testapplicaties geïmplementeerd en getest worden op de tabletop zelf.
onderwerpen:
* voorstelling paper mockup: uitleg over de werking van de applicatie aan de hand van een papieren prototype, volledig op schaal getekend. Deze uitleg gebeurde aan de hand van een analoog voorbeeld in Ableton Live. De applicatie werd op een aantal punten veranderd ten opzichte van de eerste schets. De ontwerpbeslissingen die genomen werden, worden nog gepost op deze blog.
Belangrijk is nu scenario's op te stellen en voor te leggen aan enkele testgebruikers. Op basis van de ondervindingen kan de paper mockup aangepast worden waar nodig.
* planning: Er zou een gedetailleerde en concrete planning, voorzien van milestones, opgesteld moeten worden voor de komende weken. Op 16 en 17 december zijn er opnieuw thesispresentaties voorzien met aandacht voor planning en de stand van zaken, aangevuld met een demo.
* tabletop: De tabletop staat bijna volledig op punt. Een eerste korte test van de tabletop werd door Bram voorgesteld aan de hand van een filmpje. Er zijn nog een paar kleine onvolmaaktheden (o.a. gebruik van een te kleine spiegel), maar deze kunnen snel opgelost worden. Ondertussen kunnen al wel de eerste testapplicaties geïmplementeerd en getest worden op de tabletop zelf.
maandag 30 november 2009
Verslag meeting 26/11
aanwezigen: Bram Vandeputte, Nik Corthaut, Jef Hermans
onderwerpen:
* voorstelling van een schets van de applicatie: De schets is enerzijds niet duidelijk genoeg en anderzijds bevat de applicatie zelf nog te veel fouten op gebied van gebruiksgemak (bepaalde onderdelen zijn niet gebruiksvriendelijk uitgewerkt). Ook een aantal belangrijke elementen (zoals instellen van tempo) werden nog vergeten in deze schets. Verder geeft de schets ook een te vaag idee over hoe er precies muziek gemaakt gaat worden. Een paper mockup op ware grootte (grootte tabletop: 54x96cm) zou zo snel mogelijk gemaakt moeten worden.
* volgende meeting: 3/12
onderwerpen:
* voorstelling van een schets van de applicatie: De schets is enerzijds niet duidelijk genoeg en anderzijds bevat de applicatie zelf nog te veel fouten op gebied van gebruiksgemak (bepaalde onderdelen zijn niet gebruiksvriendelijk uitgewerkt). Ook een aantal belangrijke elementen (zoals instellen van tempo) werden nog vergeten in deze schets. Verder geeft de schets ook een te vaag idee over hoe er precies muziek gemaakt gaat worden. Een paper mockup op ware grootte (grootte tabletop: 54x96cm) zou zo snel mogelijk gemaakt moeten worden.
* volgende meeting: 3/12
vrijdag 13 november 2009
woensdag 28 oktober 2009
Gebaren
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.
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.
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)
maandag 28 september 2009
TUIO tracker implementaties
overzicht van de belangrijkste tracker implementaties gebruikmakend van TUIO en geschikt voor tabletops:
* Touchlib
* touché
* TISCH
* reacTIVision 1.4
* Community Core Vision (CCV, ook bekend als tbeta)
* Surface Tracker (website down?)
* BBTouch
In essentie doen deze libraries allemaal het volgende: Een camera bezorgt de tracker een videostream. Deze videostream wordt frame per frame doorzocht op blobs (bright luminescent objects) via bepaalde algoritmen. Wanneer zo'n blob gedetecteerd wordt, genereert de software TUIO-output met info over positie & rotatie (in het geval van objecten). Alle trackers, met uitzondering van TISCH, zijn op deze strategie gebaseerd. TISCH is gebaseerd op een 4-lagen structuur.
Waarin verschillen de trackers? Allereerst zullen waarschijnlijk de algoritmes om de blobs te detecteren verschillen, hoewel enkel papers te vinden zijn met de details over de reacTIVision-tracker. Verder ondersteunen niet alle trackers alle multitouch technologieën of types van camera's. Tenslotte bepaalt de gebruikte programmeertaal in welke mate de tracker draagbaar is over verschillende platformen. Een overzicht.
Touchlib & Community Core Vision werden beide ontwikkeld door NUI group, maar men raadt aan om met de laatstgenoemde library te werken omdat deze feitelijk de opvolger van touchlib is, meer multi-touch technologieën ondersteunt, meer mogelijkheden biedt, cross-platform zou moeten werken en gemakkelijker is in gebruik.
Touché ondersteunt ook de meeste optische multitouch technologieën, maar is geschreven in Cocoa en daardoor vooral gericht op MacOS-gebruikers.
De bekendste tracker, reacTIVision, heeft het nadeel dat het niet werkt voor een LLP-opstelling (laser light plane), de techniek die we gaan gebruiken.
BBTouch is opnieuw een vrij beperkte tracker omdat die enkel FTIR ondersteunt en geïmplementeerd werd in Cocoa.
* Touchlib
* touché
* TISCH
* reacTIVision 1.4
* Community Core Vision (CCV, ook bekend als tbeta)
* Surface Tracker (website down?)
* BBTouch
In essentie doen deze libraries allemaal het volgende: Een camera bezorgt de tracker een videostream. Deze videostream wordt frame per frame doorzocht op blobs (bright luminescent objects) via bepaalde algoritmen. Wanneer zo'n blob gedetecteerd wordt, genereert de software TUIO-output met info over positie & rotatie (in het geval van objecten). Alle trackers, met uitzondering van TISCH, zijn op deze strategie gebaseerd. TISCH is gebaseerd op een 4-lagen structuur.
Waarin verschillen de trackers? Allereerst zullen waarschijnlijk de algoritmes om de blobs te detecteren verschillen, hoewel enkel papers te vinden zijn met de details over de reacTIVision-tracker. Verder ondersteunen niet alle trackers alle multitouch technologieën of types van camera's. Tenslotte bepaalt de gebruikte programmeertaal in welke mate de tracker draagbaar is over verschillende platformen. Een overzicht.
Touchlib & Community Core Vision werden beide ontwikkeld door NUI group, maar men raadt aan om met de laatstgenoemde library te werken omdat deze feitelijk de opvolger van touchlib is, meer multi-touch technologieën ondersteunt, meer mogelijkheden biedt, cross-platform zou moeten werken en gemakkelijker is in gebruik.
Touché ondersteunt ook de meeste optische multitouch technologieën, maar is geschreven in Cocoa en daardoor vooral gericht op MacOS-gebruikers.
De bekendste tracker, reacTIVision, heeft het nadeel dat het niet werkt voor een LLP-opstelling (laser light plane), de techniek die we gaan gebruiken.
BBTouch is opnieuw een vrij beperkte tracker omdat die enkel FTIR ondersteunt en geïmplementeerd werd in Cocoa.
zondag 27 september 2009
TUIO
TUIO is een protocol dat gebaseerd is op Open Sound Control (OSC) en definieert een communicatie-interface tussen de tabletopinterface en onderliggende applicatielaag. Bovendien maakt het ook communicatie mogelijk tussen totaal verschillende 'tangible user interfaces' (reacTable <--> tDesk). Het protocol laat toe informatie over positie & rotatie van objecten op het touchscreen uit te wisselen alsook positionering & beweging van vingers. TUIO werd oorspronkelijk ontwikkeld voor het reacTable project, maar wordt ondertussen al door een aantal andere projecten in het domein van multitouch interactie gebruikt. Momenteel zijn er implementaties beschikbaar voor C++, Java, C#, Processing, Pure Data, Max/MSP, Quartz Composer en Flash.
Wat is de meerwaarde van TUIO ten opzichte van OSC? OSC is een algemeen protocol dat de communicatie regelt tussen computers en multimedia-apparaten; algemeen in de zin dat het gebruikt kan worden in een zeer brede waaier van toepassingen. TUIO daarentegen spitst zich toe op de interactie tussen of met 'tangible surfaces' en definieert daarbij een aantal specifieke profielen (bv. voor een 2D of 3D interactief oppervlak).
Algemene werkwijze
tracker applicatie (ism computer vision) encodeert data (bv. coördinaat waar vinger het scherm raakt) volgens TUIO protocol --> client applicatie decodeert de info
Protocoldetails (v1.1, wordt binnenkort opgevolgd door de veel uitgebreidere v2.0)
-> 2 hoofdklassen van berichten: set & alive
set: wordt gebruikt om info over objecten door te sturen
alive: geeft de aanwezigheid van objecten aan
objecten worden geïdentificeerd adhv een sessionID
-> transport type: UDP --> pakketverlies mogelijk, maar wordt opgevangen door implementatie die redundante info meestuurt (in v2.0 gaan er ook alternatieven voor UDP bekeken worden)
-> elk bericht heeft een bepaald profiel dat het aantal parameters en type ervan definieert
Wat is de meerwaarde van TUIO ten opzichte van OSC? OSC is een algemeen protocol dat de communicatie regelt tussen computers en multimedia-apparaten; algemeen in de zin dat het gebruikt kan worden in een zeer brede waaier van toepassingen. TUIO daarentegen spitst zich toe op de interactie tussen of met 'tangible surfaces' en definieert daarbij een aantal specifieke profielen (bv. voor een 2D of 3D interactief oppervlak).
Algemene werkwijze
tracker applicatie (ism computer vision) encodeert data (bv. coördinaat waar vinger het scherm raakt) volgens TUIO protocol --> client applicatie decodeert de info
Protocoldetails (v1.1, wordt binnenkort opgevolgd door de veel uitgebreidere v2.0)
-> 2 hoofdklassen van berichten: set & alive
set: wordt gebruikt om info over objecten door te sturen
alive: geeft de aanwezigheid van objecten aan
objecten worden geïdentificeerd adhv een sessionID
-> transport type: UDP --> pakketverlies mogelijk, maar wordt opgevangen door implementatie die redundante info meestuurt (in v2.0 gaan er ook alternatieven voor UDP bekeken worden)
-> elk bericht heeft een bepaald profiel dat het aantal parameters en type ervan definieert
vrijdag 25 september 2009
Verslag meeting 24/9
aanwezigen: Bram Vandeputte, Joris Klerkx, Jef Hermans
onderwerpen:
* planning: Er moet asap een planning, voorzien van milestones, opgesteld worden. Deze begint met een literatuurstudie en naarmate het jaar vordert, komen hier de iteraties van de ontwerpcyclus van een user interface nog bij.
* literatuurstudie: Best zoveel mogelijk lezen over recente onderzoeken en projecten in het domein: rapporteren en samenvatten op blog en eigen reflecties vermelden. Enkele pointers naar interessante projecten/libraries (Touche, Touchlib, TUIO, Reactable, ...) werden reeds bezorgd. Een verslag van de literatuurstudie moet eind oktober ingediend worden.
* Het vak 'Gebruikersinterfaces' wordt aangeraden om te volgen. Dit opnemen in het ISP ligt moeilijk want ik heb nu al 62 sp nog verplicht te volgen vakken en het vak wordt pas in het 2de semester gegeven. Er is geen echte cursus van, maar de slides zijn te vinden op slideshare van prof. Duval. De belangrijkste onderdelen van dit vak zijn de ontwerpcyclus van een user interface (Shneiderman) en de evaluatie ervan (Jakob Nielsen). Deze moeten asap doorgenomen worden, onder meer om in de eerste plaats een planning te kunnen opstellen.
* De tabletop wordt zelf gebouwd door Bram om niet gebonden te zijn aan een bepaalde technologie of programmeeromgeving (bv. .net bij Microsoft Surface). Voorlopig is de tabletop nog in aanbouw, maar dit hindert de thesis niet want tabletop kan geëmuleerd worden.
* In het vervolg zal er wekelijks even samengekomen worden (dit kan heel kort zijn), maar hiervoor moet er nog een moment afgesproken worden in samenspraak met Nik (best via mail).
onderwerpen:
* planning: Er moet asap een planning, voorzien van milestones, opgesteld worden. Deze begint met een literatuurstudie en naarmate het jaar vordert, komen hier de iteraties van de ontwerpcyclus van een user interface nog bij.
* literatuurstudie: Best zoveel mogelijk lezen over recente onderzoeken en projecten in het domein: rapporteren en samenvatten op blog en eigen reflecties vermelden. Enkele pointers naar interessante projecten/libraries (Touche, Touchlib, TUIO, Reactable, ...) werden reeds bezorgd. Een verslag van de literatuurstudie moet eind oktober ingediend worden.
* Het vak 'Gebruikersinterfaces' wordt aangeraden om te volgen. Dit opnemen in het ISP ligt moeilijk want ik heb nu al 62 sp nog verplicht te volgen vakken en het vak wordt pas in het 2de semester gegeven. Er is geen echte cursus van, maar de slides zijn te vinden op slideshare van prof. Duval. De belangrijkste onderdelen van dit vak zijn de ontwerpcyclus van een user interface (Shneiderman) en de evaluatie ervan (Jakob Nielsen). Deze moeten asap doorgenomen worden, onder meer om in de eerste plaats een planning te kunnen opstellen.
* De tabletop wordt zelf gebouwd door Bram om niet gebonden te zijn aan een bepaalde technologie of programmeeromgeving (bv. .net bij Microsoft Surface). Voorlopig is de tabletop nog in aanbouw, maar dit hindert de thesis niet want tabletop kan geëmuleerd worden.
* In het vervolg zal er wekelijks even samengekomen worden (dit kan heel kort zijn), maar hiervoor moet er nog een moment afgesproken worden in samenspraak met Nik (best via mail).
dinsdag 25 augustus 2009
Brainstorm
In afwachting van de aankoop van een tabletop kan er al gebrainstromd worden over hoe muzikanten concreet samen rond 1 display tot een muzieknummer kunnen komen. Uiteindelijk zou het naar mijn mening mogelijk moeten zijn om met meerdere, 2 tot 4 (4 zal waarschijnlijk het hoogst haalbare aantal zijn, hangt af van de grootte van de tabletop), artiesten een elektronisch muziekstuk te maken, iets in het genre 'electro-house-dance'. Voortbouwend op de VST host Ableton Live beschikt elke muzikant over dezelfde grafische interface: het display zou hierbij in 4 gelijke stukken gedeeld kunnen worden, vertrekkend van een cirkel of vierkant.
De interface per artiest moet volgende elementen bevatten: mogelijkheid tot selectie van virtuele instrumenten/samples, per gekozen instrument mogelijkheid tot regelen van parameters (draaiknoppen/faders/drukknoppen), interface om muzikale structuur te bepalen.
In het midden van de display is er dan plaats voor een venster dat gemeenschappelijk gebruikt kan worden door alle gebruikers en toelaat algemene instellingen te wijzigen (bevat o.a. een master mixer om de bijdrage van elke gebruiker te regelen).
De interface per artiest moet volgende elementen bevatten: mogelijkheid tot selectie van virtuele instrumenten/samples, per gekozen instrument mogelijkheid tot regelen van parameters (draaiknoppen/faders/drukknoppen), interface om muzikale structuur te bepalen.
In het midden van de display is er dan plaats voor een venster dat gemeenschappelijk gebruikt kan worden door alle gebruikers en toelaat algemene instellingen te wijzigen (bevat o.a. een master mixer om de bijdrage van elke gebruiker te regelen).
donderdag 20 augustus 2009
Multi-touch display
Wat is een multi-touch display en wat is het verschil met een standaard touchscreen? Heel simpel. Een multi-touch display is een touchscreen dat meerdere contactpunten met het scherm tegelijkertijd kan detecteren en daardoor ruimte creëert voor multi-user applicaties. Het bestaat al vrij lang (sinds 1982), maar werd eigenlijk pas met de komst van de iPhone op het grote publiek losgelaten.
Wikipedia schetst een definitie en geeft een overzicht van displays die momenteel op de markt voorhanden zijn (denk aan Microsoft Surface, open-source CUBIT, HP TouchSmart, ...)
Bill Buxton, researcher bij Microsoft inzake multi-touch, geeft op zijn site enkele kritische bedenkingen mee ivm multi-touch en schept duidelijkheid omtrent de gebruikte terminologie. Verder een chronologisch overzicht, beginnend bij 'n-key rollover' tot hedendaagse display technologie, voorzien van links naar foto- en beeldmateriaal.
Website (bevat veel verwijzingen naar papers en video's!) van de Mitsubishi onderzoeksgroep die onderzoek doet op het gebied van tabletops in multi-user omgevingen. De DiamondSpace projectgroep ontwikkelde de DiamondSpin, een uitbreidbare java-toolkit die toelaat aan meerdere gebruikers gelijktijdig te werken op een digitale tabletop.
Wikipedia schetst een definitie en geeft een overzicht van displays die momenteel op de markt voorhanden zijn (denk aan Microsoft Surface, open-source CUBIT, HP TouchSmart, ...)
Bill Buxton, researcher bij Microsoft inzake multi-touch, geeft op zijn site enkele kritische bedenkingen mee ivm multi-touch en schept duidelijkheid omtrent de gebruikte terminologie. Verder een chronologisch overzicht, beginnend bij 'n-key rollover' tot hedendaagse display technologie, voorzien van links naar foto- en beeldmateriaal.
Website (bevat veel verwijzingen naar papers en video's!) van de Mitsubishi onderzoeksgroep die onderzoek doet op het gebied van tabletops in multi-user omgevingen. De DiamondSpace projectgroep ontwikkelde de DiamondSpin, een uitbreidbare java-toolkit die toelaat aan meerdere gebruikers gelijktijdig te werken op een digitale tabletop.
Abonneren op:
Posts (Atom)