TK.

So long as you don't use the MIDIbox with a display, the order doesn't matter, since the pots are free assignable. A changed order could also be irritating when you plan to use Serge's MIDIbox editor for the configuration of MIDI events Best Regards, Thorsten.

Hi Klaas, thats not exactly the point, but you will regognize the difference when you start to play with the code. The first example doesn't need a branch with the IFNEQ macro (If-Not-Equal), since simply the pot number and the pot value will be sent out. Pot #0 will send: B0 00 <value>, Pot #1: B0 01 <value>, Pot #2: B0 02 <value>, ... Your modification for the second example will work. And you see that this method will lead to a lot of code (and therefore to a high danger that anything will not work due to a copy&paste error or similar). But fortunately there are two more advanced solutions: array and jumptables. An array can be accessed by the "table read" instruction on this way (I don't write the complete code here, because can be found in the examples later): (Note: the functions with capitalized letters are predefined macros which simplifies the programming - they contain some additional instructions)  ;; get 7-bit value of pot, result in working register    call   MIOS_AIN_Pin7bitGet     ;; save value in MIOS_PARAMETER1    movwf  MIOS_PARAMETER1   ;; preload table pointer with first entry of MyCCTable  TABLE_ADDR   MyCCTable  ;; get pot number  movf   SAVED_POT_NUMBER, W  ;; add pot number in WREG to table pointer  TABLE_ADD_W  ;; read table entry  tblrd*  ;; get table entry, it has been stored in TABLAT  movf   TABLAT, W  ;; this is our CC number. now set the CC parameter  call   SID_CCSet  ; (value in MIOS_PARAMETER1)  an example for the table: MyCCTable     ;; define CC values for Pot #0 - #16     db    44, 46, 48, 52, 56, 60, 61, 62, 01, 02, 03, 04, 05, 06, 07, 08 This reduces the code a lot and different banks can be defined on this way. Another advantage: for users who don't like programming, a GUI could be provided which allows to edit such tables. The second method are jumptables. It's like a "case" function in C. Here an example for the buttons: ;; this routine will be called when a DIN pin has been toggled. ;; DIN pin number in WREG and MIOS_PARAMETER1, ;; DIN pin value (0 or 1) in MIOS_PARAMETER2 USER_DIN_NotifyToggle  ;; branch depending on pin number (which is in WREG)  JUMPTABLE_2BYTES 4  ;; 2-byte instructions, 4 entries  rgoto   DIN0_MIDIChannelDown  rgoto   DIN1_MIDIChannelUp  rgoto   DIN2_DeviceNumberDown  rgoto   DIN3_DeviceNumberUp DIN0_MIDIChannelDown  ;; only continue if button has been pressed (value = 0) movlw 0 IFNEQ MIOS_PARAMETER2, ACCESS, return  call   SID_MIDIChannelGet  addlw  -1  call   SID_MIDIChannelSet  return DIN1_MIDIChannelUp  ;; only continue if button has been pressed (value = 0) movlw 0 IFNEQ MIOS_PARAMETER2, ACCESS, return  call   SID_MIDIChannelGet  addlw  1  call   SID_MIDIChannelSet  return ;; ... Best Regards, Thorsten.

A Windows version of gimp? Cool! Yes, gimp is also one of my favourite tools, but it doesn't offer a grid mode for bitmaps - or where can I find this feature? Best Regards, Thorsten.

Ah, now I understand the problem. I haven't noticed that the Gallery is offline. I moved the pictures to my old (5 year old) tripod account since the downloads on the puretec server produced too much traffic (more than 2GB extra). Ok, I've already an alternative free account at www.8ung.at and will try it there again. Best Regards, Thorsten.

Both are ok - take the cheapest one :) Best Regards, Thorsten.

Hi, ok - here an illustrated guide: first cut the cable ends with a cutter: the cable ends should be tinned to ensure proper junctions: also the connectors should be tinned: now you can solder the cables to the connectors very easily without additional tin: Best Regards, Thorsten.

If your keyboard has no Thru port, it possibly also provides an integrated merger - this would be perfect! Which keyboard do you own exactly? Best Regards, Thorsten.

Ich selbst kann mittlerweile schlecht einschaetzen, ob fuer einen Neuling die Programmierung anhand von Vorlagen (Copy/Paste/Modify) schwierig ist, aber spaetestens bis zum Wochenende sollten die Beispiele fertig sein, so dass Du Dir selbst ein Bild darueber machen kannst. Gruss, Thorsten.

Hi, I can confirm this. Thomas (who built a mega-midibox with a lot of motorfaders) had the same problem. Best Regards, Thorsten.

Hi Klaas, any help (especially for the applications) is appreciated. With the MIOS functions it will be easy to learn PIC assembly, since the difficult jobs are handled by the operating system itself, and you only have to control the data flow. Here a short example, how to realize an application for common software synthesizers like Reaktor, Reason, etc. --- for such programs, the controller has to send unique MIDI events for each pot: ;; this driver hook is called by MIOS when a pot has been moved ;; pot number in working register MIOS_AIN_NotifyChange ;; save the pot number movwf SAVED_POT_NUMBER ;; get 7-bit value of pot, result in working register call MIOS_AIN_Pin7bitGet ;; save pot value movwf SAVED_POT_VALUE ;; send a unique MIDI controller event on channel 0: ;; B0 <pot-number> <pot-value> movlw 0xb0 call MIOS_MIDI_TxBufferPut movf SAVED_POT_NUMBER, W call MIOS_MIDI_TxBufferPut movf SAVED_POT_VALUE, W call MIOS_MIDI_TxBufferPut ;; print the value on LCD at position 14 (first line) movlw 14 call MIOS_LCD_CursorSet movf SAVED_POT_VALUE, W call MIOS_LCD_PrintBCD3 ;; thats all return And now the same example for MIDIbox SID/18F if you would like to control the cutoff parameter with pot #0 MIOS_AIN_NotifyChange ;; normaly we would use the table jump method here (64 gotos ;; in a table) - but this is just a simple demonstration ;; save the pot number movwf SAVED_POT_NUMBER ;; if pot number is not 0 (first pot), branch to another routine movlw 0 IFNEQ SAVED_POT_NUMBER, ACCESS, rgoto NotPot00 ;; get 7-bit value of pot, result in working register call MIOS_AIN_Pin7bitGet ;; save value in MIOS_PARAMETER1 movwf MIOS_PARAMETER1 ;; forward the value to SID CC#46 movlw 46 call SID_CCSet ; (value in MIOS_PARAMETER1) ;; thats all return NotPot00 ;; do something else ;; ... return Such code snippets can be uploaded within one second to the MIDIbox... And by using tables (arrays), the configuration can be clearly arranged. I hope that the upcoming examples and applications will provide enough inspirations :) Best Regards, Thorsten.

Hi Klaas, major problem of the PIC16F architecture are the memory limitations, therefore it wasn't possible to offer such a high flexibility like with the PIC18F. In theory it could be possible to include an ADC driver for some pots to the PIC16F firmware of MIDIbox SID, but this would result into a lot (!!!) of effort for me - to find some free RAM, some free program memory in the 4 memory banks, and to build the hardware in order to test the extension. And the next guy wants to use rotary encoders, another guy wants a sequencer... not with me ;-) Since I don't use the MBSID in this configuration, this would be lost time for myself. But with MIOS everthing will be changed. All routines which are necessary to handle with the MBHP modules (pots, faders, motorfaders, rotary encoders, buttons, LEDs, LED rings, LED digits, LCDs, BankStick) are already available and accessible by a simple software interface. Therefore it will be possible for the users to add their own extensions to the application source code in order to customize the box. I will provide some examples which can be copy & pasted into the code. My hope is, that with this concept other users will begin to distribute their customizations :) Btw.: In theory also a graphical user interface could be programmed like known from Reaktor which allows to create the "functional connections" between the modules and drivers. But this will not be my job. In the meantime you've to work with your favourite texteditor ;-) Best Regards, Thorsten. P.S.: regarding performance: I noticed that possibly the whole MIDIbox LC (8 motorfaders, 96 buttons, 64 LEDs, 8 rotary encoders, 8 LED rings, graphical LCD) can be handled by one PIC18F core with a latency of ca. 1 ms!)

Problem is, that MSpain(t) isn't really usable and the others are commercial solutions. I haven't found a freeware which can be used on the same erconomic way like xpaint, although xpaint does exists for more than 5 years now ;-) However, I will add support for .bmp files into my converting script, so that this format can also be used. ".xpm" is a special unix format which contains the picture in ASCII text (one character for every pixel), so that it also can be edited with a texteditor. Best Regards, Thorsten.

Hi Dimitris, no, it has a different interface. But if you need an adation, just send me the display for one week and I will integrate an option into MIOS. I already prepared the functions for different LCDs Best Regards, Thorsten.

Hi, yes, thats correct. Only solution is a MIDI merger: Best Regards, Thorsten.

Hi Mitch, no, there is no easier way. But so long as you are using ribbon cables (known from computers), it isn't much effort, since these cables are very easy to solder. Here an example: Although this wiring looks chaotic (since it has been made very quickly), it still works without failure. Best Regards, Thorsten.

Hi Mitch, no, this isn't supported by the firmware and it isn't planned for the future, because with the MBHP designs I'm already providing a better solution for more buttons. Every extension of the MIDIbox Plus would go to the direction of MIDIbox64... Best Regards, Thorsten.

Hi Clae, Yes, due to the modular concept of hardware and (PIC18F) software this will be possible. You will also be able to temporary use your box for other applications. In fact with the new MIOS concept the MIDIbox is not far away from a homecomputer! (how about an interface to the 1541?) ;-) No, for every SID a dedicated core will be required. My private focus is a high-quality sound with additional, software emulated sound features. This requires CPU performance. The current MIDIbox SID implementation already loads the system about 50%. The other half is required for the realtime behaviour on incoming MIDI events (latency should be less than 2 mS). Sure, it would be possible to remove some features in order to connect more SID chips, but this is not in my interest... a PIC costs just 8 US$... ;-) Yes, this will be possible. This feature is required anyhow in order to control the "slave" cores. For myself this wouldn't be so usefull, since I already built al step sequencer. But the source code of the SID will be published, so that everybody is free to add and distribute his own extensions. The source code of the MIOS based MIDIbox64 SEQ will also be published... Thanks :) Best Regards, Thorsten.

Hi, it seems that this is really an overheading problem. You can reduce the temperature by using a lower input voltage. It should be between 6V and 9V. Note: due to the law of energy conservation the 7805 has to transform the "unused" energy, which is linear to the voltage difference (input_voltage-5V) and the current load, to head. That means: than higher the current, than higher the input voltage, than more head will be produced. Best Regards, Thorsten.

Hi Matteo, since your MIDI In is working, you don't need to exchange the CNY17-II by a 6N138. Only the additional line to the LCD is required. And the new firmware of course. Maybe you will notice a better performance with your breath controller, since LCD accesses don't slow down the ADC driver anymore. Best Regards, Thorsten.

This time a question by me ;-) Under Linux I've a small but really usefull tool called "xpaint" which allows me to edit bitmaps for the graphical display very efficiently. It provides a high zoom level of 20 and more and it features a grid view which is very important for editing small characters and icons. Does anybody know a tool for Windows which offers similar features? high zoom factor grid view basic drawing tools (pen, line, circle) text editing two-colour bitmaps optionally export to the .xpm file format It's not for me, but for the users who want to change the bitmaps for their MIDIbox NG. ;-) Best Regards, Thorsten.

Hm, sieht eher nach einem Mix aus Houston und Mackie Protokol aus (oder die Houston Leute haben einfach das HUI Protokol abgekupfert ;-)) Ich selbst werde fuer dieses Protokoll kein "MIOS Application PlugIn" programmieren - bin halt Logic und somit LC user - aber wer moechte, kann es von einer der demnaechst erscheinenden Applikationen ableiten. Gruss, Thorsten.

Fine Ian - it seems that bad solderings are mostly the reason for the fails, so I can only suggest to check the connections again, again, next day again and again ;-) You made a cool panel foil, Dan! Hopefully I will find a similar foil in germany for my control surface... :) I will add the pictures to the gallery soon! Best Regards, Thorsten.

Hi David, All MIDIboxes can send NRPN by using "Meta events" (programmed sequences of MIDI events). However, MIDIbox64 works with 8 bit resolution internally, the max. resultion is 10 bit, but this requires some additional programming effort. MIOS offers 10 bit by default (see Concepts->MIOS->Status) For higher resolutions it's better to use rotary encoders, because more than 10 bit cannot be handled by affordable pots/faders Best Regards, Thorsten.

Hi Rogic, the receive button requests a dump from the MIDIbox (-> MIDI In/Out has to be connected). But I think that you want to send a dump? Best Regards, Thorsten.

Hi Dave, some pictures can be found here: http://www.midibox.org/midibox_lc_photos/index.html http://www.midibox.org/midibox16e_photos/index.html http://www.ucapps.de/midibox/midibox64_foto3.jpg http://www.ucapps.de/midibox/midibox64_mf_inside.jpg (expired design) Best Regards, Thorsten.