sysex hijinks / custom UI elements / perl

Jul 9, 2008 at 12:21am

sysex hijinks / custom UI elements / perl

Fact: bombarding synths with randomish parameter changes leads to fun and otherwise crashing hardware in hilarious fashion.

See attached example – this overly complicated mess of spaghetti allows you to map CC parameters to sysex data that drives a dave smith mono evolver … I can’t stress _overly complicated mess of spaghetti_ enough…

I’ve made similar patches for quite a few synths, and it’s a tedious PITA, leaving me longing for a streamlined solution – in other words, some sort of interface that allows me to abstract the process and easily switch between parameters and synths, etc.. a full fledged midiQuest/unisyn-but-not-a-piece-of-crap type deal would certainly be nice, no?

I had hoped that there would have been at least 1 psycho out there who had similar thoughts – that there might be some library which would help streamline the development process … at the very least, some lib of UI primitives that would save me from crying myself to sleep each night as I wasted weeks writing tedious jsui-based tools. While something like the iceUI jams look interesting, it’s a no go for me due to my using Max on both Mac and PC.

So, ehm… Suggestions? :) Greatly appreciated…

Also, I’m a Perl programmer by profession. I see that we have nice implementations of Ruby and Python, but nada for Perl. I realize that Ruby is similar, but … what can I say, I want my binky. I spent a good day checking out the ajm.ruby’s source and attempting to find a working java-perl solution that i could think about hacking in (Inline::Java seems like it might work… but so far my attempts to get it working in vista have been a no go) … Any suggestions regarding making this a reality would also be greatly appreciated.

Oh, and I’ve made quite a few other tools (that fortunately look nothing like the attached) that I’ll likely release in the future – Among them a super in-depth midi LFO generator, robust ‘zero-config’ IP midi networking tools, etc…)

Cheers,

mike

http://www.nintariman.com/
http://www.teamtechno.com/

http://www.myspace.com/nntrmn

– Pasted Max Patch, click to expand. –
#38800
Jul 9, 2008 at 4:28am

Quote: c74@nintariman.com wrote on Tue, 08 July 2008 17:21
—————————————————-
>
> Also, I’m a Perl programmer by profession. I see that we have nice implementations of Ruby and Python, but nada for Perl. I realize that Ruby is similar, but … what can I say, I want my binky. I spent a good day checking out the ajm.ruby’s source …

Brave man. Let me just say that ajm.ruby’s source is way more complicated than it “needs” to be, because I kept adding features for use within the Max environment that aren’t directly related to evaluating Ruby scripts. These features are useful to me but weren’t required to run Ruby in Max. The shared context feature alone makes the code about twice as complicated/confusing as it originally was.

My point is, if you want some basic Perl support it could be a lot simpler.

> and attempting to find a working java-perl solution that i could think about hacking in (Inline::Java seems like it might work… but so far my attempts to get it working in vista have been a no go) … Any suggestions regarding making this a reality would also be greatly appreciated.
>

It looks like Inline::Java is kind of the opposite of what you need. It “allows you to put Java source code directly inline in a Perl script”. But Max can’t run Perl code. It can run Java, so you would need to inline your Perl scripts in Java. Or do it some other way…

If you want to go the Java route, I googled a couple projects that sound sort-of promising but look immature and haven’t been updated since 2004. Not a good sign, but who knows? Maybe one of them will work well enough for your needs.

First there is BSFPerl: http://bsfperl.sourceforge.net
In case their docs are lacking, maybe the java code from this BSF/ruby tutorial will help: http://compusition.com/web/articles/ruby-eclipse
If you replace the JRuby stuff with BSFPerl it should work similarly.

The other Java-based option I see is PLJava: http://search.cpan.org/~gmpassos/PLJava-0.04/README.pod

Another approach would be to embed Perl in a C external. Google finds a few options, but this is getting outside my realm of knowledge. This option isn’t good for Max 5 yet because the C SDK isn’t out. Maybe soon? I’d guess it may be trickier to get this approach working intially, and cross-platform support will take additional effort, but it might be better than the Java route in the long run.

If it really came down to it, you could write a C or Java external that just execs perl on the command line. But the integration is very loose in this case. You can only communicate back to Max by watching sysout, but maybe that’s good enough?

Good luck! Let us know if you make any progress.

#135653
Jul 9, 2008 at 4:36am

One other thought on perl:
You could write standalone perl programs that communicate to Max via the network (UDP or TCP), possibly using a protocol like OSC. Maybe it’s an easier way to get started. This is how a lot of people integrate with languages like Processing or Flash without doing a lot of extra work to embed them inside Max.

#135654
Jul 9, 2008 at 6:50am

Er, Inline::Java::PerlInterpreter – Sorry, should have been more specific – Slightly confusing module hierarchy there as well.

Very interesting tips that I will definitely look into. Thanks. And, hey, credit where credit is due! your ruby implementation actually looked quite understandable and concise. The python bridge I looked at, however… yikes! almost as scary as python itself. ;)

-Mike

#135655
Jul 28, 2008 at 9:29pm

It’s heartening to see that there is (at least a tiny amount) of other interest in using Perl within Max. I’ve been consistently surprised to see no talk of it at all, although I’ve never taken it upon myself to start the conversation either. I’m certainly curious to see what you come up with.

Recently, I’ve found myself drifting towards learning Python as an alternative. A little scary, yes, but possibly wouldn’t hurt to loosen my grip on the Perl security blanket a bit.

#135656
Jul 29, 2008 at 12:44am

I’m interested in Ruby enough to warrant the time spent learning – Python I can’t bring myself to. I spent a few days rewriting that hacked-together python hook-in to Live a few months ago, and, (although successful), this reminded me of how much I disliked
the language.

Another thing to consider is that no matter what [scripting] language we get working, unless we’re talking about implementing it through an external written in what I assume is C or C++, it seems we’re stuck with implementing it through Java. Unless you’ve somehow gone to the next level and figured out how to interface with a compiled version of said scripting language, when you think about it, the bottlenecks are entirely absurd. Timing, stability, and efficiency are often of vital importance, and, well… do you see what I’m saying? If not just for that reason, I’ve always wondering why C74 chose to integrate Java and JavaScript so closely…

Other options as far as languages that are tightly integrated to the max core would be such a nice thing … With perl, you have the joy of CPAN, which often saves tons of time and keeps one from unnecessarily reinventing the wheel. Can I dream of a ‘perlui’ external? :)

In any case, I’ll end my b*tching there :) I love Max, but it’s shortcomings do frustrate me more days than not. As with all things in life, better to try and do something about it than complain.

With that in mind and in regard to the _actual_ topic, I have looked further into Perl integration at the “Scotch Taped on through Java” level, and yes, it is possible – I’m working on it. Hopefully within the next few months I’ll have something worth releasing.

Cheers,

mike

http://www.nintariman.com/
http://www.teamtechno.com/

http://www.myspace.com/nntrmn

#135657

You must be logged in to reply to this topic.