OK, I'll kick this topic off on our new forum. (thanks Chris)
Here a couple of things to consider when handling data for data sonification software (DSS)
- When is a flat file structure not enough?
- Having read it (.CSV's?) into memory, then it has to be parsed into
-Lists - Dictionaries - SQL dBs - Other external DB structure (b-trees ...
- Metataging - when to and when not to and what schemes?
- there might be an arg. for developing a common XML
- Interprocess and/or trans-network data flow logistics incl. between different sw apps.
- Access to statistical processing - how does each of us do it? External tools, integrated?
- Develop a set of tests/benchmark targets towards which we can design.
(From a suggestion by Greg and Bruce towards an conf. demo/workshop)
- What things need addressing in dataflow of complex models, such as Tom H's, to make them more widely available?
- What links can be made between TaDa-like DBs and actual data.
- Data cleaning what tools/experiences? Can they be shared?
- An example data repository to which contributions can be made. (Extension of 2004 EEG experiments.
- Buffering for repeated playback
- Streaming audio vs direct to HD
That's a bit of a core dump on some data topics,
Perhaps others would like to add their data-handling concerns/topics.
-drw (David Worrall)
What kind of data?
These are good questions. It brings up issues of data type, data content, and typical information processing.
What kind of data is in DSS? In order to be flexible, it is probably a pre-rendered form (not, for example, a MOV or MP3 file). Does it include the original data? Mandates for particular types of rendering (such as MIDI, WAV, JPG)?