Forum rss-feed


Developers: MIDI key illuminator

Most Recent

written by: NothanUmber

Ok, here a Windows version of the MIDI Illuminator agent for EigenD 1.4.12. Please have a look at the contained Readme.
If it doesn't work just come back to me and I can have a look.
(As far as I can remember, there were problems with very big setups - like the Alpha3 setup. Because the way layouts are handled is more on the memory intensive "brute force" side. Here it might help to experiment with the "light" versions (also included - but not fully tested if I remember right), that use less memory - but also offer fewer features.)

Also added the complete sources in the state I left it. (Not prettiest possible, this was mainly for learning how things work. Wanted to clean it up but never did... - but it should work.)
P.S.: Forgot to add the Stage tabs. If the folder should be empty - please redownload

written by: NothanUmber

Sun, 4 Dec 2011 15:37:27 +0000 GMT

Well, if it's just the "direct key" feature (enabling and disabling individual LEDs via OSC) - that should already work without problems for some time now.
So here the link to the version from last week (only contains the Mac binaries as the people testing it only are on Mac).
Instructions are included - not for the OSC part though.
But it's easy:
Connect to port 55551 and use the following OSC path:
path: /alpha_midi_light_controller_1/keys/key_1 to key_120 (for Alpha)
Then use
0: no color
1: green
2: red
3: orange

Just tell me if setting things up with the included instructions does not work, perhaps I can help.

written by: barnone

Sun, 4 Dec 2011 16:24:03 +0000 GMT

I seem to remember that the control for each led must be placed on a stage tab for it to respond to OSC. Is that not correct?

written by: NothanUmber

Sun, 4 Dec 2011 16:38:33 +0000 GMT

Yes, you have to load the Stage tabs that are provided as part of the package and load them into your Stage setup (it's described in the readme.txt)

written by: dhjdhj

Sun, 4 Dec 2011 16:43:29 +0000 GMT

Hmmm, I"m not using a stage setup, at least I'm not running the Stage app at all --- I'm just trying to use the raw bottom-level setup with as little loaded as possible. In fact my next question was going to be about how to load EigenD programatically (well, I know that part) but with the scan for new VSTs disabled.

So am I out of luck if I just want to turn on/off the lights without manual intervention at startup time?

written by: NothanUmber

Sun, 4 Dec 2011 17:41:00 +0000 GMT

Did a short test. The OSC functionality is part of the EigenD-side Stage functionality and not a feature of the GUI (the GUI application is actually communicating with EigenD via OSC). So only controls that you load into Stage tabs can be automated. After you did the initial set up inside Stage you can save your setup and don't need to start Stage anymore afterwards - the controls are now instantiated inside EigenD and can be controlled via OSC, even if the Stage GUI application is not running.
So you can define the setup with midi illuminator and the accompanying Stage tabs loaded as default setup. Then all you have to do is to launch EigenD without parameters and Max with a shell script (or presumably there will also be a Max object to start applications? You are the Max expert.. :) ).

written by: dhjdhj

Fri, 9 Dec 2011 22:03:32 +0000 GMT

I have a question about response time for controlling the LEDs. Thank's to all the help, I now have complete control of the LEDs on the Alpha from Max. I was doing some tests where I arranged for each row to flash in sequence, once per second. I noticed that while most of the time, the entire row would light up essentially instantly (obviously, I'm sending 5 OSC messages) but I noticed that occasionally, there was some "hesitation" meaning that I could see the first two LEDs in a row turn on before the other three....very brief but noticeable.

I haven't had time to do too many tests but I'm trying to understand from where the delay is coming. One test I did perform was to have Max send the UDP packets to a monitoring program that timestamped incoming messages and the delta times between the packets were negligible, for all practical purposes, the 5 packets were arriving at network speeds.

I'm wondering whether this is a problem with event scheduling.

written by: NothanUmber

Fri, 9 Dec 2011 22:44:53 +0000 GMT

Haven't done measurements or even profiling into this direction. All the modification of atoms via Stage/OSC currently have to pass the non-realtime Python side of EigenD (e.g. the setters for the atoms are written in Python), so as soon as the realtime threads get something to do (e.g. playing audio) the rest is on a back burner and can in the worst case even become noticeably delayed. Perhaps there is an additional worst case latency introduced inside the midi illuminator though, would have to investigate.

written by: dhjdhj

Fri, 9 Dec 2011 22:53:37 +0000 GMT

My experiments were done with the Eigenharp sitting in its stand, it was not being played.

I'm not really that concerned about this, but wanted to mention it. I had thought about creating a marquee object through which one could actually have the Alpha display text in a moving ticker format....would be cool to have our band name displayed on it when it's sitting on stage but not being used.

My main goal was to be able to illuminate certain rows representing 5 7 9 12 (when I'm using guitar tuning) and other rows when I have splits. It works perfectly fine for that purpose.

written by: john

Sat, 10 Dec 2011 09:51:45 +0000 GMT


The lights are turned on and off in the 'slow thread' of execution. This has a whole load of non-critical things run in it, some of which are housekeeping jobs that have to happen but are not critical as to performance, and it's scheduling is as a result much more non-deterministic than the real-time thread.

The reason that the lighting is run in that thread is to save real-time, critical CPU for the routing and processing of performance data and the generation of audio. Lumpy processing (like turning a lot of lights on and off via OSC) would otherwise be able to cause glitching, so in order to maximise polyphony we allow lights to be de-prioritised which means running them in the same priority as a load of other non-critical stuff. This does mean that you will occasionally see small (but as you point our noticeable) delays in lights changing - this is the price we pay for not having them affect polypohony whilst we actually are playing. That real time CPU thread is a very precious resource and gets used up even on modern CPU's amazingly quickly, the more we can have running out of it the better, hence this particular design decision.


written by: dhjdhj

Sat, 10 Dec 2011 13:34:47 +0000 GMT

Not a problem, I just wanted to understand what I was seeing.

written by: dhjdhj

Sat, 10 Dec 2011 13:34:48 +0000 GMT

Not a problem, I just wanted to understand what I was seeing.

written by: dhjdhj

Mon, 12 Dec 2011 02:51:34 +0000 GMT

Now that I understand what I'm seeing, there may be a bug here. Basically, after creating some fundamental objects to switch arbitrary LEDs to any of their states, I then created an object that worked with rows at a time. So, for example, I have a command to turn off all LEDs and then I can turn on all LEDs of row 3 (say) to green and then row 5 to red.

I have discovered that occasionally, after executing one of these sequences, my alpha does not always end up in the expected state. Most times it does, but occasionally, one or two of the LEDs that were supposed to turn on, didn't.

I don't know whether UDP packets are being dropped because (perhaps) they're arriving too fast to be processed or whether there's something else going on but thought it would be worth mentioning.

I did however force Max to slow down the transmission of each packet and then the LEDs always (well, so far) responded as expected.

No keys were being pressed during these experiments.

written by: NothanUmber

Mon, 12 Dec 2011 09:37:38 +0000 GMT

That sounds strange. (Have a new version of the midiilluminator with a few additional bugs fixed. But those shouldn't affect the effect you describe.)
Could you please try to log the EigenD-side OSC messages so we see whether the packages arrive on the EigenD side?

written by: john

Mon, 12 Dec 2011 11:48:46 +0000 GMT

You may find that the OS is throwing away the packets itself - the UDP stack is prone to do this with high volumes, regardless of the destination's ability to process them. We used to ship a lot more communication directly through the UDP layer inside EigenD but found packet loss in the OS to be enough of a problem that we had to change that, UDP is really not that reliable as the data rates rise.

The easy way to see if this is the case is to log the EigenD side and see if the packets ever arrive there, as NothanUmber suggests.


written by: dhjdhj

Mon, 12 Dec 2011 12:33:59 +0000 GMT

Yes, I did suggest that UDP packets might be getting dropped. However it's hard to believe packets are getting lost out of a total of 150 UDP packets (which is about what I'm sending out) when they are just being sent to another process on the same machine. I don't know how big a stack is available. I also don't know how much time is getting lost dealing with memory allocation (if any) for incoming strings and with parsing. Are incoming packets pulled off the UDP stack as they come in and just stored by EigenD for processing with a different thread? I would think that would help minimize any losses.

It might be worth considering using shorter "words" in the OSC messages.

For example, instead of

I'll take a look in the logs and see what I can find.

Appreciate the feedback. I'm now awaiting my third basestation so that I can do development while leaving two other basestations permanently built in to my live rigs.

written by: fcolasanto

Wed, 15 Feb 2012 06:10:08 +0000 GMT

Hi there,

I need some advice. I use Max to control my TAU. From there I can change scales, octaves, etc. I created a light arrangment to show a chromatic scale (green ligth correspond to white keys of piano and red lights are black keys of piano). The problem is that when I use a different scale (for example whole tone) the lights do not correspond with the pitches. So this "direct key" feature to illuminate and change color of light via OSC could be very handy for me. I tried to install NothanUmber system on 1.4.11 stable...but was unsuccessful. This key illuminator has to work in this version too ?
Its possible to add this agents in the 2.x versions ? ...I'm a little lost here....:-) Somebody could help me to solve this ?

Thanks a lot


written by: NothanUmber

Wed, 15 Feb 2012 14:39:31 +0000 GMT

Hi, should definitely work with 1.4.11 - I'll double check when back home.
Theoretically it should also work with EigenD 2 (not tested yet though). At some point I want to build an optimized version vor EigenD 2 that directly uses the scaler and kgroups (so you don't have to define a separate layout).
Perhaps it makes sense to extract the direct keys functionality into a simpler, separate agent for the Max users.

written by: fcolasanto

Wed, 15 Feb 2012 17:33:52 +0000 GMT

Dear NothanUmber,

So I copied libmidiilluminator_plg_1_4_8_testing.dylib into /usr/pi/release-1.4.11-stable/bin

Then I copied and plg_midiilluminator folder into modules folder

Then alpha_midi_light_controller, pico_midi_light_controller and tau_midi_light_controller into plugins folder

Then midi_illuminator folder into Library/Eigenlabs folder and, just in case, in /Library/Eigenlabs/1.4.11-stable folder

Then opened EigenD and Stage and Commander. When I entered "tau manager create" I have an error: Inappropriate arguments for the verb create ...

So what I'm doing wrong ?
Thanks a lot for your patience



written by: NothanUmber

Wed, 15 Feb 2012 18:24:56 +0000 GMT

"tau manager create" sounds strange..

please try (from memory, still at work... - assuming that you start with an empty setup, otherwise the first steps are not necessary):
alpha manager create (also used for tau)
tau midi light controller create
tau midi light controller 1 to tau keyboard 1 connect

That should be sufficient if you just want to use the direct keys functionality.


written by: fcolasanto

Wed, 15 Feb 2012 22:02:38 +0000 GMT

Dear Ferdinand , when I enter "tau midi light controller create" I have an error : tau midi light controller create failed. What else I could try ?

Thanks a lot


Please log in to join the discussions