jimhenry

SM_DOUT_VALUE is a 1 of 8 bit code for the *next* column to be selected by DOUT: ;; determine DOUT value for *next* iteration step ;; this value gets active with the next latch pulse incf SM_BUTTON_COLUMN, W, BANKED call MIOS_HLP_GetBitANDMask ; (inverted 1 of 8 code) movwf SM_DOUT_VALUE, BANKED The SM_BUTTON_HANDLER_SHIFT MACRO is used 8 times in each loop of a column select to shift in the 8 bits of the DIN and shift out bits according to SM_DOUT_VALUE to set up DOUT for the next latch which will select the next column. This is the code that chooses when to shift the 0 into the DOUT shift register for the next column select: ;; set DOUT value bsf SM_SRIO_LAT_DOUT, SM_SRIO_PIN_DOUT btfss SM_DOUT_VALUE, 7-bit_number bcf SM_SRIO_LAT_DOUT, SM_SRIO_PIN_DOUT Because btfss tests bit (7-bit_number) column 0 is selected by Q7 of the DOUT register, column 1 by Q6, and so on. I tried changing the test to simply: btfss SM_DOUT_VALUE, bit_number There were no obvious problems and Q0 selected column 0 etc. which seems easier to deal with for wiring. Any subtlety I'm overlooking?

To confirm, is this a good concise statement of the data RAM usage: ;; Data memory layout (Data RAM) ;; 0x000-0x00f reserved memory for MIOS ;; 0x010-0x37f free memory for user applications ;; 0x380-0x5ff reserved memory for MIOS ;; 0x600-0xf7f free memory for user applications on 18F4620 ;; 0xf80-0xfff special function registers (SFR)

QBas removed the second loop in his scan matrix enhancements. I removed the second loop with no apparent ill effects. I think it is confirmed that it can be safely removed. I will contact you regarding repository access when I think my update is ready. Best Regards, Jim Henry

Now Graham and I are both trying to really understand sm_fast.inc so that we can create some switch matrix projects. I have commented SM_Init thusly: ;; -------------------------------------------------------------------------- ;; FUNCTION: SM_Init ;; DESCRIPTION: This function initializes the scan matrix. ;; It should be called from USER_Init ;; IN: - ;; OUT: - ;; USES: BSR ;; -------------------------------------------------------------------------- SM_Init ;; set button value to initial value (1) for all 64 buttons in data buffer lfsr FSR0, SM_ROW0_VALUE ; FSR0 <- first row address movlw 0x08 ; set Reg F as row loop counter movwf TMP1 SM_Init_Loop1 setf POSTINC0 ; set all bits for row and increment row address decfsz TMP1, F ; dec loop counter rgoto SM_Init_Loop1 ;; init values of all 64 buttons lfsr FSR0, SM_ROW0_VALUE ; FSR0 <- first row address movlw 0x08 ; set Reg F as row loop counter movwf TMP1 SM_Init_Loop2 setf POSTINC0 ; set all bits for row and increment row address decfsz TMP1, F ; dec loop counter rgoto SM_Init_Loop2 ;; deselect all columns by setting the DOUT data bit and shifting through all registers bcf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK ; clear the shift clock bsf SM_SRIO_LAT_DOUT, SM_SRIO_PIN_DOUT ; set DOUT data bit movlw 16 ; 16*8 shifts for up to 16 shift registers movwf TMP1 ; Reg F is the register loop counter SM_Init_Loop3 ; set and clear the DIO Shift Clock 8 times to shift through one pair of registers bsf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK bcf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK bsf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK bcf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK bsf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK bcf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK bsf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK bcf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK bsf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK bcf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK bsf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK bcf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK bsf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK bcf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK bsf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK bcf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK decfsz TMP1, F rgoto SM_Init_Loop3 ; loop though 16 pairs of registers ;; latch DOUT values that were shifted in by clearing and setting the DIO Register Latch Pin bcf SM_SRIO_LAT_RCLK, SM_SRIO_PIN_RCLK nop nop nop bsf SM_SRIO_LAT_RCLK, SM_SRIO_PIN_RCLK return Do have this much right? Why are the row values set twice, once in SM_Init_Loop1 and then again in SM_Init_Loop2?

I think DOUT is the column and DIN is the row. There is a parameter to reverse the polarity of the diodes but I don't know if that affects the row/column terminology. It might be useful to look at sm_fast.inc as modified by QBas for the 32x32 scan matrix to see how the size of the matrix was altered.

Perhaps this document will help: http://www.northparkmeadows.com/midio_mystery.pdf

Well, I guess everyone was enjoying their candy bars instead of debating. I really don't want to debate whether middle C should be reported as C4 or C3. I'll just say I think MIOS Studio and the LCD displays of the MIDIbox apps should report it the same. Now we can debate what that same should be... Walk ten paces, turn, and fire.

When you're standing in the middle of the forest looking at a bunch of trails leading off in all directions, all somewhat twisty and less than perfectly marked, it is natural to think there must be some better way to provide a path out of there. Once you become more experienced I think you'll find that those paths are less twisty and better marked than they looked when you weren't at a point that you could grasp all that you were looking at. I think you'll also realize that a good bit of the initial confusion is the result of the fact that people want to start off in all kinds of directions depending on their interests and that's why there is no clear cut direction to start off in. Remember that those who went before had less information than you have. Everyone has had to hack their way through some rough patches. A lot of them left some notes to help those who follow. It is better to view MIDIbox as an adventure game than a cookbook. My advice is to pick some modest objective of interest to you and then start working on achieving that objective. Accept that you will make some (or a lot) of wrong turns. Your wrong turns are learning opportunities. There are plenty of people who will give generously of their time to help you find your way back onto the path. By the time you reach your objective, not only will you have whatever it is you set out to make but you will have a lot of new knowledge that will be of use for other projects. Then you can decide what would have made your life easier and add that to the library of MIDIbox documentation. Remember, nobody gets anything for writing documentation except the satisfaction of helping others (who rarely acknowledge the gift BTW). By the time you know enough to write documentation it is of little use to you. I recently wrote a document about how to assemble a Core from a SmashTV kit (something that should be close to the top of the list for getting started). Writing that turned a 2 hour job of building a Core into an all day job. So that is 6 to 8 hours that I could have used moving my project further along that will instead hopefully move a lot of other people's projects along. So, as a wise man once wrote: Are you volunteering? :) If not... STFU! :D Yes, he and I are kidding. But truth is the basis of humor. Better documentation is not the result of requests. We all know the documentation could be better. All documentation could always be better. The documentation will be improved only by contributions, and they come slowly. So what you see is what you get. Hopefully someday you'll be contributing more for those who follow.

Graham is trying to MIDIfy on organ console. A 32x8 matrix is easier if the switches are set up as a matrix, i.e. the common bus is divided. Organs generally have a common bus for all 61 keys and may have a common bus that extends across an even greater number of stop switches. In such a situation, it may be easier to bring in all keys in parallel. What I think would benefit Graham is to start with TK's second switch matrix example and morph the 8x8 matrix into a 128x2 matrix. Actually, I think 64x4 might be more advantageous. I think Graham is hoping to finesse a single DOUT bit from the Core to do the 128x2 with 4 DINs. But you can do 64x4 with 2 DINs and 1 DOUT which saves 1 board and quite a bit of programming effort.

SPEEDY BEND LEAD FORMERS--5166-801 from Mouser About US$5

If that is being a PITA, bring it on! ;D Good idea! I'll make that change and then see if I can upload the PDF to be hosted here. I saw the info on how to include files after I initially did this. I've also added a second link under MBHP...Core.

Here's a possible LCD display: http://www.allspectrum.com/store/product_info.php?products_id=967 Mouser and Digi-Key are usually sort of expensive for LCDs. Pick up an HD44780 compatible 2x16 or larger from a surplus source.

I've added a link to a PDF document that describes how to assemble a SmashTV Core Module Kit in the DocuWiki under Basics, Practical Tips: http://www.midibox.org/dokuwiki/basics

In short, you set the MIDI channel in the .ini file as the second nibble of the command byte.

AFAIK (I haven't had to link to Cores yet) with MIDIIO128 projects you can set one Core to merge its MIDI In to the MIDI Out and just connect the two Cores with a MIDI cable. Easy-peasy. It is useful to get a different ID on the second Core so you can leave the Cores coupled and program one or the other with the same MIDI In from the computer. One of the great strengths of the MidiBox architecture is the ease of reconfiguring it. Just do what you need at the moment, or just something simple as a finger exercise, and then reconfigure as you grow.

You'll only need to use 1 of the contacts for MIDI. All the splitting can be done in MIDI from a single MIDI output produced by the console.

I would put the DIN in with the pedals and connect it to the Core up top with a 5 wire cable. A 6 wire mini-DIN cable used for keyboards and mice is inexpensive.

Consider the inputs when the problem occurs, one is at ground and one is at +5V. I think you get a low resistance path from +5V to ground from the off input to the on output. If that is the problem then either diodes on the output or resistors on the inputs might be the solution.

You need a Core Board to handle all the processing chores. You should have an LCD display so you can see what the Core is doing. You need 1 DIN Board to make the connection to the switches on the pedalboard. You will use the MIDIIO128 Project for the software that controls the hardware. There is a lot of information to digest so just take it at a comfortable pace. The MidiBox may be overkill for MIDIfying 13 bass pedals. I believe there are more specialized boards that are limited to a small number of inputs that can do the job. It might be easier to use one of them. However, I am a dyed in the wool MidiBoxer and I don't know much about these other solutions beyond knowing they exist. You might want to sign up for the Forum at www.virtualorgan.com and look through the messages in the MIDI Electronics area. That site is devoted to virtual theatre organs. Even if you aren't interested in theatre organs the folks over there have a wealth of experience in the area of MIDIfying organ consoles.

Actually you said you spent "a lot of time looking" and that isn't necessarily the same as using the search tools. I think the discussion you are referring to is in the Miditzer Forum. There is a long rambling thread about ways of building a stop rail in the MIDI Electronics area. The discussion of toggle switches in MIDIIO128 and tracking the state of the combination memory starts here: www.jbwebserver.net/mforum/forum_posts.asp?TID=718&KW=toggle&PN=7 As far as I know, the modifications to MIDIIO128 that would be necessary to make the toggle input memory respond to external changes in the switch state caused by MIDI In messages that change the state of the DOUT LED indication that tracks the toggle in state have never been discussed in meaningful detail anywhere. For the lurkers, the Miditzer is a free software program that emulates a Wurlitzer theatre pipe organ. Many Miditzer users build consoles for their virtual theatre organ using the MidiBox. So there is a lively discussion of Midification issues that are specific to organs in the Miditzer Forum. If you are midifying an organ console, you might find some useful information in the Miditzer Forum even if you aren't using the Miditzer.

The hardware for MIDIO128 is 1 Core plus up to 4 DIN and 4 DOUT, all available from Smash.

Yes. Enable the MidiMerge setting in the MIDIIO128 .ini file to merge the MIDI In with what is generated on the board.

Have a look under "Basics" in the DokuWIKI.

Each manual is set back 4.25 inches. Here is a link to a drawing of an AGO spec console: http://www.jbwebserver.net/mforum/uploads/20070917_170840_agoconsole.pdf

Manuals are 2.5 inches from key top to key top. They can also be slightly angled so the upper manual rises toward the rear. I don't have the amount of this close at hand. It's slight but it makes the keyboards more comfortable to play and it might help with clearances. If you want to slope the upper board I can track down the spec. I plan a similar project and I am thinking in terms of a wood case based on my tools and skills.