Disconnect i/o pins from main app.

[Jidis]

Sort of a confusing title I guess. 8)

Thorsten mentioned in a shift key thread, that you could prevent your chosen shift button from triggering any of the usual events, by filtering it out in the "buttons.inc" file:

  ;; exit on event from button ID = 0x10

  movf MIOS_PARAMETER1, W

  xorlw 0x10

  skpnz

  return

In that case, it was at the beginning of the MB64E_BUTTON_GP function, where the user was making his other edits.

How/where do you safely kill an i/o pin's connections to the rest of the MIOS activity? (I guess the above was one place)

I was tinkering with the use of one of the LED's as an indicator for something and was noticing that something was immediately turning it off after my dedicated button turned it on. Like something was updating the output shift registers and wasn't aware of my change. The pin itself (I believe) shouldn't have been linked to anything else. I had it set to receive an unused high register's MIDI notes or something.

Thanks!

George

PS (if anyone can answer this one too)

That "general purpose" area of the buttons file is just global code, which all button events will ultimately pass through right?  - I know there's that general purpose button section in the main file for some menu specific functions.

[TK.]

How/where do you safely kill an i/o pin's connections to the rest of the MIOS activity? (I guess the above was one place)

this is only possible within the application. If it overwrites a DOUT register, then you have to find, where, and you have to disable the appr. code.

I was tinkering with the use of one of the LED's as an indicator for something and was noticing that something was immediately turning it off after my dedicated button turned it on. Like something was updating the output shift registers and wasn't aware of my change. The pin itself (I believe) shouldn't have been linked to anything else. I had it set to receive an unused high register's MIDI notes or something.

Maybe the LED ring handler overwrites the DOUT registers? You can disable it in the main.asm file (one of those #define's)

That "general purpose" area of the buttons file is just global code, which all button events will ultimately pass through right?  - I know there's that general purpose button section in the main file for some menu specific functions.

yes, they overrule button events forwarded to the MIDI out handler.

Best Regards, Thorsten.

[Jidis]

Thorsten,

Thanks. I probably need to work through this on my own. I've been wrapping up some outside projects for a while and have forgotten some MB stuff already. :-[

Going through the current skeleton app, the MIOS functions ref, and the LEDs.inc file, it looks like there's a few different ways to turn them on anyhow. I may try some others.

Much to learn,

George

[Jidis]

Sorry to come back to this, but I've gotten a bit frustrated with the amount of time I've spent on this one thing, and the idea that I may save myself if I could just get a quick pointer from someone else.

My light is still getting killed off, and it appears to be happening within the MB64_LED_Update call in the mb64_leds.inc file (I can jump out of that with a return, and I'm OK).

Is there anything similar to the button handling filter, where you can pop in a "literal" button number and jump out if it sees that? I'm getting worried that the LED stuff is more a matter of looping through every single light's current value, and that it would require me to get *my* value inside the group of LED statuses (ouch!).

Thorsten and all- This is just a regular MB64 app (no LED rings or anything in the source). The idea works OK using an old "small skeleton" (1.6), but there's no LED's happening in that. The MB64 is currently in that mode where the buttons and lights are tied together 1:1, but I've tried others. The button handler is set to ignore the button I'm using for this, and that works well (no LED or current button change when I hit that one).

Thanks Again,

George

PS (FWIW)- I'm trying to work out a "permanent" version of the shift mode thing, with a toggle (only active on the downstroke of the button), to put me into a second group of output messages. A variable keeps track of which mode is active, and gets inverted by a "comf" on each pass through the toggle code. The LED would be tied to that, so you could tell by looking at the box, which mode it's in. Ironically, it looks like everything else is working OK. I've added a couple lines to dump the toggle status variable onto the LCD each time to make sure it's right, but that update loop is still shooting my light down the second it goes on.

[TK.]

Mapping can be so easy when you just modify the existing functions.

Let's say, you want to toggle between LED 1-32 and 33-64 - this requires, that the appr. LED patterns 1-32/33-64 are mapped to the same shift registers in main.asm:

#define DEFAULT_DOUT_SR_PIN_01_08       1
#define DEFAULT_DOUT_SR_PIN_09_16       2
#define DEFAULT_DOUT_SR_PIN_17_24       3
#define DEFAULT_DOUT_SR_PIN_25_32       4
#define DEFAULT_DOUT_SR_PIN_33_40       1
#define DEFAULT_DOUT_SR_PIN_41_48       2
#define DEFAULT_DOUT_SR_PIN_49_56       3
#define DEFAULT_DOUT_SR_PIN_57_64       4
[/code]


Now you have to modify the LED update loop, so that it either starts with the first shift register, or with the 5th shift register depending on the state of your shift button. In addition, the loop has to handle 4 instead of 8 shift registers:

[code]
        ;; ------------------------------------------------------------------
        ;; now transfer the LED values to the appr. DOUT registers
        ;; ------------------------------------------------------------------
        TABLE_ADDR MB64_LED_DOUT_MAP
        lfsr    FSR0, MB64_DATA_BUFFER
        clrf    TMP1            ; used as loop counter

        ;; BEGIN MODIFCATION (add offset depending on shift button)
	IFCLR	SHIFT_BUTTON, 0, rgoto MB64_LED_Update_SRLoop_NoShift
MB64_LED_Update_SRLoop_Shift
	;; shift button active -- add offset of 4 to FSR0 pointer
	movlw	4
	addwf	FSR0L, F
	;; and add it to the table pointer as well
	TABLE_ADD_W	
MB64_LED_Update_SRLoop_NoShift
        ;; END MODIFCATION


MB64_LED_Update_SRLoop
        ;; we are using the MIOS_DOUT_SRSet function
        ;; copy value to MIOS_PARAMETER1
        movff   POSTINC0, MIOS_PARAMETER1
        ;; copy mapped DOUT shift register to WREG
        tblrd*+
        ;; skip if DOUT disabled
        incf    TABLAT, W
        bz      MB64_LED_Update_SRLoopNext
        movf    TABLAT, W       
        ;; execute DOUT SR set function of MIOS
        call    MIOS_DOUT_SRSet
MB64_LED_Update_SRLoopNext
        ;; loop until last SR (#7) reached
        incf    TMP1, F

        ;; BEGIN MODIFCATION (was: IFCLR TMP1, 3, ...)
        IFCLR   TMP1, 2, rgoto MB64_LED_Update_SRLoop
        ;; END MODIFCATION

(here I assume, that the shift status is stored in a variable with the name "SHIFT_BUTTON", bit number #0, and that it is located within 0x00...0x7F (access range), e.g. at 0x70. Your variable has propably another name, just change the code accordingly.

So: 4 lines of additional code + one modified line (lost in the deep grounds of this forum if never stored in the Wiki ;-)

Best Regards, Thorsten.

[Jidis]

Thorsten,

Much thanks as usual!

I think I understand most of what you describe, but I get pretty shaky toward the far end. Keep in mind, I'm still barely on a 16f84/small app sort of level, so the MIOS apps still contain lots of instructions I'm not familiar enough with. I'll be reading up on the ones I need for this.

I had looked at using the PinGet function for something a few days ago, but hadn't looked into the full SRget ones.

I probably should clarify my intentions. As a "for instance":

-Say I've got 16 channels of lights and buttons to handle mute & solo across a mixer.

-I only wish to have a single button, per channel, with a global mute/solo switch (switch has two corresponding lights, plus that variable to show you what the mode is).

-The actual LED map will remain unchanged throughout (the mode toggle won't affect it). I want a constant visual indication of each channel's status, and the lights will stay mapped to the incoming MIDI events for whichever registers they're set to.

My "guess" is that I'd need 5x DOUT SR's (16 mute LED's, 16 solos, and a couple extra pins of a fifth one for the toggle indicators), then just three DIN chips (16 mute/solo "combo" buttons, and one extra button for the toggle).

Guess #2 is that I'd be seeking to pull in that whole 5th DOUT SR's contents, set or clear only the bits (pins) that I'm using for my mode lights, and send it back where it was, to be used by the rest of the LED update. BTW, I'm not ruling out the possibility that the 5th DOUT/3rd DIN would have nothing else happening on them (that was just an example). I'd need the rest of that DOUT SR's pin status to remain intact.

Sorry if that's what's happening in the example code you gave me. Again, I'll be trying to get a better grasp on a couple parts of that tonight. I can see where it's cycling through the registers and where it's checking for where to begin the map, but it still looks like it's dealing with each of the SR's as a "whole" (unless I'm missing something).

Really appreciate all the help,

George 

[TK.]

This requires a different mapping routine. I cannot give you the code immediately, but I can give you a more simple starting point: remove the whole code of MB64_LED_Update, and write:

MB64_LED_Update
	SET_BSR	MB64_BASE

	;; we don't want to overwrite MIOS_PARAMETER1, save it in TMP3
	movff	MIOS_PARAMETER1, TMP3

	movff	MB64_BUTTON_VALUES_SR0, MIOS_PARAMETER1
	movlw	0
	call	MIOS_DOUT_SRSet

	movff	MB64_BUTTON_VALUES_SR1, MIOS_PARAMETER1
	movlw	1
	call	MIOS_DOUT_SRSet

	movff	MB64_BUTTON_VALUES_SR2, MIOS_PARAMETER1
	movlw	2
	call	MIOS_DOUT_SRSet

	movff	MB64_BUTTON_VALUES_SR3, MIOS_PARAMETER1
	movlw	3
	call	MIOS_DOUT_SRSet

	movff	MB64_BUTTON_VALUES_SR4, MIOS_PARAMETER1
	movlw	4
	call	MIOS_DOUT_SRSet

	movff	MB64_BUTTON_VALUES_SR5, MIOS_PARAMETER1
	movlw	5
	call	MIOS_DOUT_SRSet

	movff	MB64_BUTTON_VALUES_SR6, MIOS_PARAMETER1
	movlw	6
	call	MIOS_DOUT_SRSet

	movff	MB64_BUTTON_VALUES_SR7, MIOS_PARAMETER1
	movlw	7
	call	MIOS_DOUT_SRSet

	;; restore MIOS_PARAMETER1 from TMP3
	movff	TMP3, MIOS_PARAMETER1

	return
[/code]
Now I guess it's easier to do modifications.
Best Regards, Thorsten.

[Jidis]

Thanks Thorsten :)

I see what that's doing (dumping them all out directly, one by one, rather than running through each of those routines in the loop), but I guess I'd still be responsible for getting my "changed" register's contents into whatever DOUT_SRSet call it went with.

When I first read this, I swapped the update routine with that list of SRSet's, and got about the same as before, but with an "inverted" output (all LED's on, and they'd turn off during each corresponding button press). The 24th light still did the same thing, where it changes for a second, and then gets wiped out. I guess with the contents of all the MB64_BUTTON_VALUES_SRx's being unchanged, that's what I should expect.

Been messing with it a lot and will continue to do so, and I really appreciate all the help.

One thing I did find while playing with it, was that I can throw PinSet's and stuff at the very end of all the calls under the MB64_LED_Update (right before the return), and it has no choice but to use them. I guess it's actually quickly clearing them with the real code and then immediately setting them with my instructions at the end. Appears to work somewhat anyway.

A strange catch to that, is that I can't for the life of me get it to reliably use any sort of bit test or "zero checking" code at the end of that update, to either clear or set the 24th light (depending on my LED_TEMP variable). Right now the buttons.inc still has a couple lines in it that throw the LED_TEMP state on the LCD every time a button gets toggled, and the variable gets comf'd every time button 24 goes down. You can see an "FF" in the corner of the screen and watch it change to "00" when you toggle #24, but the test at the end of the LED_Update seems to always find a zero. 

I've tried a couple different conditional branches at the end, and it just doesn't work.??? ??? ???

Sorry for all the hassle,

George 

[Jidis]

OK, I ate about 10 lbs of Chinese food and got the sudden urge to move the three lines of code which throw the status of the LED toggle variable (LED_TEMP) on the screen.

It was in the buttons.inc file, right at the start of the general purpose button function, before some code that checks to see if button 24 has been hit. After that, it would invert the variable and exit.

I moved it to the tail end of the mb64_leds.inc file, just before it tests the temp variable and lights (or clears) LED#24. If I move it to the very end (right before the LED update's "return"), it ruins any light status testing, just like it did when it was in the button handler. The variable still flip flops on the LCD, but the light stays in one state.

This is all that was involved:

call MIOS_LCD_Clear
movf LED_TEMP, W
call MIOS_LCD_PrintHex2  ;; shows the status of LED_TEMP

What gives??

All in all, it works. It isn't the most responsive thing I've ever seen, but it's tolerable, and it doesn't affect any of the other light's functioning.

George

PS-- OK, now the sucky part:

That thing with the LCD_PrintHex2 is just something I was using for peace of mind, so I could tell that my variable was actually being toggled. It's not anything I would want on the screen (that's what the lights are for).

I now find that removing the LCD junk completely is the same as having it in the "wrong" location (no more toggle light). Why would those three lines affect the simple testing of an unaltered variable? 

[Jidis]

(replying to my own post)

...ouch

I think that temp is in an "off limits" section of memory. :-[ :-[ :-[ :-[ :-[ :-[ :-[ :-[

I just saw MIDI-Ox mess with it during a syx dump. I'm surprised any config worked. I'll try to fix it later. (good point to leave and go to the studio 8)).

I'll post when I check it again,

Take Care,

George

[Jidis]

Did actually get to check it last night, but got in really late (got a duplicate box at the studio  ;D ).

The location of the LED_TEMP variable definitely had something to do with it. I was using a couple spots just past the last CSMD_POTBASE (0x299) in app_defines for a couple user variables. We are clear at that point aren't we (I thought it was free all the way up into the high end of 300)?

I stole the slot for one of the drum equates (0x6f), since the drum stuff is disabled, and I didn't have any trouble with random junk landing in that variable. I'll find a better home for it later.

On a positive note, this mess I made now "appears" to work, I was able to comment out the LCD part, I added a second light to the toggle, and added the actual DOUT message change that the shift toggle is supposed to make. So now:

- There are two DOUT pins (LED's) controlled by a toggle on one DIN input, tied to a flip-flopping variable.

- Only one is lit at a time, depending on the variable state.

- The change is only triggered by the forward half of the switch event (not the button release), and this particular button is ignored by the rest of the button handler.

- The toggle state currently bounces the button map 'up' by 24 items in the button list, so in the default state it does nothing and the app inits with a green light (for instance), and button #1 puts out the message you have assigned to button #1. Tap the toggle, green light goes out, red light comes on, and button #1 is now putting out the message for button #25,etc. (three shift registers forward).

I'm guessing a counter variable could be used to toggle between more than two, with inc/dec instructions on the counter for each event from the toggle button, rather than a comf. That could get a few different batches of outputs from the same buttons (with lights). Of course a "physical" toggle, slide, or rocker could also be used with no lights, and you wouldn't even need the variable (just a PinGet).

The shift part came from a post by Neomorph in 2004 ( http://www.midibox.org/forum/index.php?topic=3295.0 ).

For anyone who might read this:

How easy/difficult would it be to modify the actual outgoing (MIDI) button "messages" before the output, under "shifted" conditions? For instance, rather than being restricted to the list of button message assignments, could you pull in the MIDI message, add a number to the channel, note, or velocity value, and then let it continue to the output? Would probably be quite useful.

Thanks!

George   

-

[TK.]

Just open mb64_midi.inc, search for "MB64_MIDI_SendButtonEvent". Here you can make your enhancements, because this functions knows about the button number, it prepares the MIDI event, and forwards it to MB64_MIDI_Send

On the other hand: if you neither use the LCD menus (and therefore miss most of the specific MB64 features like MIDI learn, onscreen event editing, morphing), a C application is much easier for that what you are planning to do, and I guess that your work will be much better re-usable for other users. Because a) it's a nice programming example, b) C is easier to read and modify, c) you will see, that the program itself only consumes 2..4k at the end (you don't need most of the MB64 stuff), and d) you don't need to ask me where to find certain parts of hooks, switches, levers, etc... this is also time consuming for myself. So, it would propably be easier for both sides if you would build up an application from scratch.

Best Regards, Thorsten.