TK.

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.

Hi Nick, I tried to upload the bootstrap loader with my PICstart plus and noticed the same. Unfortunately this is not the only bug in MPLAB (did the Microchip guys every test the PIC18F drivers?), however, you will find a workaround here: http://www.ucapps.de/mios/mios_bootstrap_picstart_workaround_v1.zip from the main.asm ; This program is a workaround for the PICstart programmer driver ; of MPLAB and MPLAB IDE - following bugs have been encountered: ; o the driver doesn't allow to write the complete ID field. ; Only 8 ID digits can be specified, although the PIC18F452 ; provides 16 digits (= 8 bytes) ; o the driver doesn't burn the whole firmware correctly when overwriting ; of the ID field has been disallowed under Programmer->Settings ; ; NOTE: !!! IC-Prog users don't need to run this program, since this ; !!! buring software writes the ID field correctly ; ; So, here are the required steps for a proper ID initialization: ; o burn the MIOS bootstrap loader into the PIC ; o load this project ; o change the ID settings for your needs in the code below ; (default: 0x0000000000000000) ; o assemble this program or just use the preassembled .hex file if you ; don't want to use a different ID ; o reconfigure the programmer so that only the first 4k block will be ; overwritten ; - MPLAB IDE: click on Programmer->Settings, change Program memory ; end address from 7fff to fff, ; thereafter click on Programmer->Program ; - MPLAB V5.4: click on PICStart Plus->Program Verify, set the end ; address from 0x7fff to 0xfff, ; thereafter click on the program button ; o plug the PIC into the core module, start the program ; -> the MIOS bootstrap loader will get active for 2 seconds ; -> thereafter this program will be started ; -> the MIOS bootstrap loader will be started again, but now with ; the correct ID settings ; o don't forget to set the "program end address" to 0x7fff again before ; you upload the bootstrap loader for another PIC Best Regards, Thorsten.

Hi Steven, the MF deadband value must be greater or equal the AIN deadband value, otherwise the motorfader driver tries to move the motors with a higher precision than the AIN driver can deliver the conversion values (=fader position), as an result you will notice those stuttering moves. I guess that all the caps between the AIN inputs and ground are not really required, especially high capacitance values can cause more problems than they should solve. More important is a good ground connection between the fader chasis, the Vss pin of the fader and the Vss pin of the core module. And (this is a new awareness) one 100nF cap across +5V and ground very near by the faders. I just have measured the signal quality of my MBLC with a scope and noticed some noise at the +5V input of the fader rail. Such noise is very common on a digital circuit and it can be eliminated by using small caps near by the drains. One cap should already be enough to fix this problem. See also the updated schematic: http://www.ucapps.de/mbhp/mbhp_mf_interconnections.pdf Best Regards, Thorsten.

Hallo Slajar, den Inkrementalgeber einer Maus kannst Du genauso wie einen normalen Rotary Encoder an das DIN Modul anschliessen (siehe auch Concepts->MBHP->DIN). MIOS kann bis zu 64 davon parallel verwalten, bei Aenderungen wird ein User-Hook aufgerufen der dann bspw. die MIDI-Schnittstelle direkt bedient oder interne Parameter veraendert. Beispiele hierfuer findest Du unter Concepts->MIOS->Download (enc_example*) Die USB Geschichte have eigentlich schon laengst abgeschlossen - die Firmware steht und der Prototyp ist bei mir im staendigen Einsatz. Was fehlt ist das PCB; Tim hat das Layout mittlerweile fertiggestellt, die ersten Boards sind gerade unterwegs zu mir. :) Gruss, Thorsten.

Hallo Thomas, eine andere Loesung als die direkte MF/Core Modul Kopplung kann ich leider nicht supporten. Theoretisch waere es schon machbar, mit einem Grab and Logik-Gattern die Ausgangssignale zu multiplexen, um MF und Core Module einzusparen, aber solch eine Loesung wuerde auf jeden Fall Performance kosten, die Fader wuerden sich auf keinen Fall mehr "smooth" bewegen, ausserdem wuerde sich die Fehleranfaelligkeit des Systems erhoehen. Die Softwareerweiterung fuer MIOS wuerde fuer mich eine Menge Aufwand bedeuten, und ich haette noch nicht einmal die Moeglichkeit, das System zu testen, geschweige denn Dir zu sagen, wo es hakt, wenn mal etwas "klemmt". Deshalb bevorzuge ich die jetzige Loesung. Von den Kosten her sehe ich kein grosses Problem - bei diesen Mengen lohnt es sich die Bauteile in Amiland zu bestellen, suche mal unter http://www.findchips.com nach den ICs, den TC4427 gibt es bspw. schon ab $1 (TC4427AEPA-ND), den PIC18F452 fuer $5.70 (PIC18F452-I/PG-ND) bei Digi-Key. Und der US-Dollar steht gerade guenstig... Navigationsbuttons, Displays, etc.: wie man das prinzipiell loest habe ich ja schonmal geschrieben: http://www.ucapps.de/midibox_link/tunnel4.gif konkretere Vorschlaege kann ich eigentlich erst dann machen, wenn Du Dir ueber die Hardware klar geworden bist. Vor einiger Zeit hast Du bspw. mal den Vorschlag gepostet, fuer jeden Kanalzug ein eigenes Display vorzusehen. Ab MIOS V1.2 koennen mehr > 2 LCDs an jedes Core Modul angeschlossen werden, der Umsetzung steht also nichts mehr im Weg. Gruss, Thorsten. P.S.: noch etwas zu den BankSticks: bei 4 Presets werden die nicht mehr benoetigt. Die Daten koenntest Du stattdessen auch direkt im Flash speichern (der Flash-Speicher des PIC18F452 ist 32k gross), der Update funktioniert nun ueber den Bootstrap Loader via MIDI in sekundenschnelle :) Da Du sowieso mehrere PICs benoetigst, sehe ich keine Notwendigkeit fuer eine "Speichererweiterung"

Hi Tom, it seems that you've started the .jar file with the original JSynth release... Just open a command shell, go into the jsynth directory and type "java JSynthLib", or click on the "run.bat" file to run JSynth with the SID driver Best Regards, Thorsten.

Hi Steve, thank you for the feedback! :) The low bass is nothing else than the "P24 Filtered Bass 2" preset of the MIDIbox SID, but in fact you don't hear so much from the original sound, but primarily the subharmonics which are coming from the subbass fx plugin of Logic Audio. It makes the bass so low that it doesn't overlay the other instruments :) For mixing I'm using the Magnat Vintage speakers of my stereo, however, I'm still trying to improve the mixes, especially the compressors are killing me ;-) Best Regards, Thorsten.