This question was at the end of a long thread, so may have been missed…
By the way, I’ve been meaning to ask… in my existing patch I’ve made a crude, by eye, attempt to match 0-255 intensity values from the software to perceived intensity of individual r,g,b colour from the lamps using a hand drawn [table]. I’m trying to smooth out the light intensity as a hand is moved towards a sensor. without mapping, as values start to increase nothing much seems to happen, then there’s a rapid increase to full intensity about 2/3 through the movement range, then nothing much over the last third. And of course, the perceptual changes are different for red, green and blue (i haven’t tried to compensate for each colour individually).
The question is - does Beam do any kind of mapping so that a linear control signal produces a (fairly) linear increase or decrease of perceived lighting intensity?
Thanks
Hi David, sorry for missing the question in the other thread.
Beam’s modulation values between 0. and 1. map linearly to DMX values 0 to 255.
A situation where that may not be fully the case is when specifying color channels as transforms (rather than modulations) in a fixture profile.
When using the "rgb" : "*_normalized", the RGB color values are normalized, useful if you only want to scale the intensity with the Dimmer channel, but keep the color channels at their maximum values.
If you use the rgbw transform, RGB > RGBW conversion is performed, or when you use cmyk RGB > CMYK.
What fixture profiles are you using?
If it’s some that you made yourself, could you please share them?
Also, an isolated Max patch where you noticed a non-linear behavior, along with a Beam patch, would be helpful.
Analogously - a linear fader movement in audio doesn’t translate to a linear increase in loudness over ‘speakers. So you start a fade up quite quickly and then slow down as you approach 0. (Logarithmic? I used to know this stuff!). So there’s [ease~] in Max to turn a linear fader movement into a smooth audible increase in loudness.
So (and this may be a half understanding on my part), the eye also responds to r, g & b non-linearly. So a linear increase in values from 0-255 doesn’t produce a smooth increase in intensity of preceived colour from a lamp.Just looking at a lamp while increasing the intensity values, it seems that there’s only a slight increase in intensity for the first 1/4 (ish) of the value range, then a noticeable increaser in brightness util about 3/4 of the way up, and then nothing much seems to change for the last part of the range. Am I making sense?
What I’ve done in my main Max patch is to use [table] with a hand drawn curve to try and smooth this out - so there’s a fairly rapid increase in output values from the [table] for the first 1/4 of the range, then a slightly less than linear increase for the next part of the input range, and then a rapid curve up to full in the last 1/8 of the range.
What this means is that as someone’s hand moves towards a sensor, there’s a fairy smooth and noticeable increase in brightness from the start to the end of the movement range. If I _don’t use the mapping [table], at the start of a movement there doesn’t seem to be much increase in brightness, then there’s a noticeable increase, and then nothing much seems to happen towards the end of the movement.
So I was just wondering if the mapping between dmx values and perceived brightness from the lamps was being handled in Beam. Perhaps that is what you’re describing with specifying channels as transforms?
At the moment I’m using the RGB profile with some older lamps (ledj Slimline 1T100 (3 or 5 channel)), but the lamps I use for workshops and installations ( BriteQ 100W COB LED Par Can) I use in 4 channel mode, so I will be using RGBW ultimately as a different part of my patch fades colour mixes up and down rather than single colours.
I’m running a workshop next week, so I’ll have some time at the end of day to try out the version of my patch that I’ve added Beam to.
Which brings up another quick question - I’ve been testing Beam out with a DMX USB Pro, but next week it’ll be the ODE Mk3. I haven’t tried that yet as it’s buried in a storage box. Do I need to use one of the Help patches to get Beam to recognise that interface or can I do it from inside my lighting patch?
I now better understand what you are referring to. The non-linear relation between the intensity values and the perceived brightness is very common with LEDs. As dimming curves vary greatly from fixture to fixture, there isn’t really a way to adjust for this in a way that would apply to all the fixtures out there, at least not without some sort of fixture-specific dimming curve data.
Beam for Max also doesn’t currently have a way to apply curves to modulations/attributes on a fixture patch or fixture profile basis.
So your solution using table sounds like a good one!
Which brings up another quick question - I’ve been testing Beam out with a DMX USB Pro, but next week it’ll be the ODE Mk3. I haven’t tried that yet as it’s buried in a storage box. Do I need to use one of the Help patches to get Beam to recognise that interface or can I do it from inside my lighting patch?
You can get a dictionary with the available devices by sending get_io_devices to beam.core. You can then use this data to set the I/O configuration, using set_io to beam.core.
E.g, if the get_io_devices returns:
…the set_io-prepended dict to set I/O configuration to send Beam’s universe 1 to the DMX USB Pro device would look like this (the device object from above + sourceUniverse and targetUniverse keys):
As you have probably discovered, you can also use Beam for Max’s I/O Editor to achieve this (which is itself an abstraction that can also be added to a Max patch as beam.ioeditor).
Please let us know if you have other questions about this.