aum.haa

Hey guys,

I’ve been working on the Max6 compatibility stuff quite a bit.  The fact is, everything in b993 SHOULD work without any changes, but there is apparently a bug in Max6 which is affecting how the patches convert over from Max5.  If you’re interested in the specifics, I started a post over at C74 forums when I discovered this flaw:

http://cycling74.com/forums/topic.php?id=41312

If anyone has any further information about this, feel free to chime in there.  I’ve been unable to reproduce the behavior in fresh js instances that I’ve built from scratch with regularity, but it affects all of the scripts that I’ve written in Max5 and then carried over to Max6 (which is very strange indeed).

Anyway, its a non-issue now.  I spent the weekend rewriting the connection routine that is used between m4l and Python for the current Livid project I’m working on, and as soon as time allows I’ll be porting that stuff over to Monomodular.  Basically, I spent my time doing the exact same thing that I did six months ago, when I wrote this exasperated post:

Mirror People

Fortunately, though, I understand Python  (and m4l) a little better now, so I’ve been able to solve some problems that are happening on the front-end by applying solutions to them on the back-end  (an “ass adjustment”, if you will….the sort of thing Dad always use to threaten me with to get me to do my homework).

Since this is going to be a ‘less than trivial’ update, I’m going to try and get the other recently made architectural changes into all of the scripts before release.  Among these changes:

1)  The new connection routine, which further stabilizes editing mods in m4l (read: no more crashes (?)), and works around the js dummycallback issue in Max6 (the cause of  all the misbehavior for those of you trying work in Max6).

2) I’ve discovered a way to run the Monomodular script in the ‘background’, meaning the user won’t need to implicitly instantiate any extra scripts in a Control Surface slot.  If you load a script that needs the Monomodular script, that script will automatically instantiate it in Python, without need for the user to do anything.  For those of you already using this stuff, that’s probably not a big deal, but it will give you an extra slot to put things if you want.  For those new to Monomodular, however, this should help out with some confusion, since this is the number one support problem I have to deal with (even though I feel like it’s pretty well documented).

3) I’ve created a new MonoDeviceComponent for Python.  It is capable of connecting directly to a control surface’s controls, and dynamically changing parameter assignments to its controls.  It’s much faster than doing this stuff through the m4l API, and will eventually get integrated into all of the mods that I’ve built.

4)  I’ve been spending a lot of time creating a new mod (this one is for CNTRL:R currently, but will be ported to the other surfaces as well).  I can’t go into details at the moment, but it will consolidate the functionality of several existing mods and add new functionality to them (TR256, polygome, binary).

5)  I’ve also ported some of the Codec mods (binary and endcoders) to the CNTRL:R, and if time allows I’ll release them with b994.  I’m going to try and change the encoder response on “endcoders” before release, but with the integration of the new MonoDeviceComponent coming, most of the implementation for it is going to change anyway.  I’m afraid you probably won’t see that until b995, though.

6) There might be an extra surprise in store as well 😉

So, you might judge from this laundry list that you may not see anything for a little while:  and you might be right.  I’m not sure how long it will take me to get all of this finished, but I’m shooting for two weeks on the outside (I’ll be touring after that anyway, so it’s kind of my self-imposed deadline).  Since this technology overlaps some of the Livid stuff I’m working on currently, I’d prefer to get it out and tested sooner than later, as we may discover some problems that would affect both.

I appreciate all the offers of you’ve all made to beta test, and I’ll definitely be taking you up on them in short order;  for the moment, however, you can suspend sending bug reports, etc.  Since the existing connection routine is totally fubarred in Max6, nobody is actually getting any further than that.

On the other hand:  if you’re getting a connection with the current build in Max6 and things are working fairly well, I’d love to hear from you.  Since this js callback bug seems to affect some users and not others, it would be helpful to understand why.

Greets and cheers from the foggy summerland of the Northern Cali coast….

a

Posted in Uncategorized

I don’t have much for you in this installment.  I’ve been re-imagining some things, re-combining some things, and trying to simplify my own setup.  I’m getting closer to a release of some stuff for the CNTRL:R, but I’ve had to change directions several times so it’s taking the usual “longer than expected amount of time” to complete.  In any case, stay tuned as I’m going to try to push this stuff out before the middle of next month.

In other news, I’ve decided to make Monomodular Max6 compliant at this point, so if any of you want to test stuff out, drop me a line.

Happy blinking!

a

Posted in Uncategorized

Well, I’ve made my usual departure from programming for a while.  It has been a busy time for me doing Live sound more than usual, working for Livid, recording a folk album (!?), quitting smoking, etc. etc.  All the myriad of things that one does when one has four or five jobs and a pseudo-life.  Thank god I don’t have children or something….they would hate me. I’m still working on things, don’t worry.  I’ve definitely gotten away from the solid hours of staring at a computer screen that I’d gotten familiar with over the last year, though.

I’m afraid that most of my current programming work has centered around integrating new pieces of hardware into my Live set, and I’ve not made much progress in creating things for the “Public Domain”.  Still, the work I’m currently doing is certain to please someone out there.

I’ve recently acquired a Slim Phatty, and I’ve created/adapted an m4l device that takes care of all its parameters directly via the lh_midi plugins.  It uses sysex to communicate, which is something that was lacking in the other patches I saw.  Since Moog hasn’t published the sysex specs anywhere, this was largely a (painful) trial and error process.  When its finished, I’ll push it out into the wild.

Most of my coding time over the last several months has been spent doing things with Livid (awesome!), and trying to use my past work and techniques I’ve derived from making Monomodular to get the CNTRL:R ‘mod’ system up and running.  Now I’m turning to my own needs, and trying to tie it into Monomodular as a secondary performance controller.

Integrating the CNTRL:R into my Live rig has been…well….frustrating, to say the least.  It offers so many opportunities for expanding the nature of control I have over things.  It’s an unfamiliar arrangement of things, and its taken me a while to adapt my way of thinking in order to accomodate it.  I’ve found myself bouncing back and forth between different schemes, and I’m just now coming to conclusions about how things are going to work.  It’s made slightly more difficult by the fact that much of the programming that I’ve done for Livid over the past several months has been parallel, but slightly askew, from my own methods;  now I’m trying to integrate Monomodular with the work I’ve done already with them.   The good news is that it’s shaping up quite nicely.  The bad news is that it’s nowhere near finished.

I’ve created new ‘mods’ for the CNTRL:R that tie directly into some previously released Monomodular mods:  Binary and Knobs are both in the testing phases, but I can already see some need for major changes in what I’ve done thus far.  I’m currently adding some functionality to the main Monomodular based scripts that allow sending data out to the LCD patches/Lemur for display of data when in Monomodular mode.  I personally can’t dispense with this sort of thing, otherwise I never know what’s going on in my set.

TR256 is getting a pretty huge overhaul over the last several days.  I liked so many of the ideas that we used in the DrumStepp:r for the CNTRL:R, but I didn’t want to lose the functionality or speed (and low overhead) of the TR256, which is really the backbone of my performance rig.  So I’ve spent the last couple of days integrating all the good bits of the Stepp:r with the TR256.  This way, I can edit individual lines on the CNTRL:R, change the start/end points, mute parts, and edit all the associated instruments parameters with the soft dials.  I’ve mostly rewritten the functionality of the Livid mod completely within TR256 at this point, since the architecture of the two mods was completely different.  I finally finished the important bits tonight and gave it a little spin, and I have to say it is VERY fun.  I have it in mind to do the same thing with Polygome/SynthSteppr.  That way grid playing and editing can be done on the Ohm(or whatever grid you’ve got), and the recording/parameters can be handled with the CNTRL:R.  That one might be a ways off, though.

I’ve also spent a good amount of time writing an alternate script for the CNTRL:R that ties directly in with the MonOhm script.  Once I get the last details worked out, I hope to do some posts on the Livid forum or something explaining exactly what I did, how I did it, and how you can make your own edits.  I’ve had a lot of people asking lately “how do I get started with Python scripting in Live, what’s the easy way?”  Well, there isn’t one.  Sorry.  I stare at code until my eyes bleed.  It’s kind of painful, to be honest.  It takes some knowledge of Python, certainly, but above all it takes going over and over and over again the decompiled Live _Framework scripts until you have an understanding of what’s going on.  After that its a matter of too much time spent making trial and error.  There aren’t any short cuts that I know of, I wish there were.

Will Marshall has a nice little project he’s started to unify the Livid scripts and make understandable, modular _Framework extensions for the stuff that’s already been done.  I’d love to jump onto that train, time allowing; I’m afraid most of this stuff is going to have to wait until the fall.  In any case, it would be a better starting point than the stuff that I’ve made, since a lot of that was written when I was still getting to know what I was doing.  (please don’t misunderstand:  I still don’t know what I’m doing)

Unfortunately, time is still tight for me and I probably won’t have a lot of time to work on personal stuff after this month, but I will try to publish the material that I’ve created before I go back on the road for sound gigs at the end of the month.  I’d love to hear how you guys are doing out there, and how Monomodular is working out.  Every once in a while I hear from an excited new user, but for the most part I take the silence to mean that things are working the way they are supposed to 🙂

Thanks to all of you for the support with this thing I do…its pretty cool to get feedback from people that are using it.

I really like to hope that the next release I will make will be the kind that you listen to, not the kind you install.  But all in good time…inspiration often hits at the oddest times.

Cheers, happy sunshine and all that….

a

Posted in Uncategorized

Actually, I put the link to this stuff up last week.  I think that a few people noticed, so if you’ve already downloaded version b993, you should do so again:  I’ve made some recent fixes and additions (like the new modlink mod).

Immense gratitude to the pre-release beta testers that have been helping out with this.  There was a bunch of stuff to do, and you guys did it.

Now, of course, the rest of you are beta testers too….but all the really hard work has been done on this one, I think.

I’ve added a great amount of material to the Wiki lately.  I’ll keep adding to it as I have time, especially for the individual mods.

You should have a look at the readme in the b993 package.  There are a LOT of changes, and I’m not about to list them all here.  But here’s a summary of the main additions:

New MonoLinkClient for monome emulation….it DOESN’T require Max for Live.

New modlink mod (replaces old monolink mod).  Now supports SerialOSC, and multiple instances should work, like, groovy, man.

Several new ports:  Live Clip Chopper, Grainstorm, _xor.

New modMode ‘ALT’ functions:  Mute, Select Device, View Device, Power.

Better Device selection behavior for MonOhm and AumPad scripts.

Included a new Code template for the Lemur….it does everything a real Livid Code does.

More bugfixes than I feel like listing…see the readme included with the content.

There were a LOT of changes in this one.  I’m still working on things, and will regularly update the content, but for the time being I’ve run out of time to work on this (and spent too much time on this one anyway….it really should have been two separate releases), so it’s time to push this version out.

Documentation for the new MonoLinkClient is somewhat lacking at the moment, but I’m probably not going to spend a great deal of time on it until the next release.  I want to get some feedback about how well everything works, and then I will make some changes to things.

I’ll try to get a video up next week, but I have other priorities at the moment, so…..anyone else want to make some tutorials for MonoLinkClient?

I have a huge list of stuff to start working on for b994, and I really didn’t even finish what I had intended for the present release.  But progress is progress.  I’ll write another blog post about that on Monday or something.

Have fun, and as usual:  this is beta, please let me know what problems you are having, so I can fix them.  If you have questions about things, email me or leave a comment here so others have a chance to see the answer as well.

Happy Blinking!

https://aumhaa.com/Monomodular/Monomodular_b993.zip

Posted in Uncategorized

I’m getting very close with this b993 thing….I worked out the bug with the DeviceControlComponent earlier this evening….a simple problem with a complicated fix that was simply implemented by a closure in the right place.  I love closures 🙂

I’ve gotten a little feedback from users of a test release of b993, and no one has had anything bad to say.  All that’s left to do is tidy up the packaging, add a mute indicator for the new ModMute functionality, and add the MonoLinkClient support to the half of the Python scripts that it hasn’t been already ammended.  You’ll like it, I think. More details about this with the release, and I need to hand it off to a couple of beta testers, but here’s a teaser, if you haven’t already seen it, from about a week ago (when I’d just confirmed it was possible):

What does that mean?  Well, I’ve assembled a new Monoclient script that lives in Monomodular, and it’s capable of sending and receiving  directly from Live via _osc._udp (this isn’t really news, LiveOSC has been doing it forever); it also publishes all its connection information via ZeroConf/Bonjour, so any of the new monome patches supporting serialosc will be VERY easy to connect to.  This means that your grid-based, Monomodular compliant device will now be a ‘ringer’ for a real monome, sharing its connection protocol without needing any intermediary apps.  Just load the scripts in Live, and all the connection configuration can be handled by pressing ‘Alt’ and entering the information from the grid.  If it’s a serialosc app your trying to connect to, you don’t even need to do that:  you just hit the ‘connect’ button on the monome app, and your device will be automagically connected.  YOU DON’T NEED M4L.  It’s not going to be as fast as the m4l monolink, but I’ve been using it over the last several days, and its plenty fast for most things.  The proof will be in the pudding, though, I guess.

Oh, and I’m now taking suggestions to add to the default user configuration file for handling automatic (preset) connections.  What does that mean?  Well, basically, I want to know what the most popular monome apps are among users, and I’ll put their connection information into the script so you don’t have to do it later.  Right now, I have Polygome, Molar, and 7up in the registry, but I need twelve more.  They can be serialosc or monomeserial, as the new script does both types of connections.  You can always input the port data directly by way of the Mod grid, but the User Configuration file will allow you to store 16 preset addresses (as well as their prefixes and communication protocols) so you can get to them quickly, just like you would with normal Mods in m4l.

At this point it looks like b993 is going to be the testing ground for a whole lot of new things.

a

Posted in Uncategorized

Thanks to some other stuff I’ve been working on for Livid, and a user report a week or two ago, I’ve discovered a major flaw in the DeviceComponent stuff I’ve been working so hard to fix for the b993 release.  This means things will be taking a little longer to fix (since this problem is in, like, all of my scripts), but it also means they’ll hopefully be fixed when you get them.

The problem has been there for a while, and basically causes parameter banking not to work correctly (you get best-of banks when pressing shift to change banks, but a different set of parameters when un-shifted, and you can’t go past bank one).

I’m really curious how I got so far without realizing this, but I guess I use Macros for everything in my set, so I never actually go past the first bank.  Anyway, that will be getting fixed pronto.

Thanks again for user reports….they do help a lot (when I have time to investigate them, anyway 😉 ).

a

Posted in Uncategorized

Ok, I’m done mucking about with it.  Despite PLENTY of other obligations right now, I’ve managed to make the necessary changes to the installer and get most of the files together for b993.  Still not public, but if you want to test it and can provide proper feedback for what’s still lacking/not working, then hit me up, as I’m trying to tidy everything up for imminent release.

Thanks, as always 🙂

a

Posted in Uncategorized

Did you miss me?  Well, I’m not heartbroken if you didn’t, but I’m sorry if you did.

I’ve been extremely busy of late working with Livid, mostly getting ready for the launch of the new min:s collaboration, the CNTRL:R, and its accompanying step sequencer.  I’m officially part of the Livid Instruments team now (and very stoked about that!), so time for my personal pursuits has been slightly curtailed lately.

But don’t fret.  I’m still working on b993, and it is mostly finished at this point.  I’ve found a couple of inadequacies that I’d like to fix for release, and have added a special bonus Lemur template that will probably please some users.

Regarding a project that I’ve mentioned in the recent past:  the ClyphX integration I’ve been contemplating is getting put on the back-burner until I have some more time, but its still on the list of ‘to-dos’, so I’ll get around to it.

I’m also embroiled working as my alter ego, the ‘Recording Engineer’, recording a completely non-electronic solo album for a good friend of mine, so my time has been smeared pretty thin upon the canvas of life for me lately.

Stay in touch if you have any immediate needs regarding the existing stuff, and the time is getting close that I will be giving b993 to some beta testers to make sure that nothing has gone too far awry before a public release.  If you’d like to be included, make sure to drop me some email.

Cheers, and happy blinking 🙂

a

Posted in Uncategorized

I’ve made quite the mess of things with this most recent revision.

No worries, you’ll be happy with the end results.  But its taking longer than I anticipated (as it always does….why didn’t I anticipate that?), as I got over-zealous and made some pretty major changes to the underpinnings of some of the main scripts, and now I’m left to work out all the bugs.

The good news:  b993 is going to have some pretty significant improvements to, well, everything.  The bad news:  it’s going to be probably another week before I get everything finished.

You can look forward to improved functionality for Device selection in all the scripts (read: it will work the way it was originally intended to), improved performance for all the MIDI-generating mods (no more stuck notes when changing channels), and an extra bonus which won’t really be utilized until later versions, but adds some promise of possibilities to the entire architecture 🙂

Oh, and I have a cold, so I’m not exactly feeling much in a hurry these days.

a

Posted in Uncategorized

Just a quick note….I’ve made some further modifications to the Windows installer to make things work better for Windows 7 users.  There are still some limitations, which hopefully will be worked out before I release b993.

Mainly, the installer doesn’t seem to autodetect paths when you first drop it in.  I think that Live is probably accessing the log.txt when this happens, which prevents Max from accessing it at the same time.  In any case, you should be able to delete the installer from the track you placed it on, and then reopen it to get autodetection to work.  Sometimes it takes a few tries.

If all else fails, check the wiki for information about where to install the files manually; there is a link to the ‘Manual Installation’ instructions on the installation page of the wiki, as well as more detailed instructions on using the Installer.

Sorry about the difficulties for Win7 user’s, I’ve been trying to make this more painless. I’d really love some more feedback on your experience, be it successful or otherwise.  I updated the installer yesterday again, so you might want to re-download the most current version if you are still having problems.

a

Posted in Uncategorized