Bassman

Hi Thorsten, Ok, I would like an LED to stay on when a button is in 'OnOnly' mode and previously pressed 'OnOnly' mode buttons to clear. Then I can use these buttons for program changes and see quickly which program is used. best wishes Keith

Well, with the copious amount of help, past and present, plus figuring out that the DOUT inputs are labed backwards (that had me confused for a while), I have everything working 1st time, so I'm suitably pleased with myself, but really all the work done by others is the reason it went fairly smoothly. Fortunately, I organised my box and wiring around the 8 bit registers so it is easy to swap around DIN and DOUT inputs if neccessary. I cut up a very large stripboard (12"x12"), that I got in a local store, into 2 hole wide strips to get mountings for each group of 8 LEDs, and glued to ribbon cable to the back after wiring, that was helpful. The only unexpected thing, was the LEDs not following the button mode in OnOnly, where I thought the LEDs would stay on. Apart from that small point, I would say it was a success. Many thanks to everyone, that has contributed. Now I'm going to make a bigger system, I have so many things I want but could never find to buy. Keith

Oops, I meant to say; I could invert the LEDs by changing to; ;; my new lines to set DOUT SR3 movlw 0xff movwf MIOS_PARAMETER1 Keith

Hi Thorsten, That doesn't work, no LEDs light at all. I'm wondering if my question caused some confusion. First, the LEDs act like 'OnOff' mode, when the buttons are in OnOnly, i.e. they do not stay on in 'OnOnly' button mode. Is this correct? Your suggestion to use ; MB64_BUTTON_OnOnly ;; new SET_BSR MB64_BUTTON_VALUES_SR0+3 clrf MB64_BUTTON_VALUES_SR0+3, BANKED actually works well, though inverted, except it is reflected in the LCD display by the buttons all being 'on' in that SR, which I would expect because BUTTON_VALUES are being altered, but it does not happen with the 'un-altered' App. But it does inticate which button was pressed, by it's LED being off. Because your suggestion, above, affects the display, is this a better method? I could use this; MB64_BUTTON_OnOnly ;; save status of button rcall MB64_BUTTON_Hlp_SaveStat ;; my new lines to clear DOUT SR3 movlw 0 movwf MIOS_PARAMETER1 movlw 3 call MIOS_DOUT_SRSet ;; restore MIOS_PARAMETER1 in case it's needed, I'm not sure yet? movff TMP3, MIOS_PARAMETER1 ;; when on: send button value defined in dump ;; when off: send nothing BRA_IFSET TMP1, 0, ACCESS, MB64_BUTTON_NotifyChangeEnd rgoto MB64_BUTTON_Send This would not affect the display. But it is not inverted, and as the current button LED does not stay on in 'OnOnly' mode, I could invert the LEDS by changing to; ;; my new lines to set DOUT SR3 movlw 1 movwf MIOS_PARAMETER1 Then I would see the last pressed button as the one with the LED off? But all this is because the LED does not follow the button mode 'OnOnly'. I did not know this when I asked the first question, as I was still building the box, I just assumed. Now that the box is built and working just fine, (great job Thorsten and Smash), I do not know what the LED should do in 'OnOnly' mode. I thought that the LED would follow the button mode. Is there something wrong, or have I assumed wrong? Perhaps you could help my confusion? thanks again, and my first MB64 is working 1st time, no problems except this issue (which is minor, really), your time and effort is greatly appreciated. Keith

Thanks Thorsten, Actually that works, it is clearing, but as the OnOnly LED goes off when the button is released, it's pointless. The end result, visually with LEDs, is the same as before changes were made. Hmmmmmm. I guess my question now is how can I make the LEDs perform the same mode as OnOnly events? thanks again Keith

Thanks Thorsten, I now have this; MB64_BUTTON_OnOnly ;; new SET_BSR MB64_BUTTON_VALUES_SR0+3 clrf MB64_BUTTON_VALUES_SR0+3, BANKED ;; save status of button rcall MB64_BUTTON_Hlp_SaveStat ;; when on: send button value defined in dump ;; when off: send nothing BRA_IFSET TMP1, 0, ACCESS, MB64_BUTTON_NotifyChangeEnd rgoto MB64_BUTTON_Send This works a lot better, but it is inverted. i.e. All the LEDs are on Except for the one that is last released. They don't go on until a first button is pressed, even from a different DIN SR (that seems expected). Perhaps it's because the OnOnly doesn't seem to apply to the LEDs, as they go off with button release, same as OnOff mode? I'm not sure if that's supposed to be like that as this is my first Core. If the OnOnly mode normally has an OnOff LED mode, then the best way is inverted like this. Maybe, Thorsten, you had thought of this arleady? Just fyi, when in EDIT EVENTS, all the LEDs are cleared on every button press, and set appropriately on button release. Exiting EDIT EVENTS, clears all LEDs, which is probably normal. Thanks again, Thorsten. Keith

Thanks again Thorston for your help. Well, I tried adding the line as suggested by Thorsten; So I had this; MB64_BUTTON_OnOnly ;; new clrf MB64_BUTTON_VALUES_SR0+3 ; clears fourth SR 8 LEDs ;; save status of button rcall MB64_BUTTON_Hlp_SaveStat ;; when on: send button value defined in dump ;; when off: send nothing BRA_IFSET TMP1, 0, ACCESS, MB64_BUTTON_NotifyChangeEnd rgoto MB64_BUTTON_Send I re-assembling the App. and uploaded. Something seems to be wrong. First the OnOnly mode doesn't work. The buttons on SR3 act as if they are in OnOff mode and also the LCD jumps to Display page 1. Oddly enough, the buttons on SR0 (D0-D3) do the same. I can't really tell about the menu buttons on SR0 (D4-D7). In any case, without the changes to MB64 as above, in the OnOnly mode the LED goes off when the button is released. Is that supposed to happen? I thought the; BRA_IFSET TMP1, 0, ACCESS, MB64_BUTTON_NotifyChangeEnd is supposed to do nothing if TMP1 is set as in button released? Any more suggestions? Keith

Thanks so much Thorton, Now that you explain it, it's quite clear. I did not find the MB64_BUTTON_VALUES_SR0 (+1,+2,+3 etc) locations. This will work perfectly. Fortunately I have kept my buttons organised around the 8bit registers (also in banks of 8) so this will do well. Many thanks again, Thorston. Keith

I'm still a major newb, but wonder if I can accomplish this for the MB64 that I am trying to build, it's coming along, mainly thanks to everyone here. I want to change the button handler routine to clear a LED shift register then set the LED to indicate the toggled button. Basically, to show only the last pressed button and cancel previous LEDs. I don't want this to happen with all shift registers, just the ones that require it. I've studied the MB64_BUTTON_GP_NoSFB and MB64_BUTTON_OnOnly (the only situation I need it) and the MB64_BUTTON_Send and MB64_LED_Set routines, but I suspect the changes need to be made in MIOS. I don't want to mess with that as it's TK's work. Does anyone know how to begin with this? Keith

I hope they're answered. Of course I've a long way to go yet. Making the boards, making the panel and box, wiring it all up, uploading my application, and probably spending forever to puzzle out what's wrong. Easy......yeah right! I'm sure I'll need a bundle of help. thanks for being there Keith

Uh.........ok, I found the answer to my CORE to DIN and DOUT question at Smash. I see the new boards are made to carry the SI or SO through for easy DIL connection. It wasn't obvious, but fortunately I can trace a PCB track. I will assume that smash has also changed the DIN input lines to DIL for easier connection. I see that the real wizzkid (not a reflection on age Smash ;D) is at SmashTV. He obviously has 30 hours in his days. How does he do it? I think he deserves MUCH more credit and thanks! So THANKS SMASH! Keith

So I got my first CORE, DIN & DOUT today, yeah! But, naturaly as a newbie, I am confused. I assembled the boards ok, thanks to SmashTVs excellent documentation and pictures, otherwise I'd be stumped. But on my R5 DIN, J1 must connect to CORE J9. J1 on the DIN is a 10 pin header whilst J9 on the CORE is half of a 10 pin header i.e. 5 pins. Also on my R5 DOUT, J1 connects to CORE J8. J1 on the DOUT is a 10 pin header whilst J8 on the CORE is half of a 10 pin header i.e. 5 pins. What needs to be connected here? There is also mention of CORE J6 & J7 to be used if conditions apply. If I just want buttons and LEDs, do I ignore J6 & J7 on the CORE? I'm also curious why CORE J7 & J8 are not a together and similarly J9 & J6, as 10 pin headers. R5 DIN shows J3, J4, J5, J6 as digital input lines with 8 lines and a Vs. The wiring diagram for 32 buttons (mbhp_dinx4_32buttons.pdf), shows J3 thru J10, each with 4 lines and a Vs connected to buttons, an R2 version I guess? Do I assume J3 (D4-D7) & J4 (D0-D3) on the wiring diagram are D0 thru D7 on J3 in the R5 DIN? Similarly, J5 (D4-D7) & J6 (D0-D3) on the wiring diagram are D0 thru D7 on J4 in the R5 DIN, etc.? Thanks Keith

Re: the threaded rods. If you look for 3mm machine screws that are long enough to mount just 8 switches on (you should find them in a good hardware store), and enough nuts, you will have 4 banks of eight switches, which is the same configuration as the DIN module. You will be able to use one of the machine bolt as a common bar for each group of 8 switches, and make it much clearer to see where you are when wiring them up. Also you might not have to bend the machine screws. I'm not sure what this means, can you try again? Are the L brackets the old contacts or pushers? If they are, why change them for new switches? An alternative idea; If the problem is the amount of travel of the pedal being more than the switch, maybe you can mount a switch on the side of each of the pedals, at the toe end, instead. Then you only need something adjustable for them to push down on. Maybe you can re-use the L brackets for this, perhaps fixed to the frame at the toe end. Normally open is what you will need for the DIN module. Keith

The clicking is not really noticable if you play loud. Ok, that's not helpful. Some micro switches are quieter than others, but I've never heard of anyone being bothered by it. I usually mount the micro switches above or at the rear of the pedals, (normally there's not enough room underneath) and bend the switch levers so that they can be screwed or bolted to the pedal, and mount the switches on a frame made of threaded rods and 'L' brackets. You have to experiment to find the best place on the pedal to attach the switch, closer to the pivot with produce a small travel, further away, a larger travel. Another alternative is to attach a small 'Z' shaped bracket to every pedal so that depressing the pedal will 'pull down' on the lever. This is better on some pedals designs. I think you said you had a 32 note pedal board. They are many different construction methods, maybe yours are pivoted under the bench, so you might be able to mount the micro switches under or at the other end of the pedals, but often the return springs get in the way. I have done it with just an 'L' bracket for each micro switch, but it really depends on how your pedals are designed. Yes I would bend the threaded rod frame to follow the curve of the board, it's important to have every pedal 'feel' the same. Ideally, the whole micro switch frame should be able to raise or lower, therefore giving an overall adjustment for the trigger point of the switches. It's a personal thing, as to how far down the pedal should move before it operates the switch, I know there's some debate about it. The best solution is have adjustability, experienced players can move swiftly and lightly, novices seem to want to stomp. If you describe the pedals in more detail, a 'best way' will be easier to find. Keith

Thanks Sasha, Hopefully I can do that, I've seen the comments in main.asm so I think I know what to do. thanks again, Keith

Thanks seppoman, I know the switch idea is probably not useful. I just wanted to get my head around the possibilities as I only want 2 pots. Now I realise how the AIN ports work. thanks again, Keith

Is it possible to connect pots and/or switches to the Core J5 (A or B) directly, without using AIN Module? Something like the two diagrams below, the Switch version would just be useful for any controller that only Min or Max was needed. Thanks Keith

Hi seppoman, You're probably right, but on the good side, as soon as my core, DIN, DOUT & LCD arrive, and are assembled & tested, If the MB64 isn't the right thing, I can always dump the midio128 in there instead! Plus I will have learned a bit more in the process. I will look closer at the MIDIO128, as you recommend, and see if it does seem better. thanks for your patience! Keith

Oh, sorry, I thought I mentioned. I just want to turn an Organ bass pedals (foot keyboard) into a midi controller using MB64. It's only 13 keyboard notes and I would add 10 to 13 Program change buttons with LEDs and a volume control. I'd like an octave up/down button (I know there's no midi command for this) but I can do this with pitch bend on a button (crude, but it works), and a note velocity adjustment pot (again I can find a suitable controller for the synth's filter instead). I don't really see why the MB64 application can't do this very simple task. I am taking your advice on just trying stuff out, well, I will as soon as my core, din, dout & LCD arrive. Keith

Hi seppoman, I do take your point about it being called 'midibox' for the fact that most people may use it for the purposes described. However, I think you are quite wrong on this point. Just look in the Midibox64 Editor, at the buttons page, you can choose note on, and the application will deal with the note off too. Thorsten clearly mentions it as a Feature. "Features up to 64 Pots or Faders, dynamic priorities: latency < 1 ms! :-) up to 64 Push-Buttons up to 64 LEDs one internal bank +16 external banks with every BankStick sends CC/Note/Aftertouch/PitchBender/ProgramChange". So it can be used as a keyboard encoder, plus, many organ midi-fiers (is that a word?) use note on data to operate stops and so on. It also sends Pitch bend & Aftertouch, clearly both keyboard designed facilities. Maybe I'm missing something here, the MIDIO128 was designed to receive midi input and translate this into physical switches or voltages. Quite the reverse of pressing a button and sending midi data out, i.e. MB64. I don't really get your point, am I totally wrong about the MB64, I can read ok, and understand some of the assembler in the application, most of it deals with sending midi data derived from knobs and buttons, or keys (they're just switches). Sorry, seppoman, if I sound argumentative, I'm not trying to be, just trying to make sure I don't get it all wrong. Keith

Yes, but as a controller, tranposing the notes, at least, would be a normal part of it? This is nothing to do with having information fed though it. Granted, it's not much use for knobs and faders, (unless you have 12 buttons and want to shift them all up/down by 12), but a small midi keyboard would benefit from such a function. Actually, using pitchbend to transpose, has one advantage. One can 'toggle' up/down an octave easily, and/or get a 2 octave range with 2 or 3 buttons (down 12 notes, center normal & up 12 notes). But the best advantage is that you can transopse whilst still playing a note. Software alterations would not make any difference until the next played note. Not elegant, as you say, but still a useful method. Keith

Well I can't get to my pedals right now, they're in transit. But here's a couple of diagrams that may help you. good luck Keith

Of course I could just cheat and make a few button that send full up/down or centre pitch bend messages and program all my synth sounds to bend by 12 notes instead of the more normal 2? That will be possible within MB64 as it is? Keith

Thanks Seppoman, That looks a lot easier than C. At least I can understand it! I wonder why the MB64 or MIOS has no transpose facility written in? Maybe everyone is more into being a knob and button twiddler than play a keyboard? Just teasing, don't get you're faders in a twist! :P thanks again. Keith

Thanks Thorsten, I have read lots, so I guess I'm in for a lengthy stay, lots to learn. Is there somewhere where I can get the PIC assembler instruction set? Keith