Tim Sutton

funny that I should see a "nanoKontrol not working" post at exactly the same time I go to post about a nanoKontrol problem!

Just got it yesterday. The device connects to Max without problems. When I am moving two or more CC's at once (problem is the same for knobs and faders), the lowest CC number is the only CC that responds smoothly. The other CC's only send a value when there isn't a stream of changes happening on the lower CC. In other words, if I try moving a few faders slowly, they all seem to be working okay, but once I reach a certain speed (that's not unreasonable), all CC's but the lowest wait and may never send their value if movement is continuing on the lowest CC.

So not only is the performance unacceptable whenever I'd want to move more than one fader/knob at the same time, but CC values easily get stuck at values far from where the knob may finally rest.

I've tested this by hooking up a few ctlin's to cycle~'s to listen for the zippering, to make sure it's not a strange UI update issue.

Other MIDI controllers work fine in Max. Tested Doepfer pocket dial and Faderfox LV2 (both working over standard MIDI, though, not USB).

I've tested the nanoKontrol in Live and Logic, and no such issue occurs.

Has anyone experienced anything like this, either with this controller or USB MIDI drivers in general?

Running OS X 10.5.6 on a Macbook 2nd gen. Max 5.0.7 and 4.6.3. Issue persists before and after installing Korg USB MIDI drivers.

Works perfectly in Windows XP. Any OS X 10.4 users?

**EDIT**
Works perfectly in Windows XP. Any OS X 10.4 users?


korg-nanokontrol-dropping-midi-messages-in-max-os-x

Tim Sutton wrote on Wed, 15 April 2009 23:22

Hi I experienced exactly the same problem but hadn't time to dig deeper since it's already broken (the usb port broke and it's to tiny to be weld by my clumsy hands)

Same problem, same configuration. Perfect in live.

Tim Sutton wrote on Wed, 15 April 2009 23:22
Just got it yesterday. The device connects to Max without problems. When I am moving two or more CC's at once (problem is the same for knobs and faders), the lowest CC number is the only CC that responds smoothly. The other CC's only send a value when there isn't a stream of changes happening on the lower CC. In other words, if I try moving a few faders slowly, they all seem to be working okay, but once I reach a certain speed (that's not unreasonable), all CC's but the lowest wait and may never send their value if movement is continuing on the lowest CC.

I had the same trouble when I plugged my little baby nanokontrol in also, I believe I saw a post mentioning that using the more stable [midiparse] object instead of ctrlin's may help.

I use a CClearn object I built for easy mapping of controllers and haven't tried altering it for midiparse's so I'm not sure it'll work but it's worth a try.

I had the same trouble when I plugged my little baby nanokontrol in also, I believe I saw a post mentioning that using the more stable [midiparse] object instead of ctrlin's may help.
I use a CClearn object I built for easy mapping of controllers and haven't tried altering it for midiparse's so I'm not sure it'll work but it's worth a try.

This is indeed a ctlin issue (I have the same trouble with an Edirol controller anyway) which I also solved by using midiparse. Here's my little abstraction (and help file) to fix it and add a MIDI learn function, maybe someone will find it useful...

I also broke the USB connector on my Nano, but did manage to solder it back together, so that too can be fixed. However it definitely takes careful hands.

This is indeed a ctlin issue (I have the same trouble with an Edirol controller anyway) which I also solved by using midiparse.  Here's my little abstraction (and help file) to fix it and add a MIDI learn function, maybe someone will find it useful...  

I also broke the USB connector on my Nano, but did manage to solder it back together, so that too can be fixed.  However it definitely takes careful hands.

This is indeed a ctlin issue (I have the same trouble with an Edirol controller anyway) which I also solved by using midiparse.

Same here, I adapted my ctl.in to work with midiin instead of ctlin. It does solve the problem basically, but I had another issue on my old PPC Powerbook. As I wanted the same behaviour as ctlin, which receives on all ports, I instantiated many midiins. And each ctl.in would have those. On the old machine touching one fader would let my CPU jump beyond 100% (causing audio dropouts) for a reason I don't know. On my recent MacBook that doesn't happen...

I just wonder if Cycling is ever fixing that issue. As midiin doesn't skip events, there must be a way to fix ctlin. It should be fixed!

The actual link to my St.ools/abhaXions collection is

https://dl-web.getdropbox.com/zip/Public/St.ools?w=afd8f940

it is the mirror of the St.ools on my hard drive. Its always the hottest version (including the hottest bugs...

Lewis wrote on Thu, 16 April 2009 03:37This is indeed a ctlin issue (I have the same trouble with an Edirol controller anyway) which I also solved by using midiparse.

The actual link to my St.ools/abhaXions collection is 

amazing, thanks everyone! I should have thought to try midiin.

My temporary workaround was running a pd patch with a midiin -> midiout to route the nano into the internal Max midi device. Wasn't looking forward to depending on pd for regular use 

brilliant! i thought it was just a cheapo controller problem and i was trying to put up with it. whole new dimensions of control are now open to me... thanks people. n

can someone explain on a low level why this is the case? does it make sense on a low level to change to midiin rather than ctlin when midi ctl messages are the concern?

ctlin (and notein) do not correctly implement the OS X CoreMIDI spec, which says that multiple MIDI messages may be placed in a single MIDIPacket.

Some drivers do put multiple messages in a single MIDIPacket if the messages are received within a certain threshold (about 1ms), especially the built-in OS X generic USB MIDI driver. Ctlin and notein will drop all but the first message in such a packet.

So it's a bug in ctlin/notein. Midiin does not have this problem.

ctlin (and notein) do not correctly implement the OS X CoreMIDI spec, which says that multiple MIDI messages may be placed in a single MIDIPacket. 

So it's a bug in ctlin/notein. Midiin does not have this problem.


Thanks for your lk.ctlin. i bought a nano kontrol today, started putting it together, encountered problems, ran into your lk.ctlin. Again, many many thanks..

Lewis-
       Thanks for your lk.ctlin.  i bought a nano kontrol today, started putting it together, encountered problems, ran into your lk.ctlin.  Again, many many thanks.. 

Amazingly enough, I have a NanoKontrol, and I also wasted an evening of my life in April on this known BUG where one of the most fundamental Max objects, ctlin

1. simply DOES NOT WORK (on the Mac - though I believe most Max programmers are on the Mac still)

2. seems well-known not to work by the Max programmers (you can see the question appears at least two other times on this forum, each time being established as "well-known")

3. could easily, easily be fixed in a lot less time than either I or the original poster *completely wasted* in tracking down an old, known bug.

As a programmer myself, I generally want to avoid saying how easy something is to fix unless I am the developer - but you could trivially do it by replacing ctlin with a Max patch containing midiin and midiparse - it might be a few microseconds slower than a native-code ctlin but it would *actually work*.

At the very, very least they could have ctlin print a warning on the console when you instantiated it!

I was pretty snarky about this when I ran into it back in April - it's like leaving sharp edges when making toys - and it disappoints me to see that this serious, well-understood, easy-to-fix bug has not been addressed.

Soooo.. lk.ctlin stopped working after a bit.. And I used midiparse and route as a work around... the first three scenes all go the the same faders and knobs. i think i set my fourth scene up wrong in my nano editor, so i didnt get into it..

Soooo.. lk.ctlin stopped working after a bit.. And I used midiparse and route as a work around... the first three scenes all go the the same faders and knobs.  i think i set my fourth scene up wrong in my nano editor, so i didnt get into it..

You might also want to have a look to the 

You might also want to have a look to the midiselect object which appeared in Max 5.1.


But Emmanuel, don't you think it's time to get this old 

Interesting!
But Emmanuel, don't you think it's time to get this old ctlin bug corrected?

[midiparse.help] should point to [midiselect] as an alternative

It'll be in the next incremental. Thanks.

Thanks a bunch, now I have to find the old versions of my ctl.in to redo them the old way...;-)

Wow after so many years finally...
Thanks a bunch, now I have to find the old versions of my ctl.in to redo them the old way...;-)


I didn't see anything related to this in the latests support information page, but this good old 

I didn't see anything related to this in the latests support information page, but this good old ctlin seems to work correctly now. Thanks.

I have the same problem, but with nanokontrol and Modul8 ( 

"My temporary workaround was running a pd patch with a midiin -> midiout to route the nano into the internal Max midi device".

Could you please describe in detail which code or functions did you use?

Also, maybe anybody else could help me with my question?

I have the same problem, but with nanokontrol and Modul8 ( http://www.modul8.ch )
Tim, you wrote:
"My temporary workaround was running a pd patch with a midiin -> midiout to route the nano into the internal Max midi device".

Could you please describe in detail which code or functions did you use?
So that I will do it for Modul8.
(I haven't use pd before.)

Should also work in Max, even before the ctlin problem of skipping events, midiin was working just fine, simply connect [midiin]->[midiout]. But you have to set the ports of midiin, unlike ctlin, it will listen only to one port per default...

I found that Lewis' "lk.ctlin" object worked very well for a small number of controllers, but once I made an interface for every controller on the nanoKONTROL's first scene (a total of 32 controllers) the object became very laggy. I also had this problem when I ran stoplaughing's first interface patch.

This lag problem was completely remedied by the regular ctlin in the 5.1 update (I was running 5.0.8 beforehand).

I can post my interface when it's finished, if anyone would like it.

This lag problem was completely remedied by the regular ctlin in the 5.1 update (I was running 5.0.8 beforehand). 

I need to resurrect this thread. The title could still be the same, but the situation is slightly different from what was described in the original post.

Regardless of which object to use, ctlin or midiin, nanoKontrol2 works fine in Max 5, but not Max 6. Also, the problem does not occur unless dac is on.

I just got nanoKontrol2 and am trying to use it in Max 6.08. Opening a patch (such that attached to this message), the device can be found no problem, and it works just fine in the first few minutes. But after a while (varied from immediate to several minutes), as eddiebreitweiser mentioned two years ago, it becomes very laggy.

Precisely to say, it works in the way that there is an invisible speedlim object created after midiparse -- the value reaches the destination but skipping lots. Interestingly, I can observe no value is skipped in what is printed in Max window, but the skipped values are not obtainable in the patch.

As the supplemental info, the problem occurs:

2. some minutes (1~5 mins?) after dac is on

My system is OS 10.8.2, Max 6.0.8, MacBook Pro Retina.

If you have nanoKontrol2 and using Max 6, please find the attached patch and test yours. If you possibly know a workaround, please let me know. Thank you.

I just got nanoKontrol2 and am trying to use it in Max 6.08. Opening a patch (such that attached to this message), the device can be found no problem, and it works just fine in the first few minutes. But after a while (varied from immediate to several minutes), as eddiebreitweiser mentioned two years ago, it becomes very laggy. 

1. only when dac is on
2. some minutes (1~5 mins?) after dac is on
3. also in the latest Max 6.1.1

I'm having this problem now also. Sorry to give this thread yet another bump. If I turn audio interrupt off it works fine, but my patch needs audio interrupt on for timing purposes.

Works well for some minutes then goes choppy...

Toggling audio interrupt temporarily fixes the problem. Controller works fine in Logic and Live

I’m having this problem now also. Sorry to give this thread yet another bump. If I turn audio interrupt off it works fine, but my patch needs audio interrupt on for timing purposes.

Works well for some minutes then goes choppy…

We had that exact same problem... but with an Akai LPD8.

Korg nanoKontrol dropping MIDI messages in Max, OS X