Week 2

Initial Meeting

• Platform: Mac? PC? Linux?

Need more investigation on UI tools. Possibly cross-environment. Look into QT, GTK and WX.

• Underlying sound format: MIDI? Audio? Other? Format agnostic?

MIDI, with a wrapper interface.

• How will the AI "publish" their musical activity for the others to process?

Open question. Investigate Producer/Consumer model.

• How do we describe musical instruments such that new ones can be introduced later on?

Need a tree hierarchy of musical instruments that is reasonable for an AI to fall back on.

• What are the most crucial goals for the finished project?

1. Sounds like music
2. UI that is appealing, reactive and responsive
3. Variation and creativity in the AI performers
4. Ownership: user must feel like a conductor, work must persist and be exportable.
5. Extensibility: new AI should be simple to create/import.

• Which controls should globally affect the AI (i.e. tempo)?

Open question. Currently we want a tempo, some qualitative controls, and individual volume controls.

• Should we take embrace an "electronic" approach or try to simulate real instruments?

Either/or. The framework should support each.

Other Items

• UI should feel malleable, as if the user is controlling tangible objects.
• Take advantage of space in the design, it could control volume or performance role.
• Could there be performance analogies, such as a stage and a spotlight for triggering solos?
• Should there be a way to guide performers to the next section or pattern of a song?
• Instruments should have a visual indication of their performance, such as a volume meter or contraction/expansion (like a speaker)
• AI -- keep them simple?
• How to filter instruments? Garage band analogy of filters by genre/instrument.
• A thumbs up/thumbs down system to "train" AI what to play or not play?
• Ways to force instruments to loop on the same groove

Second meeting

• Created UML diagrams separating the flow of user input, AI manipulation and response, and stream processing/output.
• Discussed and clarified UI concepts and goals. Added Interface page.
• Constructed use case categories and examples.
• Discussed FluidSynth and SoundFont as potential solutions to sound generation. Added Libraries.

Other items (TODO)

• Learn limitations of MIDI
• Explore language options
• Finalize UI
• Build a schedule/development plan
• Meet to finalize Requirements document

Week 3

Third meeting, Sunday, April 12

• Determined preliminary roles
• Gathered most of the Requirements_Document
• Determined our toolset, including the decision to develop in Python

Fourth meeting, Tuesday, April 14

• Milestones to be determined after project investigation and design begins when scope of project becomes clearer.
• Acknowledged that packaging of software is of concern and multifaceted; noted as a general TO DO.
• Agreed each member creates an interpretation of the overall architecture and module relationships; due start of week 4.
• Discussed individual schedules considering language/library education, experiments, module design. Short term goals decidedly clearer than longer ones.
• Agreed that functionality of demo should include musicians who perform together well, and instrument choices that sound well together. Example given (jazz): drum kit, brass, bass
• Reached consensus that module testing is to happen; modules are to provide stub functionality for their interfaces early on.
• Travis stressed importance of use cases to bring unforeseen issues up early; recommended to write use cases to assist in module definition.

Fifth meeting, Thursday, April 16

• Make a paper prototype!

  • We built and defined roles for the prototype.

• Everyone gets their environment configured!

  • Most people still need to do this.

• Python crash course?

  • Still need to do this as well.

Paper prototype takeaways

• Mostly made sense to non-musicians.
• Lock button doesn't make sense to most users.
• Time signature, key signature don't make sense for non-musicians.
• We need to start playing as soon as an instrument is added.
• Resizing of instruments wasn't obvious.
• Band order effect wasn't obvious.
• Discussed how the instruments could automatically loop if left alone, requiring user action. Do we want to implement it this way?

Homework over weekend, to be done sometime next week

• Get familiarized with tools (Python, FluidSynth, etc.)
• Tim will write up brief summary of what we learned from our paper prototype.

Week 4

Sixth meeting, Sunday April 19th

• Who's doing what for the paper prototype writeup due Monday?

  • Travis and Tim are taking care of this.

• Each person does 5 min at the whiteboard and 5 minutes for questions.
• Debrief... bring us close to a final spec.
• Address (lack of) ownership for exporting song.

  • This is still an open item which needs an owner.

• Also assigned ownership for the document due Wednesday.

Seventh meeting, Tuesday April 21

• Does everyone have everything they need to do their part of the SDS?

  Only Rich is blocked, with the Architecture needing finalization.

• Questions/concerns/comments on the Architecture?

  Many brought up, thanks! I will update the Architecture tonight or Wednesday (likely the latter).

• Review Milestones -- do these seem feasible?

  Rich added much more detail that I will merge with the existing milestones.

• Review test plan and documentation details.

  Test plan looks good. Gave task of documentation to Tim, and test scaffolding to Mike.

Other

• Put animations on hold to address other issues.
• Reviewed risks, Mike owns these.
• Agreed to meet at 2:30 next Thursday.
• Environment configurations is important!

Eight Meeting, Thursday, April 23

• Scrum
• Review Architecture changes.
• Schedule Overview.
• Tasks overview.
• Break off and work on individual areas.
• Convene and create powerpoint slides.

System Design Specification and Plans (SDS)

• Due Friday

• SDS gives us a good breakdown of modules and expected interfaces between them.

• Begin working on basic interface stubs

Rich Snider

• design AI module (whats inside)
• frame AI, make input and output streams

Michael Beenen

• animation design, determine how animations can be done in Qt or Python
• animation interface design, how the UI will use the animation

Travis Veralrud

• finish experimenting with FluidSynth and pyfluidsynth

  • Goal: produce programmed sound; determine if audio module explicitly should handle thread or if library does.

• Determine appropriate interface for audio module
• Assist with inter-module design

Week 5

Ninth Meeting, Sunday, April 26th

• Who does what for presentation.
• Create an SVN directory.
• Create wiki spaces for test plans.

Interface Stubs complete

• All modules should have some basic kind of interface up, even if it has no logic behind it

Tim Crossley

• pyGt main window created
• Basic instrument box created

Rich Snider

• finish developing and testing i/o streams
• begin writing core of first AI, make music
• change in inputs causes changes in outputs

Michael Beenen

• Have animation stubs complete so the UI can use them

Travis Veralrud

• Audio module: implement stub functionality and unit tests

Week 6

Tenth Meeting, Sunday May 3

• Starting building musicians
• Reviewed parser and metronome experiments
• Created example parser and Metronome musician to illustrate module interactions.

Eleventh Meeting, Thursday, May 7

• Code review discussion

  Informal code reviews until the beta is complete.

• UI progress

  Gave certain UI items highest priority.

• Musician progress

  Need changes to the score, and API. Change play() back to compose() and have the conductor manage which measure is most current.

• Decided we need a main class
• Descide to lay out Musician directory so all info for one musician is in a single directory.

Tim Crossley

• Song controls done, added to window
• Ability to add instruments to main view
• Ability to reorder instruments

Rich Snider

• finish first AI
• build interface to UI
• build interface to song description

Michael Beenen

• Instrument animations and graphics complete
• Begin focus on module testing, and working on other UI features

Travis Veralrud

• Audio module: implementation underway

Week 7

Tim Crossley

• Advanced instrument interface complete
• Ability to drag and resize instruments

Rich Snider

• develop additional ais

Travis Veralrud

• Audio module: Finish implementation

Week 8

Estimated date of Beta release

Rich Snider

• develop additional ais
• start development of a complex ai
• assumed beta release

Week 9

Fix bugs and deficiencies discovered from beta

Rich Snider

• finish complex ai, begin making older ais more advanced

Week 10

Final release

Rich Snider

• add ais, update ais