TK.

Hi Robin, I wouldn't use this configuration area for such extensions, the implementation is too difficult for that what you are doing, and I don't think that you are planning to enhance the perl script (mk_midio128_syx) in order to edit the modes. It's easier to define special MIDI events for radio groups, and to handle them in a similar way like program change events. You could use "0xf0"-"0xff" for such extensions, such "Meta Events" are automatically forwarded to midio_meta.inc (read the comments in this file) Best Regards, Thorsten.

Great! I will add this hint for the COM interface to the Bootloader page :) Best Regards, Thorsten.

See also this posting http://69.56.171.55/~midibox/forum/index.php?topic=4047.0 you can save a lot of money with a batch order Best Regards, Thorsten.

Hi Mikael, can you please inform Mike and Claudia about this mistake? Schematic and layout are matching, but the values in the eagle file are not up-to-date due to different requirements (I don't think that it makes sense to release different eagle files for different SIDs where the routing is identical). Your SID will work without C4, but it's better to stuff it sooner or later in order to improve the signal/noise ratio. C6 is only required when the Audio In is used. C9 can be 1000 uF if your are using a good PSU, 2200 uF if an AC transformer is connected to J1 Best Regards, Thorsten.

Hi, Doug: good hint, I will add a SPI port. It's just a 2-pin header at RB0 and RB1 The firmware will give enough room for such extensions. I guess that it will onl takes ca. 1-2k (if written in assembler), the bootloader takes 2k, so 28k are still free for experiments. Performance isn't an issue (the core is clocked with 48 MHz) Andrew: the P18 software itself is in english - it provides a hardware debugging window which allows you to check if the PIC programming pins (MCLR, Vdd, RB6, RB7) can be controlled in the right polarity. If it doesn't work, then you can possibly fix this by changing some pins at the parallel port (do you need more details? Best Regards, Thorsten.

Hi, great to hear that I'm not the only one who is working on a PIC based USB-MIDI solution - do you plan to publish the source code to the public domain? It would be a big help for people who want to do extensions (like USB-Audio, IO control, etc) To the descriptors: the old MBHP_USB firmware package contains the source code (-> http://www.ucapps.de/mbhp_usb.html), the descriptors can be found in "dscr.a51". Small changes can bring your windows installation to a blue screen. E.g., WinME and Win2k are crashing when you are defining an empty Audio Control device (like suggested in the USB-MIDI spec), therefore it is left out And now the fun begins: the released version doesn't work on all WinXP systems, some installations require a modified one which will be regognized correctly, but causes a crash under Win2k - due to this mess I'm thinking about a selfwritten Windows driver based on the Microchip framework - does anybody have experiences with Win driver programming? Best Regards, Thorsten.

Some time ago I made a SID remix of "No Birthday" from JCH, which is now available at http://remix.kwed.org Best Regards, Thorsten.

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.