I came back from two weeks vacation yesterday. Prior to that I only had one day in Bergen after returning from a very exciting week-long trip to Paris. I still have not had the time to write much about that trip.
May 17th I met Pascal Baltazar Mathieu Chamagne and Olivier Pfeiffer
for a one day workshop/presentation on Jamoma in Paris. I first demonstrated how to use first one Jamoma module and later on a combination of modules including the cuelist module to give an idea of how it works from a user perspective. Afterwards I showed how to create a simple control module and next an audio effect module.
Pascal Mathieu and Olivier have all built similar frameworks for their performance patches though the approaches and solutions differed between the various solutions. They showed me their approaches and we had some stimulating discussions on approaches differences and similarities and the benefits and disadvantages of the various solutions. To me it was really useful to see their approaches often offering quite a few good ideas that we could benefit from adopting in Jamoma.
WARNING: This post is now turning exceedingly technical:
Mapping
One of the topics discussed extensively was mapping of data. Alexander and Tim implemented a mapping module in Jamoma during the Teatrix workshop in March/April but I believe that it could both be made a lot more efficient CPU-wise and more intuitive from a user perspective.
Currently the remote communication between various modules is done using a single send/receive bus named jmod.remote.fromModule and jmod.remote.toModule. Inside the mapping module route is used for creating the various mappings. So if we set up 20 mappings each parameter change will be routed 20 times even if it maybe is not used for any mapping at all. In computer science the problem of efficient search is a basic problem with several optimized solutions. The current solution in Jamoma have to be the least efficient possible. I believe that it should be possible to improve this by using the OSC name of the parameter to create unique send/receive pairs for each mapping vastly reducing the number of routings required inside the mapping module. Another possibility would be to investigate if pattrforward could be used but I imagine that this will be a less transparent and easily manageable solution if it will work at all.
If it is possible to optimize mapping I believe that it should also be possible to extend this to how communication is handled between jmod.hub and jmod.parameter and jmod.message inside the modules to speed that up as well. I will try looking into this over the next few weeks. This should help towards reducing the CPU overhead introduced in parameter handling in Jamoma somewhat.
Pascal in his framework named “Z” has a nice feature with a menu being built automatically displaying all available mapping parameters. He poll the range of the parameters mapped from and to so that the mapping is auto-scaled and use lp.scampf from the Litter Power Package by Peter Casine and tap.smooth from tap.tools by Tim Place for various mapping modes and smoothing of data.
Another interesting approach is that Pascal utilize amplitude envelope data from level monitoring as a flow of data that can be possibly mapped. This information is probably more or less available already in the Jamoma audio modules using jmod.meter~ so it should be possible to consider implementing.
Namespace
The namespace of modules came up again as a topic of discussion. This I have previously discussed with Henrik Sundt at NoTAM. Two days later it came up once more as I did a brief presentation of Jamoma to Diemo Schwatz and Rémy Müller at IRCAM (we also discussed a lot of other exciting issues but that is a different story). To me it makes more and more sense to try to adopt the concept of namespaces that is currently being defined in the Integra project or at least parts of it. The Integra OSC namespace is based on an object-oriented approach. Henrik has recently published a first proposition for it online. The integration with Integra makes even more sense now that Pascal is joining in as a Jamoma developer as he is also involved in the Integra project through La Kitchen in Paris.
I learned programming (BASIC Pascal and FORTRAN) in the late 80s before object oriented languages such as C++ and Java emerged so I will have to fill in a few holes here in the near future to get a better understanding of object-oriented languages.
Apart from these issues a number of smaller issues and bugs and stuff was discovered or suggested during the session. I tried to write short notes on them as we went along and Pascal has repeated most of them in a mail at the Jamoma-devel list a few days ago. One of the first things to do probably is to revise the road map and try to structure it all so that it can be approached in a systematic way.
Another interesting observation: Mathieu Chamagne use a touch-sensitive display for his live performances. Even if it is not multitouch it is fast and responcive and provide better interfacing with the patches than an ordinary mouse would do. In addition he also avoid the typical laptop performer layout as he have the display laying flat on the table instead of being hidden behind a laptop.
Links:
Peralvino by Olivier Pfeiffer
Sys-org Pascal has been developing the framework “Z” mainly for the project sys-org.
