Forum

Not a problem for me...I have everything working very well just using my original setup. However, it wasn't clear to me that the problem getting a blank setup to work was related to the OSC or to a more fundamental issue where some other underlying stuff wasn't getting initialized. I figured that might be of interest to someone else.

In the mean time, I already have simple (from a usability perspective) max objects implemented that let me do splits, layering, multitimbral control, with different scales.....really enjoying being up and running again.

I just bought a second base station and I'll probably get a pico soon as well....I'm a happy camper now -:)

"@dhjdhj you might want to try starting with a really blank slate when loading the blank setup instead of loading your Guitar OSC setup beforehand. "

Yes, this is why I'm starting EigenD using --noauto switch. But if I start with release version, I make sure I load the "Factory - Blank" setup on launch.

@dhjdhj You should try doing this to resolve your issue.

I was under the impression that if I hold two (say) keys down, and then apply vibrato to both of them, the Eigenharp will send continuous events reflecting this.

I noted that when I did this, events would be sent for the second note pressed, but no longer for the first. I assumed this was a bug in my Max code but tracing backwards and printing the raw data coming in via udp packets, it would appear that indeed only events for the most recent key held down are being sent.

I'm wondering if this is a bug in OSC, an underlying behavior of the Eigenharp (which would surprise me), or whether in fact it really is something bizarrely wrong with my own code that I can't yet see.

Thanks.....I'll try testing with your example patch as well.

I would like to thank Chris, Geert and Ferdinand (no particular order!) for their help and patience and responding to my questions while I tried to get Max/EigenD integration working properly. I did also figure out and solve the problem I was having with continuous events.

As of now, I have a basic (but elegant by my own definition!) model running that integrates cleanly to the rest of my environment.


The goal is that a workable patcher can be created very quickly using a few abstractions.

For anyone interested, take a look at this picture
http://i.imgur.com/bUnOw.jpg


There are two "keygroups" (I'll probably change the name to "split" soon) defined, one for row 1 to 8 and another for row 10 to 20. The output from keygroups consist of the Row/Col of the key pressed (always normalized to zero by the way) along with note on/off and X, Y, Z parameters)

Each keygroup feeds into an [Eigen.Scale.Guitar] object which imposes guitar-string tuning (top 5 strings). The arguments are the starting note number and the MIDI channel to be used. If you wanted each key to generate two notes a fifth apart (say) you could just use two [Eigen.Scale.Guitar] objects with different starting note numbers. Clearly, creating other scales can be done by replacing [Eigen.Scale.Guitar] with something else. An obvious enhancment would be to allow just the "highest" note in each column to play, thereby supporting bar chords.

These then can feed into an external MIDI instrument or into a VST using my [GenericVST] object which is a useful helper object to hide some of the more bizarre control requirements.

Essentially, once the Max backend stuff is running, one can create really simple patchers to get useful results very quickly.

Using this technique, I have already been able to duplicate my "Lament" performance which uses a few keys in one group to trigger chords in a sequence and then another group to play the melody.
http://i.imgur.com/Riifx.jpg

I haven't had much time (probably two full days worth spread over two weeks) but I'm very encouraged. I still haven't figured out how best to detect initial velocity and those experiments will start as soon as I have more time, but to paraphrase the possibly apocryphal comment by Galileo at his trial... "damn it, it works"

Thanks, again.
David

Thanks --- I continue to improve it a little as I have time --- now able to easily select just small areas of the keyboard (e.g, rows 1 through 3 but only column 4 and 5) and pass that into a VST or trigger, etc.
One of my partners who has a Pico is getting interested to see how this stuff could be easily integrated into M4L as it seems this would become a trivial way to use a pico to trigger clips and then play solos.

I'm wondering whether it will be possible to detect strips at some point?

Geert heard you, since three hours ago the answer seems to be: yes :)
https://github.com/Eigenlabs/EigenD/commit/47a1ff7a9aee4a4f4da3f980195d3d6bfd7ab5ca (this is in the EigenD 2 branch)

Hi David

If you wait 'till next week, it'll be in the new 2.0 release due out then.

John

Hello, Im back with my Eigenharp Pico after a lengthy absence. Very pleased to see that most of the things I complained about in the early days have been sorted.

Anyway I purchased a 6-month Pro package yesterday, can you tell me whether the OSC stuff made it into workbench yet, as thats my main reason for trying 2.0. I am just starting to learn workbench now, and I see an OSC agent listed, but Im not sure if its supposed to work since you mention a newer software release that I don't think has happened yet?

No, it changed, based on the new keystream data that we're fine-tuning. Note that the OSC Output agent and EigenD 2 are still experimental, we could still be making backwards incompatible changes. Things will only freeze as we enter testing phase.

Take care,

Geert