Apologies if this is all a bit confused - I may be a bit out of my depth here…
So, I’m evaluating B4M to see if I can use it as an imp.artnet replacement for my fairly simple setup with 14 4-chan LED lights. My max patch uses movement and touch sensors to play music while at the same time either controlling individual R/G/B values per lamp, or colour changes to individual lamps.
I’m testing it out using an Enttec USB DMX Pro, rather than my usual ODE mk3.
I’ve got 2 lamps set up for the test, using the RGBW profiles, set to ch1 and ch5; universe 1.
I’ve got the tag set to Sidebeams.
(not sure if images will upload)
Poking around in the Help files, I’ve figured out that this is the way to send messages to the lamps (or am I wrong? - I couldn’t find a particularly clear explanation of available messages).
That’s 4 float number boxes into
4 message boxes - [blue $1] [green $1] [red $1] [dim $1]. Into
[beam.tag Sidebeams] into
[beam.ouput]
Looking in the Monitor Window, scrolling eg the red value up and down cause changes in values in all 4 channels on every light. What I’m expecting is that scrolling the value for each colour will change only that colour! (Then the next problem will be doing that per lamp rather than all lamps).
My ignorance may just be too great to sort this! But I’d hope that setting up to control a small rig would be pretty simple.
[edit] if I want to address each individual light separately (ie sending different varying RGB values to each lamp) do I need to use a different tag for each lamp?
… well the answer to that is yes, though I don’t know if that’s the best way to do it? Scrolling eg the red value is still causing the other colour values to change. It’s almost as if there’s some kind of relative change going on. Is there a setting somewhere that would do that?
Hmm. A degree of finger trouble. I’m using some older LED lights out for the testing, and they are either 3 or 5 channel, not the 4ch lights i currently use. So I switched to the RGB profile, and now I have individual direct control of the colours, and the [dim] messagge still seems to work as an overall “level” fader, even though it doesn’t show as outputting on ch4 in the Monitor. Ie the test patch above now does what I expected.
I’ve still got a different tag for each lamp. Is that the best way to do this?
Looking in the Setting up/Fixture Profiles tab at the Profiles for RGB & RGBW, there doesn’t seem to be any difference apart from the number of addresses. Though if I look at the actual files I can see that the RGB file has “fallback” and “mergeMode” parameters which the RGBW one doesn’t. Is that something to do with why I was getting changing values in each colour output (in Monitor) when scrolling a single number box???
And if I look in the .json file, with the RGB profiles loaded, I can see
Ranges - lower 255, name pan , upper 205
What does that signify?
hi, i just went through all this and while the moderators could definitely fill you in more than I, it looks like you need to make your own custom tag for your fixtures, i.e. replace “Sidebeams” in beam.tag with “mytest” or whatever. Then make sure in the fixture editor that you’ve entered that same tag name for the fixtures you want to speak to.
Hi,
yes, i think so. I replaced the Sidebeams tag in the first few items in the Fixture list, and that got it working. Though I had to give a different tag to each individual lamp as I want to address them separately, and as that seemed to be the only way to do it - ie none of the lamps are part of a group which responds similarly to a single instruction; I need each light to be separately addressable by the data stream in my max patch. So the first light is tagged lamp1, the 2nd lamp2, and (eventually) so on.
I’m used to sending a dmx list of 56 values (14 lights, 4 channels) at once and letting the lights sort it out!
Using a tag for each light individually is one way to do it but it can become cumbersome if you have a large amount of lights. Another solution is to send [beam.tag] a list of values. This distributes the values over the lights within the same tag. For example, red 0.1 0.5 1.0 0.75 will control the red of all your 14 lights in 4 groups. If you send a list of 14 values, it’ll control each light individually.
[beam.tag]'s help file has a tab called multiple values that has an example of how that works.
This has been a very powerful and flexible workflow for us. If you’re mostly working with color, [beam.matrix] might also be of interest. That object lets you control Beam signals with Jitter matrices, so you can pixel map the output of Jitter objects to the color of your lights.
And if you prefer sending raw DMX lists - check out [beam.dmxio]. You can use it without specifying profiles and tags.
And to touch on your questions about the profile and patch files:
Looking in the Setting up/Fixture Profiles tab at the Profiles for RGB & RGBW, there doesn’t seem to be any difference apart from the number of addresses. Though if I look at the actual files I can see that the RGB file has “fallback” and “mergeMode” parameters which the RGBW one doesn’t. Is that something to do with why I was getting changing values in each colour output (in Monitor) when scrolling a single number box???
I don’t think these parameters make a difference in your situation.
“Fallback” is relevant for cases where a Beam signal stops controlling a specific light. For example because the tag changes or a patch coord was disconnected. pan and tilt are often set to last which means their values stay on the last value instead of returning to their default.
Merge Mode defines how two Beam signals are added together. For example when two patch coords are connected to the same inlet. We have some information about that here: Beam | Merge Modes
And if I look in the .json file, with the RGB profiles loaded, I can see
Ranges - lower 255, name pan , upper 205
What does that signify?
Ranges allow you to control how the Beam signal translates to DMX. In the example you gave, the signal range of [0...1] turns into [255...205] in DMX values. This can be useful if your lighting rig changes and you don’t want to make changes to your patch. We have some information on this in our Beam manual: Beam | Ranges
Yes, I thought individual tags might become cumbersome .And I can see how I can use
[red $1 $2 $3 $4] [green $1 $2 $3 $4] [blue $1 $2 $3 $4] [dim $1 $2 $3 $4] to control the lights. I guess I’d have to put the LED pairs that are single colour (red or green or blue ) into one group, and maybe the multicoloured lights into either another group, or 4 separate groups (I haven’t thought that far yet).
I’m thinking, though, that won’t easily fit into the existing way I’m handling the lights, so I’ll take a closer look at [beam.dmxio] next. (Seems a pity to just use Beam for that though! I don’t suppose you’ve considered selling a basic Max object to handle dmx out without all of the bells and whistles? Sort of a replacement for art.impnet.controller? That would make things much easier for me going forward (ie with future installations in schools, and upgrading past ones, most of which use Enttec ODE).
Here’s a couple of images to illustrate my existing system. Generally, Sensor 1 is red (2 lights in group 1), 2 green (2 lights in group 2…etc), 3 blue, 4 red/green. But that can be changed in the patch, both which sensor controls which lights, and what colour it controls the brightness of. The third light in each group is usually controlled by one of the touch or pressure sensors, where each note is mapped to a different primary or secondary colour. Again, each input can be routed to any of the lights.
Ok, so this is the way to do it with direct out? I need to send the changing values via a [dict] to get them formatted correctly for [beam.dmxio]? (There are only 2 3-channel lights in my testing setup)
(Deleted this image so that I can add a more complete one below. At his point it’s just the left hand side of the patch, with beam.dmxio output))
(This is working; I’m just wondering if this is the best/correct way)
I’ve figured out controlling the colour of a light using beam.matrix now. And added that into the patch above, with beam.matrix also connected directly to beam.output, and the beam.tag on the left input of beam.matrix set to tag lamp3. So it’s a mix of direct output and tagged output. Is that the right way?
Ha! No, that doesn’t work (I tried direct output with only 4 values (for lamp1) and setting the tag on the beam.matrix to lamp 2. So mixing beam.dmxio with other beam object outputs deosn’t work?
I thought about beam.join, but isn’t that for tagged outputs?
… but I can stick with the dmxio method, as I can use the swatch controlled via the hsl message to send values for the third (multicolour) lamp.
Note that [beam.dmxio] does not need a [beam.output]. The values from [beam.dmxio] are applied after all other processing so it overrides the whatever [beam.output] receives.
Creating a rough example of what a patch for your setup could look like, here’s an example of using jit.matrix’s setcell message to set the individual pixels of a 14x1 matrix. [beam.matrix] then reads the matrix and will use one pixel for every light. I’m using a swatch object to choose the color for the pixel and a “sensor 1” float value to scale the brightness of pixel 1 and 2, while each pixel can still have a separate color. You’ll have to duplicate some parts of the patch a few times, but encapsulation or other patching tricks can probably make it nicer.
I also added a [beam.op] object before [beam.output] as an example of how you can then still add “post processing” that applies to all lights. In this case, clicking the toggle would turn all lights off, as a sort of “blackout” function. The benefit of using [beam.op] is that you don’t need to add that functionality somewhere else in your patch.
As for your last comment: [beam.join] is indeed for merging signals, so that won’t work with [beam.dmxio]. Unfortunately, I don’t think we currently have a good way to mix [beam.output] and [beam.dmxio] when controlling lights in the same universe. This is something we can probably improve. Curious if @Luka has any thoughts about this.
Fantastic. Thanks for the patient help on this, especially dict, which I’m not very familiar with as I never found a use for it in the ways I work.
The (video? Image?) of the example patch at the bottom just displays a rototating busy cursor when I click on it???
You’re very welcome! Dict can indeed feel a bit uncomfortable if you’re more used to lists, but it can be really powerful and has seen some improvements. For [beam.dmxio] we decided to use dict since it allows you to control multiple universes in one go. [beam.sig] also uses dict and now I think of it, can also be an option for your setup. I’ll try to come up with an example.
Here’s a screenshot of the video I posted in my previous message. Hopefully the video will suddenly start working in a bit…
Cool. Thanks for that. About to prep supper, so I’ll try that later or tomorrow. And I think I’ll go ahead and purchase Beam, and then later sort out how I go about getting additional licenses for educational installations (which I’ll need to do if I’m going to incorporate Beam into this particular patcher).
Here’s an example of using [beam.sig]. This might actually be an interesting approach for you. [beam.sig] can turn dictionaries into Beam signals, and from that moment on you can use all other Beam objects ([beam.join], [beam.matrix], etc) with it. You can use Max’s dict objects to create the dictionary in the format you need (or you can even use the JavaScript object if you’re into that!)
In this screenshot, I’m creating a dictionary with the keys one and two, and each containing red, green, and blue values. [beam.sig] turns this into a signal that we can connect to [beam.output] and the monitor shows the DMX values sent out of Beam.
The big trick I did to make this work is had to edit the fixture patch a bit. Normally, each light gets an internal id assigned which you then use in [beam.sig] so that Beam can apply the values to the correct light. By editing the fixture patch .json manually, we can set this id ourselves and give the lights more readable names, like one and `two.
In this screenshot you can see part of the fixture patch. I added an "id" key and the value I set there is the one I used in the dictionary for [beam.sig].
Let us know if we can help you further! We’re happy to sort out the additional licenses. For that it’s best to write to firstcontact@showsync.com.
Being still in an early bird release right now, it’s also very helpful for us to have these insights in how you’re trying to use Beam in your existing patches. This will help us identify missing features or find out where we can improve our documentation. Many thanks for trying out the software and being so involved!
Thanks again. Here’s a page showing a few images of the system I install. This is the older version (which I probably won’t update to Beam) using infrared sensors. I’ve changed my workshop system and the last school installation to use low powered lasers, which are _much more precise to play.
So, something like this? (You obvs won’t get any output unless I also send you the fixture json, which I can do if you like). This is just the beginning - when a touchboard is routed to a specific light, it needs to mute and zero any previous settings from a ToF sensor sent to that lamp (and vice versa), otherwise those values remain active. But that’ll all be in earlier parts of the patch.
What a beautiful project, David! Thanks a lot for sharing!
I have some trouble getting your patch into Max. It looks like Max doesn’t recognize the data as a compressed patch. Maybe our forum corrupts the text in some way. Could you share the .maxpat instead?
.And I can see how I can use
