davidestevens

14 LED lamps (4 groups of 3, plus 2 extra floods), controlled via a Lanbox, connected to my OSX Retina MBP via Ethernet, running either Max 6 or 7. Each lamp is set to 4chn (ie r,g,b,w) so there are a total of 56 channels.

A choice of 2 lighting sequencers - the original (max6) one triggers simple envelopes that drive the lights. The newer (max7) one has an envelope for each of the possible rgb colours, either 1 colour per lamp (ie a red lamp, a blue lamp, a green lamp, in sets of 3).

All the generated data goes to an [lcupd-pack] then a [updsend], maxpacketsize & maxqueuesize set to 5096 (though I just upped that to 7144)

The max7 one wasn't working at all till I added a [change] for each channel, and then would only work smoothly up to 2 sets of 3 lamps, starting "sticking" when I added set 3, and not working at all with all 4 sets being sent data.

The max6 one is better, but still v clunky with 4 sets of lights running (I'm sure it didn't used to be as jerky as it is now, but maybe that's my memory).

Anyone running lots of lamps over dmx and getting it to work smoothly? (What's your secret!)

_Should_ I be able to run 14 lamps (with continuous colour changes) smoothly from Max, or is that pushing things too far?

Is there a max packet/queue size that I can go to, and should increasing those limits improve things? (Up to what limit?)

I don't think there's any problems with the patches; the data is getting to [lcudppack] ok. I've tried the patches with and without a [speedlim 40] before [lcudppack], and it doesn't seem to make a whole lot of difference. And one still has to keep sending lots of 0.s in the output list, because dmx doesn't AFAIK allow me to address the lamps individually.

Here's what I'm trying to do..
14 LED lamps (4 groups of 3, plus 2 extra floods), controlled via a Lanbox, connected to my OSX Retina MBP via Ethernet, running either Max 6 or 7. Each lamp is set to 4chn (ie r,g,b,w) so there are a total of 56 channels.
A choice of 2 lighting sequencers - the original (max6) one triggers simple envelopes that drive the lights. The newer (max7) one has an envelope for each of the possible rgb colours, either 1 colour per lamp (ie a red lamp, a blue lamp, a green lamp, in sets of 3).
All the generated data goes to an [lcupd-pack] then a [updsend], maxpacketsize & maxqueuesize set to 5096 (though I just upped that to 7144)
The max7 one wasn't working at all till I added a [change] for each channel, and then would only work smoothly up to 2 sets of 3 lamps, starting "sticking" when I added set 3, and not working at all with all 4 sets being sent data.
The max6 one is better, but still v clunky with 4 sets of lights running (I'm sure it didn't used to be as jerky as it is now, but maybe that's my memory).
So...

Anyone running lots of lamps over dmx and getting it to work smoothly? (What's your secret!)
_Should_ I be able to run 14 lamps (with continuous colour changes) smoothly from Max, or is that pushing things too far?
Is there a max packet/queue size that I can go to, and should increasing those limits improve things? (Up to what limit?)
Anything else I should be doing?

I don't think there's any problems with the patches; the data is getting to [lcudppack] ok. I've tried the patches with and without a [speedlim 40] before [lcudppack], and it doesn't seem to make a whole lot of difference. And one still has to keep sending lots of 0.s in the output list, because dmx doesn't AFAIK allow me to address the lamps individually.


how-many-lamps-should-i-be-able-to-control-at-once-over-dmx

To answer your questions briefly. DMX allows transmission of 512 channels at up to 44 fps. The LanBox hardware however cannot output faster than 20 fps. This isn't a great frame-rate, but still shouldn't be obviously jerky. Bear in mind though that cheaper LED fixtures suck at dimming, and will never be smooth when fading through low intensity values.

I'm not sure what your mean by not being able to "address lamps individually". Have you not set the DMX start channel on each fixture?

Yes, each lamp has its own start address. I've just always thought it a bit crazy that I have to keep sending 0's in each message rather than just the changing numbers to the specific addresses that need them. It's kind of sending a constant stream of noteoffs in a midi stream to a bank of synths, which would be unnecessary while also clogging up the data buss. But I realise that dmx doesn't work like that.

Disappointing that a box as expensive as the Lanbox has such a low frame rate. Is the dmxpro (which seems to be the one that a lot of people are using) have a better frame rate? The LEDs I'm using are mid-range-ish (I think), LEDj, and yes, they're less than smooth at the low end!

The patch - I'll see if I can simplify them enough to post compressed. More shortly...

Hi David,
Thanks for responding.
Yes, each lamp has its own start address. I've just always thought it a bit crazy that I have to keep sending 0's in each message rather than just the changing numbers to the specific addresses that need them. It's kind of sending a constant stream of noteoffs in a midi stream to a bank of synths, which would be unnecessary while also clogging up the data buss. But I realise that dmx doesn't work like that.

The patch - I'll see if I can simplify them enough to post compressed. More shortly...


I'll post the sub & main patchers separately - first here's the bpatcher... save it as lightingdesigner1.maxpat

And here's the main patch, with all of the bpatchers turned into [p ] patchers (I hope)

... hmm, site won't let me post that as a compressed patch. Instead, I've attached it as a zipped file.

to keep things fast in dmx most boards only output channels (0 - last channel it has data for). As you fill up the whole universe things can start slowing down but it all depends on how your hardware operates.

"I’ve just always thought it a bit crazy that I have to keep sending 0′s in each message rather than just the changing numbers to the specific addresses that need them. It’s kind of sending a constant stream of noteoffs in a midi stream to a bank of synths, which would be unnecessary while also clogging up the data buss. But I realise that dmx doesn’t work like that."

Also, your biggest bottleneck is funnel. Check what's happening right now, if you use a print on the output. You've got some massive massive duplication of data going on, if I read this right. - the lightseq patch seems to have a bit of that going on too, so if that's the case, then it's a quadrupling of data? Have you tested this?

It might help you a lot to do a cut-down version that you can troubleshoot a lot easier. especially the lightseq patch is extremely difficult for me to troubleshoot for you.

@wetterberg > eh? You don’t need to keep sending 0s.

I may be misremembering something from when I started figuring out dmx to do with having to send a full list for every channel of all the lamps; ie dmx requires that a value is sent for each channel in every message, so with 12 lamps every tick of the clock requires a list 48 values long. Even if there are no changes taking place in a channel.

So dmx is either pairs of channel/value (which means I don't need to send unchanging values), or it's a list of values where the position in the list determines the channel (in which case I_do have to send unchanging values). I'd assumed it was the latter (for some reason I don't remember)/ But I may well be wrong!

> Also, your biggest bottleneck is funnel

The funnels are there to give each channel value the required channel number. (They're actually replacing another subpatch that, among other things, used [t i #1] [t i #2] (etc) inside an abstraction to channelise the values. )

So what am I missing here? Surely the values all need a channel number before being sent to lcudp-pack, don't they?And funnel is a fairly tidy way of doing that?

> You’ve got some massive massive duplication of data going on

Well there's certainly a _lot_ of data!. But if I look at a single stream (eg put a print on one of the outputs of one of the [p changes]) then I only see a single stream of values (and not all contiguous, so it's not a continuous line that's being output anyway, which is good!). So I'm not clear where the duplication is at that point.

Overall, the patch has one [function] per bank (1 each of r,g,b) (which can also be sent combined to each lamp, so that rather than there being 1 lamp per colour, you can get combined rgb colours on _each lamp, though that bit isn't quite working right yet), with 4 banks (and the other 2 individual floods which I removed for clarity). so in this demo version, there are up to 12 function objects spitting out values at the same time. (12 lamps with 3 channels per lamp (rgb; w is unused)

Those streams of values are routed as lists of 3 values (ie a list per lamp). Now it may well be that it would be neater to avoid using [funnel] at this point to identify the list streams and just send them out of the light seq patch as several lists (though then I _would_ potentially have lots of unnecessary zeros packed into each list - the advantage of funnel/route (I believe) is that if there's no values going into a funnel inlet (because there's a [change] eliminating the repeating zeros) there's no output from that outlet of route, therefore less processing going on.

(and why do i keep going on about repeating zeros? Because if a function line is at a constant value (generally 0) for a while, which it will be, it's still sending out a lot of repeating values every pulse of the clock that's driving the function)

Anyway, that's why the route/unpack combination before the [monitor] patch. That patch _could actually go - it's mainly there as a confidence measure to check that the sequencer bit is working. Though it's also useful to be able to wiggle the faders to check that the lights are actually working. Which would reduce the work load somewhat. I think I tried that though. but I'll double check in the morning.

> especially the lightseq patch is extremely difficult for me to troubleshoot for you.

It's basically just 4 bpatchers, which each contain 3 [function] objects (along with buttons etc to turn different functions on and off, and rescale the [functions])

The contained [functions] are stepped through by the metro 80 in lightseq (top right) (all the stuff on the right is for preset storage, so you can ignore that).

The stuff to the left is for routing the values as either 1 colour to 1 lamp, or (and this bit is broken) sending all 3 colour values to a single lamp (or 2 or 3, in that bank). But for basic use, the routing section of the lightseq patch should be set to 3_out.

Is that any clearer? I think the structure of it is fairly simple, it's just that there are multiple copies of each unit.

@wetterberg > eh? You don’t need to keep sending 0s.
I may be misremembering something from when I started figuring out dmx to do with having to send a full list for every channel of all the lamps; ie dmx requires that a value is sent for each channel in every message, so with 12 lamps every tick of the clock requires a list 48 values long. Even if there are no changes taking place in a channel.
So dmx is either pairs of channel/value (which means I don't need to send unchanging values), or it's a list of values where the position in the list determines the channel (in which case I_do have to send unchanging values). I'd assumed it was the latter (for some reason I don't remember)/ But I may well be wrong!

The funnels are there to give each channel value the required channel number. (They're actually replacing another subpatch that, among other things, used  [t i #1] [t i #2] (etc) inside an abstraction to channelise the values. )
So what am I missing here? Surely the values all need a channel number before being sent to lcudp-pack, don't they?And funnel is a fairly tidy way of doing that?

Overall, the patch has one [function] per bank (1 each of r,g,b) (which can also be sent combined to each lamp, so that rather than there being 1 lamp per colour, you can get combined rgb colours on _each lamp, though that bit isn't quite working right yet), with 4 banks (and the other 2 individual floods which I removed for clarity). so in this demo version, there are up to 12 function objects spitting out values at the same time. (12 lamps with 3 channels per lamp (rgb; w is unused)
Those streams of values  are routed as lists of 3 values (ie a list per lamp). Now it may well be that it would be neater to avoid using [funnel] at this point to identify the list streams and just send them out of the light seq patch as several lists (though then I _would_ potentially have lots of unnecessary zeros packed into each list - the advantage of funnel/route (I believe) is that if there's no values going into a funnel inlet (because there's a [change] eliminating the repeating zeros) there's no output from that outlet of route, therefore less processing going on.
(and why do i keep going on about repeating zeros? Because if a function line is at a constant value (generally 0) for a while, which it will be, it's still sending out a lot of repeating values every pulse of the clock that's driving the function)

It's basically just 4 bpatchers, which each contain 3 [function] objects (along with buttons etc to turn different functions on and off, and rescale the [functions])
The contained [functions] are stepped through by the metro 80 in lightseq (top right) (all the stuff on the right is for preset storage, so you can ignore that).

Is that any clearer? I think the structure of it is fairly simple, it's just that there are multiple copies of each unit.


Your problem is that your patch is sending single integers to lcudp-pack. Look at the help file for the external. You need to set the start channel *once*, format your data into a single list of 8-bit integers (no channel numbers included, the channel number will be determined by a values position in the list + the start channel you set), and continuously send this list to lcudp-pack. Lanbox is clever enough to continuously output DMX even if you don't update the values, so you most likely only need to send the list when a value changes.

On the subject of sending zeros: DMX is not comparable to MIDI really, it's much more like a video signal. It repeatedly sends a set of data (regardless of whether that data has changed) at a given frame-rate. The job of your patch is to collate the data you want to output via DMX into a list of values and then send this list to your output object.

For future reference, have a look at imp.dmx, it will help you out with DMX management in a patch.

http://www.theimpersonalstereo.com/software/imp-dmx/

For future reference, have a look at imp.dmx, it will help you out with DMX management in a patch.
http://www.theimpersonalstereo.com/software/imp-dmx/


I simplified the data generation bit, and am trying this out with just 3 lamps at the moment. I've taken the lists for the 3 lamps and [pack]ed them into a single list. Then it's as per the help file (see patch below).

(hmm. yet again copy compressed won't work, so I'm attaching a zipped version)

EDIT - duh! I'd disconnected the Lanbox to get back internet access to post this reply. I've got that sorted and it's working, so thanks very much for the hint.

Next I'll add back the other lamp sequencers and see if it still all works.

>For future reference, have a look at imp.dmx, it will help you out with DMX management in a patch.

I looked at your imp-dmx library when I was starting out building the lighting control part of my patch, but didn't see how it would be useful in my specific situation. If you have the time, I'd be interested to have your thoughts on if/how your objects could be used for what I'm attempting.

I simplified the data generation bit, and am trying this out with just 3 lamps at the moment. I've taken the lists for the 3 lamps and [pack]ed them into a single list. Then it's as per the help file (see patch below).
But now it doesn't work at all! 

EDIT - duh! I'd disconnected the Lanbox to get back internet access to post this reply. I've got that sorted and it's working, so thanks very much for the hint.
Next I'll add back the other lamp sequencers and see if it still all works.

EDIT 2-
>For future reference, have a look at imp.dmx, it will help you out with DMX management in a patch.
http://www.theimpersonalstereo.com/software/imp-dmx/

I looked at your imp-dmx library when I was starting out building the lighting control part of my patch, but didn't see how it would be useful in my specific situation. If you have the time, I'd be interested to have your thoughts on if/how your objects could be used for what I'm attempting.


Below is a basic example of outputting data for a number of fixtures using imp.dmx.

Thanks for that. Looks like that would save a lot of wiring

However... I changed the udpsend settings in the patch you posted to match my Lanbox

(i also modified the [pak]s & channel messages to allow for the fact that my lamps are in 4chn mode (rgbw)).

So then I turned the metro on, and tried moving a few dials, but nothing happened with my lamps. I stuck a message box on the output of lcudp-pack, and there was no FullPacket message being output.

I assume that I don't need to be sending the start channel message, as imp.dmx.read does that for me?

Just for the hell of it I tried sending a single start value (1) into the 2nd input of lcudp-pack. Which caused the object to output a FullPacket message, and then shortly afterwards sent Max into "not responding" and having to force quit.

Thanks for that. Looks like that would save a lot of wiring
However... I changed the udpsend settings in the patch you posted to match my Lanbox
[udpsend 127.168.1.77 4777]
(i also modified the [pak]s & channel messages to allow for the fact that my lamps are in 4chn mode (rgbw)).

So then I turned the metro on, and tried moving a few dials, but nothing happened with my lamps. I stuck a message box on the output of lcudp-pack, and there was no FullPacket message being output. 

I assume that I don't need to be sending the start channel message, as imp.dmx.read does that for me?
Just for the hell of it I tried sending a single start value (1) into the 2nd input of lcudp-pack. Which caused the object to output a FullPacket message, and then shortly afterwards sent Max into "not responding" and having to force quit.
Any ideas what might be wrong?


I think the lcudp-pack external is quite poorly designed. You really shouldn't have to set the start address every time you send it channel data (as their helper patch shows), as this isn't how max objects are supposed to work - all inlet values should be stored and used for the operation until a new value appears. You shouldn't even have to set the value once for the object to work, it should have an initial value.

I can't really offer much advice beyond experimenting to find a scenario where the external doesn't crash, (or alternatively contacting LanBox support).

Another option (if the LanBox supports it), you might be better off using the Art-Net externals included in imp.dmx and setting the hardware to receive Art-Net and output it via it's serial DMX ports. Not sure if this is possible though.

How many lamps SHOULD I be able to control at once over dmx?