TK.

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.

Just enter the "Layer Assign." menu, it shows you which function has been assigned to which layer. The steppy result can be prevented by increasing the gatetime of the CC track, and the layer which is assigned to the gatetime can be found in the assignment menu. Sometimes it makes sense to have the CC gatetime in the same layer like the Note of another track (e.g. for a chopper effect), sometimes it's more usefull to control the CC value at the same layer (fast filter or slide effects) .. however, everything is in your hand ;-) Yes, you can switch between the patterns in the "Patterns" menu. Hope that your hardware has the "shortcut" button which allows to switch betwene the menues very fast. Best Regards, Thorsten.

Hi Nebula, yes, StepD requires no additional PIC. The software already has been prepared for the whole thingy, I only need to build the hardware before I'm able to complete the integration. Hmmmm... yes, you are right. The implementation is very easy, I only have to insert a loop into the CS_MENU_SendParameter function (cs_menu.inc), so that parameter changes are sent to all selected SIDs. Thanks for the input! :) Good that I haven't started with my panel yet... ;-) Btw.: Dan - with a simple trick it is already possible to control all SIDs from the control surface at the same time. First you have to change the firmware so that the MIDI merger is not switched off in Local mode (the upcoming release will provide a switchable option for the MIDI merger) - in cs_menu.inc replace CS_MENU_Init_SID ;; enable/disable MIDI merger depending on local mode movlw MIOS_MIDI_MERGER_ENABLED btfsc CS_MENU_SID, 2 movlw MIOS_MIDI_MERGER_DISABLED call MIOS_MIDI_MergerSet by CS_MENU_Init_SID movlw MIOS_MIDI_MERGER_ENABLED call MIOS_MIDI_MergerSet Thereafter enter the Local mode. Every parameter change of SID1 will no be sent as CC message, and every slave SID which is assigned to the same MIDI channel like SID1 will receive the parameter changes :) Best Regards, Thorsten.

great! :) Best Regards, Thorsten.

Ok, it's time again to check the system status via remote ;-) Following SysEx messages have to be send with MIDI-Ox one after another. Write down the return values and post them here: (LCD type, MIDI interface, core frequency) F0 00 00 7E 40 00 0D 02 00 00 00 00 00 00 01 00 00 00 00 F7 (LCD option #1 and #2) F0 00 00 7E 40 00 0D 02 00 0A 78 00 00 00 02 00 00 00 00 F7 (LCD timeout state) F0 00 00 7E 40 00 0D 02 00 0B 12 00 00 00 02 00 00 00 00 F7 Best Regards, Thorsten.

Hi Pilo, yes, you can use this optocoupler, it works perfectly with most MIDI interfaces, but sometimes you've to tweak the resistor values, therefore the 6N138 should be prefered. However, here the schematic: Best Regards, Thorsten.

Hi DriftZ, no, this isn't it exactly. The MB64SEQ doesn't start a NOP loop to insert delays between the MIDI events, but it uses a timer which interrupts the main program every x uS. The x value is derived from the BPM setting, for example, with 120 BPM 480 steps will be triggered per minute (if the clock divider of the appr. track has been set to 1:1), makes 8 steps per second or 125 mS delay between every step. A microsecond timer will be preloaded with this value, it starts the sequencer handler periodically. The sequencer handler switches to the next step and pushes the new MIDI events into a FIFO buffer (it doesn't send the MIDI events directly to ensure best performance) If the MB64seq is running in slave mode, the timer will be switched off and the step sequencer will be triggered by incoming MIDI clock events instead. This has also be realized as a interrupt service routine, therefore the latency in this mode is below 10 uS The main program is never idle, a lot of tasks are called when nothing else is to do, tasks which prints out messages on the display, samples the 64 pot values, drives the DIN/DOUT register chains, handles with the MIDI FIFO buffers, etc. Best Regards, Thorsten.

Possibly SmashTV means the DS1801 from Dallas Semi.; this chip provides two digital potentiometers with logarithmic characteristic which can be controlled via a simple serial protocol. Several DS1801 can be cascaded to a long chain. Datasheet: http://pdfserv.maxim-ic.com/arpdf/DS1801.pdf The serial protocol (called SPI) is exactly the same like for the SID module. So, no special MIOS extension is required, you just only have to connect the first DS1801 of the chain to J10 of the core module, thereafter you can transfer the command words with the SID_SR_Write routine in sid_sr.inc of the MIDIbox SID application (note that this routine has been optimized for speed and could be written in a less complicated way ;-)) Best Regards, Thorsten.