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.
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)
