I need control midibox LEDs from PC via MIDI. I want use the AIN 64 DIN 128 DOUT128(example) program, because I need 128 buttons. But in this example isn’t code to drive switching LEDs via MIDI. The MB64 program is too complicated for me, and I can’t find this problem in large code.
I thing that the place for switching code is at USER_MPROC_NotifyFoundEvent.
I noticed tonight in Serge’s vmidibox editor, you can apparently map d.out lights to whatever MIDI signals you have your d.in buttons set to, so if they see that same message come in, they light up.
It may not be exactly what you’re talking about, but it was easier for me to do than finding it in the code right now, and I’m also just learning the stuff.
Thank you for reply, but this work in MidiBox64 prog., which can use only 64 Buttons. I need 128 Buttons, it supports AIN 64 DIN 128 DOUT128(example) program, which is for me more simple, but it haven’t part of code for lighting LEDs from incaming MIDI events.
funny that you just have the same problem as I wanted to post now. I noticed the same effect, compared to the midio128 application where it is possible to trigger the led with midi.
as far as I can see the ain64_din128_dout128_v1_3 - application is only a test application, and will lack the functionalities of midio128 (the amount of code speaks for this).
to get to the required result we either have to expand the midio128 application so that it can handle AIN as well, or if the ain64_din128_dout128 can be expanded so the DOUT reacts on midi-events. Maybe some of the experts can give us a hint or two?
however, I am not familiar with PIC programming or assembler, so for the moment I cant give any help, but we might join forces…
I would guess the vmidibox result is available through the right changes or includes in the midio source, but it looks like most of us in this thread are on the same level.
The MIDIBox skeleton and example apps are the same way, so comparing them with a full featured source would give an idea of what to add. I’m guessing again that most of it isn’t specific to just the MB64 apps.
ok, if you want to use two cores anyhow, the solution is much simpler: just open mios_tables.inc in the AIN64DIN128DOUT128 application and replace 0xb0 (CC) by 0x90 (Note)
Then add following line to USER_Init:
MIOS_MIDI_MergerSet(MIOS_MIDI_MERGER_MBLINK_FP)
to configure this core as a “forwarding point”
or:
MIOS_MIDI_MergerSet(MIOS_MIDI_MERGER_MBLINK_EP)
to use it as an “endpoint”
Best Regards, Thorsten.
P.S.: don’t forget to clamp all unused analog inputs to ground (for the DIN/DOUT core this means: the whole J5 port)
In order to get my head around the AIN64DIN128DOUT128 application and the mios_tables.inc:
The first 128 entries define the midi-events sent in case of a DIN-event.
The next 64 entries define the midi-events sent in case of a AIN-event.
Where are the events defined that control the 128 DOUT? Do they correspond with the 128 entries for DIN? That would mean If I send back the same midi-event received for a DIN-event, the corresponding DOUT LED will be set on/off, like with MIDIO128, right? (my tests showed this doesnt happen, but maybe I made a mistake?).
When a DIN-event occours, the corresponding DOUT LED lights up. Is it possible to turn this off?
whoops - you are right. I oversaw that the LEDs are not MIDI controllable in this application.
However, just open main.asm, search for following comment:
USER_MPROC_NotifyFoundEvent
;; here we could insert code which switches the LEDs on/off via
;; MIDI
return
[/code]
Replace it by:
[code]
USER\_MPROC\_NotifyFoundEvent
;; entry number is in WREG --- it corresponds to the LED which should be switched
;; the note velocity (or CC value) switches on/off the LED, it's stored in MIOS\_PARAMETER3
IFSET MIOS\_PARAMETER3, 6, call MIOS\_DOUT\_PinSet1 ; set LED if value \>= 64
IFCLR MIOS\_PARAMETER3, 6, call MIOS\_DOUT\_PinSet0 ; clear LED if value \< 64
;; thats all
return
In order to prevent that a button controls a LED, search for “USER_DIN_NotifyToggle” and remove following code:
;; now toggle the appr. DOUT LED
movf TMP3, W ; button number has been saved in TMP3. This is also
the LED number
IFCLR TMP4, 0, call MIOS_DOUT_PinSet1 ; if button has been pressed (value = 0V = CLR): LED
on
IFSET TMP4, 0, call MIOS_DOUT_PinSet0 ; if button has been depressed (value = 5V = SET): L
ED off
[/code]
Best Regards, Thorsten.
P.S.: sometimes I don't know why I'm writing comments... ;-)
Thank you very much for your quick reply. I successfully implemented the MIDI controllable code for DOUT.
Though deleting the code inside the “USER_DIN_NotifyToggle” function doesnt do the trick. The button still toggles the corresponding LED.
However, when I plug off/on the powersupply to the core, the Button doesnt toggle the LED anymore. Only.. nor can I control the LED via MIDI anymore. The button still sends its MIDI signal though.
As soon as I upload the new main.hex (I work with MIOS studio) I have the same effects again as I described above.
I made the following test:
When I simply delete the code-snipplet inside “USER_DIN_NotifyToggle” without adding the code for “USER_MPROC_NotifyFoundEvent”, it works as expected: The button doesnt toggle the LED anymore (and the LED doesnt react on MIDI signals of course).
…Its still pretty dark in this black box, and I just lost my lighter…anybody got a match?
cheers
martin
P.S.
P.S.: sometimes I don’t know why I’m writing comments…
… in order to understand your stroke of genius from last month again!
There might be an issue with the “USER_MPROC_NotifyFoundEvent” function
playing around with lcd_print I figured out the following:
once the application is uploaded and a button is pressed, the function is called, even though NO midisignal was sent to the midibox. (according to the doc it only reacts on received midisignals that are mapped in the CONFIG_MIDI_IN table)
I print out the entrynumber with “call MIOS_LCD_PrintBCD3”. no matter which button is pressed (see above) or which midisignal I send the number is “55” (Assuming this method displays the content of WREG). However, the proper LED is switched on and off - so I obviously dont grasp the whole thing…
after a (power off/on)-Mios boot, the USER_MPROC_NotifyFoundEvent is not called anymore (the display doesnt show any reaction), not even by a button.
but this not the case. I had the mentioned errormessage of a path longer than 62(?I think) charakters and resolved this. As far as I can say, I dont have any problem with the compiler. all is green.
Assuming you’re running a fairly current Cubase and the “generic” remote-
If you pull up the generic editor window where you assign all your controls, in the top (source) columns, each item has flag parameters you can change over on the right. They default to “R” or receive, but you can add the “T” or transmit capability to any of them, and they’ll send their changes back out from Cubase as well. There’s also a “relative” encoder type setting, maybe for jog/shuttles or something.
Don’t feel bad, I’ve been on Nuendo since v.1 and I just figured out it could do that a few weeks ago :-[