TK.

Addendum to Pay_c's answers: Maybe the simplest solution: you could enhance the button handler in cs_menu_buttons.inc by a function which calls CS_MENU_ENC_CS_Handler with following input parameters: the encoder number which relates to the button, and incrementer=0 (!). This means: the CS will change to the correct menu entry but won't increment or decrement the value. Create 15 functions for 15 encoders and assign them to the buttons in cs_menu_io_tables.inc read the comments in midi_rxtx.inc Best Regards, Thorsten.

The reason why I'm suggesting a 20x2 display is, that it allows to display the 5 parameters which are also assigned to the 5 encoders of the OSC and ENV group. However, the "CS_MENU_DISPLAYED_ITEMS" setting should work fine... Best Regards, Thorsten.

To 1) it's better to run the upcoming MIDIbox MF on the second core (see also the roadmap) since it will provide the "MIDIbox Link" feature To 2) in theory yes (you can switch between the LCDs by calling MIOS_LCD_Init with different parameters) , in practice you have to program such stuff by yourself, since possibly nobody uses such a configuration. Best Regards, Thorsten.

correct - it depends on the used IIC devices. You should find the required informations in the appr. datasheets. Best Regards, Thorsten.

Sure, the MIOS based MIDIbox64 it is compatible with Serge's vmidibox64 editor (but note that the transfer rate has to be changed, see ChangeLog!) Bosone: No, I see no way to adapt MIOS and the MB64 application to the expired MIDIbox Plus hardware - the maintenance and documentation effort would be too high and some applications would have to take care for the different pinout. It would be much easier if you would just make your board MBHP compatible! ;-) Best Regards, Thorsten.

Hi *, I'm back - some words to your questions: This roadmap only lists my plans for "MIDIbox controllers". Of course, other tasks will run in parallel. ;-) Some words to the AOUT module: I already wrote the driver some months ago, it can now be found at the MIOS download page. But the hardware is still uncomplete - since I don't own an analog synth with CV inputs yet, I'm just not able to test the circuit - and I don't want to start with a PCB before the module works perfectly. If somebody is interested, I could create a schematic of the current circuit with a cheap voltage reference and an output voltage range of 0V and 4.096V - the final module should come with an improved v reference and an OP-amp driver for extended voltage range (e.g. 1V/octave) Possibly you misunderstand me, there is no "NG platform", there is the one and only MIDIbox Hardware Platform MBHP and the one and only operation system MIOS. MIDIbox NG is just an application which simplifies the use of pots/encoders/motorfaders/buttons... at the same time without modifying the source code, and it will provide an additional API to simplify the integration of custom extensions (programmed and shared by the community). MIDIbox NG is just a spin-off project of the MIOS based MIDIbox64/MIDIbox16E/MIDIbox MF/MIDIO128 applications, just a variation - and I think that it will provide all the features which are necessary to setup a flexible controller w/o programming skills. It should cover all the needs for a "generic controller". I prefer not to talk about my other plans, just to prevent that anybody relies on it (see MIDI router, which was nothing more than a suggestion...) --- and to prevent that this forum reaches the file quote again ;-) Best Regards, Thorsten.

Hi Ian, I never promissed to start this project, I only proposed how it could be realised and made a schematic to clarify the principle. I wrote that I maybe would program the firmware if somebody would build the hardware for me (just for having fun during the programming of a multi-slave system). In the meantime I created the MBHP_USB so that I don't need a router as multi-MIDI-IO interface anymore (I've 3 of them, makes 6 MIDI IOs, and the routing works great with MIDI-Ox), and I have a lot of plans for the next months. So I can only say: you have to search somebody else who is interested in implementing such a hardware. Best Regards, Thorsten.

All these features are already provided by MIOS, so in fact MIDIbox NG is MIOS + a frontend for people who don't want to start with assembler programming. ;-) Best Regards, Thorsten.

is now available for download. Thanks to all beta testers who checked it with their hardware! Application: MIOS->Download->midibox64_v2_0.zip ChangeLog: http://www.ucapps.de/midibox64_changelog.html Updated Tutorial (not complete yet): http://www.ucapps.de//midibox64_tutorial_en.html Unfortunately I've no access to the internet in the next days, so if there are open questions, just search for the answer in the source code ;-) Have fun! :) Best Regards, Thorsten.

To keep you informed how I will proceed with the MIDIbox projects, I will give you an insight into my plans for the next weeks/months: All PIC16F projects will be "phased out" until end of this year to avoid any confusion about the hardware. This means that all references to the PIC16F will vanish from my website (ok, maybe I will create an archive for interested people...). The reason: In the last time I oftenly get mails from newbies who are asking for features which are already implemented in existing projects - more than 16 pots, more buttons, using encoders and pots with a single core, larger display, etc... they didn't read the MIOS page and therefore were not informed about the endless flexibility which is only given with a PIC18F. I also want to prevent that they are starting with hardware which is not supported anymore (since I already migrated all my own MIDIboxes to MIOS) the MIOS port of MIDIbox64 will be released today. Together with MIOS this application already includes the basics which are required for the other projects the MIOS port of MIDIbox16E will be the next one, release date: end of this month the MIOS port of MIDIbox MF will be released together with MIDIbox16E thereafter the MIDImon and MIDIO128 port will be released and at last the MIDIbox64SEQ port end of november the MIDIfilter/processor is already included in MIOS, only the documentation has to be updated the MIDImerger will possibly stay the only official PIC16F project (together with a IIC slave --- later guys ;-)), but I plan to release a PIC18F version, too... After every project has been ported to MIOS, I will start with the final MIDI controller supported from my side: the MIDIbox NG MIDIbox NG will be nothing else than a combination of MIDIbox64, MIDIbox16E, MIDIbox MF and MIDIO128 with a new, more flexible data structure. MIDIbox NG won't be the "all-in-one device suitable for every purpose" (German: "eierlegende Wollmilchsau"), but the easiest way to send MIDI data from pots/faders/sensors/motorfaders/rotary encoders/buttons from a single core without modifying the application software. Special controllers, totally customized to synths, HUIs, Fx gear or whatever will still require their own application software. But MIDIbox NG will be a very powerful generic controller application, which will run on any MIDIbox hardware (not only on MB64/16E/MF/MIDIO128, but also on the MIDIbox SID control surface or the MIDIbox LC - for example) and which will interact with any MIDI soft- or hardware which supports generic MIDI control. Additionally to the features provided by the new MIDIbox64 release + the upcoming MB16E/MF following functions are planned: new data structure which doesn't rely on a static number of pots, buttons, etc. labels will also be provided for buttons (in fact for every physical input) support for button & LED matrices (to save some DIN/DOUT modules) unlimited number of events which can be sent, but limited number of events which can be received (to set the pot/fader/encoder position, MIDI controlable LEDs..) - possibly 156 alternative "generic receiver" which allows to receive up to 512 values (in this mode the type of MIDI event cannot be changed, only the channel can be selected) multiple banksticks remote control for all functions direct assignment of MIDI events to pots/buttons/faders/etc... from external via SysEx (so that a setup can be saved in a song e.g.) individual assigment of pot behaviour mode for every single pot more flexible meta event handler which provides additional control flags, e.g. for a more elegant realization of NRPN controllers a semi modular software concept which allows the users to add and share drivers - e.g. for LED rings, LED digits, display pages, menu extensions Planned release date: 25. Feb 2004 at 1:22 AM ;-) Best Regards, Thorsten.

Don't understand me wrong: I'm not interested in programming a .wav player, it's too boring and the result wouldn't be very useful for making music. But feel welcome to program this by yourself ;-) Best Regards, Thorsten.

See also: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=misc;action=display;num=1061917936 Best Regards, Thorsten.

Hi, you can freely assign the DOUT shift registers to DIN shift registers or other functions (e.g. MB64 allows to indicate the selected bank with 16 LEDs). See the upper right corner of this snapshot: The first button of a DIN shift register relates to the first LED of a DOUT shift register, etc... Best Regards, Thorsten.

This time the modular MIDIbox by Noskule (made in Switzerland, see also http://www2.snm-hgkz.ch/~b/Projekte_Hauptstudium/KBEEKRJE/docu/midibox.html) And the handy controller in slim line case by Douglas (made in Australia): (see the gallery for further descriptions)

dito.... ;-) ordneren: just wait for the next release (after my holidays), it will make clear how to create customized/animated fonts. In the meantime you could already play with the script in the utils directory, but it requires a paint program which supports the .xpm format (support for the windows-specific .bmp format is planned for the future) Best Regards, Thorsten.

Hi Ian, is this entry located to the correct address? Maybe it has been changed during your modifications. Just take a look into the main.lst file, search for "MIOS_MPROC_EVENT_TABLE" and ensure that it is located at 0x003080: 003080 00063 MIOS_MPROC_EVENT_TABLE The entry for button #48 (==0x30 hexadecimal) should be located at 0x0030E0: 00118 ;; entry 0x30-0x3f 00119 MT_ENTRY 0xb0, 0x30 0030E0 30B0 M dw (0x30 << 8) | 0xb0 Best Regards, Thorsten.

Hi Xan, the HCF4051BE is working, but did you take into account that the AIN example 3 demonstrates how to realize a soft-overtake function (which doesn't send any MIDI value until the pot reached the received position for jumpless changes). It's better to try it with a test application like ain64_din128_dout128_v1_3 You could set the number of connected pots to 1 in order to check a single 4051 with a single input. You could run the AIN driver in "UnMuxed" mode (see main.asm) and stimulate the select pins (PORTC, 0; PORTC, 1; PORTC, 2) of the multiplexers directly. Best Regards, Thorsten.

The wiring doesn't matter (so long as vss, ground, SCL and SDA are connected together in parallel), it's only important that every BankStick in the IIC network has its unique address. Best Regards, Thorsten.

Could somebody of you please check if one of these drivers is working under XP: http://www.ucapps.de/tmp/cypress_drivers.zip the .inf file is located in the root directory, the .sys files can be found under */lib/i386/free/*.sys Best Regards, Thorsten.

fine! :) Best Regards, Thorsten.

Steve wrote a very useful FAQ for the MIDIbox LC which can be found under Miscellaneous (and hopefully in the MIDIbox portal sooner or later :)) Once you know which MIDI events have to be transmitted and received, the MIDIbox LC application can be adapted to any other HUI very easily. You are also able to switch between different HUIs without opening the case, etc... just load the alternative application into the box. So, there is no compatibility issue or whatever, there is only the need for a meaningful documentation from the Hardware/Software manufacturers. Best Regards, Thorsten.

Since the transistors are not used as an NF/HF amplifier, but as a simple driver (in other words: an overloaded amplifier) here, no special calculations are required. Just take 1k and it will work Best Regards, Thorsten.

The Mackie protocol doesn't send the absolute position of encoders, but only the LED pattern. So digits are not really helpful. sure - maybe an option which will be provided next year from my side, but if anybody else wants to program it, just try it - the basics still exist. Best Regards, Thorsten.

The Mackie protocol doesn't send the absolute position of encoders, but only the LED pattern. So digits are not really helpful. sure - maybe an option which will be provided next year from my side, but if anybody else wants to program it, just try it - the basics still exist. Best Regards, Thorsten.

A nice and especially clear design! :) I've only one request (hope that you don't feel attacked, I'm just a perfectionist ;-)) we should find a way to prevent that informations will be spreaded over three sites (uCApps.de, Portal and this forum) - for example, if somebody asks an interesting question about a certain topic in the portal news section, the followups cannot be retrived with the search function of this forum. Nearly every day I get mails from newbies who are asking questions which are already answered somewhere in the jungle of uCApps.de - I just want to lower the "confusion rate". ;-) So, the three sites should be linked together, and the same informations should not be published twice. For my part: I would like to change the purpose of uCApps.de to a pure technical site which overs the construction details, sources and documentations (also HowTos) of all MIDIbox projects. My plan is to structure it like a book which can be read fluently from the beginning (the advantage of DIY controllers) to the end (outlooks) - not immediately, but in the forseeable future. The purpose of the portal could be to provide an interactive platform for the community - a quick way to publish pictures (MIDIbox gallery), reports, additional infos to my pages, FAQs, hardware extensions, software libraries, tools, SmashTVs and Mikes shop, links to related stuff --- from users, for users, everything which cannot be maintenanced by myself anymore due to the effort. In my oppinion the MIDIbox forum should stay the prefered communication platform - beside of alternatives like chat of course - to simplify the orientation. Best Regards, Thorsten.