U.FON

I've just started with Jitter few days ago, because I would like to use it for controling RGB Led matrix.

My idea is to use video as a source for driving leds - analyze every pixel of video and send RGB values out over the USBserial interface to the Teensy microprocessor. Each pixel represents one RGB led.

So I need just stream of RGB values one each next another.

I ve mixed few tutorials and built basic patch for that.

When I enable printing the values to the max window ( just for testing purpose) everything slows down. playback is immediately choppy. I am not sure if it prints int or char - how many bits the each number from jit.iter occupy?

In the matrix are used chars. Are they also on the output?

Isnt this problem just because of printing soo many values to the max window - if I will send it over the serial interface to the Teensy board, ev will be ok?

I've just started with Jitter few days ago, because I would like to use it for controling RGB Led matrix.
My idea is to use video as a source for driving leds - analyze every pixel of video and send RGB values out over the USBserial interface to the Teensy microprocessor. Each pixel represents one RGB led.
So I need just stream of RGB values one each next another.
I ve mixed few tutorials and built basic patch for that.
But somewhere is mistake...

The problem is PERFORMANCE...
When I enable printing the values to the max window ( just for testing purpose) everything slows down. playback is immediately choppy.  I am not sure if it prints int or char  - how many bits the each number from jit.iter occupy?
In the matrix are used chars. Are they also on the output?
Isnt  this problem just because of printing soo many values to the max window - if I will send it over the serial interface to the Teensy board, ev will be ok?
Where do I do the mistake?
Sorry for newbie question...

jit-iter-for-driving-rgb-leds

You might also want to try jit.spill . Printing to the Max window can definitely be expensive for a lot of matrix data with jit.iter. I would try it with the board. If the performance still suffers, there are other options. From looking at your patch, I don't think it will be a problem.

You might also want to try jit.spill .  Printing to the Max window can definitely be expensive for a lot of matrix data with jit.iter.  I would try it with the board.  If the performance still suffers, there are other options.  From looking at your patch, I don't think it will be a problem.


Actually I am just preparing software. I dont have all the hardware to test it...

But anyway - I am still little confused about how many bits the numbers occupy directly on the output to the serial object?

There are char values from 0-255. so just 8bit...

But maybe they are converted into int by int object? (it is there just for flip Right to left order).

Then it will by 32bit for each value ( even if will use numbers just in the range 0-255)?

Is there byte type of numbers in Max? I ve never seen that.... Even the char is new for me ( I ve used just int and float till today...)

Thanks!
Actually I am just preparing software. I dont have all the hardware to test it...
I will check jit.spill
Would it be faster?
But anyway - I am still little confused about how many bits the numbers occupy directly on the output to the serial object?
There are char values from 0-255. so just 8bit...
But maybe they are converted into int by int object? (it is there just for flip Right to left order).
Then it will by 32bit for each value ( even if will use numbers just in the range 0-255)?

Is there byte type of numbers in Max? I ve never seen that.... Even the char is new for me ( I ve used just int and float till today...)


I've been doing this for years for various size installations. There is a limit to how fast you can iterate through a frame of video though. For larger works, I split it across multiple processors or computers. At the size you're working with, you should be fine. I use [zl split 1] to lose the alpha channel and [zl group xxx] to capture a singe frame. See attached for a simple example.

I've been doing this for years for various size installations. There is a limit to how fast you can iterate through a frame of video though. For larger works, I split it across multiple processors or computers. At the size you're working with, you should be fine.  I use [zl split 1] to lose the alpha channel and [zl group xxx] to capture a singe frame. See attached for a simple example.


it looks fast. I hope I understand you how to work with iter this way.

But when I am checking it the order of R G B is changing. the first pixel shoul be always the same.

It is RGB than GBR than BRG etc... I have to think about it.

it looks fast.  I hope I understand you how to work with iter this way.
But when I am checking it the order of R G B is changing. the first pixel shoul be always the same.
It is RGB than GBR than BRG etc... I have to think about it.


so basicly the main performance problem was because of using soo many rows in max window.

when the stream is "zl grouped" together the performance is perfect.

I know all this is probably unimportant when it will work without max window - just with microprocessor...

so basicly the main performance problem was because of using soo many rows in max window.
each pixel had its own row in my patch.
when the stream is "zl grouped" together the performance is perfect.
I know all this is probably unimportant when it will work without max window - just with microprocessor...


After a while a I've returned to this project. Now I have three testing RGB leds connected with WS2801 and all this with Teensy SPI.

I decided to use LEDstream patch for the Teensy board for the fast data transfer from Max to WS2801.

https://github.com/adafruit/Adalight/blob/master/Arduino/LEDstream/LEDstream.pde

The hardware works well - the testing pattern is ok.

Now I am quite confused about the data format that I must create in Max and send it to Teensy.

Please is there anybody who knows how to format this serial comunication?

The info about the comunication between Teensy and host is this:

// A 'magic word' (along with LED count & checksum) precedes each block

// of LED data; this assists the microcontroller in syncing up with the

// host-side software and properly issuing the latch (host I/O is

// likely buffered, making usleep() unreliable for latch). You may see

// an initial glitchy frame or two until the two come into alignment.

// The magic word can be whatever sequence you like, but each character

// should be unique, and frequent pixel values like 0 and 255 are

// avoided -- fewer false positives. The host software will need to

// generate a compatible header: immediately following the magic word

// are three bytes: a 16-bit count of the number of LEDs (high byte

// first) followed by a simple checksum value (high byte XOR low byte

// XOR 0x55). LED data follows, 3 bytes per LED, in order R, G, B,

// where 0 = off and 255 = max brightness.

I have just the LED data and I exactly dont know how to make that magic word, led count, checksum

After a while a I've returned to this project. Now I have three testing RGB leds connected with WS2801 and all this with Teensy SPI.
I decided to use LEDstream patch for the Teensy board for the fast data transfer from Max to WS2801.
https://github.com/adafruit/Adalight/blob/master/Arduino/LEDstream/LEDstream.pde
The hardware works well - the testing pattern is ok.

Now I am quite confused about the data format that I must create in Max and send it to Teensy.
Please is there anybody who knows how to format this serial comunication?

// A 'magic word' (along with LED count & checksum) precedes each block
// of LED data; this assists the microcontroller in syncing up with the
// host-side software and properly issuing the latch (host I/O is
// likely buffered, making usleep() unreliable for latch).  You may see
// an initial glitchy frame or two until the two come into alignment.
// The magic word can be whatever sequence you like, but each character
// should be unique, and frequent pixel values like 0 and 255 are
// avoided -- fewer false positives.  The host software will need to
// generate a compatible header: immediately following the magic word
// are three bytes: a 16-bit count of the number of LEDs (high byte
// first) followed by a simple checksum value (high byte XOR low byte
// XOR 0x55).  LED data follows, 3 bytes per LED, in order R, G, B,
// where 0 = off and 255 = max brightness.

I have just the LED data and I exactly dont know how to make that magic word, led count, checksum
beforem them.

ah, you're using ws2801s and you want to send data to a string, you say?

It's the big brother of the adalight setup - it listens to your screen, so you can just pop up a matrix and show the data you want to project.

use this instead:
http://ladyada.net/make/adavision/

It's the big brother of the adalight setup - it listens to your screen, so you can just pop up a matrix and show the data you want to project.


I ve checked it and actually the arduino/teensy sketch looks exactly the same in both cases.

And both adavision and adalight are connected with processing. And I am not familiar with processing yet... so I prefer Max - also because I plan to do some sound processing in led patch too.

So my problem how to feed the LEDstream.pde from Max is still actual....

Actually I think that basic thing is how to declare that magic word, led count, checksum an than LEDdata exactly how it is expected by LEDstream.pde patch.

I know it is written in description but I am not so skilled to understand and write the proper patch right now.

thanks Wetterberg.
I ve checked it and actually the arduino/teensy sketch looks exactly the same in both cases.
( “LEDstream.pde” sketch )
And both adavision and adalight are connected with processing. And I am not familiar with processing yet... so I prefer Max - also because I plan to do some sound processing in led patch too.

I know it is written in description but I am not so skilled to understand and write the proper patch right now.
( exactly this is quite unclear for me:

The host software will need to
 // generate a compatible header: immediately following the magic word
 // are three bytes: a 16-bit count of the number of LEDs (high byte
 // first) followed by a simple checksum value (high byte XOR low byte
 // XOR 0x55). LED data follows
)

Has anyone got a patch they'd like to share which feeds LEDstream.pde from Max?

Thankfully not too many brain cells required. Here we go:

I've been asked how to change the header to allow for a different number of led's.

If you look at the Arduino patch it says the first 3 characters must conform to the magic word (by default, A,D and a - ascii codes 65 100 97

Then you have the most significant byte and the least significant byte of the number of led's - in my case 0 63.

Finally you have a checksum which can be calculated by expr MSB^LSB^85. So say you had 512 led's you would send 1 255 171.

I think thats right anyway - I haven't checked.

I haven't had much luck driving my 512 led's from Max yet and have been using processing instead.

I'm not sure what the problem is but using max the sketch only seems to receive about 100 values before it wigs out. I'll have to look at it again. Its probably something simple. If I have a zl group 1536 object in my patch it won't spit this many vaues - perhaps Max can't keep up? Or I need to enable Overdrive or something.

I'd like to get to the bottom of it but for now I've hacked the Processing sketch to accept Syphon input. More flexibility that way anyway.

I've been asked how to change the header to allow for a different number of led's.
I'm only driving 64 Led's in my patch.

As it says above:
The host software will need to
// generate a compatible header: immediately following the magic word
// are three bytes: a 16-bit count of the number of LEDs (high byte
// first) followed by a simple checksum value (high byte XOR low byte
// XOR 0x55). LED data follows

I think thats right anyway - I haven't checked. 

I'm not sure what the problem is but using max the sketch only seems to receive about 100 values before it wigs out. I'll have to look at it again. Its probably something simple. If I have a zl group 1536 object in my patch it won't spit this many vaues - perhaps Max can't keep up? Or I need to enable Overdrive or something. 

I'd like to get to the bottom of it but for now I've hacked the Processing sketch to accept Syphon input. More flexibility that way anyway.


I can haz processing sketch? Sounds pretty flippin' flexible.

At the moment the processing sketch is very work in development but here it is anyway.

It is completely hardcoded for my setup - a 32x16 matrix and accepts a syphon stream of this size!

The scaling stuff is all in the sketch but I deleted it (or just didn't use it - can't remember).

The sketch is very untidy - there are a bunch of unused variables from the capture part of the sketch and the preview etc that I haven't deleted yet.

Also the syphon implementation for Processing throws an error though it still seems to work and I have read there is a memory leak though I haven't run it for long enough or checked ram usage to tell.

Maybe we should work on a max patch that does what this processing sketch does!

Just been testing this out with my wall and it doesn't work! So just in case anyone donwloads it, you've got some work to do!

>Maybe we should work on a max patch that does what this processing sketch does!

Oh damn yeah. I've got most of the hardware lined up to do it - just need a teensy or similarly. These slow-ass arduinos aren't going to cut it, iirc.

Here's the amended processing sketch. Works now at around 45 fps on my 32x16 matrix with a teensy 2.0

I've run it for a few hours with no memory issues so hopefully the memory leak scare I posted earlier wasn't true.

Two questions: 1) the teensy code to go with it?

And 2) which LEDs are you using again? I've forgotten already, just trying to gather the information in one spot that isn't my fragile brain...

Two questions: 1) the teensy code to go with it?
And 2) which LEDs are you using again? I've forgotten already, just trying to gather the information in one spot that isn't my fragile brain...


Just need to comment in/out the relevant bits to make it work for the teensy.

I had another bash at making it work direct from max using the method higher up this thread but once I get past about 120 LEDs it doesn't work, not sure why.

The code is here: https://github.com/adafruit/Adalight/blob/master/Arduino/LEDstream/LEDstream.pde
Just need to comment in/out the relevant bits to make it work for the teensy.

I had another bash at making it work direct from max using the method higher up this thread but once I get past about 120 LEDs it doesn't work, not sure why.


At first: Thank you for your great posts here. Until now they have been a great help.

I am using the LEDStream.pde sketch and a modified patch from GAVSPAV.

I started with an Arduino Board. For 75 LEDs that works fine. When I want to control 100 LEDs (and also changing the header) the first LEDs start blinking. And some of the LEDs blink randomly sometimes.

I wanted to switch to a Teensy 3.2 board. The startup just works fine. The LEDs show R G B and then black.

When I want to build up the serial connection nothing happens.

Hello everyone!
At first: Thank you for your great posts here. Until now they have been a great help.
I am using the LEDStream.pde sketch and a modified patch from GAVSPAV.

I started with an Arduino Board. For 75 LEDs that works fine. When I want to control 100 LEDs (and also changing the header) the first LEDs start blinking. And some of the LEDs blink randomly sometimes. 

I wanted to switch to a Teensy 3.2 board. The startup just works fine. The LEDs show R G B and then black.
When I want to build up the serial connection nothing happens. 

jit.iter for driving RGB Leds?