Controlling DMXis with MIDI (Please help)

[Sionis]

After a lot of research I bought a DMXis. It just showed up today and I'm trying to set up a light show, but it isn't working the way that I need it to for my application.

I will first explain my issue, then explain WHY I need it to be done this way.

Context:

As seen in the above video, when I click a note on the Piano Roll in Logic Pro X, it will set a fader to a certain level, then reset it as soon as I take my finger off the mouse.

So, I click on Piano Roll note C#-2, it sets the fader to 63, then I take my finger off the mouse, and it resets to 0. Very simple.

The problem arises when I use a Piano Roll MIDI note to do the exact same thing. The fader will then go to whatever I set my velocity to, then stay there. I have found that this is only when the notes are too close together. The fader will then stick wherever it was set, and won't be able to be changed via MIDI until I go into the DMXis app and bring the fader back to 0 manually.


Okay now to the reason why I need this:
We are a small time band, with nobody to set our lights for us. I have figured out the things that I need to know on my own via google and youtube etc.
We play to a backing track, which transmits audio to our in ears specifically.
The backing track is also used to control our light show. We have a very basic set up of 4 Par lights in our jam space. We need to be able to make a light show at home with these 4 par lights, and have the same light show at venues that we play.

So essentially, we get the information about what light models the venue has, which channel each light is set to, then download the fixture profiles, set up the DMXis to the same channels, and drag our MIDI notes in the backing track so that our par light's "red" is the same as the venue's par light "red" etc etc.

With that being said, I obviously can't use the oscillator tool in the DMXis to control the lights. Unless I was to go through and set up presets like this:

Fader 1 - 1 Bar
Fader 1 - 2 Bars
Fader 1 - 3 Bars
Fader 2 - 1 Bar
Fader 2 - 2 Bars
etc. etc. etc.

Obviously, it would be a lot easier for me to just have MIDI notes send data to any specific fader and tell the light to go from max velocity and down and down note by note, as I have tried to do in the posted video.

If anyone knows how to fix the fader from sticking, I would be forever in your debt. This is the one roadblock that is stopping us from setting up our light show the way we would like to.

[RichG]

If I understand correctly, it sounds like you're having difficulty keeping things sync'd up while making fast changes?

If that's the case, then it's not so much a DMXIS problem, but rather a DMX protocol issue. DMX is subject to data transfer rates and sometimes it just can't keep up with what we'd like it to do. Review THIS article to see if it applies to your situation

[Sionis]

If I understand correctly, it sounds like you're having difficulty keeping things sync'd up while making fast changes?

If that's the case, then it's not so much a DMXIS problem, but rather a DMX protocol issue. DMX is subject to data transfer rates and sometimes it just can't keep up with what we'd like it to do. Review THIS article to see if it applies to your situation

No, not quite. As seen in the video posted, the changes aren't fast by any means. The problem lies within the DMXis software.

[NCN]

Note ON sets the fader to the value of the velocity. Note OFF resets it back to zero. You must be missing the Note OFF.

[Book]

Hi Sionis!
I agree with NCN.
I just tried what you want to do with Cubase and it works.
Looking at your video you have a continuous red bar which means a continuous note on! Its no wonder that the fader doesn't want to return to zero! As soon as you have a midi off the fader will return to zero.
Hope this helps!
regards Book.

P.S. As you may have seen the velocity value of the midi note determines the value on the fader.
Maybe you or someone else in the forum would know this, is there a CC value that we could draw in the DAW (as with CC1) to control the fader value continuously over time?

[NCN]

In regards to CC ... that is what I use to control faders, a CC number and a CC value. But since I don't use a DAW I've never tried what you suggest but I'm betting it would work.

[Sionis]

Hi Sionis!
I agree with NCN.
I just tried what you want to do with Cubase and it works.
Looking at your video you have a continuous red bar which means a continuous note on! Its no wonder that the fader doesn't want to return to zero! As soon as you have a midi off the fader will return to zero.
Hope this helps!
regards Book.

P.S. As you may have seen the velocity value of the midi note determines the value on the fader.
Maybe you or someone else in the forum would know this, is there a CC value that we could draw in the DAW (as with CC1) to control the fader value continuously over time?

For context, the 4 constant "red" bars are to set the master dimmer to max for the par lights. These work fine.

The issue is in the descending note velocity located on C#-2.
These notes are supposed to set the fader from max to min giving it an oscilation effect. However, after the first note, Fader #2 (which corresponds with the descending notes) just gets stuck at 100. I have to go in and manually reset it to 0 for it to receive any more midi information.

[Sionis]

Note ON sets the fader to the value of the velocity. Note OFF resets it back to zero. You must be missing the Note OFF.

I am trying to control the faders entirely with MIDI notes in logic. They are supposed to reset back to 0 when there is no MIDI information being received.

[NCN]

See this post I made a long time ago: viewtopic.php?f=2&t=2043&p=7530#p7530
I think there is a follow-on post right after it that adds more clarity. I think it boils down to each additional note ON, and it's associated velocity, just tries to set the fader higher.

Bottom line: you need the note off. I'm not sure what you mean by "reset back to zero when no info received".

It's been a very long time since I delved into this stuff ... so it's not outside of reason I've missed something.

[NCN]

So I verified this behavior as stated above ... but with the big problem of I have no idea how to make the fader go DOWN using Note ON/OFF. It only seems to go up. If you start at zero and then use Note ON/OFF then all is well as the fader drops back to zero when the note OFF is received. However, if there are intervening Note ON's with no corresponding Note OFF's, then you can't get lower than the Note ON that bumped the fader to its present value.

[Sionis]

So I verified this behavior as stated above ... but with the big problem of I have no idea how to make the fader go DOWN using Note ON/OFF. It only seems to go up. If you start at zero and then use Note ON/OFF then all is well as the fader drops back to zero when the note OFF is received. However, if there are intervening Note ON's with no corresponding Note OFF's, then you can't get lower than the Note ON that bumped the fader to its present value.

Exactly and that is the issue! I've contacted the developer to see if he can help out.

[NCN]

Since the preferred method is to use CC to control faders but yet you want to use notes, you might use Bome's MiDi translator to convert the notes into CC's and "swallow" (to use their terminology) the note OFF messages. Since DMXIS can handle multiple parallel MiDI inputs, the translator could be one of them.

This may not be the easiest program to configure (BTW both Win and Mac) but it is very powerful. It is likely that a fairly simple translation stage will do ... but it may be a bit of a challenge to configure it!

[NCN]

Well, I did it ... took 10 minutes (maybe). I translated the velocity of a given note to the CC value of a fader controlled by a CC ... plus killed off the Note OFF. Just two translation stages. You repeatedly change the note velocity and hit the note and the required fader level is set in DMXIS.

In summary, you have to have DMXIS "learn" the CC number you are going to use to control the fader. Then, in Bome's you create two translation presets, one that accepts Note ON for a particular note and stores the velocity value in a variable, "swallows" the Note On, and finally sends a CC with the variable value as the CC value to DMXIS. A second translation stage does nothing but accepts the Note OFF and "swallows" it, outputting nothing.

You have to configure DMXIS to accept the virtual MIDI output port form BOME's to be an input. Then of course you have to set your note-producing software to send MIDI to a BOME's input port. Finally, in BOME's you link the input to the output.

If there was some rhyme or reason to your choice of notes and CC numbers, you might be able to generalize it all into one translation stage... otherwise you'll need a unique stage for each Note-to-CC mapping.

[NCN]

Perhaps more convenient, I managed to set up a translator that uses successive groups of 9 notes to control a successive list of faders on 2 or more CC's. In other words, notes 1-9 controls a fader in 9 levels 0 to 127, the next 9 notes controls the next fader (next in "CC" number), and so on.

[Sionis]

Perhaps more convenient, I managed to set up a translator that uses successive groups of 9 notes to control a successive list of faders on 2 or more CC's. In other words, notes 1-9 controls a fader in 9 levels 0 to 127, the next 9 notes controls the next fader (next in "CC" number), and so on.

It sounds like youve figured it out!!! I'm gonna have to try it out when I get home but unfortunately that won't be for 6 days

[NCN]

OK, I have generalized the code for different numbers of notes, etc. to control the CC's. I could send you the Bome project file. Note what I have done is assigned "n" consecutive notes to control one fader in "n" steps from 0 to full on. You just punch the note to get the fader to the level you want.

The next consecutive "n" notes controls the next fader, and so on.

The faders are controlled by CC's on (by default) channel 1. You can either map the keyboard note groups to "m" consecutive CC's or (if you choose in the code) map them to any old CC.

Multiple instances of this preset could be used if you wanted some faders to be controlled by, say, 9 notes and others by 2.

But the advantage, if you want to use notes to control faders, is that the faders end up being controlled by the preferred CC method. Of course, anything that can be controlled by CC in DMXIS could also be used...

[NCN]

I also made a translator that does what you initially wanted: control up to 4 faders using the velocity value as the fader level (1 to 127 velocity = 0 to 100 fader). Due to some strange limitation in the translator, you can't use velocity=0 so I pretend that velocity=1 is in fact fader fully off. Again, the faders are controlled directly by CC#'s not note numbers. So this translates notes to CC's.

Edit: I have since learned that per standard Note On w/velocity 0 is the same as Note Off. It has to do with the so-called "running status" that compresses the MIDI data stream by not sending a Note On for each note, just the Note-velocity pairs. So theoretically I could code this all "perfectly" by capturing the Note Off and dropping the fader to 0 but I have the feeling that is not the action you want...namely you want the fader to stay at the level the Note On velocity gave (even after releasing the key) until the key is pressed again giving a new velocity and therefore a new fader position.

[Sionis]

I also made a translator that does what you initially wanted: control up to 4 faders using the velocity value as the fader level (1 to 127 velocity = 0 to 100 fader). Due to some strange limitation in the translator, you can't use velocity=0 so I pretend that velocity=1 is in fact fader fully off. Again, the faders are controlled directly by CC#'s not note numbers. So this translates notes to CC's.

Edit: I have since learned that per standard Note On w/velocity 0 is the same as Note Off. It has to do with the so-called "running status" that compresses the MIDI data stream by not sending a Note On for each note, just the Note-velocity pairs. So theoretically I could code this all "perfectly" by capturing the Note Off and dropping the fader to 0 but I have the feeling that is not the action you want...namely you want the fader to stay at the level the Note On velocity gave (even after releasing the key) until the key is pressed again giving a new velocity and therefore a new fader position.

You lost me on this one... I can already control fader levels using the velocity of the MIDI notes in Logic Pro X. The issue is being able to use ascending or descending MIDI notes in sequence. If you put two MIDI notes side by side with each other, the fader gets stuck. I did find a little bit of a work around. If I put just enough space in between each notes, the fader does not get stuck, and will descend. But, I need to see how this actually works with my lights when I get home.

In the end though, this is most definitely a bug and should be patched by the developers.

[NCN]

Yes, it looks like I solved a different problem, but I did have a certain amount of fun doing it!

So it appears you are content with the momentary state of the fader going from zero to a set value and then back to zero for only as long as the note is pressed. Then on to the next fader change from zero up and back with the next note. You discovered with enough dead time between these notes, everything is OK.

I, on the other hand, am using the velocity to set a fader value and then release the key, leaving the fader at that value while I deal with another fader via a different note. Later, I can change the level of the first fader as I wish with a new velocity. In my case, multiple faders can be a various set states at any time and can be manipulated by different note/velocities independently.

You will, however, run into one problem (unless Dave wishes to change fader behavior). And that is for your solution to work the faders MUST start at zero...because with the straight velocity method a fader never goes lower than its initial state. Only the CC method deals with absolute positions; the velocity method deals with relative positions.

I'm not sure Dave has officially acknowledged that this behavior of the program was intentional, rather than just an interesting side effect of something else. It is not unusual that complex programs have unique nooks and crannies that can be exploited; many of mine had those and I've taken advantage of crazy behaviors and others: but those doors can close abruptly and you can't really complain when they do.

[Book]

Wow NCN you really have spent time on Sionis’s problem! Glad to see you also have fun problem solving. I must say Sionis I can’t really understand why you want to control the fader value with a midi note velocity but if NCN’s workaround works for you that’s fine. For a stable control of the fader is, as NCN mentioned, a CC value.
I would like to show you a method I use with CC.
Here a link to a short video I made for you https://youtu.be/kvV9oTWCFRc .
I use the dmxis ‘standard’ midi channels 15 and 16 for controlling the banks and presets, using the drum editor for placing the notes and naming them. I use midi channel 14 for controlling directly the faders. I’m using Cubase but it’s the same principle in logic.
In the video I draw two curves in the CC editor for CC102 and CC103. I added the midi monitor to show the values. I didn’t use the learn function from dmxis but hardwired the CC controls to fader1 and fader2 by editing directly the xml file (dmxConfig) that holds the fixture information, paths and the midi settings per fader. In the demo under the dmxis window at the bottom you can see the first 5 faders from this file. ‘Pram name’ is the fader number, ‘channel’ I set to 14, and ‘value’ when positive is a CC value and when negative a midi note value. I set the first four faders to CC102-105 for this demo.
As you can see one has accurate control when timing the lights to the music. Maybe this will help in someway.
Note: the bank changes are because I forgot to turn off the bank midi channel before recording the clip.

[NCN]

... got "Video is Private" so it didn't play.

[Sionis]

Wow NCN you really have spent time on Sionis’s problem! Glad to see you also have fun problem solving. I must say Sionis I can’t really understand why you want to control the fader value with a midi note velocity but if NCN’s workaround works for you that’s fine. For a stable control of the fader is, as NCN mentioned, a CC value.
I would like to show you a method I use with CC.
Here a link to a short video I made for you https://youtu.be/kvV9oTWCFRc .
I use the dmxis ‘standard’ midi channels 15 and 16 for controlling the banks and presets, using the drum editor for placing the notes and naming them. I use midi channel 14 for controlling directly the faders. I’m using Cubase but it’s the same principle in logic.
In the video I draw two curves in the CC editor for CC102 and CC103. I added the midi monitor to show the values. I didn’t use the learn function from dmxis but hardwired the CC controls to fader1 and fader2 by editing directly the xml file (dmxConfig) that holds the fixture information, paths and the midi settings per fader. In the demo under the dmxis window at the bottom you can see the first 5 faders from this file. ‘Pram name’ is the fader number, ‘channel’ I set to 14, and ‘value’ when positive is a CC value and when negative a midi note value. I set the first four faders to CC102-105 for this demo.
As you can see one has accurate control when timing the lights to the music. Maybe this will help in someway.
Note: the bank changes are because I forgot to turn off the bank midi channel before recording the clip.

Again, the issue is not that I cannot control the DMXis Faders with MIDI notes. The DMXis Faders receive MIDI information, including velocity (which corresponds with the level of the DMXis Fader) fine.

The issue comes when you try to use MIDI notes to move the Faders up and down in an "Oscillation" motion.

The Faders then receive MIDI information for the first note, then hit the second note and just get stuck. They then lose the ability to receive any information, until you manually go in and reset them.

See the video below

[Sionis]

Yes, it looks like I solved a different problem, but I did have a certain amount of fun doing it!

So it appears you are content with the momentary state of the fader going from zero to a set value and then back to zero for only as long as the note is pressed. Then on to the next fader change from zero up and back with the next note. You discovered with enough dead time between these notes, everything is OK.

I, on the other hand, am using the velocity to set a fader value and then release the key, leaving the fader at that value while I deal with another fader via a different note. Later, I can change the level of the first fader as I wish with a new velocity. In my case, multiple faders can be a various set states at any time and can be manipulated by different note/velocities independently.

You will, however, run into one problem (unless Dave wishes to change fader behavior). And that is for your solution to work the faders MUST start at zero...because with the straight velocity method a fader never goes lower than its initial state. Only the CC method deals with absolute positions; the velocity method deals with relative positions.

I'm not sure Dave has officially acknowledged that this behavior of the program was intentional, rather than just an interesting side effect of something else. It is not unusual that complex programs have unique nooks and crannies that can be exploited; many of mine had those and I've taken advantage of crazy behaviors and others: but those doors can close abruptly and you can't really complain when they do.

I really do appreciate it though NCN! I hope I get a response from Dave soon.

Thank you for the information as well. I'm hoping there is maybe something I can change in the config files to allow me to perform this function, or it's going to make my method a lot more time consuming and complicated.

[Book]

Whoops! Sorry! the video is now public!
Thanks for taking time to do a new video. Yes one can see that the length of the delay between notes is critical. It will be interesting to see if Dave can tighten the response before the next note is triggered.

[NCN]

Well, Book, that certainly is a cool way to drive DMXIS ... I don't have the software for that!

As to the original problem, you could be up against a couple of things. First of all, the timing cycle inside DMXIS isn't "real time" so much as it's driven off the audio source in some way I don't understand. That limits the basic time between events.

Secondly, without looking directly at the MIDI stream being delivered to DMXIS by your DAW, there's no telling if something odd is going on there. Perhaps because of the speed it's optimizing the stream by changing to the "running status" mode for delivering notes. I can see where that could be a real problem due to no Note Off messages.

I'm not sure about the exact effect you are looking for and why it can't be achieved by using the oscillators and perhaps programmatically adjusting the oscillator controls ... they are available via CC#'s, too. Perhaps Dave MIGHT be willing to mess with this ... but since he has other really big fish to fry and I don't think adjusting faders by velocity was ever an advertised feature of the program, you should look for other solutions. To me, if nothing is changed inside DMXIS and somehow you managed to get it to work, you'll never know if something is going to go slightly awry during performance and stick the faders.

Also, looking at your original problem again, I'm not understanding why you can't use the channel remapping feature to conform your virtual light configuration to the venue's. Even if the fixtures aren't exactly the same there is generally enough similarity you would think remapping might work.

[Sionis]

Well, Book, that certainly is a cool way to drive DMXIS ... I don't have the software for that!

As to the original problem, you could be up against a couple of things. First of all, the timing cycle inside DMXIS isn't "real time" so much as it's driven off the audio source in some way I don't understand. That limits the basic time between events.

Secondly, without looking directly at the MIDI stream being delivered to DMXIS by your DAW, there's no telling if something odd is going on there. Perhaps because of the speed it's optimizing the stream by changing to the "running status" mode for delivering notes. I can see where that could be a real problem due to no Note Off messages.

I'm not sure about the exact effect you are looking for and why it can't be achieved by using the oscillators and perhaps programmatically adjusting the oscillator controls ... they are available via CC#'s, too. Perhaps Dave MIGHT be willing to mess with this ... but since he has other really big fish to fry and I don't think adjusting faders by velocity was ever an advertised feature of the program, you should look for other solutions. To me, if nothing is changed inside DMXIS and somehow you managed to get it to work, you'll never know if something is going to go slightly awry during performance and stick the faders.

Also, looking at your original problem again, I'm not understanding why you can't use the channel remapping feature to conform your virtual light configuration to the venue's. Even if the fixtures aren't exactly the same there is generally enough similarity you would think remapping might work.

I'll try to explain it a little better... I'm finding this really hard to explain to people.

I'm the guitar player in my band. I also do the songwriting, mixing, and lighting stuff. I'm by no means a professional when it comes to light shows, and it is by no means my primary job in the band.


We currently have a set up which utilizes 4 Par lights.

The Par Lights, for the sake of simplicity, let's say they have 4 Fader controls:
1: Master Dimmer
2: Red
3: Green
4: Blue

Our light show is programmed using a channel in our backing track, which is a Software Instrument set to use DMXis as the plugin.
The backing track itself is simply; a Logic Pro X project with all of our synths and Bass track, as well as a click track for our in-ears.

Let's say our Par Lights are set to:
Far Left - DMX Channel 1-4
Middle Left - DMX Channel 5-8
Middle Right - DMX Channel 9-12
Far Right - DMX Channel 13-16

Now, we are going to play a venue which has a large selection of lights, using up 48 DMX Channels.
We have contacted the venue, gotten the DMX Channels and brand of lights.

For this example, we will say that DMX channels 1-24 are used by lights that are not simple Par Lights.
Channel 25-27 is used up by a simple RGB Par Light with no master dimmer. It is located on the left side of the stage.
Channel 34-36 is used up by another simple RGB Par Light, located on the right side of the stage.

To convert our light show to the Venue's lighting, all we would have to do is simply;
Download the venue's light's fixture profiles.
Create a duplicate of the original DMXis Software Instrument track, and mute the original.
Press the Piano Roll note that corresponds with the "Red" channel of our (Far Left) Par light.
Drag it to the channel that is occupied by the venue's "Red" channel of the venue's (Left) Par light.
In this example, we would be dragging the notes that activate our "Channel 1 Fader" to the notes that occupy "Channel 25 Fader"

We repeat this process, which would take about 2-5 minutes to complete, for the rest of the lights. Viola! Our light show is now going to be displayed the same way at the venue.

I hope you can see why the Oscillating tool would be an issue in this case. It would no longer be a matter of simply drag and match. It now means I would have to re program each Oscillator macro to line up with the Venue's house lights, for every single venue we play, forever. A process that would take much more than 2-5 minutes.

Maybe you can suggest another way to do this so quickly that would work the same?

[NCN]

I still don't see why you couldn't, to use your example, use Patch Channel: (I added // comments that aren't legal in the actual table)

2/4:25 // Connect Far left RGB-only to house 25-27
14/16:34 // Connect Far Right RGB-only to house 34-36

(I think you misstated your first par example since in you write up you're connecting the dimmer of your par (ch1) to the red channel of the house light... maybe that makes some sense but what about G and B?)

So there's two of the lights. Obviously there may be situations where mapping to recalcitrant configurations isn't going to work.

I'm also led to understand that it is not unusual for a band to introduce a MIDI translator stage into the mix... so you could give up the unnecessarily fragile note/velocity method. Or better yet, the oscillators would now be a player.

[Sionis]

I still don't see why you couldn't, to use your example, use Patch Channel: (I added // comments that aren't legal in the actual table)

2/4:25 // Connect Far left RGB-only to house 25-27
14/16:34 // Connect Far Right RGB-only to house 34-36

(I think you misstated your first par example since in you write up you're connecting the dimmer of your par (ch1) to the red channel of the house light... maybe that makes some sense but what about G and B?)

So there's two of the lights. Obviously there may be situations where mapping to recalcitrant configurations isn't going to work.

I'm also led to understand that it is not unusual for a band to introduce a MIDI translator stage into the mix... so you could give up the unnecessarily fragile note/velocity method. Or better yet, the oscillators would now be a player.

Yes, there's no doubt that the configuration that I stated, and that you stated as well would work, if it weren't for the Faders getting stuck. That issue still remains.

[cgrafx]

Your suffering from the I have a hammer and everything has to be a nail syndrome. You are attempting to use DMXIS as a DMX translator for Logic, rather than what it was designed for. Meaning your stuck thinking you can control your lights directly in Logic rather than using logic to trigger lighting cues.

Now for the base reality of working across different venues.

1. You will NEVER be able to swap dis-similar lights across shows. ALL lighting will have to be designed around RGB control or your lights or it will NEVER work across venues.

2. Stop trying to control faders in DMXIS. Set up lighting CUEs using the program features in DMXIS and use MIDI commands in Logic to switch programs.

3. Use the Channel patching features of DMXIS to change the lighting assignments for each venue, bearing in mind that you have to program your show assuming every light is configured as RGB+Dimmer with the Dimmer channel always set to full on.

This way if the light has a dimmer channel there will be something driving it, and if it doesn't then it won't get patched and it won't matter.

So in a very basic configuration you will have four lights in DMXIS all programmed as if they are RGB+D. You will then patch those RGB or RGB+D channels to the appropriate house light channels.

Logic will then call the programs in DMXIS to make lighting cue changes.

[NCN]

Thank you cgrafx, you took the words right out of my mouth (including the allusion). I did not want to sound harsh in reply to the OP's last post, but OP here now is the voice of experience. Dave MIGHT do something about Note/velocity ... but I can't see why and it's likely to remain fragile. He'd probably recommend ShowBuddy as the answer, anyway.

In fact, I would double-down on Dave not doing anything about this unless it was a documented feature of the program (which I don't see). He's been remarkably resistant to adding a long list of new "features" to the program ... and I can greatly admire this being a former mainframe systems programmer myself. "Feature-itous" is a particularly deadly programming disease!

So you need to find another way.