Forum rss-feed

Forum

Developers: EigenRemote

Most Recent

written by: dhjdhj

I'm not familiar with Manta.

However, I'm a little concerned about that polling suggestion. I assumed that incoming data would be available via interrupts that could just be shoved in to a Max object.

However, if it's necessary to poll for information, then that needs to be done at a much lower level than at the Max object level so that an [eigenin] objects works exactly the same way as the [midiin] object. I.e, you just connect its outlet to something and when data comes in, your patch is triggered automatically.

1) [metro] is far less efficient
2) One might have many [eigenin] objects (just like one can have many [midiin] objects, it's VERY convenient, and one shouldn't have to include extra objects like metro+initialization every time.

written by: barnone

Wed, 5 Oct 2011 22:36:54 +0100 BST

As an initial project, thinking about creating a program that bypasses most of the host capabilities of EigenD and provides something quite stripped down.

Basically, it will communicate controller data from the harp and will send led data to the harp.

The leds will be addressable via OSC commands.

The controller data will be received raw at which point I will have to put together enough components in EigenD to probably do jitter reduction, throttling etc. I'm assuming that velocity detection is done in EigenD as well. I haven't discovered those pieces yet. Once I have a clean stream of controller data, this will be sent over OSC.

The third component would be a MaxForLive plugin that connects to the OSC stream. Eventually this could be written as a VST/AU as well. Actually, I think Bidule can even provide this type of thing as a plugin with very little coding necessary.

This is definitely more or a monome, manta, soundplane way of getting data into any host, but it allows for arbitrary applications to be developed rather than ones based on EigenD soley.

Thoughts?


written by: dhjdhj

Thu, 6 Oct 2011 02:12:00 +0100 BST

What a good idea. I wish I had thought of that!


written by: barnone

Thu, 6 Oct 2011 03:24:40 +0100 BST

haha, yeah and I agree.

There seem to be two valid approaches. The MAX external approach is similar to Manta for example.

I looked at your conceptual MAX patch. Looks good. One way to do the input is to bang it with a metro so it's polling every couple ms or so.

I'm just as interested in having the output external too to light the keys.

But I have to admit that the OSC approach is nice too.

I don't want to replace EigenD completely. A lightweight configuration that runs as a background process and is an OSC server would be ideal IMO. Similar to what monome did with serialOSC.

Bottom line, I just would like to play with the source right now, so a simple goal is fine for the moment.

Will definitely share as I go along.


written by: dhjdhj

Thu, 6 Oct 2011 13:32:55 +0100 BST

I'm not familiar with Manta.

However, I'm a little concerned about that polling suggestion. I assumed that incoming data would be available via interrupts that could just be shoved in to a Max object.

However, if it's necessary to poll for information, then that needs to be done at a much lower level than at the Max object level so that an [eigenin] objects works exactly the same way as the [midiin] object. I.e, you just connect its outlet to something and when data comes in, your patch is triggered automatically.

1) [metro] is far less efficient
2) One might have many [eigenin] objects (just like one can have many [midiin] objects, it's VERY convenient, and one shouldn't have to include extra objects like metro+initialization every time.



Please log in to join the discussions