Duggle

There a different ways an I idea like this could go. One approach is to make it a subsystem that is as transparent as possible. This means that it interfaces to an existing Midibox without any modification to the (host) Midibox firmware. This way all display/setup and other functionality as to how the keys are used is up to the Midibox firmware as it is currently implemented. The way I can see of doing this is to have a small say PIC16F84 application scanning the keyboard codes as per the project link above. The PIC then loads a 64bit serial/serial shift register with the keyswitch states which are in turn shifted into MIOS by the normal DIN operation. The 4517 is a low cost dual 64bit serial in/out shift register in DIP16 package.

The idea is a MBHP module which interfaces to a standard PC QWERTY keyboard (anyone can get these 2nd hand cheap or free) and produces IIC slave output to connect to IIC bus of 18F MIOS core. This way a user can have a reletively hugh array of dedicated midi event triggers for very little cost or construction effort. The module plus DIN keyboard socket could be added to many (any?) existing MidiBox. I imagine that the module would output an array of bits or event messages which the MIOS Core would translate and include in the MIDI output stream. In this way the great diversity of user requirements is satisfied by modifying the MIOS host (the core application).  The module code itself should not be particularly complex and should not require user customisation.I imagine a Core PCB "stuffed" with a 16F877 would surfice. In fact the layout could be simpler than that of the core.  If customisation is neccessary (it probably isn't) then the module could  itself be MIOS 18F. The QWERTY keyboard could be spraypainted a new colour and decals or other custom labels to replace the existing key markings. Possible uses: Midi Remote - dedicated application shortcuts and functions Mixer - dedicated per channel buttons (mute, arm, solo, select, etc.) Instrument - bazaar midi piano accordian (use wireless QWERTY to really rock!) Edit: found some tech info here: http://www.electronic-engineering.ch/microchip/projects/keyboard/v1xx/keyboard_v1xx.html Infact an adaptation of this 16F84 application would be a highly compact cost effective implementation.

MBHP Din module accepts wires from switch contacts and can trigger midi events (eg note on/off) and special functions. In finding your feet it will help if you familiarise yourself with the MBHP modules and roughly what they do (ucapps.de). Then look at some of the schematics which show midibox implementations to see how it all fits together. There are many combinations of modules that can be configured to fulfill just about any requirement. cheers

Looks and sounds wicked, great concept also! Well done. Using PC hardware in embedded form such as this has a huge future. I'm no expert at all but I understand linux has embeddable flavours, so that there may be ongoing device driver support and community involvement in the OS side of things into the future... I just did a google search and got >2M hits, so there seems to be a lot of activity in this area. Anyhow, what youve done should raise a lot of interest because it's very much ahead of it's time. cheers!

.....I think I agree with your wife ;D

I'd be interested too! ::) edit: PS up to 20 would be great

Try experiment with a capacitor of say (10.. 100uF) across the 10k pulldown. This will smooth any AC component of the vibrating flap. Will need to experiment with the values in the cap and pulldown if there is too long "attack" and "decay" introduced. I think without the cap there maybe a a lot of jitter on the midi CC output. Also consider that LDRs have various response times depending on their design. You may be able to use this fact to your advantage!

Another idea is to have an LDR (light dependant resitor) connected to +5V with a (say) 10k pulling the other side of the LDR to 0V. The analog voltage is at the junction. Choose an LDR with a dark resistance of several Mohm and a light resitance of a few hundred ohm or (even a few kohm). Use a high intensity LED, and make the arrangement small so that good transfer is achieved. I imagine that the valve is a rubber flap against a round or slotted apperture that is completely closed when there is no air velocity. As air passes through the apperture the flow rate exerts a proportionally larger force, creating a larger opening allowing accordingly more light onto the sensor. The shape of the apperture should have an effect on the linearity of the output. cheers

hi, follow the general trend of the supplied pcb's of MBHP to a provide basic guidelines. If you keep wires and tracks within the recomended lengths you should be fine. The most important thing for these circuits is a clean powersupply. The 5V regulator on the core is definitely sufficient so long as it is driven by an adequate supply. (9VDC under load). One common engineering practice that Thorsten doesn't seem to follow is to connect 100nF (or thereabouts)monolithic caps across the 5V rail of (each) the logic ic's. This is more of a precausion against glitches that may come about under more or less unusual circumstances. The obvious success of MBHP says theyre not strictly necessary for correct circuit operation. I used them on my midibox out of habit (accepted design practice). cheers

Does FSR2 get saved and restored in the ISRs? (if not then it can't be used in user routines without disabling interrupts)? MIOS routines use FSR1 so if I use FSR1 completely in-between MIOS calls it should be ok? (MIOS may destroy FSR1's content) Are there any dangers of using FSR0? (It gets used by main, are there any user hooks that should restore its content for use by main? thanks

Hi, Building a custom midi keyboard is a fairly unusual requirement as they are expensive and reletively complex and to implement(unless you dont want velocity :()). There are so many low cost keyboards out there that it would be difficult to justify the time required. Maybe you could convert a second hand midi synth and build-in midibox h/w for controls/ knobs/ buttons/display etc. cheers

Hi, I've just realised the significance of BSR register for making sure RAM is accessable. My understanding is as follows: ;;use macro SET_BSR my_var ;;can now access vars on same ram page as my_var ;;so long as BANKED flag is used with instructions. movf my_var,W,BANKED So my question is (to try to complete my knowledge): When don't one use the BANKED flag? Are there tricks or techniques to reduce the use of SET_BSR when working with algorithms that use variables from different RAM pages. thanks for any comments

thanks, it works, it is now clear how other defaults may be set also! :)

hi, I'm not sure where to what line to alter to get the default merger state to OFF. I'm getting feedback every time I download reassmbled code. (I have to manually change this in the menu every time..) thanks

"..accent slide nothlengh?" Accent is implemeted by a layer assigned to velocity. Notelength is known as gate which is assigned a layer. I suggest slide could be implented on a track which generates portamento time CC's. cheers

It seems like steinberg might be moving to an open standard for HW controllers! http://forum.cubase.net/forum/Forum2/HTML/055180.html I guess one shoudn't hold breath but the statement looks promising.....

Sounds like a classic application for MIOS. However, I've never seen mention of anyone developing for RS422 or AV protocols on these site. This means that you would need to be willing to do it yourself. MIOS would appear to be an excellent platform for what you want. cheers

hi, I use ini2syx method of programming banks which works as before so I guess this means the sysex structure is same/compatable. So I would say vMidibox will work also. cheers

This is of course up to you: "..my sale of midibox related things is not profit motivated.." but if you do make a good profit then everyone is happy (as I see it) and you can continue to build even greater capability. I really like the concept and implementation of your site. I speak for myself (and perhaps others) when I say that I only purchase from overseas mailorder as a last resort. This is because of postage and handling expense, possible delay and sometimes minimum order quantity as well as customs duty. I'm planning a MB LC/MC (I built a midibox64 in 2002) and I will probably have to make about 4 mailorders to different sellers around the world. This will be expensive. "Can I beat or match the price the builder can buy it directly for?". I guess this depends on the uncertainty of sales, cost of credit, operating overheads etc. I just point out that the real cost to the builder of sourcing parts for themselves is deceptively high. I suppose you have researched these issues and made a judgement so all I can say is that based on my perspective, as a builder, is that I would be willing to pay a premium to be able to get all my midibox needs from one supplier. How many others would is the $64 question. best regards

hi SmashTV, I just visited your site and am impressed. I suppose the question has been put, or you have considered this, but certain parts for MBHP are extremely difficult to get in smaller quantities (say<250 pieces) or otherwise difficult to source. The overheads involved in making various mail orders to lots of different suppliers make "one stop shopping" extremely attractive! Have you considered stocking these? Non-detented Rotary Encoders Motor faders GLCD and 2*40CLCD USB IC AN2131SC It would be great if there was a Midibox stockist who had all the hard to get stuff in one place! It may have another benefit, and that is perhaps it would encourage standard components that may make community firmware support more effective. I accept that overseas mail orders are inevitable but it would be really helpful if I don't have to make several or more orders just to complete a single project! Keep up the good work

DrB, I like the idea to cut slots for groups of pots, unfortunately the buttons on my box are relatively large in the relation to the spaces around them. This would not leave much material for the text to be on. Then again this may be the way to go. Unfortunately most LCD's arent very compact (meaning they require space beyond the profile of the screen. This means that there would need to be lots of space around the controls. Mackie use a long thin display something like a 40*2 and positon a row of 8 encoders in front. I like this. Perhaps 40*2 display for every row of 8 encoders. cheers

hi Thorsten, great news, but I can't see the file in MIOS downloads... :'( thanks and regards

hi I have build a MIDIbox64 which is very compact. I have scanned my front panel and I can use this as a template to create custom "skins". (See 2nd picture midibox64 on keyboard) http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=gallery;action=display;num=1065048413 The images on the left show a paper overlay over the pots section. The idea is to print (colour bitmap) graphics with text for each knob and button to work effectively in a particular bank (eg VSTi synth, mixer desk, analog sequencer,..etc) The overlays can be printed with a colour inkjet using banner paper of normal A4 width. It can be laminated with plastic film for little cost. The design challenge is to devise a way to make holes for 64 pots (8mm) and 30 buttons (14mm). I can make the rectangular hole for the display with a knife and ruler. I'm thinking of some kind of hole punch tool that can efficiently cut paper/plastic film with a minimum time and effort. I would like to be able to knock up a skin for a new bank with the minimum of fuss. If anyone has ideas on hole punching methods, I'd be greatful. Anyhow, I hope this provides inspiration cheers

hi, I've been searching but not yet finding info on the construction (and any other info) regarding the logic/mackie (Midibox NG?). I seem to remember seeing some pics posted by Thorsten documenting his prototype (this was some months ago.). I cant seem to get very good results from the forum search function. Does anyone have a link to this posting? I have the MIOS LC application source to examine, but I'm interested in a slightly higher level view at the moment. I've been looking at the mackie/cubase SX pdf doc and this is very helpful to visualise how it would be to use without having one to play with. Does anyone know of a high level description documenting the protocols used? thanks for any help or comments

hi, each base should have it's own current limiting resistor (I assume youre driving BC547 or similar) value 1k to 10k typical. regards