All times are UTC


Post new topic Reply to topic  [ 3 posts ] 
Author Message
 Post subject: Need some help with inbound NRPNs from MS-2000
PostPosted: Mon Sep 19, 2011 11:35 am 

Joined: Fri Jun 15, 2007 1:55 pm
Posts: 21
Location: Michigan

First, I know this is a lot of text to parse. I've tried to break it down as simply as possible to articulate what I'm asking for. Thanks in advance for your patience and understanding as this is somewhat difficult to relay as I'm relatively new to MAX/MSP in M4L. Also I'm trying to relay the entire situation as it is now, so that includes what I've succeeded with and my strategy of what I did. This is not to toot my own horn, it's so that I can give the most information to increase the likelihood of getting help :)

OK so, I'm looking for a bit of help for M4L. I've built a device for my Korg MS-2000 to control it, much thanks to Rozzer! By dissecting one of his devices I was able to get something built quickly for my microKORG which translated into this MS-2000 device.

Here is a screenshot of the MS-2000 so far:

Here is a screenshot of the MS-2000 patch so far:

Here is the MS-2000 Hardware Controller MIDI Device on

I eventually want to skin it, make it open in a window so it's not stuck at the bottom and so freaking long :) etc, but not until I address a few other things.

Regardless of my pending work, this device is fully functional as it is, just not as perfect as I want it to be. It's a hell of a lot better than nothing. .

the native integration with Live is a dream to work with as I have almost a 1:1 symbiotic relationship between my MS-2000 and Live:

  • When I adjust a control in Live on the device, it sends it to the MS-2000. This includes everything NOT sysex (which props to Korg for having a lot of foresight and only putting really fiddly bits deep into sysex) e.g. CCs and NRPNs.
  • When I adjust a control on the MS-2000, it sends it to Live device. So far this only works with CCs and not NRPNs from the MS-2000 (this is what I need help with)

Still awesome :)

I'm only missing NRPNs inbound from the MS-2000 to change the controls of the M4L device. e.g. if I turn on the ARP on the MS-2000 I want the M4L device to light up the ARP ON state. I think this is possible using a similar tactic that I used in a js file but I'm stumped. Except for sysex which is unsupported in M4L because Live doesn't do sysex, it's fully implemented outbound from the M4L device.

I've been able to solve the following:

  1. Mapping controls in M4L device to the CC outputs into MS-2000.
  2. Mapping controls in M4L device to NRPN outputs into MS-2000.
  3. Mapping controls from MS-2000 into M4L device for CCs.

What I need help with particularly is an elegant way to map controls from MS-2000 into M4L device for NRPNs.

Let me explain a bit.

How it works right now, I have ctlouts and ctlins for all the CC stuff, that part is easy. The NRPN approach I took was to code a js file called nrpn.js, then use receives for MSB: CC98, LSB: CC99, and VAL: CC6. The js file has an inlets to accept the VAL from the M4L UI control. When the control is adjusted it uses messnamed() function to send the NRPN values to each receive, perfect. This is elegant as I only need 2 boxes for every control to support NRPNs outbound.

There is one receive for MSB, LSB, and VAL, and they go directly to the MS-2000.

This works already, and I simply pass values to these receives through the js nrpn file like this:
send_nrpn {MSB} {LSB} $1



To elegantly solve the NRPNs inbound from the MS-2000 here is what I tried so far:

Creating a ctlin 98, ctlin 99, and ctlin 6 - these go into sends, but this isn't exactly perfect like the NRPNs output FROM M4L strategy I used because I need a conditional to only pass through the according values and filter the rest out.

So what I tried was creating receives for the MSB, LSB, and VALs, then referring to them in an if box:

if $i1==0 && $i2==4 then $i3

Connected to inlet 1 is r nrpn_in_msb
Connected to inlet 2 is r nrpn_in_lsb
Connected to inlet 3 is r nrpn_in_val

The outlet of the if is going into the control modifier value (for example inlet 1 on a knob, or switch so if MS-2000 sends 127, in a toggle it lights up). Inlet 1 and 2 of the if are only filters to make sure that no NRPNs go in that shouldn't (I don't know a better way to do this but I'm sure this isn't perfect).

My theory is that if I send a NRPN FROM the MS-2000, it SHOULD parse each CC into the sends from the ctlins for the MSB, LSB, and VAL, and these should be received into the receives, then pass through (assuming the conditions are met) the if box to the M4L UI controls inlet to update it's value/state.

What's strange is, the if statement never emits a value. No matter what I try.

I've put watch monitors on the wires from the ctlins to the sends, they show the proper values.

I've put watch monitors on the wires from the receives into the if and those also show proper values.

HOWEVER, nothing ever comes out of the if as the watch monitor on that always shows a 0 and it never changes. EVEN THOUGH $i1 == 0 and $i2 == 4 (which is boolean true and thus $i3 should come through). The ONLY thing I can think of is that the receives aren't happening at the identical time. I read about a MAX object that will collect values into it's inlets and only bang out all of the values simultaneously when they have accumulated/changed each one from left to right (or it may have been right to left) but I cannot remember what it was called (and this is just a developers hunch anyway).

So even if my strategy worked as expected for inbound NRPNs to the M4L device, I have a concern:

If I am receiving an NRPN and updating the value of the M4L control wont that trigger a bang?

I don't want to trigger a bang right?

Would that not cause some sort of endless loop: e.g. the MS-2000 button sends the NRPN to change the control which is wired up to send the NRPN BACK to the MS-2000, if not an endless loop and the MS-2000 is smart enough to know I did not PHYSICALLY make this change, at the very least it's going to send the same message twice right?

Anyway, thanks very much in advance for the help!

*edit* Added screenshot of the patch.

 Post subject: Re: Need some help with inbound NRPNs from MS-2000
PostPosted: Mon Sep 19, 2011 1:51 pm 

Joined: Mon Jul 26, 2004 8:37 am
Posts: 1140
Keep in mind that an 'if' object is evaluated when the *left* inlet receives a message ("hot" inlet).
So you need to make sure that other inlets have received their corresponding values before.

 Post subject: Re: Need some help with inbound NRPNs from MS-2000
PostPosted: Wed Sep 28, 2011 8:10 am 

Joined: Fri Jun 15, 2007 1:55 pm
Posts: 21
Location: Michigan
Thanks for your help broc.

I sorted it. v2.0 is up here: ... d=900#2651


I've implemented inbound NRPNs, multislider instead of knobs for modseq1-3 supplemented by live number boxes with sane defaults. I've hardwired SEQ1 to pitch (this is how it is at the factory and I can't think of a reason why I wouldn't want to use pitch for SEQ1 if you can feel free to fork it for whatever you like). I've modified the selectors when choosing OSC1 wave to hide/show the DWGS waveform picker and I've linked picking a wave from that menu to adjust the knob (though I couldn't do it from knob to menu without some problems). I added tab support for the mod seq section (this is much more elegant IMO!).

Next up will be a skinned GUI and a smaller "macro window" with an open button to open the full GUI, etc.

This is a lot fun!!!

The inbound NRPNs aren't perfect, but they are good enough. This let's the actual MS-2000 device control every aspect of the patch.

I've saved the patch frozen, and it includes all the assets in the frozen patch in my testing. (no zip file this time) though I will be making some presets and bundling those together in a zip file to distribute after the GUI is done :)

Hope you like it! Thanks for the help and encouragement.

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group