TK.

Hallo Jack, ich habe Deine Mail gleich dreimal erhalten, mir war mir allerdings unsicher wo ich die Library am geschicktesten ablegen koennte. Nun habe ich sie erstmal unter Concepts->MBHP->DIN abgelegt. PIC fuer mehrere GLCDs/CLCDs: hier musst Du schon genauer sagen, welches Setup Du Dir vorstellst und was alles angezeigt werden soll. Ich kann uebrigens nur den PIC18F452 supporten, und die anderen PIC18F sind nicht unbedingt kompatibel. Gruss, Thorsten.

Hi Pascal, I thought the answer to matteo made it clear? http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=news;action=display;num=1056228215 2 SIDs driven by one core module: not this year. CS and 2 SIDs option: not possible. From another posting: up to 8 BankSticks will be supported. Best Regards, Thorsten.

I think the timings are more relaxed when you take the required transfer time of a MIDI message into account. A three byte MIDI event requires 960 uS - nearly one milisecond. This means that the BankStick is 10 times faster than the transfer itself. Note also the MIOS provides a 48 byte transmit buffer which relaxes the timings even more, since in this way the bytes are sent in background and your application can continue to read from BankStick or to calculate the next events (I read that you plan some interpolation features for CC events...). I also don't think that your code has to read so much data from the BankStick during every MIDI clock when everything which is time critical is stored in RAM. The planned MB64seq port for example will be implemented in a different way compared to the PIC16F solution, but will work with a better performance. Of course, the possibilities will not be so powerfull like your plans, but I guess that the principle method, the skeleton will maybe open your eyes. I've planned to realise it in following way (this is only a short abstract from my ideas, if I would have to write all ideas, it would be faster for me just to program the assembler code in order to "document" what I mean --- and every time I have to write more details, the day of release will be more delayed ;-)): either the USER_Timer or the incoming MIDI clock triggers the sequencer with 24 ppqn (note: higher resolutions should also be possible). The timer itself doesn't process the sequencer data at the same time, but only notifies to the main program that the pulse should be processed "as soon as possible". The main program checks if the sequencer has been triggered as often as possible. This handler will be called from USER_Tick - this hook is triggered ca. every 5-50 uS (microseconds) if nothing else is to do (no button event, no encoder event, no pot event, no MIDI event, no display event). If - for example - a button function has to execute a long running part of code, e.g. if it has to write something into the BankStick, the sequencer handler can also be called during every single write operation. In this way extreme low latencies are guaranteed without any OS overhead. What will the sequencer function do: anything you want ;-) Mainly it will handle with a lot of delay counters, once a counter reaches zero, any action will be performed - sending MIDI events from BankStick or derived from RAM variables, or whatever... Best Regards, Thorsten.

Hi Duggle, especially based on your (yes, really!) idea with character offsets I integrated a special function into MIOS called "MIOS_LCD_YAddressSet" (see the documentation) - one advantage of this function is that it allows you to shift a 2x16 screen to the middle of a bigger LCD However, the interface to MIOS functions can be found in mios_vectors.inc, to user functions in user_vectors.inc A MIOS function can be overloaded by disabling the appr. entry in mios_vectors.inc and by adding a replacement with the same name into the application. Best Regards, Thorsten.

Good that you've identified Vss and Vdd, so the others pins should be in the same order like known from the Displaytech, I never saw a display with a different order yet (except those displays with a 2x8 pin header). So it's maybe a good idea to check the tracks on the core module, too - when you read the last postings you will notify that users mostly have problems with these pins (exchanged wires or bad solderings) Did you already ensure that the box is running? Does it send any MIDI data? Best Regards, Thorsten.

So far as I know vmidibox doesn't provide the MB-Link protocol - or does it? Serge? Best Regards, Thorsten.

Now you will find the .hex file in the official mios_v1_3.zip package. I'm a little bit carefull with this file as the ".hex" extension implies for an unexperienced user (who normaly never reads a README) that this OS release has to be burned directly into the PIC. But thats not the case - never use IC-Prog to upload the OS, since this would remove the first level bootstrap loader. Regarding the device ID: I'm not sure, but maybe you don't know that the device ID of the MIDIbox SID application has to be changed in order to get the multisetup running. The MIOS device ID is a different value which is mainly used for firmware uploads. In other words: the MIOS device ID identifies the core module, the MIDIbox SID device ID identifies the SID The reason why others didn't notify this "problem" is possibly that they are using a PIC16F for the slaves... the PIC16F solution doesn't provide a specific device ID Best Regards, Thorsten.

The .syx file contains blocks which are assigned to a dedicated device ID. The only way to switch to another ID is to replace the appr. entry in the SysEx stream by the new ID, or to generate a new .syx file with the hex2syx.pl script (-device_id <id>). The "mios_upload.pl" script allows to change the device ID on the fly so that no new .syx file has to be generated. But this script runs only under Linux The planned Java GUI which will also run under Windows will provide the same possibilities MIOS itself has not been released for Device ID 0, as the the Java GUI will allow to change the device ID on the fly. If somebody want's to help me, he is free to program this Java GUI for us, because I'm not sure how long it can take until I will find the time for this task. Temporary solution: I could give you the mios_v1_3.hex file which allows you to convert .syx files for different device IDs. Alternatively you could change the device ID manually in the mios_v1_3.syx file (for every code block which begins with F0!). The main.hex file of the SID application is already available in the .zip archive. Best Regards, Thorsten.

Could you please check the next try? ;-) (same location, once more: untested) Best Regards, Thorsten.

Hi Pay, the capacitor specs are depending on so much parameters that it would be too difficult for a newbie to decide which values is the right one for his design. So I used the biggest value, which is good enough for a clean value when also a LCD with backlight and a lot of LEDs are powered from the same module. Of course, if your PSU already contains a cap, you can left out the one of the core module. Or if you don't use the analog inputs and therefore a clean voltage is not important, you can also replace it by 100 uF or 470 uF... Regarding the crash issue: I'm totally unsure how to reproduce this, my monitor runs fine but maybe your application sends any event (maybe an invalid event??) for which the firmware has not been prepared? Best Regards, Thorsten.

The LCD bus isn't multimaster capable, the only way would be to switch between all data and control lines (=11 signals) with a bidirectional switch (since the data bus goes to both directions) --- too difficult :-/ But for the records: one of the next MIOS examples will demonstrate how to use the new "customized LCD" driver (app_lcd.inc) to send all messages which are normaly printed on a LCD via MIDI to another MIDIbox in order to share a LCD. The "app_lcd.inc" file can be linked into any MIOS application. Only the application which displays the messages must be prepared for this capability (like MIDIbox LC), it has to provide a function which switches between different display buffers. I know that this isn't the answer which you want to hear, but it's just an inspiration for a possible solution which works w/o problems. Best Regards, Thorsten.

Geoff, if you are using a MIDIbox64 it's ok, this firmware doesn't provide an unmultiplexed mode like MIOS. Yes, you can leave out the unused ICs, you just only have to connect the open analog lines to the PIC with ground - in the same way like the remaining analog pins of the PIC for the second AINX4 module have to be connected to ground. Best Regards, Thorsten.

*grin* ;-) This is just a link to an article which describes the SID CS handling (so that this info doesn't get lost) http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=news;action=display;num=1056228123;start=15

Just some comments to prevent the scare that LED rings or a replacement is required: my own surface is not stuffed with LED rings. The values are displayed on LCD instead. Maybe I should left some words to the workflow before you start to create your panel: when I press the OSC Select button. The SID CS jumps to the OSC menu immediately. If the OSC menu was already active, the cursor stays at the same position, otherwise the cursor jumps to the first menu item. The OSC number will be incremented, but also mixed OSC combinations can be selected. There are 6 button states for 6 different oscillator combinations the behaviour of the OSC Ctrl button is similar, but it has only three states: Envelope, Misc and Assign Layer. Every time I press this button the LCD changes to a menu view so that the 5 encoders are matching with the 5 menu items. using the OSC Select or OSC Ctrl button is also important if you want to change a parameter which is not assigned to any rotary encoder or functional button - just press the OSC/Ctrl button for a quick change into the OSC menu and select the menu item with the rotary encoder beside of the LCD when an encoder is moved, the menu page changes quickly to the same view like above this means: by using the OSC Ctrl button you can make the values visible on the LCD, and by using the OSC button you can select the 6 oscillator combinations (if more than one is selected at the same time, the values of the first oscillator will be displayed). Also by moving the rotary encoder, the values will be visible. Btw.: because of this LCD<->Button<->Encoder interaction, a 2x20 LCD is absolutely recommented. Ok, now some words to LED rings: they are nice to have, but in my oppinion they won't give you much more. Due to the (perfect ;-)) interaction with the menu interface, I'm more concentrated on the LCD and (especially) on the sound than on my fingers which are tweaking the knobs and selecting the functions. But don't forget the LEDs next to the buttons - they are important for an ergonomic handling. LED bars: a good replacement for LED rings, maybe even more ergonomic but not required LED digits: nice to have but not really important. Please note that you need 3*14 = 42 digits to display the decimal values of 14 encoders. But only two additional DOUTX4 modules can be connected, and every DOUTX4 module can only be stuffed with 12 digits maximum (due to the multiplexing method). Best Regards, Thorsten.

Yes, the last two shift registers of the DOUT chain are reserved for the modulation matrix. I just have added the 56 LEDs to the schematic (I've a nice animation in mind which could be showed during the startup phase ;-)) http://www.ucapps.de/midibox_sid_cs/mbsid_dout_default.pdf Best Regards, Thorsten.

The order of pins depends on the display, not on the controller. Yes, the signals are the same - please search for a datasheet of your display if you are unsure. Best Regards, Thorsten.

If the description of MIOS_HLP_Dec2BCD doesn't help (see Concepts->MIOS->Functions), please wait for the example application. Yes, this function helps to display values on LED digits. Best Regards, Thorsten.

It's also my new toy ;-) The updated version can be found here: http://www.ucapps.de/tmp/mios_upload_b.zip Unfortunately the return messages of a debug command will not be received (too fast) - possibly I've to rewrite the receive handler so that input and output streams are handled in parallel. However, something for the next days... Best Regards, Thorsten.

I prefer perl ;-) Could you please check if this script works on your system: http://www.ucapps.de/tmp/mios_upload_a.zip The next version will also support the MIDI IN in order to print the return message and to compare the checksum. Best Regards, Thorsten.

I've to learn how to use pipes so it can take some minutes. ;-) However, a quickfix for the debug function can be found here: http://www.ucapps.de/tmp/mios_v1_3atmp.zip Best Regards, Thorsten.

I've the same problem with ALSA. But since I own the MBHP_USB, I'm able to use MIDI again :) I just noticed that the debug function has a bug - the working register (WREG) will not be written correctly, you will see a "-" instead. I will fix this and I will write an upload script for MIOS .syx files, so that it is possible to update the new code under Linux. Best Regards, Thorsten.

Maybe it would be the best solution for us all when I just release a downstripped version of the SID CS code (called MIDIbox TC2) which already includes some examples for the XG card. My advantage would be that I will get a perfect interface for my own XG (sooner or later...) developed by you, and your advantage will be that you don't have to reinvent the wheel. In this way MIDIbox TC2 would also give the basics for other customized control units. When Do you plan to start with the hardware? :) Best Regards, Thorsten.

Perfect! The KS0066 is HD44780 compatible, so it will work with LCD type #0 :) I just remember that I also own a display with this controller. Best Regards, Thorsten.

Cool! Duggle, could you please try the following setting - this will be the upcoming suggestion, but I want to ensure that it works on all systems w/o problems: buffer size 2048, number of buffers: 4 Best Regards, Thorsten.

Hi Pilo, I've no idea how to make the LCD brighter... :-/ Yes, you could try to find out the exchanged data lines by printing different chars. I can suggest two solutions: If you like the Unix feeling (like me! :-)), just install Cygwin (http://www.cygwin.com), this is a nearly complete Unix environment running under Wintendo. Perl and Emacs are part of the standard release (the setup program allows you to select all the programs which you would like to use, thereafter the appr. packages will be downloaded and installed automatically) Another, maybe faster solution for the first tests: you are able to execute any function via MIDI by using the debug feature which is integrated into MIOS. I just have inserted this tool into the MIOS release http://www.ucapps.de/mios/mios_v1_3.zip (debug/mkdbg.pl) Examples: Search in mios_vectors.inc for the address of the appr. function. Or search in the .lst file if an application function should be executed. Run the mkdbg.pl script with the appr. parameters and send the generated SysEx string to the core. clear the display - the address of MIOS_LCD_Clear is 0x2d04. Start the mkdbg.pl script with following parameters: perl mkdbg.pl exec MIOS_LCD_Clear.syx 0x2d04 0x00 0x00 0x00 0x00 Print a character (here: 0x40 = @) - the address of MIOS_LCD_PrintChar is 0x2d28: perl mkdbg.pl exec MIOS_LCD_Char.syx 0x2d28 0x40 0x00 0x00 0x00 Hope that it still works ;-) Best Regards, Thorsten.