Genome Progress 1
Work continues on my multi-touch enabled music software, Genome. I've been using Freemind to make some diagrams of the interactions of the various classes which is working out very well. Being able to link multiple mindmaps together is a nice feature that I'm starting to get some mileage out of. I'm planning on making some large 'under-the-hood' changes. One is to change the way that parameters are referenced from the UI layer. Before I required each one to have a unique name - this required some naming hacks which I didn't like. Now, you'll be able to reference them by their place in the hierarchy using some XPath like statements. This way it'll be easy to say 'change the pitch of all the oscillators of all the voices in this synth'. It also makes it possible to reference specific parameters like 'just change the pitch of OSC1 in Voice1'. This will come in handy when I add the ability to make custom Control Surfaces. These control surfaces will add the ability to build custom synths, but they will also add the ability to build a simplified interface to your music tracks. This is something I have wanted to do in Buzz for a long time. Basically it would let you just put the controls you are interested in on the screen and also unify several modules into one interface. So, lets say I have a track which has an analog synth running through a tremolo effect. I can create a control surface that lets me put the analog synth's filter cutoff knob and the tremolo effect depth knob on one page - that way I can limit the view to just the parameters I'm interested in or that I want to tweak. Adding the controls would just be a matter of picking which parameters from the sub modules you are interested in. With the ability to attach scripting logic to the control surface and also record your knob tweaking, this could be a powerful feature.
I also did some brainstorming about the patch library situation. Patches are files of module settings which users save when they find some settings they like. In this case they can be settings for a single module or for a module that contains a hierarchy of modules (such as a song-track or an instrument). Instead of having patches all over your hard drive like now, patches will be added to a central database, similar to how iTunes works. The goal is to make it easier to manage and find patches. You'll be able to set meta-data on patches such as author, rating, category, sub-category which will make it easy to find what you are looking for. It will also be possible to publish your patches to a community website which will contain a master list of patches and to download other user-made patches (all from within the program). This is a big advantage over VST which leaves it up to the individual VST instruments to manage their patches or leaves it up to you to manage your directories. VST hosts typically don't offer much in the way of patch management.
I also did some brainstorming about the patch library situation. Patches are files of module settings which users save when they find some settings they like. In this case they can be settings for a single module or for a module that contains a hierarchy of modules (such as a song-track or an instrument). Instead of having patches all over your hard drive like now, patches will be added to a central database, similar to how iTunes works. The goal is to make it easier to manage and find patches. You'll be able to set meta-data on patches such as author, rating, category, sub-category which will make it easy to find what you are looking for. It will also be possible to publish your patches to a community website which will contain a master list of patches and to download other user-made patches (all from within the program). This is a big advantage over VST which leaves it up to the individual VST instruments to manage their patches or leaves it up to you to manage your directories. VST hosts typically don't offer much in the way of patch management.

0 Comments:
Post a Comment
<< Home