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
21.11.10
2.11.10
Back to work.
It's been a while since I've had time to post here. I've been extremely busy in real life running sound for shows that have been going on here in town. It's been fun, but harvest is about over and the weather is getting grim, so its time to hole up in the studio and get some work done there whilst burning things to keep warm.
I won't even go into enumerating all of my plans for ammending my previous work and making things better. I'll try to post on a more regular basis as I work on things. I have some good ideas now that I've spent some time writing the Python scripts for the Ohm64 about how to better use Python to make m4l more powerful and productive. The main goal is a complete rewrite of the TouchOSC interface using Python...but this is still probably a few weeks off. And of course I need to publish the finished version of the Ohm64 script after I've made the necessary refinements to it (thanks to the beta-testers for their feedback on this).
I also want to spend some time documenting the Monomods abstract so that others can use it if they want, however I've given this relatively low priority since nobody has really complained about the missing info. If anyone needs direction, let me know....otherwise I assume no one is using this stuff besides me for writing code.
On the other hand, someone is reading this stuff (and using it presumably)......anyway, people keep downloading it ;)
Cheers.
I won't even go into enumerating all of my plans for ammending my previous work and making things better. I'll try to post on a more regular basis as I work on things. I have some good ideas now that I've spent some time writing the Python scripts for the Ohm64 about how to better use Python to make m4l more powerful and productive. The main goal is a complete rewrite of the TouchOSC interface using Python...but this is still probably a few weeks off. And of course I need to publish the finished version of the Ohm64 script after I've made the necessary refinements to it (thanks to the beta-testers for their feedback on this).
I also want to spend some time documenting the Monomods abstract so that others can use it if they want, however I've given this relatively low priority since nobody has really complained about the missing info. If anyone needs direction, let me know....otherwise I assume no one is using this stuff besides me for writing code.
On the other hand, someone is reading this stuff (and using it presumably)......anyway, people keep downloading it ;)
Cheers.
17.10.10
Ohm64 Beta is out to testers...
I've finished a preliminary version of the new Ohm64 remote script for Ableton Live. Its accompanied with a new version of Monodular which integrates the Ohm64 with the other controllers that work as Monomod controllers.
It's out to the testers...time for a beer and some kick-back. I'll try to get some videos out in the next coupla days.
It's out to the testers...time for a beer and some kick-back. I'll try to get some videos out in the next coupla days.
14.10.10
7up appears to work with Monomodular....
I don't have a great deal of time to learn 7up right now, but it appears that everything works (I had a report to the contrary). Seems kinda slow to me, but again, I've only spent five minutes with it and have no idea how its really supposed to work. A project for another day....
Anybody with experience, please leave some feedback.
Cheers :)
Anybody with experience, please leave some feedback.
Cheers :)
Ohm64 script is done :)
My apologies to those of you to whom I've made promises and haven't delivered on yet....I know there are a few of you out there lately.
Real life is extremely busy for me presently, and I've had little time to spend coding and doing computer related things.
I have, on the other hand, finished the Python script for the Ohm64. There are a few errors I've been getting that need to be tracked down, but for the most part it is complete for now. There is also a lot of room left for additions as people request them or I think of them myself.
I need to finish the m4l companion to the new script so that it can be released. It will provide a HUD that works in the same fashion as the LCD patch I built, but will function for all the knobs/faders on the device. I may add some feedback for button assignment, as well. It is mostly finished already; the only thing left to do is to incorporate the pertinent parts of Monomod into the mix.
What this means for the rest of you: probably nothing, unless you own (or plan on buying) an Ohm64. However, because of the investment in time I've already made working in Python these past few weeks, the iPad script will be getting rewritten next, and oh man its gonna be so much better (read: faster). I've come to the conclusion that any API stuff that I need to do for now on will be taken care of in Python, as its easy to link the functions from m4l. There's so much raw horsepower in there, its such a shame that the Abes won't give us clear docs and a debugger....I mean, they've already given us access with m4l, but its basically worthless without rewriting the _Framework functions to take advantage of this.
Sigh.
I'll have the Ohm64 script out to the public next week if I can find some beta testers (maybe the following week, if there are a lot of things to fix). Then a rewrite of the iPad script, and finally back to Plinko: I'm going to recode its engine in Java, so I have some more headroom. Basically, I should be able to cut down the processing load for the main patches by 50% I think. (I hear someone far away yelling "the proof is in the pudding!")
Real life is extremely busy for me presently, and I've had little time to spend coding and doing computer related things.
I have, on the other hand, finished the Python script for the Ohm64. There are a few errors I've been getting that need to be tracked down, but for the most part it is complete for now. There is also a lot of room left for additions as people request them or I think of them myself.
I need to finish the m4l companion to the new script so that it can be released. It will provide a HUD that works in the same fashion as the LCD patch I built, but will function for all the knobs/faders on the device. I may add some feedback for button assignment, as well. It is mostly finished already; the only thing left to do is to incorporate the pertinent parts of Monomod into the mix.
What this means for the rest of you: probably nothing, unless you own (or plan on buying) an Ohm64. However, because of the investment in time I've already made working in Python these past few weeks, the iPad script will be getting rewritten next, and oh man its gonna be so much better (read: faster). I've come to the conclusion that any API stuff that I need to do for now on will be taken care of in Python, as its easy to link the functions from m4l. There's so much raw horsepower in there, its such a shame that the Abes won't give us clear docs and a debugger....I mean, they've already given us access with m4l, but its basically worthless without rewriting the _Framework functions to take advantage of this.
Sigh.
I'll have the Ohm64 script out to the public next week if I can find some beta testers (maybe the following week, if there are a lot of things to fix). Then a rewrite of the iPad script, and finally back to Plinko: I'm going to recode its engine in Java, so I have some more headroom. Basically, I should be able to cut down the processing load for the main patches by 50% I think. (I hear someone far away yelling "the proof is in the pudding!")
8.10.10
7 up with Monomod
I haven't tried this yet, but has anyone gotten 7up to work with Monomod? I had an inquiry yesterday and simply don't have time to check it out right now. Drop me some email if you have some details. Cheers.
a
a
5.10.10
Blinky
I received a wonderful package in the mail last Friday, and am just now getting around to playing with it. Peter Nyboer and the guys from Livid have let me borrow an Ohm64 in order to port the Monomodular stuff over to it. Its a very sexy piece of hardware, and I can't wait to be triggering stuff from it in the manner that I'm accustomed with the other controllers that I've worked with previously.
My original intention was to just port over the pertinent sections of Monomod so that Ohm64 users would have access to my patches, but I realized very quickly that things weren't going to be that straightforward. After all, Monomodular is centered around multicolor grid controllers, and the Ohm64 is just...well, "blue". But that was kinda enticing in itself, since blue is my favorite color for leds, and none of the other c_s's that I use even have that color (why is it always all or nothing?!).
So my first task was to implement some kind of flashing state built in to the Python script for the controller. Since I was having to use a lot of my own functions, it seemed simpler to just write a new Python script on top of what I've already done for Monomodular and use it for more general purposes. I thought it was going to be a lot of work (and probably will be, by the time I'm done), but at least the initial work is already done: I have flashing buttons (which can be set by sending a message between 1 and 126 to set the interval), a session controller, and some other basic functionality working quite well.
I built a new class on top of the _Framework for the button class that overides a few things and adds a few other things. This, in conjunction with another call from the main class, is all it takes to get buttons with flashing feedback. This is general, so you can use it with any other Python script that is based on the _Framework stuff. I'll probably revise it a little when I have time to figure out how to add an internal timer instead of calling everything from _update_display, but its some good progress, and I think a few people will be really happy about it.
I have another evening to work on this before I have to go back to work, but there should be some new releases here in the next couple of weeks that support another piece of hardware and round out some of the things that I've already released. I'm now trying to incorporate as much as I can into these Python scripts and move a lot of the heavy lifting from m4l over to them. So far, so good.
My original intention was to just port over the pertinent sections of Monomod so that Ohm64 users would have access to my patches, but I realized very quickly that things weren't going to be that straightforward. After all, Monomodular is centered around multicolor grid controllers, and the Ohm64 is just...well, "blue". But that was kinda enticing in itself, since blue is my favorite color for leds, and none of the other c_s's that I use even have that color (why is it always all or nothing?!).
So my first task was to implement some kind of flashing state built in to the Python script for the controller. Since I was having to use a lot of my own functions, it seemed simpler to just write a new Python script on top of what I've already done for Monomodular and use it for more general purposes. I thought it was going to be a lot of work (and probably will be, by the time I'm done), but at least the initial work is already done: I have flashing buttons (which can be set by sending a message between 1 and 126 to set the interval), a session controller, and some other basic functionality working quite well.
I built a new class on top of the _Framework for the button class that overides a few things and adds a few other things. This, in conjunction with another call from the main class, is all it takes to get buttons with flashing feedback. This is general, so you can use it with any other Python script that is based on the _Framework stuff. I'll probably revise it a little when I have time to figure out how to add an internal timer instead of calling everything from _update_display, but its some good progress, and I think a few people will be really happy about it.
I have another evening to work on this before I have to go back to work, but there should be some new releases here in the next couple of weeks that support another piece of hardware and round out some of the things that I've already released. I'm now trying to incorporate as much as I can into these Python scripts and move a lot of the heavy lifting from m4l over to them. So far, so good.
Subscribe to:
Posts (Atom)