Forum rss-feed

Forum

Developers: Prototype open-source OSC EigenD agent available

STICKY

written by: geert

Hi everyone,

Given the current developer interest and barnone's motivation to dig into the code, Jim has spent some time creating a prototype EigenD agent that is able to output EigenD data streams directly through OSC.

This implementation is just a start and was quickly written in two days to bootstrap the learning process of users that wish to participate in the development. Its serves both as a documented example for creating agents as well as an initial step towards the OSC plans that we've been making. As time progresses, our OSC support will mature and the EigenD OSC protocol will be formalized in more detail, but this should give you an idea of the direction we're heading into. We've discussed various approaches towards how to handle the OSC representation over the network and have hit limitations of the network stack in the past due to the massive amount of performance data that the Eigenharp generates. This performance data is essential to the expressiveness of the Eigenharp and we obviously want to allow it to be exposed in as much detail as possible. The document named "OSC" that comes with this example agent briefly explains what we consider the best approach, it will mature as we further work on the OSC support.

The document named 'Roadmap' explains how to use this OSC agent and gives a high-level developer-centric explanation of EigenD's internal architecture. The source code is heavily documented and should make it easy to adapt towards any other functionalities that you might want to implement with an agent.

The source code can be found on GitHub in the 1.4 branch of EigenD. Here is a direct link towards the source of just the plg_osc agent:
https://github.com/Eigenlabs/EigenD/tree/1.4/plg_osc

More information about getting involved in EigenD development can be found on this wiki page:
http://www.eigenlabs.com/wiki/Developers/

Please realize that we have very limited resources to provide direct support to external developers as we're hard at work wrapping up the initial release of EigenD 2.0 and Workbench. We hope that this example will give you enough information to make EigenD development more accessible.

Take care,

Geert

written by: john

Tue, 11 Oct 2011 23:19:50 +0100 BST


That's a pretty good summation of why we wrote something from scratch, very well observed. To add to it and clarify from the Eigenlabs point of view;

*We made the decision to develop EigenD in 2004/2005 - Max was not even remotely capable of supporting what the Eigenharp does then and there was no indication it would be able to. If there had I been would have been on a plane to California instead of kicking off a difficult and expensive software project. I'm not stupid and I hate the 'not invented here' syndrome. I have paid heavily enough in the past for it and watch for it assiduously. This has not been and is still not one of those moments.

*There do exist Open Source variants on Max, but Max isn't one of them. Open source is the only guarantee that the instrument might still be usable, viable and still developed in 50 years. I am personally passionate about this and the idea that any component of what makes it playable would be unusable because some third party died and took the rights to code with them is and will continue to be unacceptable. You will note that we even chose an open source cross platform framework (JUCE) for our GUI tools with a view that over time they might be viable in that sphere in the future.

*Max is expensive and for Pico owners would raise the cost of ownership to an unacceptable level. This is not that complicated an equation. If we make a cheaper Eigenharp in the future this picture just gets more stark.

*I'm seriously unconvinced that you can do what EigenD does in Max. Happy to be proved wrong, go for it, but having spent some time coding in EigenD for the first time this year, I've realised that it's a hard world dealing with that amount of data, in real time and making audio from it. And Max, as far as I'm aware, has never handled anything like that. And yes, you can decimate the data so it can cope, but that's really not the point - the reason we create that amount of data has a serious purpose and throwing it away just to run some piece of software that costs a load of money and doesn't give you anything spectacular in return is pretty stupid.

* And lastly, Max is old. Lots of the stuff in it is MIDI centric, and that is simply not where we're headed. It's a lot more mature than EigenD for sure, but it's formed from a different set of objectives than the ones we have and meets a different set of needs. We have a different vision of the future, one revolving around highly expressive performance rather than offline composition, academic musical pursuits and twiddling with noise. Those things are interesting in their own right, just not to me and as I have found over the last two years, not to the vast majority of Eigenharp players either.

We have invited other developers to share in that journey towards a seriously expressive electronic future, and a proprietary development environment that might disappear sometime at the whim of others does not figure strongly on that road right now. I'm very happy to see someone interfacing the Eigenharp to Max in some way, I'm sure there could be some interesting things come from it. However, we have near zero customer interest in such a thing, so it's not something that we can give any bandwidth to at the moment.

cheers

John


PS; to add to NothanUmber's OSC comment - we have substantial plans with OSC and any volunteers to help us with that would be greatly appreciated. A test OSC input would be a great little project...


written by: barnone

Wed, 12 Oct 2011 00:16:20 +0100 BST

Count me in as one who does NOT want to replace EigenD.

I can't promise to not do silly experiments with OSC and experimental sounds, controllers, etc. That's part of the enjoyment for me. Trying new techniques and connections between devices. I do think that a lot of electronic musicians are always furthering their techniques and setups. This involves many connections and I don't think those connections will become any less in the future. It's constant innovation as constant as the march of technology itself.

John, I've always been highly impressed by your vision and motivation to make this the absolute best possible instrument. It's truly a monumental achievement.

I agree that having something that will endure as a whole system both hardware and software is very desirable.

Now that the code is open source and we have this example agent, I feel pretty empowered to contribute both to my own experiments and also to the source. Will take some time to be productive I'm sure.

Over the past year EIgenD has really matured and the initial roadblocks have been removed. Some quite amazing features especially around the controller and midi mappings have made the interfacing much better. I attribute that to Eigenlabs listening to customers and also to you rounding out and strengthening the eng team. Thank you.

Most of the roadblocks now are ourselves. You can't learn this instrument properly without practicing. Duh.

I regret my comments about boiling the ocean, although you kind of have it simmering already. You have my support on the subscriptions and I am awaiting the invoice. If it ever came down to either stopping dev or stripping features, I'd definitely choose to strip features cause I want you guys to keep going.

Best,
Chris

test OSC input? On the EigenD side or consumer side? Could help with both.


written by: dhjdhj

Wed, 12 Oct 2011 00:40:20 +0100 BST

John, I don't know when you last looked at Max but it's certainly not for offline composition....are you thinking of CSound?

Max is a state-of-the-art system that includes real-time DSP (audio rates) and real-time video processing. People are building synths (subtractive, additive, granular, physical modeling and so forth) as well as effects and graphics processing. It has had network (udp,tcp) + OSC support for years. People from the top music centers (CCRMA, CNMAT among others) are working with it....trust me, they are not futzing with old MIDI stuff, they are pushing the limits.

There's a reason it got integrated into Ableton Live almost 2 years ago. There's a significant and vibrant community building instruments and effects processing in Max For Live with new stuff showing up daily. Some of it is astonishingly cool. People are also interfacing it to other physical devices.

The Max Runtime System is available free so if you've created an application with Max, people can use it without having to purchase their own Max license.

It is actively supported and a new version will be out in the next month or so and they're reducing the price significantly to try and get it into more hands.

I cannot imagine that a system designed to process high quality audio and video in real-time could not handle the data rate from an Eigenharp. The only reason I mentioned decimating the data was so that it could be connected to external MIDI devices (and the point is that there's no need for EigenD to do it, Max can).

Finally, while I don't know this, I would not be surprised if you could sell a lot of Picos into the Ableton Live market, if it integrated nicely (i.e, via Max). That market is hungry for interaction and physical devices for performance and the Pico is not that expensive compared with other controllers and physical devices that people are buying to use with Ableton.

I'm not suggesting for one moment that Eigenlabs get involved in Max development, I realize resources are limited. But helping to kickstart things for people who can contribute Max stuff would not be a bad idea. Once you have a base system, the growing Max community will take over.

If I can get the OSC thing to work, I'll go from there, and I'm excited to give it a try (thanks barone)....but even that stuff is overkill as really the only thing necessary is to feed the physical parameters into a Max external.

There's a 3-day Max conference in Brooklyn this weekend and I'm hoping to be able to discuss this with others at that time.

Cheers,
D


written by: dhjdhj

Wed, 12 Oct 2011 00:57:59 +0100 BST

My comments in bold.

Many Ableton Live users already have Max For Live so no extra cost. Runtime system is free so a prepackaged application can be distributed at no cost to users. People would only need to get their own license if they want to add new features
* Relying on Max would either nearly double the price of a Pico (if people have to buy Max just for being able to use it) or would greatly limit the potential user base (if you just want to address those who already own Max)


This is the part I don't understand --- for me, the value of the Eigenharp is the physical device with its amazing sensitivity. I have no idea what EigenD does for me that I couldn't do with existing environments.
* the part that would have been replaced by Max is only a small part of what represents EigenD (essentially Max could presumably replace the Workbench and some parts of the Python code - the latter being presumably easier to understand and maintain than a Max patch of equal complexity). And the C++ parts would most probably also have to be written in C++ in the Max case, so there is no big advantage



What endusers (in what market) are going to learn Python and/or C++?
* For many highlevel components in Max there are comparable third party APIs for (at least) C++ available which can be exposed to Python were helpful, so using Python/C++ doesn't mean you have to reinvent the wheel. E.g. the plugin host and much of the graphics aspects are from Juce as far as I understood etc.

What kind of reconfiguration? One could easily implement things like splits, layering and so forth with Max and trigger changes on the fly by assigning a couple of keys of the Eigenharp to enter "Configuration mode". Max can be used both as a control language AND as an implementation language for processing data.
Why does a musician care about distributed setups?

And for many fundamental things like a control language (Belcanto) that allows on the fly reconfiguration just from the instrument, the network transparency that allows distributed setups etc. there are presumably no ready to use solutions for either Max nor anything else (only lower level protocols like OSC where you can start to build on).


It's a hell of a lot easier to do stuff with Max than it is with Python & C++ (I know all three) once you're in the music domain. Further, surely the Eigenharp's target market is not programmers! You're going after the music performance market. Many such people are barely technically literate. They'll have a much easier time changing stuff with Max than with Python + C++
* The number of people who know Python&C++ is undeniably bigger than the number of Max users, so the chance for open source contribution could be (potentially) higher.


Really? Cycling74 has been around for many years --- they have a huge partnership with Ableton (I'm sure lots of money was involved) ---- and Max runs on both Mac and Windows. They have a new version coming out in the next month with many new features specifically aimed at making it even easier to use.
* The future of Max is not in Eigenlab's hands. If Cycling74 runs out of money, decide to drop certain platforms or shift focus a Max based EigenD (which would presumably not have been significantly cheaper to develop) could suffer or even die with it.


Well, my sense is it could be done with Max (and perhaps just a little C++ for the Max External that would have been needed to talk to the USB hardware). I get the sense that the MaxMSP environment is being seriously underestimated.
So imho it not the question whether it couldn't also have been done with Max+C++ instead of Python+C++ (most certainly it could) but which advantages and disadvantages each solution brings - and at least I can understand why they went with the Python+C++ route :)


written by: bl4cksun

Wed, 12 Oct 2011 08:14:53 +0100 BST

Just to add to what dhjdhj has said. I like many use ableton, it's used in the studio and also live. I choose to use a pico as one of my controllers, whilst occasionally I feed audio from eigend to live, mostly it is midi. Having a simple lightweight interface to live via max would cut down what I'm asking my CPU to do, remove a couple of windows from my screen (oh for stage on my iPad). The new setups by geert help and thanks for those but as you know already, choosing midi as the transport means we are loosing so much.
Not everyone wants to use something like ableton for live performance, and that is what the eigenharps specialise in, but the majority of people using computers in a live performance to make audio are using ableton. Ableton push max for live in a big way. These people are a large untapped customer base for eigenlabs given the right technology and marketing. I see opportunities for both approaches, and whilst I can see that a solution based on max may limit subscription revenue, the extra revenue from ableton/max users should more than compensate?


written by: bl4cksun

Wed, 12 Oct 2011 08:15:35 +0100 BST

Double post, stupid iPad
Martyn


written by: geert

Wed, 12 Oct 2011 13:33:16 +0100 BST

Hi dhjdhj,

It would indeed be very interesting for certain people if Max could be make to work to directly take the data streams from the Eigenharp. It's interesting that you mention audio rates. Each data stream on the Eigenharp is 2kHz, which brings the total maximum data rate on the Alpha up to almost 17 simultaneous audio tracks running at 48kHz, consisting out of 399 individual streams (132 keys * 3, 2 strips, 1 breath) that each carry clocking information, contextual information to allow for correlation, data formats, boundaries, ... This needs to be processed in real time, without introducing latency, without losing the clocking and while respecting the data formats and doing the required data conversions. It does indeed not leave much room of inefficiencies, but it might indeed technically be possible in Max, it certainly would be cool. I just wanted you to realize what the actual rates and data relationships are. (note that this still doesn't include the 96kHz microphone input and 48kHz headphone output)

Finally, to add to the excellent summary from NothanNumber, the Eigenharp is intended to be an instrument that is accessible for people that don't want to tinker. With EigenD they can just plug it in, start the software and begin playing. Then gradually discover the depths of the system and if they so wish, customize it. Having software that is specifically tailored for the Eigenharp makes this possible. Most people are totally happy with the factory setups and don't even delve into external MIDI control, they just want to play it as a traditional instrument, accepting the boundaries and functionalities that we have provided with the shipping factory setups.

Take care,

Geert


written by: geert

Wed, 12 Oct 2011 08:49:41 +0100 BST

Hey barnone,

I'm personally very excited about any possible weird experiments that you will come up with and I think that it's part of what the open-source nature of EigenD offers. Given your track record and your software contributions to the electronic music scene, I think we'll be in for a treat :-)

Take care,

Geert


written by: mikemilton

Wed, 12 Oct 2011 09:44:38 +0100 BST

" I have no idea what EigenD does for me that I couldn't do with existing environments. "

I, on the other hand, *do*

It is simply not valid to say, in effect, that one has ignored something such that one is unaware of what it can do and that, therefore, it can't do anything.

So, let me say that I'm quite Live and MAX phobic. I've had a (brief) run at them but they are not interesting to me musically and quite opaque to me without a level of effort I see as unjustified. If they had been the required environment for an Eigenharp, I would not own one. This probably feels familiar to you as it is simply the inverse of you own position. It is nothing more.

This is *not* a critique of people who do create in that context nor am I, in any way, arguing against *including* the ability for people who have an established interest in Max and or Live to work in that idiom. Personally, I'm looking forward to see what they do as well. To be clear, I'll absolutely enjoy the outcome but have no plans to suffer through creating such an outcome... I'm a good audience.

Finally, my experience of the Eigen-system is that both contexts (the controller and the SW environment) are excitingly new in a way that argues against exclusively using the HW as a controller for older (if esoteric) solutions. Looking back, it is clear I would have been deeply underwhelmed if it had been just another controller.

m


written by: dhjdhj

Wed, 12 Oct 2011 11:58:50 +0100 BST

Never in my comments have I said or implied that "therefore [EigenD] can't do anything". Please don't put words (nor intent) in my mouth that I never said (nor implied).

I'm basing my comments on what I have seen (well, heard) people do with demos. I have not yet heard anything done with the Eigenharp (other than the physical expressiveness) where, given what I know of other environments, I've thought "wow, how is that possible".

We are in agreement about the capabilities of the controller itself. That's why I bought it too.

The irony is I have had this same discussion on numerous occasions throughout my career when people start discussing what programming language is best. They're all essentially Turing complete so you can do the same thing with any of them, but depending on the domain, it may be easier in one language than another.

If you have some examples of what you feel are significantly easier to do with EigenD than with other environments, it would be very interesting (and important) to understand that. If I am completely offbase with my view, then I will absolutely stand corrected.

Given its popularlity as part of Ableton, it's hard to argue that Max is esoteric and it's certainly hard to argue that it's more esoteric than EigenD, which is useful only with an Eigenharp whereas Max is being used in conjunction with many different controllers. (Kinect, AudioCubes, Wii, Haken Continuum, heck somebody even interfaced a bicycle to it (http://www.cycling74.com/forums/topic.php?id=5132))


By the way, for the record, although I have a copy of Ableton and have played with it, it would definitely not be my go-do environment for anything serious. But MANY people feel otherwise, and that spells "opportunity", in my opinion.


written by: dhjdhj

Wed, 12 Oct 2011 15:37:40 +0100 BST

Not sure I understand what a datastream represents --- is it the case that data is being sent out continuously for each key, even if you're not touching it? If so, then it seems to me that it would make sense to block unnecessary data (i.e, nothing happened) at driver levels. It's my understanding that the upcoming release of Max 6 will have an option (for a small extra payment) to compile the patchers, leading to even faster response times.
It would indeed be very interesting for certain people if Max could be make to work to directly take the data streams from the Eigenharp....



Actually, this is one of the key issues for me. I agree completely that it should be useful for people who don't want to tinker. I am not suggesting that everyone who gets an Eigenharp would touch the Max code. It should be feasible to build a sophisticated Max environment, that at the top level can simply accept commands (using Eigenhap keystroke sequences if that's desirable, but lots of other ways) to change the behavior (e.g., similar functionality to keygroups/splits, layering, scale definition and so forth). Max already has built-in support for playing sequences, drum loops, samples, managing VSTs and so forth that can also just be triggered remotely.
Finally, to add to the excellent summary from NothanNumber, the Eigenharp is intended to be an instrument that is accessible for people that don't want to tinker.


This is the other key issue for me. The problem from my perspective is that EigenD wants to be in charge. Whereas, I view the Eigenharp as something to be integrated into an existing environment. I think that is true for many people. I have had 45 years of training in keyboards and guitars....I'm not about to drop those instruments and dedicate myself to the Eigenharp. I want to extend my expressibility where it makes sense
With EigenD they can just plug it in, start the software and begin playing. Then gradually discover the depths of the system and if they so wish, customize it.


This takes me back to the earlier point --- I do not know what EigenD is able to do for me what I cannot do in other environments. Some examples that show me where I'm misunderstanding EigenD capability would be terrific.
I realize I'm hammering away on this and maybe people are getting fed up with me. I apologize for that but understand that I am a PASSIONATE believer in the capability of the instrument itself....just not so much EigenD right now

Having software that is specifically tailored for the Eigenharp makes this possible. Most people are totally happy with the factory setups and don't even delve into external MIDI control, they just want to play it as a traditional instrument, accepting the boundaries and functionalities that we have provided with the shipping factory setups.


written by: geert

Wed, 12 Oct 2011 16:06:40 +0100 BST

Not sure I understand what a datastream represents --- is it the case that data is being sent out continuously for each key, even if you're not touching it?

No, of course not, that's why I said maximum data rate. It does mean that it has to be able to scale up for that when needed, instantaneously.

I've been playing the guitar for a very long time also, never used Live or Max as when I tried them out, I personally found them particularly hostile and not suited for me (I'm not particularly clueless when it comes to using complex software either). I personally host my entirely live rig in Bidule and use the +DSP capabilities of my Metric Halo boxes with custom programmed graphs.

I've always seen and still see EigenD as the brain of that makes the Eigenharp tick and it can interface with other environments in a growing number of ways, ways that can evolve over time. I much prefer that approach to what most instrument makes are doing with built-in software that's almost impossible to access. However, if you look at the Eigenharp as an instrument, just like a guitar is an instrument, then EigenD imho also makes perfect sense. It sits hand in hand with the physical instrument, you put it on a computer that you don't look at and forget about it. That's how many people use it and that's what it's designed to do well: be an instrument with an external brain and heavily optimized communication with it. I'm still seeing proof that this approach is valid and works since my daughter and girlfriend who just want to play an instrument, pick up the Pico or the Tau and go at it. The quick reference guide is all they need to understand.

If you want to use it as a controller that integrates with your environment, that's cool, what's even cooler is that you're getting an increasing number of ways to do so. As time progresses, this will also progress and John's vision of ensuring that the Eigenharp is still current in 50 years is not a pipe-dream. OSC is still pretty new and almost no software is able to use it for musical performance directly, not surprising as apart from MIDI over OSC there's no standard for this. So this use-case that you're interested in, is very interesting, but certainly not one for people that just want to play a musical instrument.


written by: geert

Wed, 12 Oct 2011 16:20:56 +0100 BST

Forgot one reply, here's a very basic example David.

Imagine the Eigenharp just outputting raw data (Max isn't open-source so it's not even an option to be the standard 'brain', gratis is irrelevant here) ... how would anyone that just wants to play an instrument pick the Eigenharp up? Learn about whatever data format it outputs, learn how to transform and correlate that data, figure out how to make it work with musical notes, ... and so on. I vastly prefer the current experience that gives users effortless access to all the expressiveness through EigenD and still allows you to integrate with other environments.


written by: barnone

Wed, 12 Oct 2011 16:36:02 +0100 BST

@dhjdhj
>I realize I'm hammering away on this and maybe people are getting fed up with me.

yes

I realize you are passionate about MAX but the constants rants on it are tiring. I especially hope that every thread that gets created in the Development forum doesn't get turned into this same topic.

I was hoping this thread would be for an actual discussion of building agents and using the OSC agent that geert and jim were so kind to provide. It's (The MAX thing) is a valid discussion but maybe we can confine it to one thread.

I know that in other forums, the admins can move related posts into the proper thread when a valuable thread gets derailed and help keep things better organized in the forum.

So responding to this MAX thing..

It's certainly not an either / or proposition regarding EigenD anyway. EigenD is the host of choice for the instrument and is really valuable to the platform and it's users. Personally I value both the ability to fire up EigenD and be productive as well as the more experimental approach of possibly connecting to MAX or another host more directly.

The thing is, Eigenlabs is rightly focused on one thing right now which is polishing EigenD and completing the vision there. This is a totally valid direction for them and I doubt ranting about MAX will change that. John has already been quite clear on this.

At the same time, we have been given this wonderful opportunity which is the Open Source code to EigenD.

There is nothing stopping you or I from creating a MAX external if that is your wish. Already there is this osc example which will get you productively to MAX or other environments like PD, Supercollider, Bidule, whatever you wish.

You'll catch more bees with Honey than Vinegar.

Keeping the discussion productive and limiting the amount of time that eigenlabs employees need to spend dealing with supporting Developers will help. If we, the community prove that we can contribute productively to the platform that will build trust and I imagine will open up more communication channels between Eigenlabs and external devs as well as foster a proper developer community that can help themselves be productive.

@dhjdhj
This bit about not wanting to spend time building the code gives you absolutely zero credibility with me. Don't expect to get binaries from me as you are simply wasting my time rather than your own.

You have everything you need to start on your MAX patch. Even without binaries, you have the OSC protocol which can get you started. If that gets changed to an external in the future, it would be an easy swap. And I do believe that you did receive binaries from NothanUmber. Is he expect to package these up for you everytime there is a source improvement?


written by: dhjdhj

Wed, 12 Oct 2011 17:08:58 +0100 BST

Nobody is expected/required to do anything for me. I absolutely have what I need.

I am sorry you feel your time would be wasted.

I'm done here.


written by: NothanUmber

Wed, 12 Oct 2011 20:43:32 +0100 BST

@dhjdhj: Suggestion: just load the MIDI-only setup that Geert provided for the Alpha into EigenD and encapsulate the MIDI->Max datastream conversion into an EigenD root subpatch as you suggested in your initial picture. Then you don't have to care about EigenD at all and all you have to do once full OSC support is available is to exchange MIDI->Max datastream with OSC->Max datastream conversion inside your root EigenD-bridge patcher to gain the additional resolution that OSC has over MIDI.
Then you can load-and-forget EigenD and concentrate on having fun with Max.

Greetings,
NothanUmber


written by: dhjdhj

Wed, 12 Oct 2011 21:55:57 +0100 BST

@NothanUmber

That is an interesting suggestion.

Note that I have been "having fun" doing Max processing with the Eigenharp for the last year by essentially just using a MIDI out port from EigenD. I then brought that MIDI data into a Max patcher where I did all my processing. I used some keys for controlling the patch itself, and others for playing, both solo notes as well as triggering chords in a Max sequence.

The problem I ran into was due to pitchbend and aftertouch being channel messages and so unless one was in poly mode, it wasn't possible to add vibrato to multiple notes independently (for example). But poly mode caused a different set of issues for me at the time.

I'd like to be able to do things like floating splits where, (for example) my left hand is playing one sound, my right is playing another, and as I move up and down the keyboard, as long as there is at least one (say) row separating my hands, then the left hand might use one set of MIDI channels and the right hand could use a different set of MIDI channels. To do this, I need to know things like physical key locations.


Now, your suggestion makes me realize that the combination of a scale that maps each key to a unique raw midi note number (from 1 to 120 for the alpha) AND poly mode could be used so that you could always tell which specific keys had aftertouch (or pitchbend) applied. That could then be merged back into a representation that just gives me keynumber + X,Y,Z values at all times which is what I would like to be working from.

I will explore this.

Thanks,
D


written by: barnone

Fri, 14 Oct 2011 01:51:27 +0100 BST

Some nice things to try re OSC.

Follow the instructions in the source at ./plg_osc/Roadmap for creating the OSC setup.

In EigenD, save the setup so you can use it later.

Next time you run this setup from your compiled version of EigenD.

All you have to do to register a destination for the OSC events is goto the commandline and type...

oscsend localhost 9999 /register-fast si keyboard_1 5555

Now OSC will be sent to port 5555 on localhost.

Alternately, use can use the MAX patch I posted above to do the exact same thing.

Some stats on the kind of event volume we are getting here.

Very very rough estimate of touching keys and counting events.

We are getting @1000 events per sec per key through OSC.

Now these measurements were not timed, but simply human estimated.

So, yeah, it's a lot of raw data. But totally within striking of some MAX patches or similar. It's quite easy to use some smoothing algorithmns when sending to destinations that are going to choke on the event volume.

[edit] I'm seeing these lines when I really hit it hard

: debounce 21 19870 us
: debounce 23 19452 us
: debounce 24 19987 us
: debounce 46 19884 us
: debounce 21 19966 us

Is this events being bounced because the network stack is overloaded?

Wondering if 19xxx is bytes?

Interesting yet solvable in many ways, such as some intelligent smoothing and or decimation at the send point.

I might also just be misreading the log.




written by: barnone

Fri, 14 Oct 2011 02:10:53 +0100 BST

/keyboard_1/key/4 siffff "48" 47 2.000000 0.028564 -0.027344 0.050781
/keyboard_1/key/4 siffff "" 0 0.000000 0.000000 0.000000 0.000000

This is interesting output. What's with the empty string and the all zeros? Just wondering.


written by: jim

Fri, 14 Oct 2011 09:46:57 +0100 BST

The bounce messages are a physical thing; the keyboard agent is detecting a key retriggering inside a certain threshold, which usually indicates a physically bouncing key. It's a spring and rubber phenomenon.

The OSC networking is UDP. If the stack overloads, it'll just silently throw packets away.

It should be 2000 events/sec/key. If its not, I'm losing some somewhere!

The string there is the event-id. I'm using an empty event on the channel to indicate end-of-event. The event boundaries for a stream generally depend on the physical controller, but in general, events correspond to physical activity, like pressing a key or blowing the pipe.

I put in a placeholder for decimation in the agent, but haven't implemented it yet.



Please log in to join the discussions