TK.

Hi, there are so many hints at different places how to change the device ID (mk_syx.pl ... -device_id <id>), I don't know where I should add them anymore. However, I will ask Adam if he can send you the beta version of MIOSStudio - it's based on Java, can upload MIOS code (one of a lot of features!) and change the device ID on the fly (of course) Best Regards, Thorsten.

Hi Andrew, I got the PICs yesterday and was able to burn them with P18 without any failure - see also http://www.ucapps.de/mbhp_burner.html, the upcoming PIC programmer for the parallel port Picture of the prototype (not all parts will be used in the final circuit): I've burned the USB bootloader which is provided by Microchip and allows to upload code via USB. The USB connection also worked immediately Prototype: The final board will be much smaller, here the schematics: http://www.ucapps.de/mbhp_usb_pic.html Some words to the possibilities (and especially to the things which are not possible): It won't be possible to run MIOS applications on this chip due to compatibility issues. A silicon bug prevents me from re-using the code 1:1 (the movff issue), the USB DPRAM overlaps a register range which is normaly allocated by MIOS itself, and the USB bootstrap loader allocates too much memory, so that most MIOS application won't fit into the flash anymore. However, this isn't really a drawback. The PIC18F4550 (or PIC18F2550) is so cheap, that it isn't worth the effort to create a perfectly running MIOS solution. I will provide a firmware later which will allow people to make their extensions if they want, but most people will already be happy when they are able to connect the MBHP_USB_PIC module via MIDIbox-Link Port to the MBHP_CORE module Now a lot of programming effort is waiting for me, because the USB framework which can be downloaded from the Microchip homepage is only available in C18 ($$$), therefore the whole thing has to be re-implemented in assembler. Maybe I will start with this at easter time (during holidays...), but if anybody wants to do this (for a GNU GPL release) - step forward! Best Regards, Thorsten.

Hi, we've moved to a new server again - have fun! Twin-X, where can we donate? :-) Best Regards, Thorsten.

Thanks Twin-X!!! The forum will be moved next friday Best Regards, Thorsten.

Nice - additional ideas: like already mentioned you can use the inbuilt switches of your encoders as a replacement for the FAST button. Next to the Power switch you could add a MIDI In and Out LED I'm not sure about the short distance between the encoders, maybe it will be hard to turn a single encoder without touching the neighboured ones - you should try this out Best Regards, Thorsten.

Folgende Mail ist in meinen Briefkasten geflattert. Ich betrachte sie nicht als Werbung, sondern vor allem als Hinweis darauf, dass sich eine Menge Geld sparen laesst, wenn ihr nicht einzeln bei albs.de bestellt, sondern eine Sammelbestellung organisiert - evtl. auch zusammen mit Interessenten aus dem Ausland - je mehr sich daran beteiligen, umso guenstiger der Endpreis (Lets Buy It ;-))

Duggle sent me this schematic for an alternative PSU: So, who wants to try this out? Best Regards, Thorsten.

No, it doesn't show any graphic, it's already (very) hard enough to bring all the code into the small flash ;-) A 4x20 should work, it allows you to display up to 10 items at once, but you've possibly to do some modifications in the display layout (never tried this...) Best Regards, Thorsten.

please wait for the first schematic. One feature I'm planning is to allow an on-board configuration for 4*8bit outputs or 2*16bit outputs (however, I think that more than 12bit are not really required, but it's more than 8 bit ;-). Another thing which isn't clear yet is the number of OP amps (I guess one TL074 is enough for 4 outputs per module, but maybe I've to add another for the voltage reference) - this could affect the layout Best Regards, Thorsten.

Hi Ludo, you could wire all switches together to a single button function and connect one end to ground, and the other to the FAST button input. This allows you to modify values faster when the encoder is pushed down Best Regards, Thorsten.

Some weeks ago I built an option into the firmware which routes 6 analog inputs to the LFOs, selectable as 6th waveform and gated with the LFO rate - this was a nice experiment and possibly it makes sense to bring this into the official version, but making it usable for non-programmers will cost me (at least) twice the effort. To the other suggestions: who should program all this stuff? I don't feel addressed, I'm not your personal code generator, and if you would read the other posts in the forum, you would know my current focus. Especially processing digital streams in parallel to the tasks which are already running in the firmware is nonsense, I'm really frustrated that you haven't got this yet from my previous answers and don't want to give any additional comments. Best Regards, Thorsten.

Seems that I have to add some words why I favour the resistor solution - I want to realize an alternative board which is always madeable without the need for special ICs which are rarely available or hard to get in low quantities. Remember how difficult (and/or expensive) it is to get special parts - Maybe not in your country if you've the luck that a national distributor offers the chip... Maybe not for people who are ordering electronic stuff once or twice a month so that shipping costs don't matter... Maybe not if you are doing batch orders.... Maybe not for people who order a small number of samples (who knows how long this will be accepted by the manufacturers, I already got complaints...) But whats about the people who just want to play a little with analog outputs *immediately* and without much costs? And what should happen once the chips, which have been suggested in the last months, are discontinued? And where did you lost your DIY spirit? ;-) Ok, seriously: this is a very generic solution which won't require any change in the application code if somebody wants to connect a DAC with parallel interface (which are mostly cheaper and easier to get than DAC with serial interface). So long the device isn't laser-trimmed, the output voltage of the resistor ladder can be more adequate, especially if hand-selected resistors are used. The output voltage is not limited (you need balanced or high voltage outputs? No limitation here). 7-bit resolution is mostly sufficient so long the output is controlled by MIDI notes, velocity, CCs, after touch, etc. --- higher resolutions become interesting with frequency or filter sweeps, but they are mostly so fast that a gain or offset error cannot be regognized. If somebody wants to have a high-quality solution, he can spent more effort in selecting the resistors, he can still use the MAX525 design, he can choose another DAC and adapt the software driver, or he can connect a lasertrimmed integrated DAC with parallel interface Ok, these are my motiviations :) Best Regards, Thorsten.

It definitely is - just to give you an impression: I've synthesized the spdif_tx unit with some additional circuirity which intitializes the SFRs. The logfile says that ca. 10% of the FPGA is allocated, and that it runs with up to 180 MHz. However, in pratice you've to take care for the tx clock frequency, because it must be divitable by the bitrate, thats currently my blocking point (have to wait for the next Reichelt order to get some parts for a PLL) Best Regards, Thorsten.

a comparison between the two solutions would be great! Best Regards, Thorsten.

This is a suggestion from KD (member of the SynthDIY list) for a low-cost DAC interface as a cheap replacement for the MAX525: http://www.midibox.org/users/kd/KDdac.pdf I'm refering to the 8bit discrete DAC module which is uses one 74HC595, one OP amp stage and resistor ladder --- the signal quality is possibly adequate enough for most of our applications - and the availability of the parts should be superb! I will try it :) Any thoughts? Best Regards, Thorsten. Update: the final schematic of the MBHP_AOUT_LC module can be found here: http://www.ucapps.de/mbhp/mbhp_aout_lc.pdf

Hi, I just want to inform you that I've created a new PIC programmer based on the AN589 application note from Microchip with some additional circuity to ensure a stable programming voltage (7805 for 5V and LM317 for 12V) and proper digital signals (74HC14 schmitt triggers). For myself this programmer will be required to bring the bootloader into the PIC18F4550, because this chip is currently only supported by P18 (http://www.sprut.de/electronic/soft/p18/p18.htm) which doesn't support the JDM However, the new solution requires more components than Broccoli (e.g. an external power supply), but should work with all PCs. I will release the beta schematic once I got the PIC18F4550 and was able to test it with this chip Best Regards, Thorsten.

Hi Sebastian, do you mean the MIDI In LED of a LTC module? Please take care that the MAX232 chip is not stuffed, otherwise the Rx input of the PIC is driven by two output pins (-> short circuit). If you are not using a LTC, and connected the LED directly to the Rx pin, then you have to remove it first, because it lowers the signal level so much that the PIC cannot read the MIDI stream Best Regards, Thorsten.

Hi Ludo, please don't order the panel before you've completely prepared all button/encoder boards, otherwise it could happen that anything doesn't fit perfectly. Check also the LCD dimensions and especially the screw holes. I'm not 100% sure if it is more economic when the Solo button is placed below the track buttons (right to the Layer buttons so that you've 4 in a row), and the Fast/All buttons left to the F buttons. This would save one button row, and 3 * 4 buttons at the right side possibly look better than the current 4/3/4/3 combination Best Regards, Thorsten.

Hallo, unter Linux ist das Empfangen und Senden von Daten ueber den COM Port absolut kein Problem - irgendwo habe ich schonmal einen speziellen UART treiber gesehen, der die Schnittstelle nach /dev/midi? legt, doch zur Not klappt auf alle Faelle /dev/cua? (ersetze ? durch die COM Port Nummer) --- auf diese Weise habe ich anno 98 noch meine allererste MIDIbox getestet, da zu der Zeit MIDI-Ox unter Win 3.11 noch ziemlich buggy war Die Baudrate des COM Ports muss auf 38400 baud gesetzt werden - habe ich frueher meistens mit miniterm gemacht, sollte aber auch mit "setserial" (oder wie hiess das noch?) funktionieren Zu den Modulen: ersetze AIN (analog input) durch DIN (digital input) und es wird klappen :) Gruss, Thorsten.

Hm, die Performance ist katastrophal und der Speicherverbrauch enorm --- vergessen wir das lieber mal wieder ;-) Gruss, Thorsten.

It's a piece of cake to realize such a SID test software with the C wrapper of MIOS, even if the SID is not directly connected to the core: ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when an button has been toggled // pin_value is 1 when button released, and 0 when button pressed ///////////////////////////////////////////////////////////////////////////// void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) { // do nothing if button has been released (pin_value == 1) if( pin_value ) return; // clear screen MIOS_LCD_Clear(); // print header at upper line MIOS_LCD_CursorSet(0x00); MIOS_LCD_PrintCString("SID test finished."); // print SID class at lower line MIOS_LCD_CursorSet(0x40); switch( TestSID() ) // returns the quality class { case 2: MIOS_LCD_PrintCString("Quality: Class III :-/"); break; case 1: MIOS_LCD_PrintCString("Quality: Class II -> $ -> :-)"); break; case 0: MIOS_LCD_PrintCString("Quality: Class I -> $$$ -> :-D"); break; default: MIOS_LCD_PrintCString("Quality: Class IV :-( Press Button again!"); break; } } ///////////////////////////////////////////////////////////////////////////// // This function returns the quality class of the SID // Just hold it near to Port J5 (the ADC inputs) // Note: the inputs should NOT be connected to any voltage source and // should especially not be grounded!!! ///////////////////////////////////////////////////////////////////////////// char TestSID() { return (MIOS_AIN_PinLSBGet(0) + MIOS_AIN_PinLSBGet(1) + MIOS_AIN_PinLSBGet(2) + MIOS_AIN_PinLSBGet(3) + MIOS_AIN_PinLSBGet(4) + MIOS_AIN_PinLSBGet(5) + MIOS_AIN_PinLSBGet(6) + MIOS_AIN_PinLSBGet(7) ) & 0x03; } [/code] Best Regards, Thorsten.

Hi Dimitris, you can just upload the CS version to see at least the patch number/bank/name and MIDI channel. So long your core module is stuffed completely (especially the 10k pull-up at J9), it won't hurt no, this is not possible Best Regards, Thorsten.

You know what the word "evaluation" means? ;-) Sooner or later I will try out the SPDIF modules on my FPGA board, maybe I can tell you thereafter if using a PIC for processing is feasible or not Best Regards, Thorsten.

Best Regards, Thorsten.

Hi André, by using the C wrapper of MIOS it's a piece of cake to create (and especially to customize) such a 4-display MIDI monitor . It only has to decode the incoming MIDI events in MPROC_NotifyReceivedEvnt() and has to place the parameter name and value at the right display positions. Details about the C wrapper can be found in the MIOS programming section of this forum. Once I find the time, I will provide some examples to demonstrate the usage, but I think that such a project doesn't need so much explanations, it's a straight forward programming task which should be easy to realize even for programming beginners. However, 4 LCDs require a driver adaption, because by default only 2 LCDs are supported. Such addaptions can be made in a customited app_lcd.inc driver (see also the lcd7_clcd.zip package) and need assembler due to execution speed reasons Best Regards, Thorsten.