TK.

Tronico.net mailed me that they will add some nice coloured 2x20 and 2x40 LCDs in the next days. :) Unfortunately they are not able to offer graphical LCDs... Best Regards, Thorsten.

Hi Dan, the 5V spec means continuous voltage level, but the MF driver sends a PWM voltage in order to control the speed of the fader. So in fact the PW modulated voltage is much lower than the output voltage of the LM317 Best Regards, Thorsten.

I've ordered my MIDIbox SID panel from Schaeffer Apparatebau, so Step D should be up and running in about 2 weeks. :) Here a snapshot: http://www.ucapps.de/midibox_sid/mbsid_surface4.gif Some words to the last changes: I removed the LED rings due to mechanical reasons. I've experimented with several mounting techniques, but found no way for soldering the buttons, LEDs and encoders to the same board. A solution would be the use of other buttons, but the C64 case is too small... therefore I will use two boards: one for the encoders, another for the buttons and LEDs, which is on the top of the encoder board (double-decker). Disadvantage: so there won't be enough place for the LED rings. However, the LCD will display the values anyhow when a select button of a section is pressed (e.g the OSC or Ctrl button), and since most people don't plan to build LED rings, too, it's maybe better when I focus upon the handling without the rings. of course, the firmware will support LED rings for people who plan to design another layout with more relaxed constraints (bigger) The poly/mono/legato and single/unison/split buttons/LEDs have been removed, since even more modes are planned. They will be selectable in a special menu entry the 4 SIDs are now selectable seperately (see suggestion from Nebula: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=news;action=display;num=1054076482;start=15#15 the previous "local mode" has been replaced by the "link" and "CC" function the "link" button enables/disables the MIDI merger which forwards incoming notes to the slave SIDs. Sometimes it's advantageous to disable the link (e.G when CCs should be recorded with a sequencer) in order to avoid feedback loops if the recording software doesn't provide an intelligent routing (like Logic Audio ;-)) the "CC" button enables/disables the sending of CC's on encoder moves if the "edit" function is turned on, the CS will ensure that changed sounds will not get lost when you switch to another patch. If the current patch has been changed, the CS will ask for saving In the next days I will modify the current step B implementation so that the 7 control buttons (SID1-4, Link, CC and Edit) are available for people who plan to use multiple SIDs with a minimal control surface. Best Regards, Thorsten.

Hi Steven, some weeks ago I've experimented with a MIOS mod which slows down the fader before it reaches the bottom. It doesn't work perfectly yet, but I have an idea how to improve the behaviour. If I find the time I will release the final modification with MIOS V1.3 Best Regards, Thorsten.

Hi Pilo, the PIC could be damaged with a negative voltage at an analog inputs, so it would maybe be better to add a shottky diode to all Vss pins of the PIC in order to shift the negative reference voltage by ca. 0.3V - but I'm not sure which side effect can occur thereafter. :-/ Best Regards, Thorsten.

Hi Antman, several poly, unisono, layer and split modes are planned :) Best Regards, Thorsten.

Hi Pay_c, :) this can have several reasons, but not because of a firmware error, but because of the sound setup. For example, if three voices are oscillating with exactly the same frequency, you will only hear the superposed result, which mostly doesn't sound very interesting. And depending on the other parameters these effects can occur with different notes. If it was your intention to play a thin sound, just disable oscillator 2 and 3. Or if you want to play a fat sound (unisono effect like known from the Virus), change the finetune parameters of osc 2 and 3, and assign one or two LFOs to the pitch to prevent the overlay effects. thats an imperfection of the SID chip. :-/ I just tried this with the Line Out of my RM1x - no problem. But I noticed that the polarity of the "Ext" flag is wrong. Means: you have to "disable" the external input if you want to hear the sound. I will fix this in the next release. Best Regards, Thorsten.

Hi Helder, although this is the wrong thread (the topic is "MB64 seq ) here my answer ;-) could you please check if the 1k pull-up at pin RA4 (core module: R2). the 10k pull-up at pin RD1 (core module: R9), and the 1.2k pull-up at the tx pin (core module: R6) are connected properly? Best Regards, Thorsten.

Fine! :) Any firmware crash so far? ;-) Best Regards, Thorsten (has a bug-phobia).

Next milestone reached: TK received the well made PCBs from SmashTV for testing. :) Best Regards, Thorsten. P.S.: only problem: I'm going into holidays tomorrow and therefore will not be able to finish the tests before mid of june

Hi Nebula, no, MIOS isn't compatible with the MIDIbox Plus PCB, and I don't want to support an alternative version of MIOS as it would mean double effort for myself and for programmers of an application. So, maybe it's better to start with a MBHP design. Best Regards, Thorsten.

No, it isn't. The integration into MIOS is possible, but the performance will be very poor (comparable with the T6963C driver), therefore I cannot recomment this display. See also http://www.delta-components.de/Suchbaum/hd61830/10.htm the dots are displayed horizontally :-/ Best Regards, Thorsten.

Hi DriftZ, no --- out of memory --- it was already very hard to include these minor features into the firmware, I had to optimize old routines again and again to get just 4 or 5 free bytes for a new button function. Sometimes this makes fun, mostly not ;-) Please check if the new release is already working without crashes. Best Regards, Thorsten.

see the troubleshooting board, there are a lot of articles about this problem and how it has been solved (mostly it's a wiring or software configuration problem) Best Regards, Thorsten.

Yes, any SPI compatible chip, also the the AD5206 Best Regards, Thorsten.

Hi Ilmenator, no, this isn't possible, so only a MIDIbox-Link will help. Btw.: I'm not sure if you've regognized that your suggested rotated display driver is up&running ;-) http://www.ucapps.de/mbhp/mbhp_glcd7_photo.jpg Best Regards, Thorsten.

Hi Chriss, the SID firmware changes the resolution of the encoder depending on the max value so that the value can be entered with an accurate precision. But you are right, I'm also not satisfied with the encoder "feeling", I've planned to add more parameters to the encoder handler so that more settings than "SPEED_SLOW", "SPEED_NORMAL" and "SPEED_FAST" are possible. I never tested this application with a detented encoder, therefore it will possibly not run correctly. In the main menu the value will be scaled by 4 (same reason like above). It seems that an additional option will be required which disables this scaling for detented encoders, I can build this into the application as soon as I receive the detented encoders from Ian. Quick&dirty workaround: open cs_menu.inc, search for CS_MENU_EncSpeedSet. Add following code to the first lines: CS_MENU_EncSpeedSet movlw MIOS_ENC_SPEED_NORMAL movwf MIOS_PARAMETER1 movlw 0x00 goto MIOS_ENC_SpeedSet Menu scaling: search for all "#if CS_MENU_USE_INCDEC_BUTTONS == 0" in cs_menu.inc, change this to "CS_MENU_USE_INCDEC_BUTTONS == 2" to disable the scaling of the menu position. Could you please also test the encoders with the enc_* examples in the meantime? Because these examples are using the encoder only in normal mode, without the progressive mode and without scaling. It would also be interesting for me if your detented encoder runs better with the undocumented third encoder mode. Replace MIOS_ENC_MODE_DETENTED by 0x81 to test this. I never was able to use the driver with a detented encoder yet, so I really rely on your inputs! Best Regards, Thorsten.

Hi Thomas, I must admit that I've tested this variant only for one minute, it could be that I overlooked something. Does your box work correctly with the original version? Best Regards, Thorsten.

Hm, so the reason is unclear, maybe a wiring problem or a bad soldering? Did you test the same inputs with the pots, just to ensure that they are working ok? Best Regards, Thorsten.

Hm, so the reason is unclear, maybe a wiring problem or a bad soldering? Did you test the same inputs with the pots, just to ensure that they are working ok? Best Regards, Thorsten.

alright, the 3tracks variant is now in the v101 archive under MBHP->MIDIbox64seq->Download hope it works ;-) Best Regards, Thorsten.

V101 can now be found in the MIDIbox64seq download section. (I've implemented a shift button for the mute function like suggested by DriftZ, because the handling is more ergonomic :-)) New wiring diagrams: http://www.ucapps.de/mbhp/mbhp_doutx4_mb64seq.pdf http://www.ucapps.de/mbhp/mbhp_dinx4_mb64seq.pdf Have fun! :) Best Regards, Thorsten.

Hallo Matthias, dies trifft fuer den PIC16F877A zu (das ist der Nachfolger vom PIC16F877), aber nicht fuer den PIC18F452 Beim PIC16F877A muss man unter "Hardware Settings" das IO-Delay auf den Wert 20 einstellen, um die Spannung auf den richtigen Level zu bringen. Gruss, Thorsten.

> The DB50Xg doesn't transmit anything, so i can't recieve into the > controller. Yep, I only gave a general statement to for the case that other people want to realize something similar and have to write a receiver handler > But what do you mean with 'my own table format'? Do you mean > the table i have to make for all the sysex commands and stuff > i want to implement instead of idea i had about putting > everything in MIOS_TABLES.inc. > Which was the wrong solution as i've read now. using MIOS_MPROC_EVENT_TABLE in mios_tables.inc is the wrong solution for your application. The format of this table should never be changed, since it is used by an internal MIOS function. It should only be used if an application has to react on simple incoming MIDI events, in this case the table is very comfortable, and MIOS processes the table extreme fast. The table can also be used to get the data for outgoing events (like shown in the ain_* and enc_* examples), but - as I wrote - only for simple applications with <= 256 simple parameters But four your application it's better to put everything which belongs to one parameter into one line: the SysEx parameters (not the whole SysEx message, but only the parts of the string which are different from other messages) OR the CC parameters. A reference to the function which sends the MIDI message (so that you can realize even more flexible routines, i.E you could send out more than one SysEx at once if it is required for a special menu entry). The table line could also include the parameter name (string), a reference to the function which prints the name, a reference to the function which prints the value (so that you are able to use different number formats) and finally a reference to the register (variable) in which the value itself has been stored. This will be maybe more clear when you take a look into cs_menu_tables.inc > Can i put the conversion tables i discussed in the same > file as the sysex commands? Or is this the same as you > described by putting all stuff in one line for each parameter? you mean the number conversion tables? This should be a seperate table, otherwise it would be required to define all displayed numbers (" 1 ms", " 1.1 ms", " 1.2 ms", ...) for every parameter entry, this would blow up the table. Therefore it's better if you just to add a reference to the print function into the parameter table (like ...., CS_MENU_PRINT_ms, .... The CS_MENU_PRINT_ms routine should use a second table for the strings. See cs_menu_print.inc Here an example: CS_MENU_PRINT_FIL_Chn ;; print selected channels TABLE_ADDR CS_MENU_PRINT_FIL_Chn_Tab movf INDF0, W andlw 0x07 rlf WREG, F rlf WREG, W TABLE_ADD_W movlw 0x03 goto MIOS_LCD_PrintPreconfString CS_MENU_PRINT_FIL_Chn_Tab dw "--- " dw "1-- " dw "-2- " dw "12- " dw "--3 " dw "1-3 " dw "-23 " dw "123 " > Couldn't there be a permanent bankstick in case my > setup is too big and i have to write it to the > bankstick like you described? And couldn't there > be a second (or even more) bankstick 'slot' that > can be used to save other things to if nessecarry? A system function for MIOS which allows to select up to 8 BankSticks which are connected to the same line is planned :) The handling will be very easy, you only have to call an additional function before you call the MIOS_BANKSTICK_Read or MIOS_BANKSTICK_Write function. Example will follow when this function has been integrated (the implementation is a piece of cake, but I have to test it... ;-)) > What would happen if an incomplete Midi Event were > to be recieved? Couldn't there be something like a > safety program/app that filters these incomplete > messages out or some other protection method? The receiver already has a savety function, I meant the transmitter (means: the MIDI data which is sent by yourself). You have to ensure that your program never sends out invalid MIDI events so that the receiver on the other side never notifies an error. Also the merger wouldn't work correctly in this case, it would merge correct incoming events with invalid events which are sent by your routine. If MIOS receives an invalid event, the USER_MPROC_NotifyTimeout function will be called. > I listened to your tracks, some of them are very nice. > That 'Lovesong for my SID's' is very good stuff. > Keep it all up! thanks! :) Best Regards, Thorsten.

> Ok, I've begun to read the files from the MIOS d/l page > and i'm beginning to see some structure in it. I've also > d/l all the software that's needed for writing the code > and all. Haven't installed it yet, so i don't understand > what activeperl is for. without perl you are not able to convert the assembler code to a SysEx (.syx) file, which thereafter has to be uploaded to the core module by using MIDI-Ox > Anyway, I looked at your SID control surface and i see > something that resembles the Yamaha A3000 interface. Is > it so that the rotary encoders beneath the display control > the functions that are currently displayed exactly above the > encoders on the LCD? This is planned for Step-C of the control surface. Currently the handling is different, see the Step-A introduction under Projects->SID->Control Unit However, the integration of more encoders is easy. > If so, i could use this as a skeleton for my own control > interface, right? I'm thinking about making it in such a > way, is this still possible if i can't use your SID CS > as a skeleton? yes, you can use it as skeleton, all files which begin with cs_ are the code for the control surface itself > Oh, and the rotary encoders on the A3000 can also be used > as (digital?) pushbuttons. Is something like that easily > integrated into MIOS? Would be very cool.... just connect the terminals of integrated push-buttons like every other button. Button changes will be notified in sid_din.inc and forwarded to cs_menu_buttons.inc > All the CC messages and sysex messages that i want to use, > will have to be put in MIOS_TABLES.inc, right? No, mios_tables.inc are a standardized way to react on up to 256 different common MIDI controllers (like CC or notes) which are received from the MIDI In. SysEx is not supported by this "simple" method. If you want to receive more than 256 values, or if you plan to parse SysEx streams, you could to program your own handler instead (see the *_mproc.inc file). However, possibly you don't want to receive data, but only transmit data, in this case ignore this and just use your own table format > I looked at the snippet you posted above for sending sysex > to the DB50XG, but i don't understand something. Why is > it that the number of lines in your sysex message as less > than what it says in the DB50XG manual? In other words, You > only input the midi channel, parameter number and the parameter > value. In the manual it says that you also have to send the > following sysex messages if you want to change the variation > effect type to for instance Echo: there are different types of SysEx messages, I used only a small supset. The high address corresponds to the MIDI channel so far as I remember... > So my question is, why are there less strings/messages/whatever > in your snippet for sending sysex to the DB50XG? And if i have > to do it like i described from the manual, can i put all of > these 'blocks of messages' into MIOS_TABLES.inc? exactly - but never into mios_tables.inc, you have to create your own table. Advantage: in this way you can also insert additional infos about the parameters, for example the full name (string), the output number format, the function which should be called when the parameter should be sent out, etc. Everything in one line for each parameter - this will simplify the maintenance. > Display question. It's possible to display for example the > actual delay time in ms instead of the decimal/heximal > value on the lcd that you have to input in the sysex > message, right? > If so, do these tables with conversion values to ms > (there are about 9 of them) have to put into MIOS_TABLES.inc > or do they have to be somewhere else? yes, you can do this by creating additional tables (not mios_tables.inc ---- this is a standard table which can be found in every application for some system functions, put your own tables into another file) Example: see cs_menu_tables.inc > How much space is there in the MIOS to build a menu for the LCD? Your application has about 16k, and with every BankStick you have additional 32k. So, if there are too much strings, just copy them into the BankStick. You could also write the whole table into the BankStick. > You also got an DB50XG Thorsten ( that's what i've understood!), > so you know how big the menu could be. I want almost every > parameter to be accessed from the menu if possible. > The menu should also diplay all correct values and names of > effects, parameters and values. Some encoders have to control > functions that are diplayed above them on the display as yoy > go through the menu, other pots, encoders and buttons should > control fixed functions. Would there be enough space in the > PIC to implement all of this? when you program it on a good way: yes > One thing i don't understand about the bankstick. Is it possible > to implement a code into the MIOS that allows two buttons to > directly load and save a setup into the bankstick? you mean "into your MIOS application" Sure - there are functions which allow you to write and read to/from BankStick - your application can react on a button event and do anything with the BankStick > Or have i overlooked it and is this code already present in MIOS? no, this wouldn't be much usefull as this is a very application specific function (i.E the SID Control Surface has a different Bank management compared to a MIDIbox64 or a MIDIbox64 SEQ) > Isn't there any space in the PIC for saving user setups? > Or will this space only be used to implemnt future functions? You've 256 bytes in the integrated EEPROM, you could also write into internal flash, but this depends on the space which is required for your application itself. The MIOS program space is reserved and will never be greater than planned (goes from 0x0000-0x3bff) Larger setups should be saved into a BankStick > And how is midi feedback handeled by the hardware or MIOS? MIOS merges all incoming events with your own events when you enable the merger with "MIOS_MIDI_MergerSet". You only have to ensure that you never send an incomplete MIDI event >Do you know of any sites or ebooks that have some really > good info for starting PIC programmers? When i search with > google i get so many sites, i don't know which ones are any good! http://www.piclist.com unfortunately not too much info about the new PIC18f family... http://www.microchip.com look for the PIC18F452 datasheet (especially the chapter about assembly instructons is interesting), the PIC18F manual and the application notes Best Regards, Thorsten.