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.
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.
Notes are added by creating instances of the following class (short version):
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.