Vacation :)
Vacation from the usual work, anyway. I have a little respite from running sound as much as I have been lately…so I’ll only be working 1 1/2 full time jobs for a little while. More time for coding 🙂
I’ve been trying to tie up some loose ends over the last couple of days. I’ve created a javascript that emulates a lot of the functionality of the [coll] object and acts a link between [coll] and [pattr]. There are still some things it doesn’t do (mostly related to sorting and use of symbol links to coll registers), but I don’t use those features and am not terribly inclined to add functionality for them. Everything else appears to work, so I’m going to package this new object up with all of my patches for the next revision. I’m curious to see how well the system works….it should be faster and more efficient than using [matrixctl] linked to a parameter enabled [pattr]. This object should make future efforts of porting patches between raw Max and m4l a good deal easier.
I’m almost finished with the Sooperlooper interface I’ve been working on, but haven’t had any time to test it out. I’m going to try to take care of that tomorrow.
I have a couple weeks to work without much interuption, and the weather here right now is perfect for staying inside and burning copious amounts of wood (and other burnables) to stay warm and dry. Expect the next revision of Monomodular in short order, along with final versions of the Ohm64 control script. It will see some pretty major additions if all goes well; if not, it will see some minor ones and a quick release. Either way, there will be some note-modes available and Drum Rack support.
I will add a link to the raw files for the [coll_pattr] object. It works by living in between [pattr] and [coll]. You can send it any command you would send a [coll] except for “delete”, which is a reserved internal js function name (use “del” instead, it will forward the proper command to the [coll] it is connected to). It updates the pattr with the new coll every time it receives one of the messages it understands. There is a list of functions which it merely passes on to the coll, without making any changes in its internal structuring of the data. It is also capable of retrieving the information directly from [coll] if the two are connected properly. The first, second, and fourth outlets of the [coll] must be connected to the second, third and fourth inlets of [js coll_pattr.js] for [coll] to send its data to the [pattr]. The function “collect” will read the current data from the [coll] object.
If there is no need for collecting data from the [coll], then its only necessary to connect the output of the javascript to the input of the [coll] and send any message you would send to [coll] to the input of the javascript. As long as a [pattr] is connected to the first inlet of the javascript, and has “parameter mode” enabled, it will function nearly identically to the [coll] downstream from it and will store nearly identical data in the [pattr].
“Nearly”…what does that mean? I don’t know yet. Some ordering will probably get lost….time will tell. Check it out.
http://dl.dropbox.com/u/6044993/collstore_112110_release.amxd
Uncategorized
Leave a Reply