TK.

One of the big advantages compared to MIDI is the replacement of strict data structures and MIDI channels. Take MBSID V2 as an example: the full stuffed version allows to run 4 multi engines, each multi engine controls 6 voices, makes 24 independent voices. But there are only 16 MIDI channels - so, not only that the user has to define suitable channels and keyboard splitzones (to overcome the channel limitation) - has has to do this at both sides (synth and keyboard/sequencer), which makes the handling difficult, inflexible and error-prone. With OSC you are working with pathes instead. E.g. voice #3 if SID2 could be addressed with /sid/2/voice/3, voice #6 of SID4 with /sid/4/voice/6 And now the power of OSC: by using wildcards, you can access a set of voices the same time, like: /sid/*/voice/* or /sid/2/voice/* What I don't like on OSC is (but I could have missed this in the past), that there is still no solution for a client to find out which parameters are supported by an OSC server. Or in other words: wouldn't it be nice if you plug a MBSID and MB64E together, and MB64E would automatically get a list of all parameters on a standardized way, so that you only need to assign the named and characterized parameters (resolution, center value, long and short name, button behaviour) to the faders, knobs and buttons? And that the same would work, when you select other servers from MB64E like your favourite host sequencer or VST instrument without changing the cabling? If such features would be supported by the protocol, it would be a killer argument against MIDI. So, does anybody know more about this topic? Best Regards, Thorsten.

It isn't possible to support continue, you can connect it to ground. Start is the same like Start/Stop or like Run. The signal is 1 when the sequencer is running, and 0 when it is not running. This matches with the description I've found about this sync input at various websites... Best Regards, Thorsten.

the same issue exists when the SID is controlled from a C64 of course. It also exists on other SID synths, like the SIDstation, and people have learned to live with this... Have you ever heard the background noise we are talking about? ;) I mean - the s/n ratio is about -60 dB on a 6581, and ca. -90 dB on a 8580 (depending on the quality of the PSU), therefore you only notice it when the SID is silent (which was not the case in C64 tunes ;)), and when the audio output is dynamically amplified, e.g. with a compressor. But there are simple Fx (e.g. VST) based solutions without need for additional hardware to remove the background noise completely if desired. Also - if a compressor is used, tweak on the parameters (keyword: knee) so that at a certain silence level the output won't be amplified. I for myself mostly don't use such measures, there is just no real need for this -> in the mix <- Therefore I don't understand the endless discussions about alternative, more complex and more expensive solutions. I also don't know, who should document and support all these solutions... However, if this is a 50 Hz buzz, then it is another problem of course. Have you grounded the unused audio in channel? (strongly suggested) Best Regards, Thorsten.

OSC is a protocol like MIDI, there is no need for using python in order to convert messages, you can just send them directly to the host, e.g. via ethernet; you could also use an alternative interface, like CAN, USB or similar. But as most computers are stuffed with an ethernet interface today, and in OSC host applications this interface is also prefered, it's the first choice. Best Regards, Thorsten. P.S.: for LiveAPI it seems that OSC is only available through the python interface, but I haven't digged so deep into the docs (not really interesting for me...)

I'm sure that OSC has a future, and I'm also sure that there will be MIDIboxes with ethernet support sooner or later. It could even be possible to connect an external ethernet controller like the ENC28J60 to a common core module to prevent a major hardware re-design. But I fear that for a decent application which satisfies all the request we normaly get from you guys, an 8bit controller is not sufficient. In this special case (complex controller which supports OSC) maybe an ARM based microcontroller with Embedded Linux installed would be fine and easy to handle... However, for simple OSC controller applications the PIC could still be sufficient. Best Regards, Thorsten.

We had this suggestion many times, but my assumption is: when somebody asks such generic questions, it will be very difficult for him to build and setup external DACs and VCAs Such an option will only be supported by MBSID V2 anyhow (see the appr. postings about external outputs) But to make it short: it's still a tinkering solution - it especially won't work on multi or drum patches Better solution: use a 8580 or 6582, or some Fx VSTs like an envelope follower or noisegate (like you mentioned) Best Regards, Thorsten.

Yes, of course. But MBCV also provides a more generic way for requesting and sending dumps: a) F0 00 00 7E 48 <d>1 F7 Request a Dump <d> = device number (0-7) b) F0 00 00 7E 48 <d>2 <dump> F7 Write a Dump <d> = device number (0-7) <dump> = 512 bytes dump data [/code] It's the same format which is sent out when you press the SELECT button within the SysEx menu page With a common sequencer (only tested with Logic) you can record and replay such a dump. Normaly I'm doing it this way: start record, go into SysEx menu, press SELECT - done Once you playback the track, the configuration will be sent to MBCV, and it will update the internal parameters automatically. Best Regards, Thorsten.

Hi Toby, the 3 multiplexer control lines of the two AINX4 modules have to be connected together like shown in this schematic: http://www.ucapps.de/mbhp/mbhp_ainx4_64pots.pdf It doesn't matter, if you link them at the AIN module, or core module side. Only the electrical junctions are important. :) But the control lines should not be connected to J7 of the core module, this port has another purpose Best Regards, Thorsten.

Hallo Simon, vielleicht hilft diese Info weiter: http://www.midibox.org/forum/index.php?topic=9363.msg66977#msg66977 Gruss, Thorsten.

Hi, you are using 6581s, right? There is no real help, it's the VCA leackge issue, which cannot mute the oscillators completely. And yes, there are also variations between the SIDs, see http://www.midibox.org/forum/index.php?topic=9135.msg66996#msg66996 Best Regards, Thorsten.

Very good point. I've no experiences with photo MOS delays, but it looks like a 4066 w/o galvanical connection, which is good! Somebody has to try this on some real gear Btw.: according to the data sheet, the LED operating current is 1.4mA typical, and 3 mA maximum (not 50 mA) - thats even better :) Best Regards, Thorsten.

Yes, this is normal. In the first years Commodore optimized the chip production process, with the effect, that the SIDs - especially the filters - are sounding different. Also the leackage varied (high leackage -> hot chip). Only the newer 6582s and 8580s are sounding relatively equal, therefore (and also because of the better filters of course) this should be the prefered choice for stereo synths Here two samples for comparison: Two 6581 from calendar week 40/84 and 25/84 which sound very different: http://www.ucapps.de/mp3/midibox_sid/mbsidv2_filter_6581.mp3 Note that the filter characteristic is not linear, therefore a simple linear-based calibration doesn't really help here. Two 8580 (or to be correct: 6582) from the same batch (but my two 8580 sound equal to 6582) http://www.ucapps.de/mp3/midibox_sid/mbsidv2_filter_8580.mp3 Note also the silence at the end (nearly no background noise compared to 6581) Best Regards, Thorsten.

The handling of all incoming MIDI events is equal, but it sounds like your keyboard (or controller) sends CC over a different channel, is this correct? In this case you have to change the channel setup on your keyboard/controller Best Regards, Thorsten.

Der Master steuert natuerlich alle drei Slaves an. Du kannst das ueberpruefen, indem Du Dir die MIDI Meldungen anschaust, die vom Master bspw. waehrend eines Patch Changes gesendet werden. Selektiere mal SID4 und drehe auf der Hauptseite am Encoder - welche Meldungen werden gesendet? (mit MIDI-Ox laesst sich am einfachsten debuggen) Gruss, Thorsten.

When pressing two buttons the same time, you are switching between matrix and meter mode -> see changelog Best Regards, Thorsten.

Faster than the PIC can be clocked - the transfer speed is no issue here What are you planning to do exactly? Best Regards, Thorsten.

A T6963C is too slow for a MBLC - it could work, but due to the long access times there is a high chance for MIDI IN buffer overruns which cannot be avoided. See also the LCD benchmark: http://www.midibox.org/forum/index.php?topic=2169.0 I'm using a KS0108/KS0107 based GLCD, and it still works great! :) Best Regards, Thorsten.

Hi, did you handle the AC/ground lines with special care to avoid short circuits? It's for example important, that the PSU is not powered when you are soldering the cables. If not, propably the fuse has blown-up. I don't know the US version of the PSU, but on the EU version it can be easily replaced (there is screwable socket) Best Regards, Thorsten.

Hi, this is a low-performance T6963C based display - for what kind of MIDIbox are you planning to use it? Best Regards, Thorsten.

Great! :) Best Regards, Thorsten.

MIDI clock and SMPTE/MTC are two different things. There is no direct relation, as MIDI clock works step based, whereas SMPTE works timeframe based. See also http://www.borg.com/~jglatt/tech/midispec/seq.htm and http://www.borg.com/~jglatt/tech/mtc.htm Best Regards, Thorsten.

Hi, With MBSID V2 you cannot use joystick or pots the same way it was possible with MBSID V1, as the analog inputs are not handled by MIOS anymore, but directly scanned as analog modulation sources by the firmware. The rest of the panel is fine, but please consider that for MBSID V2 the labeling is slightly different. See also http://www.midibox.org/forum/index.php?topic=9040.0 And since there is enough place on your panel, you could add an 8th modulation line for "Vol" (below "Filter") Best Regards, Thorsten.

Hi matcom, it looks like there is a missing or bad connection between IC2 and IC3, see also the schematic http://www.ucapps.de/mbhp/mbhp_sid_v3.pdf You will see three control lines which are going to the SCLK, RCLK and SER input of the 74HC595. At least one of them seems to be faulty. You can check these signal lines visually, and/or with an ohmmeter when no ICs are connected Best Regards, Thorsten.

no, these are the flags for various hardware options (e.g. oscillator selection, brownout voltage, code protection). These two words should never be changed. The ID field is a number with 16 digits (8 bytes). It is "all-1" after erase, and if it won't be programmed, you will notice exactly the described effect. I just have downloaded WinPIC and searched for a possibility to change the ID field. It seems that the GUI doesn't allow this. But under "Device->Program ID locations" you can program it, propably with the values which are embedded in the .hex file (and in this file I've written the all-zero header) So, just try this function, hope that it helps. If not, the "TEST SW2" workaround of the MIDI troubleshooting page could help Best Regards, Thorsten.

Last week I've heard exactly the same noise on a MBSID - the reason was a bad soldering joint on the C1 cap (connected to pin 1/2 of the SID). So, it makes sense to check the C1/C2 cap connections Best Regards, Thorsten.