TK.

thanks! I knew how you mean your article, and just wanted to highlight again for people who propably join the discussion and don't know the background, that there are huge differences between programming 8bit controllers (which are mainly constructed to save costs and therefore come with many restrictions) and 32bit controllers (which mostly provide much better peripheral functions, and in addition allow to apply state-of-the-art programming concepts) yes, thats the most comfortable way to go for PICs which are connected to a PC anyhow (this wouldn't be the case for MBSEQ or MBSID/MBFM...). Best Regards, Thorsten.

Hi Didier, I fear that I won't have enough time to discuss this topic intensively enough. Since you have some fresh ideas how to improve MBNet, I would recomment that you start to work out an alternative protocol in order to prove that it is working sufficiently enough to meet all requirements. MBNet was mainly tailored for interconnecting MIDIbox SID V2 cores with the limited features of the integrated ECAN peripheral of PIC18F4685. Therefore the restrictions were driven by free resources (under resources I understand flash, RAM, CPU load and peripheral features) and special requirements of this synth application. I'm sure that there are better CAN based solutions possible, e.g. for MIDI controllers - like OSC/ACN as you proposed by you in this article http://www.midibox.org/forum/index.php?topic=9376.msg67121#msg67121 But I'm also sure, that a synth which is running on a 8bit controller would never be able to support all features. And I'm also sure that you would never achieve the same performance and robustness. As mentioned above: it was tailored around an existing application. And this application is one of the most complex one I ever implemented. Best Regards, Thorsten.

This topic has been moved to Miscellaneous. [iurl]http://www.midibox.org/forum/index.php?topic=9564.0[/iurl]

There are some simple tests which allow you to check, if the problem is related to the DIN module connections. Details are described here: http://www.midibox.org/dokuwiki/doku.php?id=din_module Best Regards, Thorsten.

SEQ_BLM_ROW_CTR has already been incremented in SEQ_LED_UpdateIRQ, SEQ_BUTTON_GetRowIRQ uses the same counter. It's dirty code - I wanted to save one variable and never assumed that somebody really wants to work with these low-level functions... Best Regards, Thorsten.

DETENTED3 mode fixed ultra's issue (see http://www.midibox.org/forum/index.php?topic=9695.0) Martin: what about yours? Best Regards, Thorsten.

Renaming existing PCB version numbers would add even more confusion. Especially for people who are reading old articles in the forum. Best Regards, Thorsten.

Thanks for the page Using a #define is not the right approach, as it will conflict with the appr. definition in the next MIOS release. Once this release is available, you only need to copy the migration/mios.h file into the application directory, so that the constant definition is available. For the latest MBSID V2 beta release, this has already been done. Thats the reason why I suggested you to write 0x82 instead of using a define, as the change will be compatible with next releases So - please update the snapshot once the complete mios release is available, or already "fake" it by copying the mios.h of the latest MBSID V2 beta release into the application directory. Best Regards, Thorsten.

You could try the brand new "DETENTED3" mode, it could help (e.g. at least for the issue, that values are changing when encoder is wiggled around). See http://www.midibox.org/forum/index.php?topic=9672.msg70488#msg70488 As for MBSEQ V3 no new release with the DETENTED3 define is available yet, write 0x82 instead Best Regards, Thorsten.

Hi Enrico, if you've luck it will help, but I fear that your problem is more based on the quality of your encoders. Unfortunately such "cheap" encoders are widely used today. E.g., the volume knob of my Dell computer keyboard has exactly the same problem. Sooner or later I will open the keyboard and replace the encoder, because it could be a nice control element for Logic. :) Best Regards, Thorsten.

Hi Robert, I don't have much experiences in this area, but synchronizing the PWM oscillators from a global clock sounds like a good plan and will propably already solve the problem. You could use J7:SO (PIC pin #17) as a clock output, it can be driven from the PWM peripheral (don't mix with the PWM oscillators), accordingly the frequency can be easily controlled. Here an example for a 1 MHz clock: ;; Initialize Clock Generator (the PWM unit is used to generate a 1MHz c lock with 1:1 duty cycle) movlw 0x09 movwf PR2 movlw 0x24 movwf T2CON movlw 0x0f movwf CCP1CON movlw 0x04 movwf CCPR1L [/code] It isn't possible to synchronize the PICs this way, as they are running with an internal PLL which quadruples the clock (-> jitter). Also the reset (pin #1) is asynchronous, and the firmware doesn't always execute the same code. A software-wise synchronisation could cure the problem a little. E.g., the firmware could reset timer1 whenever a special MIDI event has been received. You could use MIDI event "0xff" for such a purpose, it could be checked within the USER_MIDI_NotifyRx hook, which is triggered at interrupt level and therefore guarantees best response time. If the MIDI In ports of the two cores are connected together (in parallel), your MIDI host software needs to send such an event. If the cores are chained, you could do it the same way (merger forwards the sync event, this causes an additional but compensatable delay). Alternatively the first core could send the sync event e.g. one second after startup to the second core (requires some additional firmware changes). This procedure has to be repeated periodically (maybe once each hour) depending on the clock drift between the two cores. Best Regards, Thorsten.

Hier der Link zu einer Pre-Release; der AIN Handler funktioniert nun auch mit dem PIC18F4685: http://www.ucapps.de/tmp/mios_update_v1_9f_pre1.zip Gruss, Thorsten.

Ok, so here is a pre-release of MIOS V1.9f which provides the new "detented3" mode: http://www.ucapps.de/tmp/mios_update_v1_9f_pre1.zip In difference to "detented2", values are incremented "during the click", and not "after the click" (when you try it out, you will see what I mean). It seems that this works better with Bourns encoders. The mode has to be selected in the encoder table (replace MIOS_ENC_MODE_DETENTED2 by MIOS_ENC_MODE_DETENTED3 in your setup_*.asm file) Thereafter rebuild the .hex file like described here: http://www.ucapps.de/howto_tools_mpasm.html Here a link to beta6, which contains the new MIOS_ENC_MODE_DETENTED3 definition: http://www.midibox.org/forum/index.php?topic=9457.0 Best Regards, Thorsten.

I've tested the bourns encoder today, and can reproduce the effects - I'm currently thinking about a proper solution (there is hope) Best Regards, Thorsten.

I remember, that last time a user reported such an issue, he used an older MIOS Studio version which doesn't upload the complete application. So, please make sure that you are using MIOS Studio v7.5 or later. IIC_MIDI, shown LED polarity in PCB overview pic: will be fixed soon Best Regards, Thorsten.

Today Seppoman visited me, and we tested the AOUT_NG module with MIDIbox SID V2. It works great! (what else would you expect? ;-) But the bad news: the serial protocol of TLV5630 doesn't match exactly with the protocol used by 74HC595 (data is latched with different clock edges). In addition, the TLV5630 only accepts 16bit frames, which makes it difficult to chain multiple AOUT_NG modules. After a long discussion we decided to remove the 74HC595 from the AOUT_NG module. The gates have to realized with a common DOUT module, which will be accessed by the driver by sharing some AOUT pins, and using a dedicated RCLK pin. Alternatively a DOUT register of the common DOUT chain can be used And alternatively, some MIDIbox applications like MBSEQ and MBCV provide gates via port J5 of the core module So, this drawback isn't really a "killer"... Sorry for the inconvenience, but I think that you will be able to life with this limitation. Best Regards, Thorsten.

Rio has implemented a decent control unit for Audiocommander's SpeakJet application: More informations can be found here: http://www.midibox.org/dokuwiki/doku.php?id=midibox_speakjet_k64_modul Btw.: did anybody read the comment the german "Synthesizer-Magazin", Issue 3/07, last paragraph of the "Flame Talking Synth" article, Page 25: "Fuer Bastler aller Art duerfte zusaetzlich der Speakjet-Chip selbst ein interessantes Stueck Technik darstellen, und so moechte ich mit der Wette schliessen, dass es nicht lange dauern wird, bis die ersten DIY-Instrumente mit Speakjet-Chip das Licht der Welt erblicken." Rough translation: "the SpeakJet chip is an interesting chip for DIYers, I bet that it doesn't take so long until the first DIY instruments will see the light of day" The name (Henning Schonvogel) didn't know, that Lorin was one of the first guys who developed a DIY synth with SpeakJet ca. 3 years ago (see http://www.midibox.org/forum/index.php?topic=2870.msg24839#msg24839), and that Audiocommander's project exists since more than one year... Rio's enhancements are the next step, and who knows what comes next... So, if you want to win a bet, just try to find out his address and drop him a mail ;-) Best Regards, Thorsten.

this remembers me, that I wanted to check the bourns encoders by myself (SmashTV sent me some parts time ago, but I haven't found the time to build a test board yet) - maybe there is a way to optimized the driver for these encoders (-> DETENTED3) Best Regards, Thorsten.

Thank you! :) I must say, that I'm glad that you made such a good progress with building the hardware. To be honest: after your first postings I assumed that you will give up frustrated very early, since the whole synth DIY topic is so new to you. But now - two months later - your box is almost running, and you are helping newbies as well (on your way!) - thats really great! :) Best Regards, Thorsten.

Hallo, ja, das ist richtig so. Aus softwaretechnischen Gruenden steuert Bit 0 Pin D7 and, Bit 1 Pin D6, Bit 2 Pin D5, ... Bit 7 Pin D0 an. Dieser "Dreher" gilt nur fuer die DOUT Register. Gruss, Thorsten.

Smile! :-) Great work! Best Regards, Thorsten.

Hi Gusto, yes, all 16 tracks can be edited directly. yes - this is the reason why MBSEQ V3 requires a PIC18F4620, which contains enough RAM for loading all patterns into the PIC. Best Regards, Thorsten.

If you are using the Bourns PEC11 encoders from SmashTV (same for voti encoders), you don't need to change the encoder settings in setup_*.asm - they are already configured for the DETENTED2 type. But check the pinning - there are three possibilities, two lead to a wrong behaviour (yes, one error effect is, that values are decremented and/or jumping). So, if the pinout description in the wiki doesn't help, just try the three possibiities until it works :) Best Regards, Thorsten.

The two core x 4 SID solution would fit perfectly. 6 voice polyphony can be realized with the multi engine. The audio channels of the two SIDs have to be merged (e.g. with a small mixer) to get a mono signal. Best Regards, Thorsten.

No, this isn't normal. P18 detects the burner by toggling the DATA OUT signal, and checking if the same value can be read at the DATA IN pin of the parallel port (see schematic). This wouldn't work, if IC4 or R9 are not soldered correctly, or if there is a missing connection between these components. It also makes sense to check the Vss/Vdd voltage on IC4 Best Regards, Thorsten.