henrik frisk   →   research   →   Research diary

« November 2004 | Main | January 2005 »

December 19, 2004

Real-time versus non real-time

I should have realized that, in starting to re-work etherSound, I would end up changing almost everything. Since the new version is multi timbral, i.e. it will play back several messages simultaneously, some of the solutions I came up with for the first version will no longer work. I had two GEN23 objects in my CSound score file that read data from a text file written by the JAVA application that processed the incoming messages. It is not a big deal to put this data into additional P-fields of the score file for the non-real time version but the first solution was very elegant in its own way. Also, I would really like to have the real-time and non real-time version to be as compatible as possible when it comes to the instruments. In other words, I should make sure to think about how the real-time version can use the same instrument file to avoid having to redo it once again. Real-time / non real-time should be an option controlled in the JAVA application.

I have now a working CSound score file generation utility class in my JAVA app that seems to be working. By using the AbstractDocument model I can add notes to the score without having to write to disk everytime. It also implements the option of reading in a template from a disk file to avoid unnecessary creation of function table data within the JAVA app.

public class CScoreTmpl { File fileName; StringContent tmpl; CScoreTmpl() { } CScoreTmpl(String fileName) { tmpl = new StringContent(); try { this.fileName = new File(fileName); } catch(NullPointerException npe) { System.out.println("Couldn't open file\n\n"+npe.toString()); } } public AbstractDocument.Content getTemplate() { StringBuffer sb = new StringBuffer(); String line = null; try { BufferedReader reader = new BufferedReader(new FileReader(fileName)); while((line=reader.readLine())!=null) { sb.append(line+"\n"); } tmpl.insertString(0, sb.toString()); } catch(Exception e) { System.out.println("This is getTemplate\n\n"+e.toString()); } return tmpl; } }

Now, with the following calls I have a PlainDocument containing the necessary information and all that is added by the application are the actual note creation lines.

tmplFile = new CScoreTmpl("/path/to/template/cscore.tmpl.txt"); tmpl = tmplFile.getTemplate(); doc = new PlainDocument(tmpl);

Notes are added by creating instances of the following class (short version):

public class CScoreNote { int fields = 0; Float[] pFields; CScoreNote(int fields) { this.fields = fields; this.pFields = new Float[fields]; } CScoreNote(int fields, int instr, double start, double length) { this.fields = fields; this.pFields = new Float[this.fields]; pFields[0] = new Float(instr); pFields[1] = new Float(start); pFields[2] = new Float(length); } public void setPField(int field, double value) { if(field<1 || field > fields) return; else pFields[field] = new Float(value); } public static int getInstr(CScoreNote note) { return note.pFields[0].intValue(); } public static int getNumberOfFields(CScoreNote note) { return note.fields; } public int getNumberOfFields() { return this.fields; } public String serialize() { StringBuffer sb = new StringBuffer("i"); // Warning!! Error checking is not performed here. // An empty pField throws an index out of bounds error. for(int i=0; i<pFields.length; i++) { if(i==0) sb.append(pFields[i].intValue()+"\t"); else sb.append(pFields[i].toString()+"\t"); } sb.append("\n"); return sb.toString(); } }

This class allows for keeping each note with all the p-fields in an array, and saves the formatting to the call to serialize. There are obviously a number of ways to achive the same thing, but for what I am trying to do, this seems to be a reasonable way to achieve it.

Posted by henrikfr at 11:12 PM | Comments (0)

December 13, 2004

More on etherSound

In my November 18 post, I mentioned the need for limiting the number of messages that would play back simultaneously. I think the way to solve this is to have two separate life indexes. One local that rules the length and impetus of the current message and one global that influences all currently playing messages. Once the global index, which is an indicator on how many messages has been sent over time, rises above a set threshold the music abruptly changes character until the value falls back below the threshold. This also is a way to encourage collective efforts among the performers.

In the new version the voice sample in its original state will not be used. Instead I am using the sample (a recording of John Cage reading) to extract syllables that I process with the same technique used for the ‘accompaniment’ part in the first version. This gives that part more life and variation than before when I used simple sine waves throughout. With the FOF synthesis used to process samples it is possible to continously move from low density structures whith discrete sound streams representing the original sample, to continous pitched sounds [Clarke, 2000]. By mapping these samples to letters I will also achieve a higher level of integration between the text input and the sonic output.

I still need to figure out how rythm and time should be reflected and how the two parts in the music should interact with each other.

Posted by henrikfr at 12:15 AM | Comments (0)