TK.

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]

The conclusion is: if you want to generate PWM with a satisfying resolution, you need additional hardware components which are doing this job. And these components can be easily controlled from the PIC. It's a similar approach you already know from Monome. It uses a MAX7221 to control a 8x8 LED matrix. This unloads the CPU, and it saves you from adding LED drivers. There are also chips which allow you to control LEDs with PWM instead. Sorry, that I cannot give you more details, because I haven't worked on such topics yet (and I'm not planning to do this) - but it would be great if some people could just colaborate together here. The implementation is very straightforward at the software side, and at the hardware side you only need to find chips which are available in low quantities (without ordering >= 1000 pieces) Best Regards, Thorsten.

End of setup_mbfm_v1.asm Best Regards, Thorsten. P.S.: README.txt of the current MBFM release is confusing, it contains some artifacts from the previous "flat" project structure - sorry about that! I already corrected this in the development version.

Why do I have this deja vu two times today? -> http://www.midibox.org/forum/index.php/topic,10911.0.html Best Regards, Thorsten.

Cool! Thank you! :) Best Regards, Thorsten.

See this answer, and the discussion below Best Regards, Thorsten.

PIC18F452 is only a subset, PIC18F4620 is compatible, but provides more flash, more RAM, and more bugs ;) Means: you are able to run programs compiled for PIC18F452 on a PIC18F4620 without changes. With the upcoming project setup (which is still not completely documented), it will be much easier to change the processor type. See apps/examples/ain64_din128_dout128_v2_0, how clear an application does look meanwhile :) So, in order to change the processor, you would only need to change the PROCESSOR variable, and pic18f452.o file in the Makefile - thats all. E.g., the register file of the processor is not included directly into main.c anymore, instead we are using <pic18fregs.h>, which internally selects the register file depending on the PROCESSOR argument, which has been predefined in the Makefile Also the Linker File will be selected automatically, so that you don't need to take care about this :) Best Regards, Thorsten.

I would say, it's impossible with the MBFM firmware for various reasons. But you could easily use a second microcontroller which handles the triggers and analog inputs, and which communicates with MBFM via MIDI. Maybe this will cost you 10 EUR more, but assumed that you are using a premade project like EDrum or Megadrum, you will get a perfectly working solution and don't need to develop new software. Best Regards, Thorsten.

You know, we have multiple sequencers, multiple engines, multiple possibilities to control the volume concurrently to velocity. Your question "what I've forgotten to setup" doesn't really make it easy for somebody to understand, what could be wrong ;) Please read the RIOFAQMARKER again: If you don't remember the details anymore, why not attaching the patch (in .syx format) to this posting, so that somebody could try it on his own hardware? Best Regards, Thorsten.

See MBSID firmware, USER_Init hook how to enable PWM (in this firmware it's used to provide the 1 MHz SID clock). For 38 KHz clock, you want to use the same configuration as shown in the Basic Code example. Transmitting informations at 1kbaud should be easy, because you could control the NAND from USER_SR_Service_Prepare or USER_SR_Service_Finish. These hooks are called each mS Using different baudrates is impossible, because all other timer sources are already allocated by the firmware. Best Regards, Thorsten.

Mode 5 should do this. You wrote, that you built MBSEQ V3 long time ago, but are you also using the latest firmware? Meanwhile the usage of mode 5 is more comfortable than before. Previously you had to configure the trigger layers correctly to get it working. Meanwhile you only need to push the GP button below "copy preset" in the event configuration page (where you already select the mode) :) Thats an unexpected usecase (I'm a big fan of unsynched changes), but no problem: just added this option. The change is already available on the SVN server (seq_song.inc), but unfortunately, the flow how to fetch such immediate versions isn't documented yet. So, if you are not familar with subversion, try to copy the cs_m_song.inc into the latest release If this doesn't work due to incompatibilities (I haven't tested it), open seq_song.inc of the original release, search for "call SEQ_CORE_ChangePattern_Song" and replace this line by: ;; in phrase mode (bit #7 set): allow synched pattern change BRA_IFCLR SEQ_SONG, 7, BANKED, SEQ_SONG_FetchPosLoop_Song SEQ_SONG_FetchPosLoop_Phrase call SEQ_CORE_ChangePatternSynched rgoto SEQ_SONG_FetchPosLoop_PhraseCont SEQ_SONG_FetchPosLoop_Song call SEQ_CORE_ChangePattern_Song ; change pattern SEQ_SONG_FetchPosLoop_PhraseCont [/code] Best Regards, Thorsten.