Midibox LC & MotorFader+LCD problem

Testing/Troubleshooting
1

Hello.

I have a small problem. I try to explain…

When I activate the motorfaders (MF enabled) in the main.asm, faders are moving to follow the Cubase mixer. Everything seems ok.

I’ve connected 4 buttons for Bank left/right and Channel left/right.

Then, when I press one of these buttons, Faders move to the new position (to follow Cubase Mixer again). Faders are ok, but channel title on LCD is not… Sometime, cursor position is not ok, sometime, random caracters are displayed everywhere, …

I suppose first it was because I’ve not connected the 100 nF cond to the faders. But also with this condensator, my error is not solved.

Maybe an idea, I’ve not connected yet the fader sensitive touch.

Does this explain my problem ?

Any idea ?

Thanks

2

Hey Steve,

 My LC sometimes does not print one or two of the channels’  info on the LCD, but it usually re-appears within 5 seconds or so. Is this similar to your problem, or is your problem worse than this? Which MIOS revision are you using? I don’t think it could be due to the ‘touch’ or the condensor/capacitor.

 Occasionally, I have had to re-load the bootstrap loader, upload mios, etc due to a bad load or something… then it works OK, but this has only happened a few times out of hundreds of uploads!

 Could also be that the sysex from Cubase is getting jumbled up somehow. Are you able to try it with someone’s system who is running Logic, just to see if it is a Cubase problem?

 good luck, from Steve

3

Hi !

Not the same problem… Everything on LCD is Ok when I set Motorfaders to 0 in main.asp…

May be a wiring problem…

Steven_C, do you use Cubase SX or Logic with your LC ?

4

It’s a EMC problem. Add the 100nF caps (maybe also to the LCD), and check your power supply (5V@core should still be stable when *all* motorfaders are moved)

Best Regards, Thorsten.

5

Hi.

I have now 2x100 nF caps (1 on Faders, 1 on LCD +5v/0v). The problem is still there…

I will try to move one of my 2 transformers : the 220/9V and 220/12V are very close to and maybe it makes some radio troubles (sorry, I know better way to explain this in french, but in english…  :)

I’ll tell you if it works !

6

5V@core should still be stable when *all* motorfaders are moved

so, TK, its a problem when the power is drained from the motorfaders? Or RF interference? (I’m not sure what EMC means. But will have a look on google in a second!  ;))

Stephen, Your description reads ok in English! Just change ‘radio troubles’ to ‘RF interference’ (means radio frequency interference) Maybe you should have one 100n cap across each motor on the motorfaders.

Are you using a separate transformer on the MF module and the core modules? if so, then I don’t understand why excessive current draw by the motors could cause a voltage drop on the core module.

(I hope I’m helping, and not confusing…)

7

Hi Steve,

so, TK, its a problem when the power is drained from the motorfaders? Or RF interference? (I’m not sure what EMC means. But will have a look on google in a second!)

it means both.

EMC (electromagnetic compatibility) is the generic term for everything which can distrurb an electronical circuit

Best Regards, Thorsten.

8

Hello !

Yes, Steve, I use 2 separate transformers, one for the core and another for the MF module. But they are very close one to one… Less than 1cm… I will try to put them differently on my box and I’ll tell you if it works !

9

Hi.

I’ve make some modifications this week-end in order to solve my problem.

First, I’ve move the MF transformer far away from the Core transformer : nothing change, when more than 3 faders move, the LCD display is not ok (missing char, wrong position or random chars).

Second, I follow Steve idea : I’ve put a 100 nF cond to eatch motor of the motorfaders (I’ve got now 8 cond to motors, 1 cond to the LCD and 1 cond between +5v and 0v of the faders). But the problem is still there…

Now, I’m not very sure it’s a RF (or EMC…) problem… Can it be a Midi problem ? Too mutch midi messages when a lots of faders move… For exemple, during one of my test, a song was playing on my host, and then I press the Bank right button. All faders moves, and randoms charswhere displayed. But these random chars contine to display (as if my midibox use meters level midi messages for LCD…) until I stop the song, even if motorfaders didn’t move any more…

If anybody have a new idea…

10

Hi,

I haven’t noticed such a problem with my display, which is 4 times slower then a CLCD, therefore I still assume it isn’t a software problem (buffer overrun or whatever), but an electrical problem.

The host software only updates small pieces of the display view when it has been changed. This explains, why random characters are still visible. You could check, if this was a problem with the MIDI In line or with the display lines by changing the display page. This refreshes the display. If random characters are still visible, you know that the connections to the LCDs are not affected.

Thereafter you could check if the same problem appears when Motorfaders are disabled (I guess that you already know the MF_ENABLED switch in main.asm) – if no random characters appear anymore, you know that the MF module influences the core voltage (and especially the core supply voltage)

Best Regards, Thorsten.

11

Hi !

Thank you for your help, Thorsen.

I have modify the Lc_table_io.inc to have 2 buttons for “Page 0” and “Page next”. My test is really strange…

When I start the midibox and my host, I’m in the first page of the Track view. On the left of the first LCD, I can see mute/solo/rec/select info for each channel.

On the right of the second channel, I can see status and beat info. For each track, I can see the name of the track.

If I press the page next button, I can see the same display, and name of tracks is replaced with meter level info. OK.

If I press again the next button, mute/solo/rec/select info for each channel and beat/status display disapear and track info is display on all LCD width (very nice and usefull for me !).

And if I press again the next page button, the “widescreen” display shows meter level. OK.

There is, so, a “normal display” and a “widescreen display” for the 2 pages.

Now, in “normal display”, I still got my problem (ie when motorfaders moves, track name is not correct, random chars are sometime send, …). But in “widescreen display”, no more problem ! Even if all faders moves, the track names are ok…

Could it be a host (Cubase SX) bug ? Or maybe it’s a RF problem hidden in “widescreen” display…

For info, when in “normal display” the track name is not correct, when I press Page next to have the “widescreen display”, the track name is not correct too.

Help ! I need somebody !

(Paul mc Cartney) :wink:

12

does the same happen when you replace

      ;; print rec/solo/mute status at 0/0

       SET_CLCD_RSM_MSG 1, 0, 0

       ;; print select status at 0/1

       SET_CLCD_SEL_MSG 1, 0, 1

by

       ;; don’t print rec/solo/mute status

       SET_CLCD_RSM_MSG 0, 0, 0

       ;; don’t print select status

       SET_CLCD_SEL_MSG 0, 0, 0

in the LC_CLCD_Init_Page0 function?

(-> lc_clcd.inc)

If it doesn’t happen again, then a possible reason could be that Cubase updates the Mute/Solo/Select/Record status LEDs more often than Logic and this could stress the application too much. A solution: use of the same update algorithm like for MIDIbox SID and MIDIbox SEQ - but this is something which has to be integrated by myself (too complicated for programming beginners - even to explain how it works ;-))

But please ensure that this is really the reason before I have to do all this effort.

Best Regards, Thorsten.

13

Hello !

Well done Mister Thorsen ! You find the problem.

I make the modifications in the lc_clcd.inc : The Solo/mute/rec/select display on LCD disapear, and the problem too ! All display are ok when faders moves !

I’m sorry that I can’t help you to solve the problem…

I have another question :

  • I’ve make an update in app_define.h to add a new entry ST_BOOL (between 0x14f and 0x180).

  • I’ve update lc_init.inc to initialize ST_BOOL to 0x00

  • I’ve update lc_mproc.inc : when I receive a D0 message, I test the ST_BOOL  value : if 0x00, I do normal thing (ie LC_MPROC_Received_D0). If not, I initialize ST_BOOL to 0X00 and return.

  • In LC_MPROC_Received_D0, I move 0xFF to ST_BOOL.

I do this in order to ignore the second midi message send by Cubase for led meter.

When I test this, it’s work ok. Before the lc_clcd.inc modification, Meters where not ok when faders moves. But with your modification, meters are ok.

Now, meters are not ok when I press Page next button.

Could it be the same type of problem (program stress) ?

Thanks.

14

Hi,

  • I’ve make an update in app_define.h to add a new entry ST_BOOL (between 0x14f and 0x180).

How do you access this variable? Did you take the special addressing for registers above 0x7f into account? See http://www.ucapps.de/mios/mios_ram_handling.txt

It’s very important that you are working with the BSR and with the BANKED flag in this cased, otherwise it isn’t much surprising that anything else (like the display) crashes, shows random numbers or is doing something totally unexpected.

Additional question: do you see the random characters only after your modification, or do you already see it with the original release?

Best Regards, Thorsten.

15

Hi.

I see random char with original release when faders moves.

Thanks for your help file. I will verify my additional code for Cubase SX meter management.

16

Hi,

could you send me your code, so that I can put it into the upcoming release?

Best Regards, Thorsten.

17

Hi thorsen

I’ve update my additional code to take care of the special adressing for registers above 0x7f and it’s better. There are still problems :

  • When I use a boolean to ignore the second D0 midi message, the led meter is close to be ok. But meters don’t move with precision (according to display on Cubase), and some time, “synchronization” is lost with Cubase, only the second MIDI message is then use for meters… I think this is not the good solution to the problem.

  • I try then to recognize the second midi message with an other way : I see in my logs that the first 4 bits in the second midi message are always the last 4 bits in the second. So, I’ve update my code to use this to ignore the second midi message. This is really close to the final solution, with no synchro lost, but with some meters errors and always no precision with meters.

  • Last test (for this week-end !), I try to use the 2 Midi messages for meter level (I take the 4 last bits of the first message, add the 4 last bit of the second and then divide the result by 2 (just a right rotation). Not the good solution…

I think that we must wait for Cubase update : I’ve read in Nuendo Forum that there are a lots of bug, especially one about the signal led, lighting a lots of track even if only one track play, very similar to our problem !

I think again that it’s very important to find the Cubase SX midi protocol implementation for Mackie control… But it seems very hard to find… A response from the Steinberg technical manager : “The Mackie Control protocol is under NDA, we can send that out.”.  :-[

18

Hi,

are you able to record the MIDI messages into a MIDI files, so that I would be able to replay it on my PC w/o using Cubase?

Best Regards, Thorsten.

19

Hi Thorsen.

Maybe I can do this with MIDI-OX… Iwill try…

Thanks.

20

Sorry…

I won’t send you a midi log file for Cubase meters… I’m now sure that it’s a Steinberg bug for Cubase SX 2 version (and Nuendo). A patch is announced for May 2004. I don’t want you to work hard for me with something not usefull in some weeks…

Thanks for your help and … nice holidays !