External midi controller—->VDMX Midi (In plugin)——>VDMX slider/knobs—->VDMX Midi out (plugin)—-via IAC bus—>Max patch with main code in a js object—->Serial Object out to wireless XBEE (9600 baud rate)—–wireless connection to a remote uP that controls an rgb led.

So the issue is when I move more than one slider at a time on the external midi controller, the max patch only receives one of the controls. e.g. if I had three sliders each assigned to a different CC# and I move all three, only one of the CC# values gets read.

I think the bottleneck (other than the 9600 baud serial port) is with the vdmx midi in to midi out plugins not managing the multiple CC# (issue with it’s event handling/monitoring)

Anything I should consider in terms of optimising the real time response of this system?

is there potential max issues or is this purely a vdmx issue?

As I do all my controls always with multiple faders, and never had a
problem I’d assume its and vdmx issuee.
I have no idea what it means, you seem to assume everybody knows about
vdmx, that assumption doesn’t help, its wrong… ;-)

You might paste your patch into a mail, to have a look at it. Usually
the reason for such problems is a bug in your patch…

Stefan

–
Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

The two big standards for VJing are Resolume and VDMX.

Also VDMX integrates really well with Quartz Composer.

cheers,
Danjel

http://www.audiovisualizers.com/toolshak/vjprgpix/vdmx/vdmx.htm

This patch basically takes an incoming midi cc and translates that into a command that an external device attached to the serial port can read (the external device is basically a uP hooked up to some rgb leds).

In order to do this the CC value is read in by the js object and matched to the right case. Most of the commands simply send a short ascii string.

The one that causes issues is part of “followcolormode”. For this I use three different CC numbers to represent the color component R, G and B. In “followcolormode” changing an rgb value results in an instant color change message to be sent to the serial port. Whenever I am sending moving more than one fader at a time (e.g. sending r and g values) it gets stuck only sending one color. To me this is may be an issue in VDMX not merging the different streams of CC values.
Or it could be that my js patch is too inefficient to deal with the steady stream of changing values.

if anyone checks out my code, I appreciate it!

e.g. when an r,g or b value comes in I change it from an integer to a string and then format it for the message protocol (double digit ascii representation of a hex value).

This might be slowing things down…

Ah, its software…

Then your solution is simple…
Instead of

> External midi controller—->VDMX Midi (In plugin)——>VDMX
> slider/knobs—->VDMX Midi out (plugin)—-via IAC bus—>Max patch
> with main code in a js object—->Serial Object out to wireless XBEE
> (9600 baud rate)—–wireless connection to a remote uP that controls
> an rgb led.

just skip the Midi route through VDMX, no IAC required, just get the
midiin from your Midi interface directly into Max…

External midi controller—->Max patch with main code in a js
object—->Serial Object out to wireless XBEE (9600 baud
rate)—–wireless connection to a remote uP that controls an rgb led.

Stefan

–
Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

I did another test where I used VDMX to generate rgb values based on analysing frequency bands of music (yes I know I can also do this within max) which resulted in a steady stream of rgb values being generated. Again the messages got messed up so that only CC number was being listened to and the others ignored.
(e.g. if r, g and b were constantly changing, usually only one value like g would be read and the other colors would get stuck).

I guess I would be suprised if VDMX is choking up while trying to send the midi for this since this should be a pretty common function (syncing audio or visual effects to external devices).

I guess I am just eliminating all other possibilties. You think the js part is not a bottleneck?

cheers,
Danjel

No problem, just receive both with different ctlin/midiin or whatever…

Stefan

–
Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

JS was nice to use for this situation because it made it so easy to form the messages for the receiving device (a lot of converting between types and string formatting).
For all the simple messages this worked out perfectly.

I guess what I can do is just look for the realtime messages (e.g. the rgb values in followcolormode) and process those with a different path than the other messages. I can do all their processing with max objects instead.

I guess another option is to learn how to make max objects written in C!

cheers,
Danjel