De presentatie van ma 26/04: pdf ppt
dinsdag 27 april 2010
zondag 18 april 2010
Verslag meeting 12/4
aanwezigen: Nik Corthaut, Jef Hermans
onderwerpen:
* implementatie extra use cases 'opnemen' en 'opnieuw afspelen': De code voor deze use cases is zo goed als klaar, maar de GUI moet nog aangepast worden. We hebben even de implementatie overlopen en deze lijkt wel OK, hoewel het ook anders zou kunnen. Momenteel worden alle MIDI-berichten die naar Ableton gestuurd worden, opgeslagen in een lijst. Deze events zouden ook gedumpt kunnen worden in een MIDI-file, waardoor ze zelfs persistent worden en eventueel op een later tijdstip opnieuw ingeladen kunnen worden.
* thesistekst: De tekst zal geschreven worden in latex. Ik ga asap de volledige structuur opstellen en al een inleidend deel schrijven.
* volgende meeting: 19/4 10u
onderwerpen:
* implementatie extra use cases 'opnemen' en 'opnieuw afspelen': De code voor deze use cases is zo goed als klaar, maar de GUI moet nog aangepast worden. We hebben even de implementatie overlopen en deze lijkt wel OK, hoewel het ook anders zou kunnen. Momenteel worden alle MIDI-berichten die naar Ableton gestuurd worden, opgeslagen in een lijst. Deze events zouden ook gedumpt kunnen worden in een MIDI-file, waardoor ze zelfs persistent worden en eventueel op een later tijdstip opnieuw ingeladen kunnen worden.
* thesistekst: De tekst zal geschreven worden in latex. Ik ga asap de volledige structuur opstellen en al een inleidend deel schrijven.
* volgende meeting: 19/4 10u
maandag 12 april 2010
Update planning
12/4: afwerken code voor extra use cases 'opnemen' en 'opname afspelen'
15/4: structuur thesistekst volledig uitwerken, inhoud paragrafen kort opsommen
16/4: GUI aanpassen voor de extra use cases, milestone: 'opnemen' en 'opname afspelen' volledig afgerond
17-18/4: schrijven korte inleiding over muziek (software/hardware).
15/4: structuur thesistekst volledig uitwerken, inhoud paragrafen kort opsommen
16/4: GUI aanpassen voor de extra use cases, milestone: 'opnemen' en 'opname afspelen' volledig afgerond
17-18/4: schrijven korte inleiding over muziek (software/hardware).
zondag 11 april 2010
Verslag meeting 6/4
aanwezigen: Nik Corthaut, Jef Hermans
onderwerpen:
* verwerking resultaten usability tests: De aanpassingen, die nodig waren naar aanleiding van de gedane tests, zijn gebeurd. Het grootste werk hierbij was de functionaliteit die het mogelijk maakt om patronen in te laden. Van deze functionaliteit werd een korte demo gegeven.
* extra use cases: Ik heb de haalbaarheid bestudeerd van het idee om opnames te maken en te bewerken. Het opnemen van en het opnieuw afspelen van een aantal loops moet zeker in een tijdsspanne van 2 weken geïmplementeerd kunnen worden. Het bewerken van opgenomen stukjes is iets gecompliceerder.
* andere mogelijke uitbreiding: Een nog andere uitbreiding van Nik bestaat erin de bestaande step sequencer te zien als een deel van een sequencer op een hoger niveau. Er wordt in feite dan een sequentie gemaakt van step sequencers, waarbij elke step sequencer een bepaalde functie heeft (bv. 1 step sequencer voor melodie 1, een andere step sequencer voor melodie 2 en nog een andere voor de drums).
* thesistekst: Overlopen van elementen die zeker in de tekst moeten voorkomen:
- korte inleiding over muziek (onontbeerlijk voor buitenstaander die weinig of geen muziekvoorkennis heeft en de thesistekst toch wil kunnen begrijpen) zowel hardware als software
- literatuurstudie: o.a. vergelijking bestaande hardware,...
- ontwerpproces: chronologisch bescrhijven: papier prototype, implementatie 1e versie, testen, aanpassingen, 2e versie, ...
- belangrijk is de gemaakte keuzes zeer duidelijk te vermelden en te verantwoorden
De inhoud van de tekst wordt in een eerste versie best opgesteld aan de hand van puntjes met eventueel korte beargumentering wanneer een gemaakte keuze aan bod komt.
* volgende meeting: 12/4 10u
onderwerpen:
* verwerking resultaten usability tests: De aanpassingen, die nodig waren naar aanleiding van de gedane tests, zijn gebeurd. Het grootste werk hierbij was de functionaliteit die het mogelijk maakt om patronen in te laden. Van deze functionaliteit werd een korte demo gegeven.
* extra use cases: Ik heb de haalbaarheid bestudeerd van het idee om opnames te maken en te bewerken. Het opnemen van en het opnieuw afspelen van een aantal loops moet zeker in een tijdsspanne van 2 weken geïmplementeerd kunnen worden. Het bewerken van opgenomen stukjes is iets gecompliceerder.
* andere mogelijke uitbreiding: Een nog andere uitbreiding van Nik bestaat erin de bestaande step sequencer te zien als een deel van een sequencer op een hoger niveau. Er wordt in feite dan een sequentie gemaakt van step sequencers, waarbij elke step sequencer een bepaalde functie heeft (bv. 1 step sequencer voor melodie 1, een andere step sequencer voor melodie 2 en nog een andere voor de drums).
* thesistekst: Overlopen van elementen die zeker in de tekst moeten voorkomen:
- korte inleiding over muziek (onontbeerlijk voor buitenstaander die weinig of geen muziekvoorkennis heeft en de thesistekst toch wil kunnen begrijpen) zowel hardware als software
- literatuurstudie: o.a. vergelijking bestaande hardware,...
- ontwerpproces: chronologisch bescrhijven: papier prototype, implementatie 1e versie, testen, aanpassingen, 2e versie, ...
- belangrijk is de gemaakte keuzes zeer duidelijk te vermelden en te verantwoorden
De inhoud van de tekst wordt in een eerste versie best opgesteld aan de hand van puntjes met eventueel korte beargumentering wanneer een gemaakte keuze aan bod komt.
* volgende meeting: 12/4 10u
dinsdag 30 maart 2010
Verslag meeting 29/3
aanwezigen: Bram Vandeputte, Nik Corthaut, Jef Hermans
onderwerpen:
* usability tests: Het rapport van de tests werd doorgenomen. Er zouden nog 2 extra vragen duidelijk gesteld moeten worden aan de testgebruikers:
1) Wat is de algemene indruk na het werken met de applicatie?
2) Wat zijn volgens u 'nice to have' features die nog wel aan de applicatie toegevoegd mogen worden?
De minpunten die tijdens het testen naar boven zijn gekomen, worden de eerstkomende week zo goed mogelijk weggewerkt.
* nieuwe features: Er zouden nog een aantal features (o.a. het opnemen van bepaalde fragmenten) toegevoegd kunnen worden, rekening houdend met de bijkomende vraag aan de testgebruikers. Voor deze features worden er best eerst use cases opgesteld om daarna de haalbaarheid ervan te bestuderen.
* planning & presentatie: De planning voor de volgende weken moet duidelijk opgesteld worden.
Na de paasvakantie is er opnieuw een presentatie; deze kan al in zekere mate voorbereid worden.
* volgende meeting: 6/4 10u
onderwerpen:
* usability tests: Het rapport van de tests werd doorgenomen. Er zouden nog 2 extra vragen duidelijk gesteld moeten worden aan de testgebruikers:
1) Wat is de algemene indruk na het werken met de applicatie?
2) Wat zijn volgens u 'nice to have' features die nog wel aan de applicatie toegevoegd mogen worden?
De minpunten die tijdens het testen naar boven zijn gekomen, worden de eerstkomende week zo goed mogelijk weggewerkt.
* nieuwe features: Er zouden nog een aantal features (o.a. het opnemen van bepaalde fragmenten) toegevoegd kunnen worden, rekening houdend met de bijkomende vraag aan de testgebruikers. Voor deze features worden er best eerst use cases opgesteld om daarna de haalbaarheid ervan te bestuderen.
* planning & presentatie: De planning voor de volgende weken moet duidelijk opgesteld worden.
Na de paasvakantie is er opnieuw een presentatie; deze kan al in zekere mate voorbereid worden.
* volgende meeting: 6/4 10u
zaterdag 27 maart 2010
Resultaten usability tests
Belangrijkste conclusies per getest scenario:
1) De step sequencer zou nog duidelijker moeten gemaakt worden. Dit door bv. ergens de gebruikte maat te vermelden en aan te geven waar elke tel begint. Ook moet er sowieso een mogelijkheid voorzien worden om instrumenten snel te kopiëren.
Om de verschillende instrumenten beter uit elkaar te kunnen houden is het beter dat de naam van elk instrument vermeld wordt.
Het instellingenvenster met het mastervolume zou maar 1 keer geopend mogen worden. Daarenboven wordt de positie best zo gekozen dat het venster de andere gebruikers niet hindert.
2) De toetsen moeten in de eerste plaats groter en er moet een knop toegevoegd worden om de gekozen noot te bevestigen. De huidige implementatie blijkt te onlogisch op dat gebied.
Er moet ook een manier toegevoegd worden om instrumenten te kunnen voorbeluisteren, evt. via een kleine play-button.
3) Het effectenvenster moet makkelijker te vinden zijn. Daarom moet er eventueel een boodschap toegevoegd worden die zegt dat het effectenvenster opgeroepen kan worden en hoe dit mogelijk is. Ook moet in het venster zelf de naam van het gekozen instrument vermeld worden, evenals de namen van de parameters die aangepast kunnen worden. Tenslotte zou er bij de draaiknoppen nog een begin- en eindpunt geplaatst moeten worden.
4) Instrumenten zouden ook definitief verwijderd moeten kunnen worden. Dit zou moeten kunnen door ofwel de instrumenten naar een 'vuilbak' te slepen of gewoon helemaal van de tafel te slepen.
5) Er zou nog een basisinstrument (klaps) toegevoegd moeten worden. Verder is het misschien interessant om instrumenten die lang doorklinken sneller af te kappen, waardoor ze meer gaan gebruikt worden omdat ze dan niet meer als langdurig en irritant beschouwd worden. Een andere toevoeging die zeker de moeite waard is, is het inladen van meerdere instrumenten (een bepaalde compositie) tegelijkertijd. Het bespaart tijd en zet de gebruiker direct op weg naar een eerste muziekstuk.
1) De step sequencer zou nog duidelijker moeten gemaakt worden. Dit door bv. ergens de gebruikte maat te vermelden en aan te geven waar elke tel begint. Ook moet er sowieso een mogelijkheid voorzien worden om instrumenten snel te kopiëren.
Om de verschillende instrumenten beter uit elkaar te kunnen houden is het beter dat de naam van elk instrument vermeld wordt.
Het instellingenvenster met het mastervolume zou maar 1 keer geopend mogen worden. Daarenboven wordt de positie best zo gekozen dat het venster de andere gebruikers niet hindert.
2) De toetsen moeten in de eerste plaats groter en er moet een knop toegevoegd worden om de gekozen noot te bevestigen. De huidige implementatie blijkt te onlogisch op dat gebied.
Er moet ook een manier toegevoegd worden om instrumenten te kunnen voorbeluisteren, evt. via een kleine play-button.
3) Het effectenvenster moet makkelijker te vinden zijn. Daarom moet er eventueel een boodschap toegevoegd worden die zegt dat het effectenvenster opgeroepen kan worden en hoe dit mogelijk is. Ook moet in het venster zelf de naam van het gekozen instrument vermeld worden, evenals de namen van de parameters die aangepast kunnen worden. Tenslotte zou er bij de draaiknoppen nog een begin- en eindpunt geplaatst moeten worden.
4) Instrumenten zouden ook definitief verwijderd moeten kunnen worden. Dit zou moeten kunnen door ofwel de instrumenten naar een 'vuilbak' te slepen of gewoon helemaal van de tafel te slepen.
5) Er zou nog een basisinstrument (klaps) toegevoegd moeten worden. Verder is het misschien interessant om instrumenten die lang doorklinken sneller af te kappen, waardoor ze meer gaan gebruikt worden omdat ze dan niet meer als langdurig en irritant beschouwd worden. Een andere toevoeging die zeker de moeite waard is, is het inladen van meerdere instrumenten (een bepaalde compositie) tegelijkertijd. Het bespaart tijd en zet de gebruiker direct op weg naar een eerste muziekstuk.
Video's usability tests 25/3
Hieronder enkele filmpjes van testgebruikers aan het werk tijdens het 'vrije' scenario waarin ze proberen een zo goed mogelijk muziekstuk te maken naar eigen smaak. Hierbij proberen ze de verschillende instrumenten uit en spelen ze met effecten om een optimaal resultaat te bekomen.
vrijdag 26 maart 2010
Verslag meeting 22/3
aanwezigen: Bram Vandeputte, Nik Corthaut, Jef Hermans
onderwerpen:
* usability tests: Een belangrijk onderdeel hiervan is het selecteren van de testgebruikers. Daarvoor moet het doelpubliek beter afgebakend worden. Dit is op dit moment nog te breed.
Verder is het nog niet duidelijk welke scenario's er gebruikt gaan worden. Deze moeten zo snel mogelijk doorgemaild worden zodat hier feedback op gegeven kan worden.
Tijdens het testen zelf moeten de gebruikers effectief de indruk krijgen dat ze muziek aan het maken zijn, dus de aanwezigheid van geschikte speakers is een must. Daarnaast is het niet slecht om eventueel het gemaakte muziekstuk op te nemen om zo een idee te krijgen van wat er allemaal mogelijk is met de applicatie, puur op muzikaal vlak.
* volgende meeting: 29/3 10u
onderwerpen:
* usability tests: Een belangrijk onderdeel hiervan is het selecteren van de testgebruikers. Daarvoor moet het doelpubliek beter afgebakend worden. Dit is op dit moment nog te breed.
Verder is het nog niet duidelijk welke scenario's er gebruikt gaan worden. Deze moeten zo snel mogelijk doorgemaild worden zodat hier feedback op gegeven kan worden.
Tijdens het testen zelf moeten de gebruikers effectief de indruk krijgen dat ze muziek aan het maken zijn, dus de aanwezigheid van geschikte speakers is een must. Daarnaast is het niet slecht om eventueel het gemaakte muziekstuk op te nemen om zo een idee te krijgen van wat er allemaal mogelijk is met de applicatie, puur op muzikaal vlak.
* volgende meeting: 29/3 10u
zaterdag 20 maart 2010
Usability tests met v0.9
Welke scenario's moeten er getest worden? Wat moet er geconcludeerd kunnen worden uit de tests?
Enkele belangrijke punten:
- Zijn de iconen groot genoeg of juist te groot?
- Is er genoeg ruimte op de display? Zijn de vensters van de juiste grootte? Neemt de step sequencer niet te veel plaats in ten koste van werkruimte voor de gebruikers?
- Is het eenvoudig genoeg om dingen te verslepen, om sliders en draaiknoppen te bedienen? Maw genoeg gebruiksgemak?
- Is de plaatsing van de elementen in de grafische interface duidelijk genoeg? Logisch/intuïtief of niet?
- Laat de huidige interface toe om een behoorlijk muziekstuk te maken? Kan de applicatie snel genoeg bediend worden zodanig dat het gebruik van 1 maat op de step sequencer voldoende is?
- Moet er een visuele scheiding gemaakt worden tussen drum en melodie?
- Kan de vorm van de step sequencer optimaler?
- Is de instrumentenverzameling goed gekozen of ontbreken er nog belangrijke instrumenten?
Wie zijn de gebruikers?
In de eerste plaats is het niet de bedoeling dat de gebruiker een professional is in het maken/produceren van muziek. Verder zijn de professionele artiesten niet het doelpubliek van de applicatie, maar dat neemt niet weg dat gebruikers enige voorkennis van muzieksoftware zoals Ableton/Reason kunnen hebben. Het doelpubliek is dus wel het publiek dat eenvoudige muziek wil maken als vrijetijdsbesteding in samenwerking met andere personen en zonder hierbij professionele bedoelingen te hebben.
Testscenario's voor v0.9 (voor telkens 2 gebruikers die samenwerken)
- van gemakkelijk naar moeilijk:
1) Er moet een willekeurige compositie gemaakt worden van 4 shakers. Gebruiker 1 maakt deze compositie en laat deze afspelen. Ondertussen zet gebruiker 2 het globale volume zachter.
(Uit dit eenvoudig scenario kan afgeleid worden of het duidelijk is waar de instrumenten te vinden zijn, of het slepen van een instrument naar de sequencer duidelijk is, of dit snel genoeg gaat. Hetzelfde voor gebruiker 2: Is het duidelijk waar het volume gevonden kan worden? Kan de slider gemakkelijk bediend worden?)
2) Gebruiker 2 maakt nu een compositie van 4 keer een snare hit van noot G3 op elke tel. Ondertussen zet gebruiker 1 een bell juist na elke snare hit van gebruiker 2. Als dat klaar is, past gebruiker 2 het tempo aan tot 130 bpm.
(Hiermee kan nagegaan worden of het samenwerken zonder problemen verloopt (vooral het aanwezig zijn op dezelfde plaats op de tabletop tegelijkertijd). Verder wordt er ook duidelijk of het concept van de step sequencer duidelijk is voor de gebruiker. Vervolgens de slider van de bpm: Kan deze voldoende nauwkeurig en snel bediend worden? Is het meteen duidelijk dat deze op het midden van het scherm staat?)
3) Er is een compositie gemaakt van een shaker en een 8ball bass. Gebruiker 1 zet de frequentie van de filter van de shakers naar een hoger niveau terwijl gebruiker 2 hetzelfde doet voor de 8ball bass.
(Dit scenario moet duidelijk maken of het eenvoudig is het effectenvenster te vinden, of de draaiknoppen gemakkelijk bediend kunnen worden en hoe de samenwerking verloopt)
4) Er is een compositie gemaakt van shakers en kicks. Gebruiker 1 moet de kicks verwijderen. Gebruiker 2 wordt gevraagd op dezelfde moment de effecten van de shakers te tunen.
(Testen of gebruiker 1 weet hoe instrumenten verwijderd kunnen worden en of gebruiker 2 duidelijk weet hoe de effecten aangepast kunnen worden)
5) In dit scenario is het de bedoeling om een muziekstuk te maken gedurende 200 loops van de step sequencer. De gebruikers mogen zelf kiezen welke instrumenten ze gebruiken, hoe de volumes van de instrumenten ingesteld worden, de parameters van de effecten, enz. Het is ook toegelaten om instrumenten van de andere gebruiker te wijzigen of te verwijderen.
(Vooral observatie van de gebruikers is belangrijk bij deze test: Welke elementen van de applicatie worden gebruikt? Zijn er elementen die nog efficiënter gemaakt kunnen worden? Daarnaast moet de test vooral duidelijk maken of het effectief mogelijk is om op een korte termijn een degelijk muziekstuk te maken. Het muziekstuk kan opgenomen worden om later te vergelijken met andere gebruikers, om te controleren welke features gebruikt worden en waar eventueel de applicatie nog tekort schiet om effectief iets degelijk te produceren. Verder kan dit scenario een volledig beeld geven of de samenwerking tussen beide gebruikers vlot verloopt, vooral qua gebruik van ruimte).
Enkele belangrijke punten:
- Zijn de iconen groot genoeg of juist te groot?
- Is er genoeg ruimte op de display? Zijn de vensters van de juiste grootte? Neemt de step sequencer niet te veel plaats in ten koste van werkruimte voor de gebruikers?
- Is het eenvoudig genoeg om dingen te verslepen, om sliders en draaiknoppen te bedienen? Maw genoeg gebruiksgemak?
- Is de plaatsing van de elementen in de grafische interface duidelijk genoeg? Logisch/intuïtief of niet?
- Laat de huidige interface toe om een behoorlijk muziekstuk te maken? Kan de applicatie snel genoeg bediend worden zodanig dat het gebruik van 1 maat op de step sequencer voldoende is?
- Moet er een visuele scheiding gemaakt worden tussen drum en melodie?
- Kan de vorm van de step sequencer optimaler?
- Is de instrumentenverzameling goed gekozen of ontbreken er nog belangrijke instrumenten?
Wie zijn de gebruikers?
In de eerste plaats is het niet de bedoeling dat de gebruiker een professional is in het maken/produceren van muziek. Verder zijn de professionele artiesten niet het doelpubliek van de applicatie, maar dat neemt niet weg dat gebruikers enige voorkennis van muzieksoftware zoals Ableton/Reason kunnen hebben. Het doelpubliek is dus wel het publiek dat eenvoudige muziek wil maken als vrijetijdsbesteding in samenwerking met andere personen en zonder hierbij professionele bedoelingen te hebben.
Testscenario's voor v0.9 (voor telkens 2 gebruikers die samenwerken)
- van gemakkelijk naar moeilijk:
1) Er moet een willekeurige compositie gemaakt worden van 4 shakers. Gebruiker 1 maakt deze compositie en laat deze afspelen. Ondertussen zet gebruiker 2 het globale volume zachter.
(Uit dit eenvoudig scenario kan afgeleid worden of het duidelijk is waar de instrumenten te vinden zijn, of het slepen van een instrument naar de sequencer duidelijk is, of dit snel genoeg gaat. Hetzelfde voor gebruiker 2: Is het duidelijk waar het volume gevonden kan worden? Kan de slider gemakkelijk bediend worden?)
2) Gebruiker 2 maakt nu een compositie van 4 keer een snare hit van noot G3 op elke tel. Ondertussen zet gebruiker 1 een bell juist na elke snare hit van gebruiker 2. Als dat klaar is, past gebruiker 2 het tempo aan tot 130 bpm.
(Hiermee kan nagegaan worden of het samenwerken zonder problemen verloopt (vooral het aanwezig zijn op dezelfde plaats op de tabletop tegelijkertijd). Verder wordt er ook duidelijk of het concept van de step sequencer duidelijk is voor de gebruiker. Vervolgens de slider van de bpm: Kan deze voldoende nauwkeurig en snel bediend worden? Is het meteen duidelijk dat deze op het midden van het scherm staat?)
3) Er is een compositie gemaakt van een shaker en een 8ball bass. Gebruiker 1 zet de frequentie van de filter van de shakers naar een hoger niveau terwijl gebruiker 2 hetzelfde doet voor de 8ball bass.
(Dit scenario moet duidelijk maken of het eenvoudig is het effectenvenster te vinden, of de draaiknoppen gemakkelijk bediend kunnen worden en hoe de samenwerking verloopt)
4) Er is een compositie gemaakt van shakers en kicks. Gebruiker 1 moet de kicks verwijderen. Gebruiker 2 wordt gevraagd op dezelfde moment de effecten van de shakers te tunen.
(Testen of gebruiker 1 weet hoe instrumenten verwijderd kunnen worden en of gebruiker 2 duidelijk weet hoe de effecten aangepast kunnen worden)
5) In dit scenario is het de bedoeling om een muziekstuk te maken gedurende 200 loops van de step sequencer. De gebruikers mogen zelf kiezen welke instrumenten ze gebruiken, hoe de volumes van de instrumenten ingesteld worden, de parameters van de effecten, enz. Het is ook toegelaten om instrumenten van de andere gebruiker te wijzigen of te verwijderen.
(Vooral observatie van de gebruikers is belangrijk bij deze test: Welke elementen van de applicatie worden gebruikt? Zijn er elementen die nog efficiënter gemaakt kunnen worden? Daarnaast moet de test vooral duidelijk maken of het effectief mogelijk is om op een korte termijn een degelijk muziekstuk te maken. Het muziekstuk kan opgenomen worden om later te vergelijken met andere gebruikers, om te controleren welke features gebruikt worden en waar eventueel de applicatie nog tekort schiet om effectief iets degelijk te produceren. Verder kan dit scenario een volledig beeld geven of de samenwerking tussen beide gebruikers vlot verloopt, vooral qua gebruik van ruimte).
Verslag meeting 15/3
aanwezigen: Bram Vandeputte, Nik Corthaut, Jef Hermans
onderwerpen:
* voorstelling applicatie v0.9: Er zijn nog enkele dingen die aangepast moeten worden: op grafisch vlak: gepaste icoontjes zoeken voor de instrumenten of een aanpassing doen zodanig dat de grafische interface duidelijker wordt. Zoniet wordt het moeilijk om relevante usability tests te doen. Verder is er nog een initialisatieprobleem met bij het effectengedeelte. Dit wordt best zo snel mogelijk opgelost door standaardwaarden in te laden (bv. uit tekstbestand) en dus niet via MIDI-berichten afkomstig van Ableton (waar de fout juist zit is na lang zoeken niet duidelijk geworden).
* planning: Deze zou opnieuw geüpdatet moeten worden.
* uitbreiding applicatie: Misschien is het de moeite om de applicatie uit te breiden met een extra feature, namelijk het opnemen van enkele maten die dan later opnieuw afgespeeld kunnen worden. Dit zou eens onderzocht moeten worden.
* usability tests: Nu v0.9 zo goed als klaar is, moeten er afspraken geregeld worden met testgebruikers en moeten er testscenario's opgesteld worden. Er wordt ook een afspraak gemaakt met prof Duval om hem een demo van de applicatie te geven.
* volgende meeting: 22/3 10u
onderwerpen:
* voorstelling applicatie v0.9: Er zijn nog enkele dingen die aangepast moeten worden: op grafisch vlak: gepaste icoontjes zoeken voor de instrumenten of een aanpassing doen zodanig dat de grafische interface duidelijker wordt. Zoniet wordt het moeilijk om relevante usability tests te doen. Verder is er nog een initialisatieprobleem met bij het effectengedeelte. Dit wordt best zo snel mogelijk opgelost door standaardwaarden in te laden (bv. uit tekstbestand) en dus niet via MIDI-berichten afkomstig van Ableton (waar de fout juist zit is na lang zoeken niet duidelijk geworden).
* planning: Deze zou opnieuw geüpdatet moeten worden.
* uitbreiding applicatie: Misschien is het de moeite om de applicatie uit te breiden met een extra feature, namelijk het opnemen van enkele maten die dan later opnieuw afgespeeld kunnen worden. Dit zou eens onderzocht moeten worden.
* usability tests: Nu v0.9 zo goed als klaar is, moeten er afspraken geregeld worden met testgebruikers en moeten er testscenario's opgesteld worden. Er wordt ook een afspraak gemaakt met prof Duval om hem een demo van de applicatie te geven.
* volgende meeting: 22/3 10u
maandag 15 maart 2010
Planning korte termijn
15-18 maart: probleem ivm presets van effecten oplossen, volledig afronden en debuggen van de multi-user grafische interface, gepaste icoontjes maken
19 maart: evaluatiescenario's opstellen
20-21 maart: code opkuisen
22-26 maart: evaluatieweek: usability tests met verschillende gebruikers
27 maart-4 april:
1) aanpassingen doen waar nodig aan de hand van resultaten van de usability tests
2) structuur thesistekst opstellen (welke onderwerpen moeten aan bod komen in de tekst?)
19 maart: evaluatiescenario's opstellen
20-21 maart: code opkuisen
22-26 maart: evaluatieweek: usability tests met verschillende gebruikers
27 maart-4 april:
1) aanpassingen doen waar nodig aan de hand van resultaten van de usability tests
2) structuur thesistekst opstellen (welke onderwerpen moeten aan bod komen in de tekst?)
dinsdag 9 maart 2010
Oplossing 2 problemen: slider BPM & sync GUI-sequencer
Het updaten van de BPM gaat wel on-the-fly, maar niet via de methode setTempoInBPM() zoals deze in de Java API beschreven staat. Er zit blijkbaar een bug in de Sequencer-klasse. Hieronder de oplossing.
Een tweede probleem was de synchronisatie tussen de grafische interface en de software sequencer. Na stoppen en opnieuw starten volgde de GUI de sequencer niet meer en ging een eigen leven leiden. Een optimalere, maar iets complexere implementatie lost dit probleem nu op.
Why is the tempo reset at the beginning of the loop when looping with the realtime sequencer?
This seems to be a bug. As a workaround, you can change the tempo factor. The tempo factor is not reset on loop iterations. You can use code similar to this:
Sequencer sequencer = ...;
public void setTempo(float fBPM)
{
float fCurrent = sequencer.getTempoInBPM();
float fFactor = fBPM / fCurrent;
sequencer.setTempoFactor(fFactor);
}
Een tweede probleem was de synchronisatie tussen de grafische interface en de software sequencer. Na stoppen en opnieuw starten volgde de GUI de sequencer niet meer en ging een eigen leven leiden. Een optimalere, maar iets complexere implementatie lost dit probleem nu op.
maandag 8 maart 2010
Verslag meeting 8/3
aanwezigen: Bram Vandeputte, Nik Corthaut, Jef Hermans
onderwerpen:
* voorstelling van de nieuwe applicatie: De DiamondSpin library wordt niet meer gebruikt; ik heb de GUI volledig herschreven in MT4j wegens eerder vernoemde redenen op deze blog. Sliders en draaiknoppen werden als extra widgets toegevoegd, hoewel de draaiknoppen nog niet naar behoren werken.
* controle van volumes: Voorlopig is er al een implementatie om het globale volume te controleren met een slider, nu is het nog de vraag hoe de volumes van instrumenten of van gebruikers apart ingesteld moeten worden. Een mogelijke aanpak is bij het kiezen van een instrument ineens de 'velocity'-waarde mee te geven en de gebruiker de mogelijkheid te geven deze later nog aan te passen. Dit is nog een punt waar goed over nagedacht moet worden.
* v0.9: tegen volgende meeting zou v0.9 klaar moeten zijn, die meerdere personen toelaat om samen collaboratief muziek te maken. Er moeten nog enkele aspecten geïmplementeerd worden en enkele kinderziektes in de GUI moeten nog opgelost worden. Als v0.9 klaar is, kan deze uitgebreid getest worden op usability en kan er een demo gegeven worden.
* volgende meeting: 15/3 10u
onderwerpen:
* voorstelling van de nieuwe applicatie: De DiamondSpin library wordt niet meer gebruikt; ik heb de GUI volledig herschreven in MT4j wegens eerder vernoemde redenen op deze blog. Sliders en draaiknoppen werden als extra widgets toegevoegd, hoewel de draaiknoppen nog niet naar behoren werken.
* controle van volumes: Voorlopig is er al een implementatie om het globale volume te controleren met een slider, nu is het nog de vraag hoe de volumes van instrumenten of van gebruikers apart ingesteld moeten worden. Een mogelijke aanpak is bij het kiezen van een instrument ineens de 'velocity'-waarde mee te geven en de gebruiker de mogelijkheid te geven deze later nog aan te passen. Dit is nog een punt waar goed over nagedacht moet worden.
* v0.9: tegen volgende meeting zou v0.9 klaar moeten zijn, die meerdere personen toelaat om samen collaboratief muziek te maken. Er moeten nog enkele aspecten geïmplementeerd worden en enkele kinderziektes in de GUI moeten nog opgelost worden. Als v0.9 klaar is, kan deze uitgebreid getest worden op usability en kan er een demo gegeven worden.
* volgende meeting: 15/3 10u
zondag 7 maart 2010
Touchy Remix
Toevallig kwam ik dit weekend terecht op de site van dit Nederlands bedrijfje: Intactlab. Zij zijn de ontwikkelaars van de Touchy Remix, een tabletop in een zeer fris en modern jasje. De optische multi-touch technologie die ze gebruiken is FTIR (Frustrated Total Internal Reflection), wat betekent dat ze een speciaal oppervlak gebruiken (typisch plexiglas) waar IR-licht wordt doorgestuurd. Die IR-stralen komen van LED's die rondom het glasoppervlak worden geplaatst. Het overige van de hardware-setup komt vrij goed overeen met de LLP-setup die we hier op de campus hebben.
Het bedrijf Intactlab houdt zich eigenlijk voornamelijk bezig met het ontwikkelen van applicaties voor de tabletop. De tafel zelf werd dan weer ontworpen door een Duitse designer. Toch maar eens naar de prijs informeren dacht ik dan. Kostprijs: 19800 euro (btw niet inbegrepen) :)
donderdag 4 maart 2010
Grafische interface
Welk framework is het beste geschikt voor deze multi-touch muziekapplicatie? Er zijn 3 mogelijkheden (of een combinatie uit deze 3): MT4j, DiamondSpin en Processing.
*DiamondSpin is geschikt voor multi-user applicaties, want biedt de mogelijkheid om frames over het display aan andere gebruikers door te geven. Het biedt echter geen herkenning van gestures aan en heeft ook geen speciale widgets die van tel kunnen zijn voor een muziekapplicatie (denk aan sliders). Bovendien is DiamondSpin nog steeds verre van bugfree en geeft het daarom soms onverklaarbare errors.
*Processing is nog een pak beperkter dan DiamondSpin. Het is niet gericht op multi-user applicaties, doet geen gesture recognition en doet dus niets met inkomende ruwe TUIO-berichten. Elke functionaliteit (van draaien van frames tot herkennen van handelingen op objecten) zal bijgevolg nog geïmplementeerd moeten worden.
*MT4j is een zeer uitgebreid raamwerk en steekt ook zeer goed in mekaar. Het houdt rekening met meerdere gebruikers, want biedt een interface om componenten te draaien en is ook in staat om gebaren te herkennen (oa rotatie, wat de gebruiker de mogelijkheid geeft om informatie of een venster in zijn richting te draaien). Verder bevat MT4j enkele widgets (sliders, lists, ...) die wel handig zijn bij het maken van een muziekapplicatie. v0.9 van dit raamwerk blijkt weinig of geen fouten meer te bevatten. Bovendien maakt het raamwerk ook abstractie van AWT of Swing in tegenstelling tot DiamondSpin, wat ook een groot pluspunt is.
MT4j lijkt de beste oplossing te zijn voor de visualisatie van deze muziekapplicatie.
*DiamondSpin is geschikt voor multi-user applicaties, want biedt de mogelijkheid om frames over het display aan andere gebruikers door te geven. Het biedt echter geen herkenning van gestures aan en heeft ook geen speciale widgets die van tel kunnen zijn voor een muziekapplicatie (denk aan sliders). Bovendien is DiamondSpin nog steeds verre van bugfree en geeft het daarom soms onverklaarbare errors.
*Processing is nog een pak beperkter dan DiamondSpin. Het is niet gericht op multi-user applicaties, doet geen gesture recognition en doet dus niets met inkomende ruwe TUIO-berichten. Elke functionaliteit (van draaien van frames tot herkennen van handelingen op objecten) zal bijgevolg nog geïmplementeerd moeten worden.
*MT4j is een zeer uitgebreid raamwerk en steekt ook zeer goed in mekaar. Het houdt rekening met meerdere gebruikers, want biedt een interface om componenten te draaien en is ook in staat om gebaren te herkennen (oa rotatie, wat de gebruiker de mogelijkheid geeft om informatie of een venster in zijn richting te draaien). Verder bevat MT4j enkele widgets (sliders, lists, ...) die wel handig zijn bij het maken van een muziekapplicatie. v0.9 van dit raamwerk blijkt weinig of geen fouten meer te bevatten. Bovendien maakt het raamwerk ook abstractie van AWT of Swing in tegenstelling tot DiamondSpin, wat ook een groot pluspunt is.
MT4j lijkt de beste oplossing te zijn voor de visualisatie van deze muziekapplicatie.
maandag 1 maart 2010
Verslag meeting 1/3
aanwezigen: Bram Vandeputte, Nik Corthaut, Jef Hermans
onderwerpen:
* voorstelling van v0.1: deze versie bevat nog geen implementatie van sliders of draaiknoppen, hier zou de eerstkomende week een implementatie van gemaakt moeten worden
* voorstelling v1.0 eind maart: over 2 weken zou er al een v1.0 of 0.9 klaar moeten zijn om een demo te kunnen geven.
* grafische interface: De interface om met Ableton te communiceren is er, nu komt het er de volgende weken op aan om de grafische interface te verbeteren en uit te breiden. Er zijn in feite 3 mogelijkheden (of een combinatie van deze 3): MT4j, DiamondSpin of Processing. Onderzoek moet uitwijzen welk framework het beste geschikt is.
* volgende meeting: 8/3 10u
onderwerpen:
* voorstelling van v0.1: deze versie bevat nog geen implementatie van sliders of draaiknoppen, hier zou de eerstkomende week een implementatie van gemaakt moeten worden
* voorstelling v1.0 eind maart: over 2 weken zou er al een v1.0 of 0.9 klaar moeten zijn om een demo te kunnen geven.
* grafische interface: De interface om met Ableton te communiceren is er, nu komt het er de volgende weken op aan om de grafische interface te verbeteren en uit te breiden. Er zijn in feite 3 mogelijkheden (of een combinatie van deze 3): MT4j, DiamondSpin of Processing. Onderzoek moet uitwijzen welk framework het beste geschikt is.
* volgende meeting: 8/3 10u
zaterdag 27 februari 2010
v0.1 klaar!
Een eerste alfaversie van de applicatie is klaar. Zoals in de planning beschreven is de step sequencer afgerond: mogelijkheid tot selecteren van een instrument uit een beperkte verzameling, plaatsen van een instrument op de sequencer, wisselen van plaats op de sequencer, eenvoudige start/stop-functionaliteit, synchronisatie van GUI met muziek. De step sequencer is niet volledig tot in detail grafisch uitgewerkt, maar de interface om met Ableton te communiceren is wel volledig klaar. Dit omdat de grafische interface in een volgende versie waarschijnlijk gebruik gaat maken van de DiamondSpin-library die in zijn laatste versie volledig werkt via TUIO-berichten (reeds getest!) en daardoor in feite grotendeels omgegooid gaat worden. Nu is het de bedoeling deze implementatie kort te evalueren (evt. na testsessie op tabletop zelf?). In een volgende stap worden de effecten en de algemene instellingen (volume per instrument, algemeen volume, ...) aangepakt. De interface Java-Ableton zal hierbij vrij gelijkaardig zijn aan die om noten te sturen: MIDI Control Change message sturen naar Ableton waarbij elke message vooraf gekoppeld werd aan een bepaalde parameter (ook al getest).
woensdag 24 februari 2010
Verslag meeting 22/2
aanwezigen: Bram Vandeputte, Nik Corthaut, Jef Hermans
onderwerpen:
* voorstelling van huidige applicatie + uitleg over gebruikte implementatie
* verzenden van MIDI-berichten: het simuleren van de sequencer door Thread.sleep() te gebruiken is zoals geweten geen goede oplossing, hier moet de komende week een oplossing voor gezocht worden in een kleine "vergelijkende studie". Er zijn een aantal mogelijkheden: Max (for Live) gebruiken, lightweight Java application die sequencerfunctie op zich neemt en gebruik maken van Ableton voor de effecten, ... Elke keuze zal voor- en nadelen hebben en ook gevolgen meebrengen voor de applicatie.
* volgende meeting: 1/3 10u
onderwerpen:
* voorstelling van huidige applicatie + uitleg over gebruikte implementatie
* verzenden van MIDI-berichten: het simuleren van de sequencer door Thread.sleep() te gebruiken is zoals geweten geen goede oplossing, hier moet de komende week een oplossing voor gezocht worden in een kleine "vergelijkende studie". Er zijn een aantal mogelijkheden: Max (for Live) gebruiken, lightweight Java application die sequencerfunctie op zich neemt en gebruik maken van Ableton voor de effecten, ... Elke keuze zal voor- en nadelen hebben en ook gevolgen meebrengen voor de applicatie.
* volgende meeting: 1/3 10u
Real Time Sequencer
Het probleem van het gelijkmatig afspelen van MIDI-berichten lijkt dan toch een eenvoudige oplossing te hebben. Sinds JDK 1.5 beschikt Java over een Real Time Sequencer die ingesteld staat als default sequencer en simpelweg opgevraagd kan worden via MidiSystem.getSequencer(false). Deze sequencer is real time en geeft dus onmiddellijk gevolg aan verandering in MIDI-events die opgeslagen zitten in een sequence-object, precies wat we willen. De klok van de sequencer kan ook naar wens ingesteld worden. Ideaal zou zijn dat Ableton de masterklok heeft en dat de Java-sequencer deze klok als slave volgt, maar de huidige opstelling (Java-sequencer is master en gebruikte interne klok) is eenvoudiger te implementeren (de ideale implementatie vereist hoe dan ook Max for Live) en geeft ook prima timing resultaten. De visualisatie (GUI) zou nu ook gesynchroniseerd moeten kunnen worden met de sequencer: ofwel via een listener die luistert naar MetaMessages ofwel direct via de klok van de sequencer (door de GUI op één of andere manier in te stellen als slave van de sequencer, moet nog nagekeken worden of dit wel mogelijk is).
donderdag 18 februari 2010
Java, MIDI & Ableton Live 8.1
Benodigdheden:
* virtual midi port (LoopBe1)
* Java MIDI device dat MIDI berichten kan zenden (ontvangen is niet nodig)
(* Max for Live (M4L) patch die muzikale output mogelijk maakt adhv ontvangen MIDI-bericht)
* Ableton Live 8.1
Om MIDI-berichten te kunnen zenden van Java naar Ableton is er een virtuele midi-poort nodig die in feite als kabel dient. In Java is het dan mogelijk om via MidiSystem het MidiDevice op te vragen dat overeenkomt met de virtuele poort. Dit device kan een ShortMessage doorgeven aan Ableton dat per instrument kan instellen op welk kanaal en welke poort het moet luisteren. Het kanaal dat opgegeven in de ShortMessage komt NIET overeen met het kanaal in Ableton! (setMessage(int command, int channel, int data1, int data2))
Ableton: Ch. 1 -> Java int: 31 of 63 of 127 ...
Ch. 2 -> Java int: 1
Ch. 3 -> 2
...
Aangezien er 16 MIDI-kanalen zijn is het dus mogelijk om op deze manier 16 verschillende instrumenten aan te sturen. Weliswaar op een beperkte manier omdat ik er nog niet in geslaagd ben om Midi events te sturen naar Ableton die niet alleen info over noten bevatten maar ook info over het tempo. Deze manier zou ideaal zijn en wordt daarom nog verder onderzocht. In de huidige testapplicatie wordt voorlopig nog gewerkt met een Thread.sleep(long) om het tempoprobleem op te lossen.
* virtual midi port (LoopBe1)
* Java MIDI device dat MIDI berichten kan zenden (ontvangen is niet nodig)
(* Max for Live (M4L) patch die muzikale output mogelijk maakt adhv ontvangen MIDI-bericht)
* Ableton Live 8.1
Om MIDI-berichten te kunnen zenden van Java naar Ableton is er een virtuele midi-poort nodig die in feite als kabel dient. In Java is het dan mogelijk om via MidiSystem het MidiDevice op te vragen dat overeenkomt met de virtuele poort. Dit device kan een ShortMessage doorgeven aan Ableton dat per instrument kan instellen op welk kanaal en welke poort het moet luisteren. Het kanaal dat opgegeven in de ShortMessage komt NIET overeen met het kanaal in Ableton! (setMessage(int command, int channel, int data1, int data2))
Ableton: Ch. 1 -> Java int: 31 of 63 of 127 ...
Ch. 2 -> Java int: 1
Ch. 3 -> 2
...
Aangezien er 16 MIDI-kanalen zijn is het dus mogelijk om op deze manier 16 verschillende instrumenten aan te sturen. Weliswaar op een beperkte manier omdat ik er nog niet in geslaagd ben om Midi events te sturen naar Ableton die niet alleen info over noten bevatten maar ook info over het tempo. Deze manier zou ideaal zijn en wordt daarom nog verder onderzocht. In de huidige testapplicatie wordt voorlopig nog gewerkt met een Thread.sleep(long) om het tempoprobleem op te lossen.
maandag 15 februari 2010
Verslag meeting 15/2
aanwezigen: Bram Vandeputte, Nik Corthaut, Jef Hermans
onderwerpen:
* bespreking problemen met processing: Het feit dat vensters niet gedraaid kunnen worden is geen probleem voor een eerste 0.1 versie van de applicatie. Het belangrijkste is om zo snel mogelijk tot een eerste werkende versie te komen die alle aspecten (touchinput - muzikale output) in zekere zin bevat. Het multi-user aspect mag hierbij even achterwege gelaten worden.
Voor het probleem met het werken met meerdere frames moet op het net zeker wel een oplossing te vinden zijn. Maar er hoeft ook niet noodzakelijk met frames gewerkt worden...
* bespreking van het muzikale aspect van de applicatie: Hierbij werd de vraag gesteld of er al onderzocht is hoe de link gelegd kan worden tussen Java en de software die voor de muzikale output zorgt (bv. Ableton Live). Java heeft een uitgebreide MIDI-bibliotheek en zou eventueel MIDI-berichten kunnen sturen om instrumenten aan te sturen. Voorlopig is dit nog niet grondig onderzocht, maar hier wordt uiteraard deze week nog werk van gemaakt.
* volgende meeting: 22/2 10u: op dat moment zou er meer duidelijkheid moeten zijn over hoe Java communiceert met de muzieksoftware adhv een kleine testapplicatie
onderwerpen:
* bespreking problemen met processing: Het feit dat vensters niet gedraaid kunnen worden is geen probleem voor een eerste 0.1 versie van de applicatie. Het belangrijkste is om zo snel mogelijk tot een eerste werkende versie te komen die alle aspecten (touchinput - muzikale output) in zekere zin bevat. Het multi-user aspect mag hierbij even achterwege gelaten worden.
Voor het probleem met het werken met meerdere frames moet op het net zeker wel een oplossing te vinden zijn. Maar er hoeft ook niet noodzakelijk met frames gewerkt worden...
* bespreking van het muzikale aspect van de applicatie: Hierbij werd de vraag gesteld of er al onderzocht is hoe de link gelegd kan worden tussen Java en de software die voor de muzikale output zorgt (bv. Ableton Live). Java heeft een uitgebreide MIDI-bibliotheek en zou eventueel MIDI-berichten kunnen sturen om instrumenten aan te sturen. Voorlopig is dit nog niet grondig onderzocht, maar hier wordt uiteraard deze week nog werk van gemaakt.
* volgende meeting: 22/2 10u: op dat moment zou er meer duidelijkheid moeten zijn over hoe Java communiceert met de muzieksoftware adhv een kleine testapplicatie
Planning tweede semester
planning: html
TODO tegen 1 maart:
1) aanmaken van instrumentenframe waar verschillende instrumenten adhv cirkels met kleuren of figuren gekozen kunnen worden (nog uitzoeken hoe dit kan in processing) -> momenteel wordt uitgezocht of het de moeite is om een uitgebreide implementatie te maken in Processing of direct gebruik te maken van de vernieuwde DiamondSpin-library
2) synchronisatie tussen GUI en muziek -> done
3) koppeling van instrumenten aan objecten (bv. cirkels met kleuren of figuren) -> done
4) afwerken (GUI) step sequencer -> done
5) nadenken over algemene software-architectuur (gui-muziek-tuio) -> muziekgedeelte is klaar
TODO tegen 1 maart:
1) aanmaken van instrumentenframe waar verschillende instrumenten adhv cirkels met kleuren of figuren gekozen kunnen worden (nog uitzoeken hoe dit kan in processing) -> momenteel wordt uitgezocht of het de moeite is om een uitgebreide implementatie te maken in Processing of direct gebruik te maken van de vernieuwde DiamondSpin-library
2) synchronisatie tussen GUI en muziek -> done
3) koppeling van instrumenten aan objecten (bv. cirkels met kleuren of figuren) -> done
4) afwerken (GUI) step sequencer -> done
5) nadenken over algemene software-architectuur (gui-muziek-tuio) -> muziekgedeelte is klaar
vrijdag 12 februari 2010
DiamondSpin
paper: DiamondSpin: An Extensible Toolkit for Around-the-Table Interaction
youtube video
Wanneer meerdere personen rond een tafel moeten samenwerken aan eenzelfde project of document, in dit geval het maken van een muziekstuk, moet de grafische interface deze face-to-face samenwerking ondersteunen. Het probleem hierbij is dat noch processing noch Java AWT of Swing hier mogelijkheden voor bieden. Met de DiamondSpin-toolkit probeert men die mogelijkheden binnen Java uit te breiden naar een tabletopomgeving waar meerdere personen met verschillende oriëntaties ten opzichte van de tafel samenkomen. Het wordt dus mogelijk om rechthoekige, octagonale of circulaire tabletop layouts te maken, waarbij de plaatsing van de documenten niet langer gericht zijn naar 1 bepaalde persoon. Om de voordelen van around-the-table interactie ten volle te benutten is het dus absoluut noodzakelijk om een toolkit zoals DiamondSpin te gebruiken.
De grote fundamentele uitdaging die de ontwikkelaars van DiamondSpin aangingen is het afstappen van de single-user rechthoekige interface en trachten een multi-user tabletop interface te maken die gelijktijdige interactie mogelijk maakt. Hiervoor wordt een nieuwe architectuur bedacht die leidde tot de DiamondSpin toolkit.
DiamondSpin architectuur
DiamondSpin bestaat grotendeels uit 2 componenten:
1) een engine die verantwoordelijk is voor de omzetting tussen poolcoördinaten en Carthesiaanse coördinaten. TouchEvents of MouseEvents komen typisch binnen als grafische 2D-coördinaten en worden omgezet naar poolcoördinaten omdat DiamondSpin intern met deze representatie werkt. Men kan dan gemakkelijk inzien dat er 3 vrijheidsgraden zijn voor een element van de GUI: de afstand tot de oorsprong, de hoek ten opzichte van de oorsprong en de oriëntatie ten opzichte van het eigen middelpunt (of een punt waar dat element geselecteerd wordt).
2) een engine die instaat voor multi-layer multi-thread display management. De verschillende elementen van de grafische interface kunnen deel uitmaken van verschillende layers. Layer 0 bevat bv. de elementen die ongevoelig zijn voor rotatie van de tabletop. Layer 1 bevat typisch elementen die passief zijn, maar actief kunnen gemaakt worden door ze bv. te selecteren (Layer 2). Ook zorgt deze engine voor het management van meerdere threads. Er is een thread die verantwoordelijk is voor input handling (aanpassing van eigenschappen van interface-elementen) en een andere voor de repaint van de elementen.
DiamondSpin API
In deze sectie legt men de belangrijkste klassen kort uit en zegt men hoe een kleine applicatie bestaande uit een DSFrame kan worden gemaakt. DSContainer (in de nieuwste versie heet deze klasse DSTabletopPane) en DSView zijn hierbij de belangrijkste klassen. DSContainer biedt methodes aan voor input handling, repainting/refreshing, documentoriëntatie, ... DSView kan gebruikt worden om meerdere views te creëren op dezelfde tabletop: een workspace per gebruiker of een gedeelde workspace voor groepen van gebruikers. DSFrame, DSPanelen DSWindow zijn klassen die de bestaande klassen uit Java Swing uitbreiden en geschikt maken voor een tabletopomgeving.
Hierna vermeldt men nog enkele voorbeelden van applicaties die steunen op DiamondSpin.
youtube video
Wanneer meerdere personen rond een tafel moeten samenwerken aan eenzelfde project of document, in dit geval het maken van een muziekstuk, moet de grafische interface deze face-to-face samenwerking ondersteunen. Het probleem hierbij is dat noch processing noch Java AWT of Swing hier mogelijkheden voor bieden. Met de DiamondSpin-toolkit probeert men die mogelijkheden binnen Java uit te breiden naar een tabletopomgeving waar meerdere personen met verschillende oriëntaties ten opzichte van de tafel samenkomen. Het wordt dus mogelijk om rechthoekige, octagonale of circulaire tabletop layouts te maken, waarbij de plaatsing van de documenten niet langer gericht zijn naar 1 bepaalde persoon. Om de voordelen van around-the-table interactie ten volle te benutten is het dus absoluut noodzakelijk om een toolkit zoals DiamondSpin te gebruiken.
De grote fundamentele uitdaging die de ontwikkelaars van DiamondSpin aangingen is het afstappen van de single-user rechthoekige interface en trachten een multi-user tabletop interface te maken die gelijktijdige interactie mogelijk maakt. Hiervoor wordt een nieuwe architectuur bedacht die leidde tot de DiamondSpin toolkit.
DiamondSpin architectuur
DiamondSpin bestaat grotendeels uit 2 componenten:
1) een engine die verantwoordelijk is voor de omzetting tussen poolcoördinaten en Carthesiaanse coördinaten. TouchEvents of MouseEvents komen typisch binnen als grafische 2D-coördinaten en worden omgezet naar poolcoördinaten omdat DiamondSpin intern met deze representatie werkt. Men kan dan gemakkelijk inzien dat er 3 vrijheidsgraden zijn voor een element van de GUI: de afstand tot de oorsprong, de hoek ten opzichte van de oorsprong en de oriëntatie ten opzichte van het eigen middelpunt (of een punt waar dat element geselecteerd wordt).
2) een engine die instaat voor multi-layer multi-thread display management. De verschillende elementen van de grafische interface kunnen deel uitmaken van verschillende layers. Layer 0 bevat bv. de elementen die ongevoelig zijn voor rotatie van de tabletop. Layer 1 bevat typisch elementen die passief zijn, maar actief kunnen gemaakt worden door ze bv. te selecteren (Layer 2). Ook zorgt deze engine voor het management van meerdere threads. Er is een thread die verantwoordelijk is voor input handling (aanpassing van eigenschappen van interface-elementen) en een andere voor de repaint van de elementen.
DiamondSpin API
In deze sectie legt men de belangrijkste klassen kort uit en zegt men hoe een kleine applicatie bestaande uit een DSFrame kan worden gemaakt. DSContainer (in de nieuwste versie heet deze klasse DSTabletopPane) en DSView zijn hierbij de belangrijkste klassen. DSContainer biedt methodes aan voor input handling, repainting/refreshing, documentoriëntatie, ... DSView kan gebruikt worden om meerdere views te creëren op dezelfde tabletop: een workspace per gebruiker of een gedeelde workspace voor groepen van gebruikers. DSFrame, DSPanelen DSWindow zijn klassen die de bestaande klassen uit Java Swing uitbreiden en geschikt maken voor een tabletopomgeving.
Hierna vermeldt men nog enkele voorbeelden van applicaties die steunen op DiamondSpin.
donderdag 11 februari 2010
Problemen met processing
Momenteel probeer ik elk onderdeel van mijn ontwerp beetje bij beetje uit te werken in processing om zo een eerste volledige iteratie af te werken en zo snel mogelijk tot een werkend programma te komen. Hierbij zijn toch al enkele problemen en beperkingen ivm processing opgedoken:
* Een probleem met de vensters is de oriëntatie. Dit geldt niet alleen voor processing, maar ook voor bv. Java AWT. Processing en Java AWT zijn niet geschikt voor GUI's waar mensen het scherm bekijken vanuit verschillende standpunten aangezien er niet dadelijk een mogelijkheid is om frames te draaien. Er is een Java toolkit die hier een oplossing voor zou bieden: DiamondSpin.
* Processing kan precies moeilijk overweg met meer dan 1 frame tegelijkertijd. Er kunnen wel meerdere frames getoond worden, maar als er één wordt afgesloten, wordt het programma beëindigd.
* Een probleem met de vensters is de oriëntatie. Dit geldt niet alleen voor processing, maar ook voor bv. Java AWT. Processing en Java AWT zijn niet geschikt voor GUI's waar mensen het scherm bekijken vanuit verschillende standpunten aangezien er niet dadelijk een mogelijkheid is om frames te draaien. Er is een Java toolkit die hier een oplossing voor zou bieden: DiamondSpin.
* Processing kan precies moeilijk overweg met meer dan 1 frame tegelijkertijd. Er kunnen wel meerdere frames getoond worden, maar als er één wordt afgesloten, wordt het programma beëindigd.
vrijdag 5 februari 2010
Eerste kleine testapplicatie
Om de tabletop en de tracker (Community Core Vision) te testen maakte ik een kleine java applet: de verschillende bollen kunnen versleept worden over het scherm of kunnen verwijderd worden door ze 1 keer aan te raken.
Abonneren op:
Posts (Atom)