Forum

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.

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)

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.. :) ).

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.

David

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.

John

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

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?

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
/alpha_midi_light_controller_1/keys/key_1
use
/amlc1/k/1


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.

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.

"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.

Best,
Ferdinand