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: geert

Thu, 27 Oct 2011 08:43:21 +0100 BST

@NothanNumber You're facing a peculiarity of Belcanto here. Before being to use any word in the language, it has to be part of the lexicon and moved to a note sequence so that it can be played on the instrument. The noun 'matrix' isn't part of the lexicon. You can find the lexicon in pibelcanto/lexicon.txt.

Take care,


written by: NothanUmber

Thu, 27 Oct 2011 21:23:13 +0100 BST

Thanks, should have though of that...

Ok, midi events are coming in now and seem to be interpreted correctly on the midiilluminator side (note on+off are processed the rest is ignored).

Now what I am wondering: If I save a setup then all the atom values are persisted, right? My understanding was that when I load my setup again all the stored values are
a) loaded into the atoms again
b) the registered callback functions get called so my C++ representation gets updated accordingly.

a) seems to happen, but nobody calls my setters, so the C++ state variables have their default values as set by the constructor and thus are out of sync to the atoms. The setters are called as expected as soon as I change the value e.g. via Stage/Belcanto.
So what is the expected way to handle this, do I directly have to access the atoms in the server? (E.g. the latch agent also doesn't seem to take special care for syncing so I expected everything works via the callbacks)


written by: NothanUmber

Thu, 27 Oct 2011 21:33:14 +0100 BST

I think I understood what's going on: The values are only stored in the setup when they differ from the default values. In this case the callbacks are called when the setup is loaded.
So I have to make sure that the default values on the Python side and the C++ side match because those are not explicitly transferred.

written by: barnone

Sat, 29 Oct 2011 04:15:47 +0100 BST

Are you working in a private branch? Care to make that a remote private branch that I can look at, or join?

I just re-read the thread and hard to follow without looking at code. If not, I have no problem waiting till it is at a good state.

I need to do the same as I get into the code. Haven't had to modify the osc agent yet. Things are fairly smooth, however there is a MAX bug with empty strings in messages. I filed a bug, but got the email saying, don't use empty strings in messages ;)

[edit] Actually, I've got plenty on my plate right now just digging into the osc agent and the stuff geert added, plus still sifting through everything. So, no rush. Impressed with your progress.

written by: NothanUmber

Sat, 29 Oct 2011 12:36:32 +0100 BST

Am currently working on a private branch - on my local hard drive (and store backup zips to a server from time to time.)
Currently there are a few things I still want to change when I am home again. E.g. atm. I use vanilla STL containers instead of the specific EigenD variants that can't be paged out, I want to find a solution for immediately taking over parameter changes (currently only happens when new midi notes arrive), want to add a file import/export so configurations can be taken over between setups etc.
Hope to have a first test version for which I'll share the code by the end of next week.

written by: NothanUmber

Sat, 5 Nov 2011 01:33:54 +0000 GMT

Fixed some bugs, import/export didn't make it yet. Also still want to refactor some things, add comments etc next week.
Here the current sources for those who are curious about how this works in principle, want to give me some hints etc. (Just fixed another bug a few minutes ago so rest asured there will still be enough bugs left to eat your breakfast if you let them ;) )
People who want to actually use this should better wait some more days.

written by: barnone

Sat, 5 Nov 2011 01:47:20 +0000 GMT

Very cool! Will be looking at this over the weekend.

written by: barnone

Sat, 12 Nov 2011 02:09:21 +0000 GMT

Been trying to dig in a bit. This week has been a bit punishing at work and it's hard to keep looking at source code after the end of a long day. I look forward to the developers conference. I hope I can have a decent grasp by then. Thanks for the code, it helps a lot.

I understand what you are doing here and really good job getting the pieces together.

I think for the use case of this agent, midi in makes the most sense as you are lighting notes specifically, and OSC does not add value in this context.

For my purposes I would like to explore an osc input agent that is the counterpoint to the osc output agent.

It would speak osc to light keys in a keygroup and would have no note semantics. This would be very similar to monome protocol philosphy and would enable arbitrary use of available canvas in a key group by external apps for example.

Already the osc output agent has the proper semantics of keys without note interpretation. I would like to hook it to a keygroup rather than the entire keyboard, so a slot in a keygroup could have an arbitrary sized canvas that would send osc for key raw data and receive osc to draw the canvas.

Seems like a worthy goal for learning the framework.

written by: NothanUmber

Sat, 12 Nov 2011 10:46:05 +0000 GMT

Having a separate OSC input agent would be worthwile for sure!
In the mean time it could also be a good start to explore the OSC features of Stage. I never tried it but if you load the "direct keys" Stage tab of the midi illuminator it should be possible to directly set the keys via OSC:

/alpha midi light controller 1/keys/key 1 = 1
sets the first key green etc.

Or you could use the direct notes feature via OSC that uses the note to key mapping via layouts:

/alpha midi light controller 1/notes/49: c4 = 2
sets all keys that are associated to the note c4 orange etc.

Make sure that direct notes and direct keys are enabled for the colors you want to set:

/alpha midi light controller 1/green lights/enable direct keys = 1
/alpha midi light controller 1/orange lights/enable direct keys = 1
/alpha midi light controller 1/red lights/enable direct keys = 1
/alpha midi light controller 1/green lights/enable direct notes = 1
/alpha midi light controller 1/orange lights/enable direct notes = 1
/alpha midi light controller 1/red lights/enable direct notes = 1

Then you can decide whether direct notes, direct keys (or midi) should "win" if both approaches try to illuminate the same key:

/alpha midi light controller 1/priorities/direct keys prio = 1
/alpha midi light controller 1/priorities/direct notes prio = 2
/alpha midi light controller 1/priorities/midi prio = 3

would change the priorites from the default midi > direct notes > direct keys to
direct keys > direct notes > midi (prio 1 is the highest priority)

Also took a few days off from "home coding", wanted to know how the novel I was reading ends ;)
Will have a look at file export/import today though.

written by: barnone

Sat, 12 Nov 2011 22:25:45 +0000 GMT

Was trying to build this today given the source that was zipped earlier in the thread.

Ran into some issues.

typedef key_t

This typedef conflicts with a system library typedef in 10.4u SDK. 10.5 doesn't have the issue but I renamed it instead to keys_t

Seemed to have an error in it which I needed to fix. Diff the files.

Reordered some definitions to fix some compiler warnings.

Now everything compiles and I can start eigenD but I can't instantiate the agent and wire it up.

Here's the console log after executing

alpha midi light controller create

: after flush, state= [abstract([alpha,midi,light,controller])]
: verb: create ['(abstract([alpha,midi,light,controller]),)']
: run imperative: ('alpha', 'midi', 'light', 'controller', 'create')
eigend-backend: verb: ['336214296',2,'',[abstract([alpha_midi_light_controller])]]
eigend-backend: assigned ordinal 1 to alpha_midi_light_controller
eigend-backend: start traceback:
eigend-backend: Traceback (most recent call last):
eigend-backend: File "pi/", line 51, in __call__
eigend-backend: return types.MethodType(self.im_func,o,self.im_class)(*args,**kwds)
eigend-backend: File "pisession/", line 620, in __asserted
eigend-backend: return self.__agent.load_agent(factory,address,ordinal)
eigend-backend: File "pisession/", line 746, in load_agent
eigend-backend: agent = AgentLoader(factory.module)
eigend-backend: File "pisession/", line 518, in __init__
eigend-backend: self.module = __import__(module,fromlist=['main','unload','isgui'])
eigend-backend: File "plg_midiilluminator/", line 22, in
eigend-backend: from plg_midiilluminator import alpha_midi_light_controller as version
eigend-backend: ImportError: cannot import name alpha_midi_light_controller
eigend-backend: end traceback:
: eigend 1: ok
: after verb, succeeded= 1 errors= 0 sync= [''] obj= set([''])
: pushing set(['']) to context stack
: starting sync after create : ['']
log:average tick 11610

On another note: How do you get stage to open at all when running a custom build of EigenD? The Tools->Stage link in EigenD does nothing for me.

Here's a link to the modified source

Modified src

written by: barnone

Sat, 12 Nov 2011 22:16:37 +0000 GMT

Ok, found the startup issue.

line 22
from plg_midiilluminator import alpha_midi_light_controller as version

Needs to be

from plg_midiilluminator import alpha_midi_light_controller_version as version

Same problem with pico version.

Now the agent starts

However I can't connect the keyboard to the illuminator

[Chaos-3:Projects/EigenD/tmp] chrislloyd% ./bin/brpc '' exec alpha midi light controller create

[Chaos-3:Projects/EigenD/tmp] chrislloyd% ./bin/brpc '' exec midi input create

[Chaos-3:Projects/EigenD/tmp] chrislloyd% ./bin/brpc '' exec alpha manager create

[Chaos-3:Projects/EigenD/tmp] chrislloyd% ./bin/brpc '' exec plumber hey alpha keyboard 1 light input to alpha midi light controller 1 light output connect

Plumber says "Incompatible" trying to make the connection.

BTW, reuploaded the src zip file linked last post with python fixes.

If we want to keep fixing, should get this on github instead. What I did was fork the repo following these instructions,

Got to admit I am a totaly noob with git so it's not always obvious to me how to do this, but learning.

written by: NothanUmber

Sat, 12 Nov 2011 22:21:58 +0000 GMT

Hi barnone,
clicking on the "Modified Src" link above gives me a "no such file" error.
Did not try to compile with MacOS yet (was working with VS 2008 compiler+Eclipse).

Will have to try that with the Mac Book...

Regarding Stage: Just copy Stage.exe and Stage_con.exe from the 1.4.8 release to your bin directory ;)

written by: barnone

Sat, 12 Nov 2011 22:24:17 +0000 GMT

Ok, fixed the link.

Ahhh, you are on Windows, hence why you don't have a conflict with that typedef in the OS X libraries.

We probably want to stay away from global definitions and macros in general though I would think.

.exe? what's that? haha, ok, makes sense.

written by: NothanUmber

Sat, 12 Nov 2011 22:33:02 +0000 GMT

Argh, sorry about the _version thing - did a name change at some point and did the adaption for pico and alpha incorrectly (only tested things with tau...)

does this work for you?

alpha midi light controller create
midi input create
alpha manager create
plumber hey midi input 1 to alpha midi light controller 1 connect
plumber hey alpha midi light controller 1 to alpha keyboard 1 connect

(the light inputs/outputs are autoconnect)

written by: barnone

Sat, 12 Nov 2011 22:42:00 +0000 GMT

Yes!!! it does

written by: barnone

Sat, 12 Nov 2011 23:10:46 +0000 GMT

OK, so I can connect stage and drop controls from Midi Key Illuminator.

What's the fastest way to test whether it lights up? I dropped some key controls onto the stage page and tried setting values, then enabling direct keys for the different colors but I don't get any lights.

On another note, do you know what port I send the OSC to? Stage displays the host but wasn't sure what port EigenD is listening on.

written by: NothanUmber

Sat, 12 Nov 2011 23:15:29 +0000 GMT

ok, merged in you changes in my version, still compiled on Win.

Am also not a git expert (we work with ClearCase and (MacOS fans will cry) TFS ;) )
I hoped not to have to maintain an actual fork of EigenD on github already from the beginning (in one part because I fear the work to keep that up to date with the Eigenlabs EigenD branch - especially if Eigenlabs won't take over many changes from this version, so it differs more and more over time. And also because one version maintained by one group (Eigenlabs) would help to keep things focused, several EigenD version with several incompatible subsets of features would be very unconvenient for users).

So my suggestion: as long as it's just you and me just send me any changes you did and I'll merge them into my version and release sources as zip files from time to time. And if it's considered stable and tested we can try to get it on the official EigenD open source branch. (I still do not know which policies Eigenlabs will have what they consider interesting to add, what they think competes with things they want to sell etc. - so perhaps at some point a user controlled fork might be neccessary - but imho that should be a last resort not the starting point.)

written by: NothanUmber

Sat, 12 Nov 2011 23:27:24 +0000 GMT

Hm, normally you should get lights... But you are the first person to test this on an Alpha, so perhaps some of my assumptions are wrong...

The easiest test is perhaps with the direct keys as for that the layout mapping is not necessary. (Can you set a breakpoint in send_led_matrix - do you ever reach this function? If not then something is wrong within the midi illuminator. If yes then perhaps my assumption of which data has to be fed to the alpha keyboard light input is wrong).

Do you also have a Pico? Will do a short test with the Pico on my side (I'll write when I did them), if that works for me and not for you perhaps this will help to find problems..

P.S.: Regarding OSC: sorry, no clue, never tried OSC with Stage. Just thought it *should* be possible from the Eigenlabs description...

P.P.S.: Another test, perhaps have a look whether autoconnect connected the right inputs/outputs with the brpc dump feature.

written by: barnone

Sat, 12 Nov 2011 23:36:39 +0000 GMT

The git version of a fork is very different than what we are used to I think.

When you fork you get a cloned repo in your local github account. This repo has both a local and github hosted remote end in your account.

This forked repo is also linked to the master version on eigenD account, so it's basically like having a local branch and you can easily pull down all the most recent changes from the eigenlabs master account.

When you have something to submit, you can create a pull request to Eigenlabs. They will see a diff of the forked repo and theirs and be able to pull the chnages back into the master.

So it's actually the best way to do custom work and get it cleanly integrated back. However, it's not super intuitive at first.

After doing these instructions

Now I can just go

git fetch upstream ("Pull all changes from eigenlabs to my fork")
git merge upstream/master ("merge changes into my remote master branch")
git merge upstream/1.4 ("merge changes into my 1.4 remote branch")

To create local branches in my fork that match the eigenlabs ones and track changes in my remote account.

git checkout --track -b 1.4 origin/1.4
git checkout --track -b master origin/master

Switch between local branches in case I want to work on master or 1.4 branch
git checkout 1.4
git checkout master

To push a feature back to eigenlabs you do this

But I'm cool with exchanging files for now. I'm trying to figure out this git stuff for myself because I am working on another git hosted project as well.

And actually if anyone reads this and sees that I'm doing it all wrong, please correct me. I'm fumbling around for the easiest way still.

written by: NothanUmber

Sat, 12 Nov 2011 23:43:11 +0000 GMT

Ah, ok, should have read the linked site first without making assumptions...

Pico seems to work on first sight on Windows (direct keys, direct notes, midi), going to Mac OS now...

Please log in to join the discussions