Forum rss-feed

Forum

Software: Low level driver --- to be used directly with tools like Max/MSP

Most Recent

written by: dhjdhj

Interesting --- I'll take a look, but I really don't need to build the EigenD environment. I'm not interested in modifying EigenD, I'm interested in replacing it

(grin).

Anyhow, John has been very patient to allow these conversations on their forum. I don't think we're going to get anywhere with this debate, the environment is what it is.

By the way, I'm still on Snow Leopard until I can verify that all my plugins work on Lion.

written by: dhjdhj

Sat, 1 Oct 2011 14:09:51 +0100 BST

How big a deal would it be to create a low-level driver for the Eigenharp that just produces the appropriate data when one touches a key? In other words, eliminate the entire EigenD scafolding, agents, belcanto, virtual instruments, etc, and just have a simple way to know that key X was touched or moved, or the ribbon was touched, etc

That way, one could build arbitrary applications with languages like MaxMSP that are not in any way constrained by the current direction from Eigenlabs and would allow far more general exploration of the eigenharp as a powerful controller?

I would love to be able to communicate directly with the eigenharp hardware from Max --- I think it would open the door to all sorts of possibilities.


written by: john

Sat, 1 Oct 2011 15:07:23 +0100 BST

Hi David

Depending on what you want to do, its probably not that hard if you start with the EigenD source - we've done most of the hard work there and the open source release contains all the USB drivers and everything you need. The only thing stopping you is the coding and then the looking after it subsequently (which is a pain as it has USB drivers, which operating system vendors seem to mess with fairly frequently. I know you're a coder - you can check out the whole system from github, there's a Wiki page with all the details here. This is something I know you'd like to have, you should go for it (provided you're happy working within the GPLv3 of course). The demand for it is too limited for us to get involved, but if you have go we'll try our best to answer any questions you might have as you go as and when we have the time.

John

BTW, we're kind of headed slowly in that direction anyway as we plan to make our network protocol OSC in the future, which I believe that MAX can understand. This isn't going to happen before next year though at the earliest - our first step was the Stage interface but the broader system requires some scary (and hence requiring a lot of testing) low level changes. The other thing you could do is just send all the keys out as high rate MIDI - the new routing matrix makes this quite possible. You can then play with it in MAX to your hearts content.


written by: dhjdhj

Sat, 1 Oct 2011 16:33:47 +0100 BST

I can imagine building a Max patcher that looks something like the following (which I just put together as a simple and incomplete storyboard) but it would enable a lot to be done quite easily.

Conceptual Max/MSP patcher

I wonder how many other people would be interested in such a thing?


written by: natcl

Sun, 2 Oct 2011 20:45:02 +0100 BST

I would definately be interested in such a tool !


written by: tefman3d

Mon, 3 Oct 2011 02:01:30 +0100 BST

Me too!

tefman3d


written by: dhjdhj

Mon, 3 Oct 2011 13:05:23 +0100 BST

Would it be possible to get a test program (with source code and a build script) that just shows/exercises the communication/data stream? I would really like not to have to wade through the entire source code tree to figure this out, particularly since EigenD itself will not need to be a part of such a tool.


written by: dhjdhj

Mon, 3 Oct 2011 14:17:24 +0100 BST

Well, just for grins, I downloaded the entire source from git and, following the instructions in the README, I just typed 'make' on my mac

I instantly got the following errors:

scons: Reading SConscript files ...
sh: /usr/pi/bin/python: No such file or directory

followed (of course) by lots of errors due to this one.

It would appear that the partial directory '/pi/' is hard-coded in the darwin_tools.py script

Can't see how anyone could have built this system from "open source" by just typing 'make'.

Much as I'd be willing to invest my own time in developing a standalone SDK to the drivers so as to be able to build a Max External, this is NOT a good start.

I have to agree with the comment at the top of darwin_tools.py

# This is all completely barking mad



Sigh


written by: geert

Mon, 3 Oct 2011 15:02:11 +0100 BST

From the README:

You will need to have the stock EigenD installed to get the
runtime support (which is a vanilla Python install) and the
Windows device drivers.

Similar remarks for the Steinberg SDK.

Several people are compiling it from source and running it like that.


written by: dhjdhj

Mon, 3 Oct 2011 15:11:27 +0100 BST

1) Why do I need runtime support when I'm still just trying to build the code
2) Why do I need Windows device drivers when I'm on a Macintosh

I already have multiple versions (2.x, 3.x) of Python installed on my Mac, in the standard places.

I know about the Steinberg SDK and had already signed their agreement to get access to those files, but I'm a long way from that....

I manually edited the darwin_tool.py and got past that error and was then confronted with a hardcoded reference to a particular version of gcc which I don't have (and don't want) as it's way too old. I don't understand why the code would not just invoke 'gcc' which is symbolically linked to the appropriate version.


written by: geert

Mon, 3 Oct 2011 16:13:16 +0100 BST

Because different gcc versions compile differently and have different bugs, the newer gcc versions have problems regarding the way symbol visibility is handled across different library files. It requires a significant amount of work to make another approach work both on the newer gcc version and windows while compile from the same code.

Same remarks about python runtime, this is the one that supported and tested.


written by: dhjdhj

Mon, 3 Oct 2011 16:18:23 +0100 BST

Well, one can't live in the past forever.

Would there be any way to just get a sample project that just talks to the USB drivers. I can use that to move forward with this project.

Candidly, there's no way I'm going to spend the time trying to work through the entire massive EigenD build environment just to figure out that tiny little piece.

Someone MUST have built something for just that purpose already, otherwise how else would one know that the low-level device drivers were working properly.


written by: geert

Mon, 3 Oct 2011 16:42:34 +0100 BST

We have planned to move to a newer gcc version, but not for 1.3 nor 1.4.


written by: barnone

Mon, 3 Oct 2011 17:29:24 +0100 BST

One device that would be a good example for this type of integration is the snyderphonics manta.

The manta is a USB HID device
http://www.usb.org/developers/hidpage#FAQ

It provides a MAX external that has quite a simple but high bandwidth interface with the device.

You can download the MAX patches and take a look at the organization. It's quite simple and provides two way communication.

Both getting data from the manta and sending data to the device to light the leds.


written by: dhjdhj

Mon, 3 Oct 2011 17:39:33 +0100 BST

I'm not concerned at all about the Max end --- I know how to do that stuff. The issue is understanding (and getting to work) the basic data communication between the physical eigenharp (basestation) and the computer ....

For example: how does one connect to the Eigenharp (basestation) and initialize it? What is the format of the data/commands that need to be sent to it? What does the data that comes back when you press a key or use the breath controller look like?

I was hoping that there would be a standalone "exerciser" for that part of the system. I could then take that and adapt appropriately to implement the Max External.


written by: barnone

Wed, 5 Oct 2011 22:09:00 +0100 BST

@dhjdhj
Have you even looked at the code in detail?
Have you built the project yet?

"Candidly, there's no way I'm going to spend the time trying to work through the entire massive EigenD build environment just to figure out that tiny little piece. "

Then don't

lib_alpha2/alpha2_active_t.h

Didn't take that long to find it frankly

No there is not a standalone example program. It's pretty clear that Eigenlabs is not building a polished c++ or python SDK for developers and they are not a developer support organization.

They are providing Open Source which is very different but very valuable.

If you don't want to wade through the code then you're going to have to wait for workbench I imagine.




written by: dhjdhj

Wed, 5 Oct 2011 22:51:44 +0100 BST

Out of curiosity, I tried that the other day. The documentation said "just type make" so I did.

First I found that the location of the python binary was hardcoded to a place where mine isn't (mine is in the standard places).

Fixed that and then discovered that it had a hardcoded version of a gcc compiler that I don't even have any more.

According to Geert, a build requires very explicit (and old) versions of tools.

I gave up at that point!

I have the official Python 2.7 and 3.2 builds. I have the most recent version of gcc suite. When updates come out, I modify my codebase to make sure everything still builds so that I don't have to deal with legacy issues (and yeah, that can be a pain sometimes, we got really bitten by one version of Qt last year)

In the cases where I want to use something that is open source, I type

./configure
make
make install

If that doesn't work, I don't bother any more --- not worth the hassle unless I'm being paid for the effort and often not even then. I'm not an open source developer, don't really want to be.

Clearly Eigenlabs is not building SDKs and clearly they're not a dev support group. Never said they were. However, it's very hard to believe that nobody built a basic exerciser, even as part of a test suite for regression testing of the drivers.


As for waiting for WorkBench, that's a different can of worms.

Per Forrest Gump, enough said. This is clearly not going anywhere.


written by: barnone

Wed, 5 Oct 2011 22:59:37 +0100 BST

I posted some notes in the Building on Lion thread on how to fix the build issues you are mentioning.

Part of this is Apple yanking out gcc 4.0 support aggresively without warning.

gcc 4.2 creates a symbol visibility problem so you can't simply compile with it.

Maybe that thread will fix your build issue. It's working for me on Lion now.


written by: dhjdhj

Wed, 5 Oct 2011 23:34:51 +0100 BST

Interesting --- I'll take a look, but I really don't need to build the EigenD environment. I'm not interested in modifying EigenD, I'm interested in replacing it

(grin).

Anyhow, John has been very patient to allow these conversations on their forum. I don't think we're going to get anywhere with this debate, the environment is what it is.

By the way, I'm still on Snow Leopard until I can verify that all my plugins work on Lion.



Please log in to join the discussions