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
dinsdag 30 maart 2010
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
Abonneren op:
Posts (Atom)