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.@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,
Geert
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)
Thanks,
NothanUmber
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.
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.
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.
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.
Very cool! Will be looking at this over the weekend.
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.
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.
/alpha midi light controller 1/notes/49: c4 = 2
sets all keys that are associated to the note c4 orange etc.
/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
/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
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
The macro DEFINE_FASTCALL_PROPERTY_MAP
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/utils.py", line 51, in __call__
eigend-backend: return types.MethodType(self.im_func,o,self.im_class)(*args,**kwds)
eigend-backend: File "pisession/agentd.py", line 620, in __asserted
eigend-backend: return self.__agent.load_agent(factory,address,ordinal)
eigend-backend: File "pisession/agentd.py", line 746, in load_agent
eigend-backend: agent = AgentLoader(factory.module)
eigend-backend: File "pisession/agentd.py", line 518, in __init__
eigend-backend: self.module = __import__(module,fromlist=['main','unload','isgui'])
eigend-backend: File "plg_midiilluminator/midi_alpha_illuminator_plg.py", 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
Ok, found the startup issue.
line 22 midi_alpha_illuminator_plg.py
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,
http://help.github.com/fork-a-repo/
Got to admit I am a totaly noob with git so it's not always obvious to me how to do this, but learning.
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 ;)
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.
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
Yes!!! it does
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.
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.)
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.
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
http://help.github.com/fork-a-repo/
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
http://help.github.com/send-pull-requests/
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.
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
UK
