Mapulator has a number of goals:
- Be musician friendly to use - not just a toy for geeks.
- Not hold back your creativity in any way shape or form.
- Save you time when mapping and creating devices.
- Be able to interact with other instances of Mapulator to extend the possibilities.
- Minimal CPU usage as absolutely possible so you can use as many instances as you need.
Today i will be talking about the last of these points: CPU usage. As some of you might know, i have been very busy working on a premium version of Mapulator thats going to have all sorts of really cool features that will bring your performances to a totally new level. One area that is of great importance with Mapulator is CPU usage, this is because a single live set or production might have upwards of 20 instances of Mapulator in it! If its possible to shave even half a percent of CPU usage then by the time you load up 20 instances, there will be a whopping 10% saving of CPU.
The development of the premium Mapulator is comming along really well and while i have been taking every step along the way to optimize the CPU usage to an absolute minimum, it has come time to look at the CPU usage of the patch as a whole. Suprisingly it turns out its not really the code itself that consumes the most CPU, it is actually the GUI that is really sucking up most of the CPU juice in Mapulator.
So now i am looking at the patch as a whole and the CPU usage of the device i have decided the best thing to do is not to have a Mapulator that does everything in the one patch, but instead take a more modular approach to Mapulator. This means that Mapulator will actually become a series of patches instead of just a single all encompassing patch, each patch will be nearly identicle to the patch before it but will modulate in a unuiqe way.
So at the time of writing this i have come up with 6 different modulation types, can you guess what they will be?