Explain LED lights animations

[RadekPilich]

Can you please explain LED lights animations to me? 

Where can I see the effect?

If I try to set them as activity / note monitor, I don't see any change.

[RadekPilich]

Oh, found it in the cheat sheet

"Use SHIFT + Y (REMOTE) to toggle the LED light show on and off."

[RadekPilich]

With the PORT MONITOR, can you explain why:
- the monitor is active only on outputs but not on inputs (speaking about DINs, strangely on USB it's active on inputs as well)
- the monitor is velocity sensitive, so unless I am hitting keys hard / sending high velocity MIDI notes, nothing might show up on outputs either

I would suggest to change this behavior to:
- show activity on inputs as well
- adjust the velocity sensitivity so that it lights up on lower velocities as well or scrap the velocity sensitivity altogether

The issue is affected by the LED brightness setting as well.

With max brightness is probably closest to desired implementation, but with min brightness, it needs even more velocity and actually changes to a different channel color with low velocity.

[Jesse Johannesen]

With the PORT MONITOR, can you explain why:
- the monitor is active only on outputs but not on inputs (speaking about DINs, strangely on USB it's active on inputs as well)
- the monitor is velocity sensitive, so unless I am hitting keys hard / sending high velocity MIDI notes, nothing might show up on outputs either

I would suggest to change this behavior to:
- show activity on inputs as well
- adjust the velocity sensitivity so that it lights up on lower velocities as well or scrap the velocity sensitivity altogether

The issue is affected by the LED brightness setting as well.

With max brightness is probably closest to desired implementation, but with min brightness, it needs even more velocity and actually changes to a different channel color with low velocity.

With the PORT MONITOR, can you explain why:
- the monitor is active only on outputs but not on inputs (speaking about DINs, strangely on USB it's active on inputs as well)

I think the idea is to only show MIDI that is being routed by the MRCC. 

- the monitor is velocity sensitive, so unless I am hitting keys hard / sending high velocity MIDI notes, nothing might show up on outputs either

Sorry about that, I imagine that Steve just thought it would be cool to have it react to velocity. It may not be the best system for keeping track of MIDI activity, but I think the spirit of the thing was more that it might come in handy, and be cool to look at, and not how can we make the perfect activity display. I will ask Steve if he wants to take a look at having a non zero minimum LED brightness for velocity, but I don't know that I would expect this to be a priority. 

And as for LED brightness, that might actually be the issue now that I think about it. The LEDs have about 256 levels of brightness (it may be 1096 even) and anything over 10 is blinding, so with LED at its lowest setting, there really aren't that many options for LED brightness to choose from. It may be that it's bottoming out. 

---

OK I put in a request to take a look, I'll report back if it gains any interest from Steve.

[Sunbusta]

With the PORT MONITOR, can you explain why:
- the monitor is active only on outputs but not on inputs (speaking about DINs, strangely on USB it's active on inputs as well)
- the monitor is velocity sensitive, so unless I am hitting keys hard / sending high velocity MIDI notes, nothing might show up on outputs either

I would suggest to change this behavior to:
- show activity on inputs as well
- adjust the velocity sensitivity so that it lights up on lower velocities as well or scrap the velocity sensitivity altogether

The issue is affected by the LED brightness setting as well.

With max brightness is probably closest to desired implementation, but with min brightness, it needs even more velocity and actually changes to a different channel color with low velocity.

With the PORT MONITOR, can you explain why:
- the monitor is active only on outputs but not on inputs (speaking about DINs, strangely on USB it's active on inputs as well)

I think the idea is to only show MIDI that is being routed by the MRCC. 

- the monitor is velocity sensitive, so unless I am hitting keys hard / sending high velocity MIDI notes, nothing might show up on outputs either

Sorry about that, I imagine that Steve just thought it would be cool to have it react to velocity. It may not be the best system for keeping track of MIDI activity, but I think the spirit of the thing was more that it might come in handy, and be cool to look at, and not how can we make the perfect activity display. I will ask Steve if he wants to take a look at having a non zero minimum LED brightness for velocity, but I don't know that I would expect this to be a priority. 

And as for LED brightness, that might actually be the issue now that I think about it. The LEDs have about 256 levels of brightness (it may be 1096 even) and anything over 10 is blinding, so with LED at its lowest setting, there really aren't that many options for LED brightness to choose from. It may be that it's bottoming out. 

---

OK I put in a request to take a look, I'll report back if it gains any interest from Steve.

I reported the port monitor IN lights ages ago but nothing came of it sadly. I also experience the lights not working on very low velocities. I think port monitoring is actually a very useul feature - amost essential in a working environment really as the MRCC can route so many different things about, and the activity display is far too small to be practical unless you are very close to it.

Other issues i've found with port monitoring but haven't bothered to report:

1) Sometimes (unassigned) output 12 seems to light as well as the assigned outputs
2) I get various yellow lights on some of the (unassigned) outputs as well as the asigned output(s) - no idea what those are!
3) Using modifiers in the routing page seems to stop the assigned output light from working

If you bother putting this feature on there, it may as well work properly, otherwise why do it? 

I've made bug reports on other topics but nothing ever got done about them.
Its such a shame things like this aren't looked at, and it seems development has basically stopped for this device.
This is not a cheap piece of kit or really that old either...

Maybe one day the firmware will become open source so someone more willing could fix some of these small bugs and maybe make some nice refinements. If issues are not "interesting" enough to look at, please, please consider letting others do the work. Here's hoping!

[Jesse Johannesen]

With the PORT MONITOR, can you explain why:
- the monitor is active only on outputs but not on inputs (speaking about DINs, strangely on USB it's active on inputs as well)
- the monitor is velocity sensitive, so unless I am hitting keys hard / sending high velocity MIDI notes, nothing might show up on outputs either

I would suggest to change this behavior to:
- show activity on inputs as well
- adjust the velocity sensitivity so that it lights up on lower velocities as well or scrap the velocity sensitivity altogether

The issue is affected by the LED brightness setting as well.

With max brightness is probably closest to desired implementation, but with min brightness, it needs even more velocity and actually changes to a different channel color with low velocity.

With the PORT MONITOR, can you explain why:
- the monitor is active only on outputs but not on inputs (speaking about DINs, strangely on USB it's active on inputs as well)

I think the idea is to only show MIDI that is being routed by the MRCC. 

- the monitor is velocity sensitive, so unless I am hitting keys hard / sending high velocity MIDI notes, nothing might show up on outputs either

Sorry about that, I imagine that Steve just thought it would be cool to have it react to velocity. It may not be the best system for keeping track of MIDI activity, but I think the spirit of the thing was more that it might come in handy, and be cool to look at, and not how can we make the perfect activity display. I will ask Steve if he wants to take a look at having a non zero minimum LED brightness for velocity, but I don't know that I would expect this to be a priority. 

And as for LED brightness, that might actually be the issue now that I think about it. The LEDs have about 256 levels of brightness (it may be 1096 even) and anything over 10 is blinding, so with LED at its lowest setting, there really aren't that many options for LED brightness to choose from. It may be that it's bottoming out. 

---

OK I put in a request to take a look, I'll report back if it gains any interest from Steve.

I reported the port monitor IN lights ages ago but nothing came of it sadly. I also experience the lights not working on very low velocities. I think port monitoring is actually a very useul feature - amost essential in a working environment really as the MRCC can route so many different things about, and the activity display is far too small to be practical unless you are very close to it.

Other issues i've found with port monitoring but haven't bothered to report:

1) Sometimes (unassigned) output 12 seems to light as well as the assigned outputs
2) I get various yellow lights on some of the (unassigned) outputs as well as the asigned output(s) - no idea what those are!
3) Using modifiers in the routing page seems to stop the assigned output light from working

If you bother putting this feature on there, it may as well work properly, otherwise why do it? 

I've made bug reports on other topics but nothing ever got done about them.
Its such a shame things like this aren't looked at, and it seems development has basically stopped for this device.
This is not a cheap piece of kit or really that old either...

Maybe one day the firmware will become open source so someone more willing could fix some of these small bugs and maybe make some nice refinements. If issues are not "interesting" enough to look at, please, please consider letting others do the work. Here's hoping!

So I mentioned the LED issues to the dev after you reported them and I'm sorry I never got back to you. I think if I remember correctly, as far as the monitors on the inputs go, I believe the idea is that the Monitor only shows data being passed by the MRCC, (same as in the on screen MIDI monitor tool). We don't actually store any data that isn't being routed, so there's no way to make that happen without rewriting the fundamental process of how data is handled on the device. 

The LED brightness issue: There are something like 255 brightness levels on the LEDs, and basically anything over 9 is blinding. I always have my unit set to the dimmest possible setting. As a result the entire range of 128 Velocity values need to be represented across maybe 9 values, and because of this some are likely to fall off at the bottom. In any case we're not likely to make any changes to this functionality at this point in time. I spent a couple hours today discussing this with the dev and he thinks he may have found a way to tackle this one. It won't likely be released until the next major update, but if you email me at support@conductivelabs.com and ask I can probably pass a test version for you to try out once it's ready. 

Yellow indicates traffic to remote ports in most cases, but I don't know if that makes sense here or not. It might be a bug. If it's a bug and you figure out a way for me to replicate it, there's a good chance I can get it fixed, otherwise it's probably staying. 

Development on the platform has not stopped, (we have released 3 updates since December).

I like open source projects myself, but we've considered it and decided that that isn't what we want to do at this time. I'm sorry.

[Jesse Johannesen]

OK, I have a beta which seems to have solved your problem, hit me up at support@conductivelabs.com and mention the LED brightness issue and I'll shoot you the file.

[RadekPilich]

I have just played with note monitor yesterday, I believe that might be quite useful. Would be even better if the front panel of MRCC had a 12 black and white keys overlay graphics on output ports ?

Anyways, the velocity visualization might be more useful in the notes monitor then in the port monitor ?