31/05/09

Date:  31/05/09

Phase:  Research & Development – Modeling

Version:  None

Summary of Activities:

The focal point of today’s activites was upon research and modeling of the environment’s main window as well as modules.  In accordance, the proceeding section is a summary of the main window and modules of the main window. 

Main Window

The main window is the workstation of the environment and will comprise of: 

Sound Modules:  the six modules, assignable through the module selection, will serve as the control center for each sound or groups of sounds

Record and Playback Parameters:  

section devoted to the recording and playback of the generated soundscape

Reverb:  optional so one may apply the effect elsewhere, the reverb unit will be significant feature due to its importance in producing urban soundscapes 

Options & Miscellaneous:  section consisting of different options, buttons, and menus

Modules

The module is assignable to “macro”, “meso”, and “object/event” - each type refers to the diverse stratums with the soundscape’s timescale.  Also inclusive in the module is the action parameter and action preset storage, which will house parameters to control the sound’s movement, intensity, and timbre.  Finally, the spatialization parameters will allow the user to graphically place the sound within the surround sound “superfield”.

Notes:

Tomorrow will be beginning of the engineering phase.

30/05/09

Date:  30/05/09

Phase:  Research & Development – Modeling

Version:  None

Summary of Activities:

The subsequent summary is an analysis of the data storage sub patch that will be utilized to store and recall playlists within the soundscape generating environment.

Playlist Data Storage Sub Patch Summary

As shown in the picture above, the sub patch consists of three inlets, two outlets, and two main sections devoted to the storage and recall of data.

Inlet One:  receives information pertaining the index of the file and it’s placement within the playlist

Inlet Two:  collects file path data and location of the audio file on the hard disk

Inlet Three:  receives four different messages

• Write:  brings up a dialog box and saves playlist to a drive
  
• Read:  brings up dialog box and loads playlist information into the coll object
  
• Load:  send data from current playlist within the coll object to the outlets
  
• Clear:  clears data within the coll object
  

1. Outlet One: outputs index number information
   
2. Outlet Two:  outputs file path information
   

Storage Section

Consists of the coll and router object that is used in order to store and recall data to a text file.  The router object then directs the integer (in the this case, our index number) to the appropriate outlet.

Recall Section

Comprises of a metro object, counter, and router object.  The metro object sends bang messages (limited by the length of the playlist within the coll object) to the counter.  Once the counter receives a bang it will increase the outputted number by an increment of one, which then recalls file path and index information contained with the coll object.

Notes:

Tomorrow will consist of final preparations for the engineering phase on Monday, which will be primarily focused up finishing the modeling of the main environment’s modules and interface.

29/05/09

Date:  29/05/09

Phase:  Research & Development – Modeling

Version:  None

Summary of Activities:

The focus the past few days’ activities surrounded playlist data storage, which has been fully finished.  Some initial work has been done with the playlist window that is in its very early stages.

Notes:

Tentatively, all objectives for the week will be completed, which will mark the formal first phase of engineering.  A summary of the playlist data storage sub patch will be posted within the next blog.

27/05/09

Date:  27/05/09

Phase:  Research & Development – Modeling

Version:  None

Summary of Activities:

Activities of the past few days have been primarily aimed at finishing the data storage sub patch for playlists.  The sub patch is nearly complete as it successfully saves the file path and index number of the items within the playlist.  Moreover, the data recall function is also nearly finished and may need a few more days of finalizing and bug fixes.  The following picture is the sub patch in its nearly completed form:

 

Patch cord information

• Red: Path of playlist index number
  
• Green:  Path of file location data
  
• Blue:  Path of the merged data (index number and file path)
  
• Black:  Miscellaneous

Notes:

The next couple of days will be focused upon polishing the sub patch as well as working on the basic layout of the environment’s main window.  More information will be posted regarding the patch when it’s complete.

Weekly Summary 18/05/09 - 24/05/09

Phase:  Research & Development 

Version:  None

Weekly Summary of Activities:

Goals this week comprised of designing the layout of the environment as well as research and some preliminary engineering of the data storage system for playlists.  These activities are expected to be continued in the next few days of this week.

This Week's Objectives: 

The continuance of last week's activities are anticipated to take until the middle of week three. Implementation of the playlist model and its functions being the focal point until the end of the week.

Next week's objectives are as followed:

1. Finish the basic layout of the environment and its windows
   
2. Finish the data storage system subpatch for playlists
   
3. Begin the engineering of the environment (playlist window)
   

24/05/09

Date:  24/05/09

Phase:  Research & Development – Modeling

Version:  None

Summary of Activities:

Design of the main window’s modules and some further work on data storage were the focus of the past few days.  Modules will consist of sets of parameters that are applicable to the timescale.  For instance, macro modules need the capability to loop a recording/sample of a soundscape’s ambience (people talking, room tone, etc), whereas on a meso modules one will need to be in control of the relative frequency of the samples being played and the order (ascending, descending, random) of them.  Modules will also have the capability to store Actions.  Actions will be a means of saving/recalling information such as the sound’s spatial placement on the horizontal plane as well as its movement within it.

Notes:

In the next few days more work will be done on recalling playlist information as well as finalizing the basic framework of the environment. The storage of playlist file paths and their relative index numbers has been successful.

21/05/09

Date:  21/05/09

Phase:  Research & Development – Research & Modeling

Version:  None

Summary of Activities:

Design of the playlist window and research of the implementation of each function within the window were the central activity.  The following is a simple design layout illustrating the sections of the playlist window.

 

Areas in light grey represent the visual components of the window, whilst the orange show the placement of functions.

1. Drag/Drop Files:  drag in specific digital audio files to the current playlist
   
2. Data Storeage/Recall & Playlist Editing:  functions for editing playlists (delete, clear, etc) as well as storing and recalling them
   
3. Playlist Files:  list box of files along with their respected filepatch
   
4. Waveform display:  Visual display of each file
   
5. Audition:  listen to the digital audio file
   

Furthermore, some work has been put in on data storage.  After some research, a subpatch has been started that’s intended to store as well as recall playlist file paths and their indexes to a text file. 

Notes:

Because data storage is anticipated to be then most challenging portion of the playlist window I have decided to start it.  It’s expected that the subpatch will be complete by the end of the week.  More will be posted when the information is available.