TK.

A release candidate for SDCC 2.8.0 is available at: http://sdcc.sourceforge.net/snapshots/sdcc-2.8.0-rc1/ Finally we also get precompiled MacOS X universal binaries :) Best Regards, Thorsten.

A general answer to this topic: for every MIDIbox which uses analog components (like pots, faders, but also audio circuits like SID or OPL3), it is recommented to use the optocouplers at both sides (so, don't leave out a part) to avoid jittering values (at the AIN side) or digital noise (at the audio side). So, just use a common cross-connection between MIDI In and Out ports. Best Regards, Thorsten.

MBSEQ V3 receives MIDI Clock in Slave mode, and sends MIDI Clock in Master mode. The clock can be distributed to individual MIDI Outs in the MIDI configuration menu. MTC is not supported (impossible to implement this for a step sequencer) Best Regards, Thorsten.

Hoert sich sehr plausibel an! Ich weiss nicht, wie die neueren C64 Netzteile aufgebaut sind (ich selbst verwende eins von 1985), doch wenn in Deinem eine elektronische Sicherung eingebaut ist, die bei Ueberstrom den Schaltkreis oeffnet, und die sich nur durch ein erneutes aus-einschalten zuruecksetzen laesst, dann waere das Phaenomen aufgeklaert. Wieviele Kondensatoren befinden sich im Stromkreis der SID Versorgung? Falls jedes SID Modul mit C9=2200 uF bestueckt ist, koennte das evtl. zu solchen Problemen fuehren. Tausche sie einfach gegen 220 uF (oder 470 uF oder 100 uF) aus, und loete stattdessen einen einzigen 2200 uF an den Ausgang der PSU. Probehalber koenntest Du C9 auch erstmal komplett weglassen (vielleicht wird es dann am Audio Ausgang ein wenig brummen...) Gruss, Thorsten.

Moin, ja, der Upload war erfolgreich. Die MIOS Meldung erscheint immer beim Hochfahren des Cores. Bleibt die Frage, warum es mit MIOS Studio nicht funktioniert. Welche Java Version verwendest Du? Gruss, Thorsten.

Ich vermute eher eine software-maessige Feedback Loop. Welches MIDI Interface verwendest Du, und wie sieht Deine MIDI-Verkablung aus? Bei mir treten solche Fehler bspw. auf, wenn ich zwei MIDIboxen mit der gleichen MIOS Device ID am gleichen MIDI Out angeschlossen habe. Beide erhalten die Codebloecke, und ein PIC wird zuerst "bin fertig" antworten. Daraufhin schickt MIOS Studio bereits den naechsten Block, waehrend der zweite PIC noch das EEPROM programmiert. Falls das der Fall ist, wuerde ich empfehlen, jedem Core eine eindeutige MIOS Device ID zu vergeben. Das geht am einfachsten mit der change_id Applikation. Aehnlich verhaelt es sich uebrigens, wenn MIDI-Ox parallel zu MIOS Studio laeuft, und der MIDI-Port Router so eingestellt ist, dass eingende MIDI Streams direkt an den MIDI Out weitergeleitet werden. Gruss, Thorsten.

I don't understand the question completely. CV outputs are provided by the MBHP_AOUT* modules (MBHP_AOUT/MBHP_AOUT_LC/MBHP_AOUT_NG). The synth engine of MBFM controls them (and not the OPL3 chip, as this chip doesn't support such functions). You can modulate the outputs with LFOs and EG5 Best Regards, Thorsten.

We've 6 mono voices, and they can be routed to 4 audio channels. By default, voices are routed to all 4 channels (for people who want to test their MBHP_OPL3 module) Best Regards, Thorsten.

Verwendest Du beim Aufladen die "Smart Mode" Option? Falls nicht, koennte es zu diesem Ueberlauf kommen. Nur der Smart Mode stellt sicher, dass keine neuen Daten gesendet werden, bevor die vorigen programmiert wurden. Das Programmieren ins EEPROM dauert etwas laenger als 300 mS, die im "Manual Mode" voreingestellt sind Gruss, Thorsten.

Hallo, zwei grundsaetzliche Fragen: wann und wo hast Du den PIC18F4620 gekauft, und verwendest Du den aktuellen Bootloader? (der Bootloader wurde zuletzt vor zwei Jahren geaendert, aber es tauchen immer wieder Leute auf, die den Update damals verpasst haben) Und verwendest Du die aktuelle MIOS Studio Version v7.5? Hier gibt es hin und wieder ein aehnliches Problem: manche Leute holen sich irgendwo aus dem Netz eine aeltere Version, die nicht mit dem PIC18F4620 und PIC18F4685 kompatibel ist Gruss, Thorsten. P.S.: falls alles up-to-date ist: versuche mal, die Firmware mit dem 1st Level Bootloader aufzuladen - der ist kurz nach dem Einschalten fuer ca. 2 Sekunden aktiv.

It also makes sense for MB808, so would be nice if you could prepare it. Btw.: I'm interested in the extension module as well! :) No, the lag is always 20 mS (or the configured debouncing time) - independent from the number of simultaneous pressed buttons. And: a lag/delay will not happen, if the there wasn't a button event for more than 20 mS Best Regards, Thorsten.

Hi Derek, JSynthLib doesn't allow to edit the patch data of the second slave directly. Thats a limitation of JSynthLib - only solution: edit the sound on master, store it into BankStick, and transfer the patch to the slave via master Best Regards, Thorsten.

Generell habe ich nichts an AVRs auszusetzen, doch in diesem Fall stimmt die Rechnung nicht. MIDI ist eine sehr elegante Loesung, denn die Daten werden kompakt in einem standardisierten Format versendet. wenn es unbedingt RS232 sein muss: MIOS kann auch ASCII versenden. Mit dem MBHP_LTC Modul ist man RS232 konform ein PIC kostet nicht 20 EUR, und 8x4051 kosten nicht 10 EUR RS232 ist obsolet, PCs werden heutzutage nicht mehr mit dieser Schnittstelle ausgeliefert. Stattdessen benoetigt man einen Serial->USB Converter (bspw. FT232) Doch wenn man schon einen Converter Chip fuer USB benoetigt, warum nicht gleich einen Mikrocontroller mit integriertem USB hernehmen, so wie bspw. PIC18F4550 oder PIC18F2550 - das waere dann wirklich eine kostenguenstige Loesung, erfordert jedoch ein bisschen mehr Programmieraufwand (MIOS wird nicht supported, aber man koennte die MBHP_USB_PIC Firmware hernehmen, und dort eine ADC Konversionsroutine einbauen), doch den haette man ja auch mit der AVR Loesung. Ich habe hier uebrigens noch einige PIC18Fx550 mit EUSART bug herumliegen, mit denen ich nichts anfangen kann. Ich koente Dir 1 oder 2 Chips zuschicken. :) Gruss, Thorsten.

Julien has finished his great looking MIDIbox SEQ V3. It fits into a 2U case! He wrote: Frontpanel Layout: http://www.midibox.org/users/julienvoirin/Seq_2U_CADv3.1.1a.fpd

Hi Mike, great work! I really like it when an application evolves this way! :) Are you interested to publish your variant in the new project repository? As you can see here, we've a much more clean directory structure meanwhile. You could create a new directory, and maintain the application on the SVN server in future :) We've a special board where you can read about the details (and get write access to the SVN server). Just drop me a mail to get programmers status :) Best Regards, Thorsten.

The extra buttons are used to select the track group directly, and the 4 integrated LEDs display the currently selected group. These buttons/LEDs are strongly recommented for new frontpanel designs. It depends on your HW configuration, if an additional 74HC595 is required. I added it to the end of the BLM chain The debouncing method I used for the BLM module is very expensive (RAM and CPU wise). MBSEQ V3 has no additional RAM free for such features (only if you would get rid of useful features like Undo buffer and Mixer...) But I could add a "cheap" version which disables all BLM buttons for a short moment (e.g. 20 mS). I guess that you wouldn't really notice a difference, because it's the same approach which MIOS uses to optionally debounce normal DINs, and nobody ever complained about this ;) Best Regards, Thorsten.

I intensively tested the PIC18F4620 B4 today, which came with the MB808 kits, and which is available in SmashTV's shop since many months. It turned out, that this chips revision is not affected by the infamous EUSART bug anymore Hurray! :) Especially for MIDIbox SEQ users this means, that the MBHP_IIC_MIDI module is not required as hardware workaround anymore. However, adding up to 4 additional MIDI Outs to MBSEQ is still useful for reduced latency (you still won't find any commercial HW based MIDI sequencer with 5 independent MIDI outputs! :)) This also means, that existing MIDIbox applications could be enhanced by new features in future; thanks to the additional memory this opens a lot of new possibilities for just US $1 more! My recommendation: MIDIbox SID V2: still needs a PIC18F4685 because of the CAN interface and bigger flash memory (96k), but less RAM as the PIC18F4620. PIC18F4685 is not fully SW compatible to PIC18F452, therefore other applications could crash MIDIbox FM: MBFM V2 is planned for far future (probably not this year). CAN support for linking MBFM with "slaves", or controlling MBFM from MBSID control surface can be expected. MBFM V1 firmware is running fine on PIC18F4685 all other MIDIbox firmwares are compatible to PIC18F452 and PIC18F4620. The usage of PIC18F4620 is recommented if you don't want to miss new features. Best Regards, Thorsten. P.S.: there is a new Wiki page which documents the obsolete HW workaround for PIC18F4620, just for the case that you bought this chip before 2007, or got it from an "old stock". However, you can decide by yourself, if buying a new one (e.g. from SmashTV) is easier than building a MBHP_IIC_MIDI module.

No, it's a remix of Cobra; Author: Ben Daglish (-> http://hvsc.tp2.be/?info=please&path=C64Music/MUSICIANS/D/Daglish_Ben/Cobra.sid) Best Regards, Thorsten.

Hi Alex, thanks for the warning! Please inform Mike as well Best Regards, Thorsten.

PCA9635 is only available in TSSOP package (=SMD), whereas TLC5940 is available as PDIP variant which simplifies soldering and/or prototyping on a breadboard. And you can easily order free samples from TI for evaluation purposes :) But you are right, PCA9635 is an attractive solution as well. Best Regards, Thorsten.

Alkex did it again: after Octopus, he built another great keyboard version of MBSID V2. :) He wrote:

So, with "seq" you don't mean an internal sequencer (like WT, bassline or drum engine sequencer), but just an external MIDI device. You haven't meantioned, how you've configured the velocity "knob" assignment - perhaps because you missed this? See also this doc for the parameter table. Volume is Parameter #1 for all engines. So, which parameter number is displayed in the Knobs menu, when K#V knob assignment is displayed? And what is the specified Min/Max range? Best Regards, Thorsten.

You are absolutely right, but you should also see it from my point of view. I can be very helpful to people who want to realize a HW and/or SW project and share it with the community. I'm especially willing to give them the right hints at the beginning before they are starting with an approach which won't be flexible and powerful enough at the end. I'm just a little bit bored from people who expect that a ready made and perfectly working solution is available, so that they only need to tweak on some parameters (like "number of LEDs", "PWM resolution") w/o spending some own thoughts on the topic (or document their findings in the Wiki). You are not one of those guys (thanks for pro-actively starting a FAQ!), this was hard to estimate after your first posting. Therefore some more infos. It depends on your design targets, which approach fits your needs. E.g. you can easily generate PWM with the common MIOS approach (updating a SRIO chain each mS in background of the main application), but experiments have shown, that this doesn't work flicker-free with more than 3bit resolution. And than more LEDs should be PWM controlled, than higher the CPU load, than less tasks can be handled in parallel. For 24 LEDs it should work, but only at 3bit resolution - this doesn't fit your requirements, and I know that 7bit is important for your plans, therefore simple answer: it does not work this way. Another solution could be to control the DOUTs in a seperate chain with higher update rate. E.g., in previous (pre-MIOS) projects I used MBHP_CORE:J7 as alternative port for independently controlled DOUTs The usage of this port is not natively supported by MIOS (there are too different usage models), but it's easy to control it from the application. Problem here: you might be able to increase the update rate by factor 2 or 4 (250 uS), but by doing so, there wouldn't be enough compute power anymore for handling 24 encoders in parallel without loosing "ticks". So - this solution works for people who only want to fade 24 LEDs, but it doesn't work for your intentions. Next possibility: instead of using a background timer, just control the LEDs in the main task (MIOS: USER_Tick). Thats basically the same approach like known from most Adruino projects. Pro: very straightfoward approach, easy to understand, easy implementation. Con: you will run into troubles once multiple tasks have to be handled in parallel. E.g., receiving and parsing incoming MIDI data, reacting on asynchronous events e.g. rotary encoder movements or high MIDI traffic, outputing LCD messages, etc... Easy to understand effect: with such a straightforward approach, LEDs would flicker. I don't think that this is acceptable from your side. ;) Concepts need to be changed once "multitasking" is required. And these are the concepts which went into MIOS. They make the implementation a bit more complicated, maybe also a bit more expensive (if additional HW components have to be added), but at the end it gives you more flexibility and a certain guarantee, that your project won't end into a half-working tinkering solution with a lot of compromisses. So, what to do: you could simply "outsource" the PWM task to a "slave" PIC, controlling the DOUT chain and waiting for "commands" from the "master" PIC. The master could send LED brightness in form of MIDI events to the slave, or it could be connected to the IIC bus as known from MBHP_IIC_MIDI and MBHP_IIC_SPEAKJET (in such a case, you could also use an inexpensive low-cost PIC derivative) If the maximum PWM update frequency for handling 24 LEDs from a single PIC is not sufficient, just use two or three PIC16F88, and control them all from the master core. Another advantage: serial registers (74HC595) are not required anymore. Just connect LEDs directly to the IO pins. This probably also saves you from using LED drivers. Disadvantage: more programming skills are required, and everybody who wants to recreate the project needs a PIC burner to program the firmware into the PIC16F88 So - at the end I came to the conclusion, that the easiest and most powerful way for generating high-resolution PWM is the usage of ready made PWM chips. TLC5940 is a good choice btw. Too bad, that this topic is continued in another thread. I really hope that users starting to collect more implementation details in the Wiki so that the final conclusions won't get lost Best Regards, Thorsten.

In far future: yes - I'm planning to implement a concept which allows to remote-control one MIDIbox (synth) from another (primitive implementation: LCD messages will be forwarded from slave to master, button/encoder actions will be forwarded from master to slave via CAN). Very simple, but effective. Best Regards, Thorsten.

This topic has been moved to MIOS programming ©. [iurl]http://www.midibox.org/forum/index.php?topic=10915.0[/iurl]