TK.

Doch, die MBFM unterstuetzt AOUT und AOUT_LC, die Pinbelegung ist auf der MBHP_AOUT Seite beschrieben Wegen des Poti-Problems: evtl. gibt es einen geringen Potentialunterschied zwischen Masse der Potis und Vss (Masse) am PIC. Schliesse die Masse der Potis mal direkt an J5:Vs, das sollte helfen. Gruss, Thorsten.

And with a higher update rate, you can try the "bit angle modulation" concept which is described here: http://www.artisticlicence.com/app%20notes/appnote011.pdf It improves the resolution, and it distance to "normal PWM", the brightness can be controlled in a linear manner. Best Regards, Thorsten.

Unfortunately it's very likely, that the drum engine of MBSID V2 will support less than 21 patches per drumkit. The intention is to provide prepared "drum modules", so that you don't need to edit wavetables - it's just a fast and easy to use solution to get some drum sounds out of the SID w/o a long installation and configuration orgy. Another important thing is, that a drum kit doesn't consume more memory like a patch of another engine, so that the same BankStick can be used for storing patches of any engine (same frame format) Best Regards, Thorsten.

It is good that alternative solutions do exist with a different focus. The documentation of Arduino is really superb, the software concept is nice, and I think that the platform is sufficient for many experiments. You will run into problems once performance does matter, but this is only a "driver" issue (e.g. converting analog inputs & scanning shift registers via interrupt). Only thing that I don't understand is, why they selected a microcontroller with a low pin-count. Normaly you can never get enough IO pins (especially when a LCD should be connected for debugging), and the price is the same... Btw.: I like the idea that they use the FT232 as a USB interface which makes the adaption to PCs much easier; if a USB driver for COM->MIDI (multiclient capable of course!) would exist, I would use this chip in the MBHP as well. Best Regards, Thorsten.

This very special MIDIbox SID based "sound and AD/DA processing" module has been created by Gerald aka. Logo64 He introduced it long time ago in this posting: http://www.midibox.org/forum/index.php?topic=4963.0, but the pictures never found the way into the gallery. Take it as an inspiration, what cool things can be made with a MIDIbox SID, see also his website for additional informations and sound samples: http://home.earthlink.net/~erinys/tech.htm

Another idea: PIC16F88 and PIC18F4620 are cheaper in the US than in Europe, and SmashTV offers them preburned with the appr. firmwares. So, a group order could be organized from a single person in Europe, who would receive the stuff from SmashTV and distribute it to the others. This shouldn't be understood as a competition between Mike and SmashTV. In fact I already asked Mike if he would be interested in such a possibility, but he prefers to buy the parts from a shop which is close to where he lives - especially the PIC18F4620 is more expensive in this shop, therefore I think that an alternative solution should be provided for people who want to save money. Maybe somebody could ask Mike again if he in interested to distribute parts from SmashTV to make clear, that this is not only my private wish. In my eyes he is the ideal person for such group buys, but if he is still not interested, somebody else has to take care about this. Best Regards, Thorsten.

This is the second MBSID that dcer10 has built - this time the full stuffed version in a 19" rack case. I'm always impressed, how good all these variants are looking! :) More pictures can be found in the blog http://www.midibox.org/forum/index.php?topic=8033.0 and on his website: http://www.dcerecords.dnsalias.com

Problem is, that Microchip hasn't fixed the bug in the new chip revision as expected. The errata sheet is incomplete, Microchip has been informed about the mistake, but an update is not available yet. So - the EUSART bug still exists, and the MBHP_IIC_MIDI workaround is still required. In germany the cheapest source for PIC18F4620 is farnell.de For the PIC16F88 Reichelt is cheaper. Note that both chips need to be programmed. The PIC18F4620 requires a special variant of the MIOS bootloader, and the PIC16F88 has it's own MBHP_IIC_MIDI firmware. If you don't find somebody who can "burn" the firmware into the chips, I would do this for free Maybe somebody could start a community order? Because these chips will be interesting for MBSID V2 users as well in future. Best Regards, Thorsten.

Hi, yes, the .pdf is the reference, in the .brd file the wrong part numbers were used Best Regards, Thorsten.

I haven't started to write any line of code for MBSID V2 yet, the whole schedule is shifted due to various reasons, and a first public beta cannot be expected before summer next year. All PICs should be 4620 Best Regards, Thorsten.

I just have added a link to a new page (MIDIbox SID V1 User Manual) here: http://www.midibox.org/dokuwiki/doku.php?id=midibox_sid Just login with your forum account, go to this page and press the edit button in order to enter the text. Formatting is described here: http://www.midibox.org/dokuwiki/doku.php?id=syntax If getting a proper layout is too difficult, just let it like it is (only enter text), and somebody else can take care about this It's really easy - like posting in the forum. Best Regards, Thorsten.

Yes, an extra resistor is not required Best Regards, Thorsten.

Sysexbox is an unsupported application. If it doesn't work on your PC, just use MIDI-Ox Best Regards, Thorsten.

Hi, the only explanation for this effect is, that the 1k pull-up R2 of the core module is not connected to the PIC Best Regards, Thorsten.

Hi, thats really a good starting point, I like the idea! Could you please bring this into the Wiki? It would allow me and the others to replace the question marks by some informations w/o much effort, and the document would always be up-to-date! :) A second one for MBSID V2 could be created later based on the manual of V1 Best Regards, Thorsten.

Der Thorsten Klose hat momentan leider nur sehr wenig Zeit, eine hoehere Prioritaet haetten zumindest die anderen Leute, die schon seit Wochen auf eine Antwort von ihm warten :-( Ich verstehe nicht ganz, warum es ein Merger sein muss. Du schreibst, dass die beiden MIDI Outs exakt die gleichen MIDI Daten ausgeben. Es wuerde also keinen Unterschied machen, ob die Events nun von einem Merger zusammengefuegt werden, oder ob sie einfach von einem einzigen MIDI Out dupliziert werden, richtig? Dann saehe die Loesung naemlich ganz einfach aus - nimm einfach das C Skeleton, und setze folgendes in den MPROC_NotifyReceivedEvnt() Hook: void MPROC_NotifyReceivedEvnt( unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { switch( evnt0 & 0xf0 ) { case 0x80: // Note-Off: 3 bytes case 0x90: // Note-On: 3 bytes case 0xa0: // Aftertouch: 3 bytes case 0xb0: // CC: 3 bytes case 0xe0: // Pitchbend: 3 bytes MIOS_MIDI_TxBufferPut(evnt0); MIOS_MIDI_TxBufferPut(evnt1); MIOS_MIDI_TxBufferPut(evnt2); // if channel 0 or 1 - send again via channel 14 and 15 if( (evnt0 & 0x0f) == 0 || (event0 & 0x0f) == 1 ) { MIOS_MIDI_TxBufferPut(evnt0 + 14); // send again with channel offset 14 MIOS_MIDI_TxBufferPut(evnt1); MIOS_MIDI_TxBufferPut(evnt2); } break; case 0xc0: // Program Change: 2 bytes case 0xd0: // Poly Aftertouch: 2 bytes MIOS_MIDI_TxBufferPut(evnt0); MIOS_MIDI_TxBufferPut(evnt1); // if channel 0 or 1 - send again via channel 14 and 15 if( (evnt0 & 0x0f) == 0 || (event0 & 0x0f) == 1 ) { MIOS_MIDI_TxBufferPut(evnt0 + 14); // send again with channel offset 14 MIOS_MIDI_TxBufferPut(evnt1); } break; default: // note: status messages must be handled within MPROC_NotifyReceivedByte() break; } } } [/code] Was passiert hier: je nach MIDI Event Typ werden entweder zwei oder drei Byte weitergeleitet. Wenn das MIDI Event auf Kanal 0 oder 1 (wir zaehlen ab 0) empfangen wird, wird es zweimal weitergeleitet. Einmal auf dem urspruenglichen Kanal, und einmal auf Kanal +14 Das ganze laeuft dann auf einem normalen Core Modul ohne zweiten MIDI In Gruss, Thorsten.

Zum Thema Uebersetzungen habe ich im obigen Artikel ein paar Hinweise hinzugefuegt: http://www.midibox.org/forum/index.php?topic=4183.msg27127#msg27127 Gruss, Thorsten.

No, this isn't a bug - the details how it is working is described in the ChangeLog. For easy usage just press "Copy Preset" within the event menu, this deselects Trigger Layer A, so that Note Layer A/B/C can be gated seperately. Roll and Accent cannot be controlled seperately, but this is really sufficiently described in the ChangeLog, this is the only documentation source so long no user manual is available Best Regards, Thorsten. P.S.: merged with MBSEQ3 talk, where you can discuss such issues

MIDIbox controllers are going to get attractive for artists :) Sasa wrote:

Das Gehaeuse ist nach einer Woche bei mir angekommen, es macht einen stabilen Eindruck, und was fuer mich wichtig ist: an der Front ist nach oben/unten hin genuegend Platz fuer ein LCD Ob sich die Rueckseite gut bohren laesst, wird sich dann demnaechst zeigen. Mir persoenlich ist die U-Form ganz recht, ich habe naemlich auch keine Werkstatt, vor allem keinen Schraubstock, kann das Gehaeuse nun aber (im zusammengebauten Zustand) beim Bohren mit den Knien festhalten ;-) Gruss, Thorsten.

Please upload the code again with the latest MIOS Studio version tomorrow, just to ensure that it is complete - would be bad, if you miss one of the new features :) Best Regards, Thorsten.

Hi, I would propose to play a little with the JSynthLib based editor, it gives you a good impression about all the parameters, and you can already control your MBFM w/o any control surface in order to play with the parameters. I think that I don't need to answer here, since my workflow is described in the user manual :) Best Regards, Thorsten.

Hi Matteo, just use the latest MIOS Studio release, it got an update especially for PIC18F4620 which is required when uploading code beyond 0x8000 Best Regards, Thorsten.

Thanks! I changed this in seq_scale.inc, a new build will be available soon Best Regards, Thorsten.

With the current snapshot it's already possible to assign 8 BankSticks to different functions. 64k EEPROMs (24LC512) are stongly recommented, but 32k types are also working. One is used for Song Mode, another for Mixer maps, the others can be used as pattern storage. The configuration has to be done in setup_mbseq_v3.asm, here the default mapping: ; BankStick Mode & Allocation Map ; Each BankStick (CS0..CS7) has an own entry ; Set the value to: ; 0: ignore BankStick which could be (or is) connected to the CS address ; 1: if a 32k BankStick (24LC256) is connected and should be used as Pattern Storage (64 patterns) ; 2: if a 64k BankStick (24LC512) is connected and should be used as Pattern Storage (128 patterns) ; 3: if a 32k or 64k BankStick is connected and should be used as Song Storage ; only the first 32k are used, so there is no advantage on using a 24LC512 here. ; 5: if a 32k or 64k BankStick is connected and should be used as Mixer Map Storage ; only the first 32k are used, so there is no advantage on using a 24LC512 here. ; NOTE: only one BankStick can be used as Song Storage, only one for Mixer Maps ; If no entry with "mode 3" is defined, Song mode will be disabled. ; If no entry with "mode 5" is defined, there will only be one Mixer Map which cannot be stored ; If a BankStick is not connected to the MBSEQ, the appr. entry will have no effect #define DEFAULT_BANKSTICK_MODE_CS0 1 ; 32k #define DEFAULT_BANKSTICK_MODE_CS1 1 ; 32k #define DEFAULT_BANKSTICK_MODE_CS2 5 ; Mixer Map (using CS2 to ensure compatibility with Atmel EEPROMs which only provide 4 CS addresses) #define DEFAULT_BANKSTICK_MODE_CS3 3 ; Song mode (using CS3 to ensure compatibility with Atmel EEPROMs which only provide 4 CS addresses) #define DEFAULT_BANKSTICK_MODE_CS4 1 ; 32k #define DEFAULT_BANKSTICK_MODE_CS5 1 ; 32k #define DEFAULT_BANKSTICK_MODE_CS6 1 ; 32k #define DEFAULT_BANKSTICK_MODE_CS7 1 ; 32k [/code] Best Regards, Thorsten.