TK.

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.

Hi Nebula, ok - the overall current drain of 4 cores, 4 SID modules and the LCD + backlight is about 400 mA, so the 5V and 12V voltage domain can also be supplied by two regulators only. this doesn't really make a difference, but it's ok. Note that neither the master, nor the slaves are exactly synchronized. yes, the optocouplers of the slaves shouldn't be mounted anyhow, since they are connected via the "MIDI Link" port to the master core rectifier and filter caps before the 7805/7812: ok but the filter caps near by the PICs and SID should not be left out to prevent unwanted signal noise on the power lines. yep. In this way you cannot use the core modules temporary for other projects, but for people who want to build a SID synthesizer and nether touch the hardware again, this is a good solution. ok don't forget to publish your layout when it is up and running! :) I don't see problems so far Only one optocoupler is required. I just noticed that this has not been documented yet :-/ No, there is no advantage so long as you are using the PIC clock (it's just a 1:1 wire connection). But it should work. And to confuse you completely: it could be an advantage if an external oscillator is used, because these parts are expensive --- but the MIDIbox SID provides a clock output, so this is no issue. ;-) you haven't mentioned it, but I guess that you already planned to left out the backlight supply circuit (transistor + 2 resistors) for the slave cores. R10 is not required for the MBSID application, and the resistors for the MIDI Out line are only necessary for the master core (the MIDI out of the slaves is useless) Best Regards, Thorsten.

...und hier vielleicht auch noch ein Tip, um den aufkommenden MIDI-Traffic zu minimieren. Fuer die MIDIbox SID habe ich einen Timer hergenommen, der dafuer sorgt, dass beim Umschalten der Patches via Rotary Encoder der erste SysEx Dump sofort gesendet wird, der naechste Update ueber die MIDI-Leitung aber erst 500 ms spaeter erfolgt. In dieser Zeit hat man die Patch-Nummer vielleicht schon um einige Werte inkrementiert, aber das ist egal, nur die letzte Aenderung ist wirklich von Interesse, das was innerhalb der 500 ms passiert ist, nimmt man sowieso nicht wahr. Die gleiche Methode laesst sich auch auf die Textmeldungen uebertragen. Aber das waere dann eher etwas, was Du umsetzen koenntest, wenn die prinzipielle Ansteuerung bereits funktioniert. Gruss, Thorsten.

Hallo Thomas, Vielleicht macht es Sinn, erstmal die bestehenden Applikationen herzunehmen und diese dann Schritt fuer Schritt anzupassen. So wie ich Dich verstanden habe, moechtest Du keine Logic Control Emulation betreiben, sondern eher Deine Pulsar ansteuern. Trotzdem wuerde es Sinn machen, zumindest auf dem letzten Core in der MIDI-Kette (der die Display-Meldungen ausgibt) eine modifizierte Version der MIDIbox LC oder HN laufen zu lassen. Somit waere die Displayausgabe schonmal via SysEx moeglich, und der Rest kommt beim Buegeln... Angenommen Du nimmst die MIDIbox LC applikation, weil sie am weitesten entwickelt ist, so koenntest Du von jedem beliebigen Core aus eine Textmeldung auf dem Bildschirm erscheinen lassen, der dazugehoerige SysEx String sieht so aus: F0 00 00 66 10 12 <position> <zeichen1> <zeichen2> ... <zeichen_n> F7 Du hast zwei 2x16 LCDs? Kein Problem, Du kannst sie beide mit einem Core betreiben und seperat bedienen (das zweite LCD wird mit dem Cursor-Offset 0x80 bedient). Der Slave sollte die Meldung bereits so aufbereiten, dass der Master sie nur noch darstellen braucht. Die Strings koennte er sich bspw. aus einer Tabelle holen. Fuer Werte (Zahlen) solltest Du vielleicht ebenfalls eine Tabelle anfertigen, so koennten sie sehr einfach mit der passenden Einheit (also nicht von 0-127 sondern bspw. von oo dB bis +6 dB) angezeigt werden. Zusaetzlich zum SysEx String verschickt der Slave dann noch das MIDI-Event, das letztendlich an die Pulsar geht. Der MIDI-Link ;echanismus (der MBLink Endpoint filtert alle MIDI-Events heraus, die in der MIOS-Applikation nicht mit einem "call MIOS_MIDI_BeginStream" und "call MIOS_MIDI_EndStream" eingerahmt wurden) sorgt dafuer, dass die SysEx Control Meldungen automatisch herausgefiltert werden. Ich glaube das reicht erstmal als Denkanstoss ;-) Gruss, Thorsten.

Hi, I would like to integrate a HUI option into the MIDIbox LC, but before I begin with the implementation please give me a list of all controllers - I don't own pro tools. If you would like to experiement, you could change the USER_AIN_NotifyChange function (-> lc_mf.inc) in the following way: after "call MIOS_MIDI_BeginStream" write: ;; for MIDIbox Link: notify begin of stream call MIOS_MIDI_BeginStream ;; finally send value: B0 00+<fader> LSB 20+<fader> MSB movlw 0xb0 call MIOS_MIDI_TxBufferPut movlw 0x00 addwf LC_FADER_NUMBER, W call MIOS_MIDI_TxBufferPut movf LC_FADER_POS_L, W call MIOS_MIDI_TxBufferPut movlw 0x20 addwf LC_FADER_NUMBER, W call MIOS_MIDI_TxBufferPut movf LC_FADER_POS_H, W call MIOS_MIDI_TxBufferPut ;; for MIDIbox Link: notify end of stream call MIOS_MIDI_EndStream ;; thats all return Best Regards, Thorsten. P.S.: the second 0xb0 has not to be sent by the MIDIbox, it will be inserted automatically by the MIDI receiver - keyword: "running mode"

Hi, I would like to integrate a HUI option into the MIDIbox LC, but before I begin with the implementation please give me a list of all controllers - I don't own pro tools. If you would like to experiement, you could change the USER_AIN_NotifyChange function (-> lc_mf.inc) in the following way: after "call MIOS_MIDI_BeginStream" write: ;; for MIDIbox Link: notify begin of stream call MIOS_MIDI_BeginStream ;; finally send value: B0 00+<fader> LSB 20+<fader> MSB movlw 0xb0 call MIOS_MIDI_TxBufferPut movlw 0x00 addwf LC_FADER_NUMBER, W call MIOS_MIDI_TxBufferPut movf LC_FADER_POS_L, W call MIOS_MIDI_TxBufferPut movlw 0x20 addwf LC_FADER_NUMBER, W call MIOS_MIDI_TxBufferPut movf LC_FADER_POS_H, W call MIOS_MIDI_TxBufferPut ;; for MIDIbox Link: notify end of stream call MIOS_MIDI_EndStream ;; thats all return Best Regards, Thorsten. P.S.: the second 0xb0 has not to be sent by the MIDIbox, it will be inserted automatically by the MIDI receiver - keyword: "running mode"

Hi Nomical, ok, it seems that we are talking about a different Elektor project. I've created a MIDI controller for a XG some years ago which have been published in Elektor 2/2000. But this was a really simple implementation which only allowed to access the most important parameters. Of course, I also used my XG50 standalone :) If you want to control all the available parameters a much more complex user interface is required. I'm very sure that this can be realized with MIOS, bigger displays and a complex menu structure are no problem (you could also use a graphical LCD), but note that the implementation requires some PIC programming skills and a lot of time. I cannot provide a 1-2-3 solution for you, I can only say that MIOS simplifies the implementation and I can refer to the existing applications. Everything else is in your hand. Best Regards, Thorsten.

Hi Chriss, thanks! :) It seems that the upload didn't work. This means also that there is a potential risk that the OS is corrupted, and therefore causes problems. this is strange! yes, but an OS update only works with the first-level bootstrap loader which is active during the first 2 seconds after power-on. It's important that every SysEx acknowledge string which is sent by the PIC during the upload procedure ends with a "0F xx F7". If it ends with a "0E xx F7" you propably got an checksum error due to a bad MIDI connection - in this case the code block will not be stored in the flash memory. I just checked this with my MBSID - the LCD screen will be updated, so this is either a problem with the corrupted MIOS version, or a MIDI-feedback problem caused by MIDI-Ox. See also: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1054029058 ok, this is definitely a feedback problem, because only in the common mode the MIDI merger will be enabled, means: everything which goes to the MIDI In will be forwarded to the MIDI Out. The merger will be disabled in local mode. In your sequencer application you have to take care about these relations (only enable the MIDI In which is connected to your MBSID when the MBSID is in local mode) I could compile a special PIC16F firmware for you with to-COM enabled. All outputs can be left open, the analog inputs are disabled, Pin RA4 requires a 1k pullup, pin RD1 a 10k pullup resistor Best Regards, Thorsten.

Hi Thomas, No, unfortunately this isn't possible, try your luck once more ;-) The RAM limitation only allows to store 8*16 pot values, a track with 3 layers allocates 3*16 values: Track 1: 3 layers Track 2: 3 layers Track 3: 2 layers Track 4: not available is this ok for you? However, you will be able to use Track4 again with the MIOS based implementation ;-) Best Regards, Thorsten.

An Audio out is not really usefull, as high sample frequencies can only be achieved with DSPs or high-performance CPUs which are doing the synthesis and nothing else (this would also mean a multi-chip solution). The use of an IC which already provides the required oscillator and filter functions is much simpler and the results are better. For "virtual" oscillators, filters, etc. - or for wavetable synthesis, just use your computer. A lot of free software is available on the net which goes into this direction, why should I reinvent the wheel? ;-) Best Regards, Thorsten.

Hi Pay, I'm not the copyright owner of this project and I'm no "copy cat" ;-) However, you are free to create your own website with a report about this project, I would add a link to my SID page for interested people Best Regards, Thorsten.

Hi Pay, I'm not the copyright owner of this project and I'm no "copy cat" ;-) However, you are free to create your own website with a report about this project, I would add a link to my SID page for interested people Best Regards, Thorsten.

Hi Drumwide, No, the enable lines have to be connected directly to the PIC or to a seperate multiplexer. However, this option is only usefull for people with programming skills and there is no application which supports more than 2 LCDs yet. I just have finished the documentation of all the supported LCD modes, it can be found under Concepts->MBHP->LCD Module Best Regards, Thorsten.

Hi Drumwide, No, the enable lines have to be connected directly to the PIC or to a seperate multiplexer. However, this option is only usefull for people with programming skills and there is no application which supports more than 2 LCDs yet. I just have finished the documentation of all the supported LCD modes, it can be found under Concepts->MBHP->LCD Module Best Regards, Thorsten.

By the way: The Elektor project which controls the XG was a publication by me ;-) This was the very first MIDIbox, very reduced and very expensive (it came with an external AD converter) Do you just only want to control XG parameters, or do you plan to write a complete control surface like the MIDIbox SID CS? Best Regards, Thorsten.

Hi Nomical, no, you don't need to copy this function, the parameters are used like variables, they have to be initialized before Send_SysEx_DB50XG will be called. There are different possibilities to initialize the parameters, normaly you only need to specifiy the "XG parameter number", which could be stored in a table. The parameter value is given by the pot/encoder/button position, and for the MIDI channel you could use a global register (=variable) which could be incremented/decremented by two special buttons or by an encoder For more details I don't want to repeat what I already wrote in the examples. Please take a look into the MIOS download section, there are several .zip files which include documented code. The comments describe exactly how to react on buttons, pots, encoders, etc. Once you've read these examples, you are possibly on a level where I can describe you the tricks in one sentence. If the examples are too difficult to understand, I will possibly not be able to describe it better anyhow. :-/ Best Regards, Thorsten.

Hi Thomas, your question in the news section hasn't been lost, I just only need some time to find a solution especially for you... ;-) The PIC16F firmware doesn't allow to store more than 8*16 parameters in RAM, and the MIOS version is not ready for use (currently only the menu handler has been written, I will not continue with the other routines before I've completed the documentations of the running projects and before I've finished the SID surface, step D) So, in the meantime there are following possibilities: if the MIDI interface of your TB303 allows to control the accent or the slide alternatively via CC (like the MIDIbox SID ;-)), you could use a second track if it is ok for you to have a sequencer with only three tracks, I could compile a special version which uses the RAM, which is currently allocated by the 4th track, as 3rd layer storage for the first two tracks I could reduce the step length to 8 and use the remaining RAM to store the 3rd layer alternatively I could also compile a variant with two tracks only where the upper three pot rows control the note, velocity and gatelength of track 1 and 2 (the track would be selectable by the current layer buttons). The lower pot-row can only be used as CC controller in this case Best Regards, Thorsten.

Btw.: here the code to send a SysEx string to a DB50XG Send_SysEx_DB50XG ;; MIDI channel in MIOS_PARAMETER1 ;; parameter number in MIOS_PARAMETER2 ;; parameter value in MIOS_PARAMETER3 movlw 0xf0 call MIOS_MIDI_TxBufferPut movlw 0x43 call MIOS_MIDI_TxBufferPut movlw 0x10 call MIOS_MIDI_TxBufferPut movlw 0x4c call MIOS_MIDI_TxBufferPut movlw 0x08 call MIOS_MIDI_TxBufferPut movf MIOS_PARAMETER1, W ; send channel call MIOS_MIDI_TxBufferPut movf MIOS_PARAMETER2, W ; send parameter number call MIOS_MIDI_TxBufferPut movf MIOS_PARAMETER3, W ; send parameter value call MIOS_MIDI_TxBufferPut movlw 0xf7 call MIOS_MIDI_TxBufferPut return this function can be used from any hook, this means: you can trigger this SysEx string in your application with buttons, pots, faders, rotary encoders, etc without writing special drivers for these control elements, because the drivers itself are provided by MIOS. Best Regards, Thorsten.

Hi Nomical, don't mix MIOS with the MIOS application. MIOS gives you all the basics for implementing an application, and it doesn't have to be changed, you can use the same operating system like all other applications. You have to program the whole user interface. Currently it can only be programmed in the assembler language, support for higher level languages is not planned for this year (as there are no suitable freeware compilers available yet). See the MIDIbox SID application how SysEx data can be send (yes, I know, it's very complex, but this is just the result when you want to create a perfect interface). In fact you can send and receive any MIDI data, but you have to call "MIOS_MIDI_TxBufferPut" for every single byte, there is no routine like "MIOS_MIDI_TxBuffer_SysExPut" or whatever since such a function has to be writting in the application layer (see SID application, cs_menu.inc, after CS_MENU_SendParameter_Slave as an example) sure :) I only have to burn the bootstrap loader into the PIC, thereafter you are able to burn MIOS and the application via the MIDI line as much times as you want. yes, some functions can be controlled by CC's, but the DB50XG supports much more parameters. So if you want to control the whole parameter set, you have to go for SysEx. However, for the application this doesn't make a big difference. you have to program these functions into your application. There are driver hooks like USER_DIN_NotifyToggle which allow you to react on button movements This is still possible by calling the MIOS_MIDI_InterfaceSet function. And you are also able to specify the default interface (RS232 or MIDI) in the ID field of the PIC, so that the correct setting is already available at power-on see the descriptions in the main.asm file of any applications which tools are required for Wintendo. However, as I wrote: currently only assembler is supported. Some more words: maybe the planned port of MIDIbox64 to MIOS will help you much more, because it will also be a good skeleton for customized controllers for those who feel that the SID application is too complex. But I will not start with this task before the running projects have been finished (maybe in 2-3 months...) Best Regards, Thorsten.